On Nov 15, 2007, at 12:50 AM, Hector Santos wrote:
Dave Crocker wrote:
John,
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:
4.5.4.1 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
non-delivery.
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.
-Doug