On May 12 Matthew Byng-Maddick wrote:
>On Tue, May 11, 2004 at 04:23:52PM -0700, Tor Slettnes wrote:
>> 20s at the MAIL FROM: command, 20s at RCPT TO:, and 20s after DATA,
> ^^^^^^^^^^^^^^^^^^^
>You shouldn't do this. It has no useful effect, (because they've already
>sent the mail), and might potentially cause duplicate mail.
No no no Mr RFC.. Delays after DATA are working just fine on our mailer.
Yes there is a chance of duplicate mail iff the client MTA doesn't follow
RFC2821. 20s is well under 10m, and all MTAs ought to be well-connected.
However, in practice it cuts large volumes of spam on our relay, so even
if it's not the most polite thing you can do[1], it is what makes my users
happiest. Our delays have cut spam by over 90% and are saving lots of our
staff and students some time every day. All this in return for going
against the grain of an ancient RFC written before spam existed..
Sometimes content examination alone flags things as spam, so you can't
delay before DATA for machines which haven't been blacklisted/odd
HELOs/blacklisted return-paths/etc.. yet.
If RFCs are sacred, let's get this one changed! Remember when Bill Gates
came up with the revolutionary idea of making spamming harder by making
the client MTA do some work?
http://news.bbc.co.uk/1/hi/business/3426367.stm
Delays in the SMTP conversation are a rather similar principle, but using
existing technology (so he can't make any money out of that particular
proposed bastardisation!). Spammers (or their compromised MTAs) have a
limited number of TCP ports and processes, and for as long as spam relies
on being able to inject an unusually large number of messages in an
unusually short time, these delays are a wonderful tactic.
[1] like your MTA sending "[irritated]" to mine.. :-P
