[Top] [All Lists]

Re: Fixing graylisting [was TBR]

2007-11-15 11:26:52

On Nov 15, 2007, at 12:50 AM, Hector Santos wrote:

Dave Crocker wrote:

Although only a near-term, tactical benefit, greylisting directly impacts mail from bad actors. It's serious downside is that it also impacts first-time mail from good actors.

Which can be minimized, to a near "unfelt" impact by simple fine tunning of SMTP router/sender frequency tables, in particular the 2nd attempt.

RFC-2821 currently recommends/states: Sending Strategy


  The sender MUST delay retrying a particular destination after one
  attempt has failed.  In general, the retry interval SHOULD be at
least 30 minutes; however, more sophisticated and variable strategies
  will be beneficial when the SMTP client can determine the reason for

The insights were laid out for variable (time/retry) strategies, making it possible for Greylisting to work with minimal to no significant impact.

Bulk emailers are often anxious to complete their campaigns and are dubious about retry delays of 30 minutes. The initial benefit of grey- listing was as a test for whether a transmitting MTA carried state since many bots did not. This is changing where now many bots retry the same message. The benefits from grey-listing are fading, while bulk emailers have become more aggressive in their retries.

I was really skeptical of GL, but when it was implemented right with proper fine tuning of SMTP to minimize impact, it is really one of those Ronco's "Set it and Forget it" ideas. :-)

Perhaps "Set it and regret it" might be the ultimate outcome when bulk emailers become even more aggressive as a result.

My recommendation for 2821bis is to include some insights about or how "variable strategies" plays a bigger roles these days and in fact, might be almost an "necessity" for improved modern operations these days - thats dealing with the realities we have out there. Even if I didn't want to incorporate GL into our own system, the sending retry strategies had to be reconsidered due to increased remote GL systems.

I agree. The TBR Extension should satisfy the desires of bulk emailers, while also providing an absolutely essential mechanism needed to protect exhaustive content filtering, the Temp error. The EHLO parameter and TBR Temp error offers a valuable alternative to "Go away and retry later."

The TBR extension can:

1) without burdening the receiver

 a- provide a valid identity of origination

 b- eliminate back-scatter

2) conserve limited content assessment resources

3) improve delivery integrity

4) eliminate bulk emailer's aggressive reties

5) protect valid email-address confidentiality

6) defer and enhance assessments of questionable messages

7) avoid the DATA phase for abusive sources

8) avoid unintended DDoS effects

While DKIM offers a good mechanism to minimize false positives in anti- phishing filters, as with any content filtering, resources used must be protected. To be effective, anti-phishing must examine message content for deceptive appearance. Deceptive appearances are not something the IETF can hope to eliminate with signatures or path registration alone. An anti-malware and anti-phishing effort requires the availability of resources needed for detailed analysis. The TBR Extension offers receivers the means to request transmitters assist in this vital effort.