Re: [Exim] spam delay trick and smtp_accept_count patch.

On Mon, 2 Feb 2004, Alan J. Flavell wrote:

| On Mon, 2 Feb 2004, Giuliano Gavazzi wrote:
|
| > let me take this slightly off subject.. Inspired by this idea I am
| > now delaying for each message that scores points at our server,
| > unless of course the score is over the upper limit (10 usually) in
| > which case it is rejected with no delay.
|
| This sounds as if you are inserting a delay at the DATA stage of the
| SMTP transaction. I'd have to say that's not a good idea, and the
| RFCs also say that one should minimise the delays during the DATA
| stage in order to avoid various kinds of unpleasantness such as
| duplicate deliveries.

Yup. And I don't quite see what delaying the final confirmation will
achieve, apart from a tiny bit of teergrubing (possibly). You still end
up processing the message as normal when the delay expires.

Whereas with earlier delays, if the sender goes away, there is no message
to process, and you've got rid of a spam!


| We used to experience problems of sending MTAs retrying if we gave
| them 5xx at end of data, but that problem seems to have been more or
| less resolved now. If we ever did see such problems again, then the
| cure is to blacklist them for rejection at an earlier stage, i.e most
| likely the RCPT stage.

Had one today - the first for some time now. It resent continually, a
coule of times per second, despite being told to "5xx off" after DATA.
So we blacklisted the IP to give 5xx at RCPT time. And it *still* kept
trying, a couple of times per second, for several hours. Duh!

FWIW the thing answered on port 25 revealing a piece of commercial junk
called "Internet Anywhere Mail Server" which ISTR has done this before.

--
Chris Edwards, Glasgow University Computing Service