On Thu, May 13, 2004 at 09:57:03AM +0100, Matt Bernstein wrote:
> 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.
Really?
> 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
How? After it's sent final dot, you're either going to accept or reject the
message. If it's a spammer, it doesn't care very much, because they're not
going to retry if it fails, but if they sense they're being delayed, they'll
just drop the connection and move onto the next host/address in their list.
If they do that, you've achieved nothing, because you've already processed
the message, and possibly are about to send a 250 and queue-id. The above,
obviously, also applies to viruses. If, on the other hand it's a real person,
then they'll act sensibly on whatever status code you give them, and so
550-ing the message is the most sensible thing you can do if you don't want
it.
> 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
Other delays will do that, I agree. I'm seeing similar orders on our
front-facing MX at work. That's why I specifically highlit the DATA
delays.
> staff and students some time every day. All this in return for going
> against the grain of an ancient RFC written before spam existed..
It's not so much that it's going against the grain of the RFC, it's that
I fail to see what it gains you (the one thing that you could argue is
a gain is that it prevents the spammer's/virus's connection from going
and trying to send their spew to someone else) if the connection drops
at that point.
> 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.
Agreed. Though that doesn't help you. You're going to be 550ing the message
anyway, and if you're not, then a connection drop after final dot should not
stop the message being processed.
> [1] like your MTA sending "[irritated]" to mine.. :-P
Well, that's just an indication of the delay strategy status. Full codes
range from "Ecstatic", "Pleased", "Irritated", "Angry" to "Incandescent
with rage". In ecstatic and pleased, there will pretty much be no delays,
in "Irritated", delays to negative responses, in "Angry", delays to both,
and possibly some stall lines, and in "Incandescent with rage", it might
choose to divert you to the stalling system, which takes half an hour to
give you a full 421 response (gives multiline one line at a time).
Of course, you don't have to read all your mail logs. ;-)
MBM
--
Matthew Byng-Maddick <mbm@???> http://colondot.net/
(Please use this address to reply)
