Re: [Exim] FW: Defending Against Rumplestiltskin Attacks???

At 10:17 +0100 Matthew Byng-Maddick wrote:

> On Thu, May 13, 2004 at 09:57:03AM +0100, Matt Bernstein wrote:
>> No no no Mr RFC.. Delays after DATA are working just fine on our mailer.
>
> Really?

Yes. 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 they've dropped the connection before you can issue 250, then you
haven't accepted it yet.

This is what we would do--spam would end up in our users'
"P{roba,ossi}bly-Spam" folders were it accepted.

Our users complain even when there's too much spam in such folders..

>> 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.

..unless your MTA notices before issuing 250 :)