ietf-smtp
[Top] [All Lists]

Re: new draft: draft-santos-smtpgrey-01

2011-10-27 15:19:17

Paul Smith wrote:

On 26/10/2011 16:22, John C Klensin wrote:
Independent of what advantages it offers people who are trying to cooperate in sending legitimate mail, to paraphrase Paul Vixie, giving spammers the information they need to become smarter and the incentives to do so are really not in our long-term best interests.

The reason why I don't think this is an issue, is that spammers already have the information they need to get around greylisting.

Right, the 4yz retry code.

The 'retry=<time>' data won't give them any information they need to be able to get their messages through. However, the fact is that, for now at least, many are not doing anything about countering greylisting. When they do decide to do something about it, the 'retry=<time>' data won't be vital to them, or even make their job significantly easier.

+1.  There is basically two categories of senders GL addresses:

1) Primarily those that will never retry for whatever reason that may be. They just don't. However, one can reasonable suggest Spamming a low margin, high volume market business and success is measured in low acceptance rates such as 1% or even less. So randomly blasting 1 million harvested email addresses and getting 1% (10,000) is often deemed successful in this market. I still see 1990's address for our usage base when we offered Free accounts to customers. We also see many CIS (CompuServe) email addresses still being tried. And a huge amount try obscure variations user-ids in addresses.

2) Secondary are those that do retry, but they retry again maybe twice more immediately and often using a different IP. Even with a low GL blocking time such as ours with 55 seconds, I see these getting blocked again and stop after the 2 to 3 fast retries.

With #2, it is also apparent many that do have fast retry will back off and retry later and GL can not stop any client that retries after the blocking time.

But it is #1 which is by far the major benefit of using an intentional 4yz temporary rejection methodology for mail filtering anonymous senders.

Having said that, I'd prefer the 'retry=<time>' extension to be generic, and not linked to greylisting, except by coincidence.

The problem with going generic will depend on what we mean by "Generic" and how broad we want that to be.

Ideally, in my technical opinion, from a pure mechanical client/server state machine protocol framework, it can be a very simple generic SMTP concept or generic SMTP extension to the 4yz response. We could called it:

      SMTP Extension for Handling 4yz Temporary Rejections

The abstract may say:

      SMTPRETRY is SMTP extension to provide retry time delay
      information in negative temporary rejections 4yz responses
      to help address issues related to wasted attempts and
      delayed mail delivery.

With a very simple implementation description with no subjective background reasoning for why the SMTP 4yz exist in the standard or why servers use it, it can simple define:

      A server MAY add a retry=time-delay in in 4yz responses and
      clients MAY leverage the server time hint in the client
      retry framework employed in their implementation of SMTP.

So this would be simple generic idea for extending the SMTP 4yx description.

But if we begin to talk above and beyond that with SMTP Traffic Control and Management ideas then IMO, it gets more complex and begins to introduce a whole range of things that is not closer to modifying SMTP protocol and definitely will require more code changes to implement the more elaborate proposal. What will happen IMV is that people will pick and choose what they need and chances are good it will be for "Greylisting" reasons systems are facing today.

SMTPGREY tries to keep a real focus to realistically deliver this extension with specific existing practical purposes and things that we can measure today. It is not experimental or a BCP although documenting the basic GL framework does lends itself to making some "suggestions." I approached that by simply indicating to keep delays as low as possible in the name of keeping with timely deliveries and lowering the impact of intention temporary rejections. I provided some empirical average values for blocking times. But overall, the extension is not intended to change the standard SMTP protocol, the pseudo-standard GL "protocol" and begin to mandate any idea that intends to change how systems concurrently behave. Its an extension and by its definition, its all optional and does not alter anything but to allow a server to tell a client how to handle a 4yz response in terms of "Time."

--
Sincerely

Hector Santos
http://www.santronics.com