On Mon, 2 Feb 2004, Martin Evans wrote:
> An anti-spam trick was suggested to me a few weeks ago by a colleague in
> our university. The idea is that we add longish delays into the smtp
> conversation if we suspect that the sender is a spammer.
[...]
I've got something resembling what you describe, though it's only
attempted after checking whether we want to reject the sender/IP
combination outright.
Because there will have been variable delays during DNSRBL lookups
etc in the ACL, I decided to try to compensate for that: I read the
timestamp at the very start of the ACL:
warn set acl_m2 = $tod_epoch
and then, when I decide that I'm going to try the timeout trick, I
compute the residual time
set acl_m2 = ${eval:XX+$acl_m2-$tod_epoch}
where XX is the desired delay in seconds. If the result is positive,
then the delay is started. Usually the adjustment, compared to the
fixed delay, is only a couple of seconds, but occasionally the
adjustment is as much as 10-20 seconds.
If folks all were to use the same delay, then the abusers would just
need to set their timeouts slightly larger. But suffice it to say
that the delay we're currently using is larger than 60s, but less than
99s - but if the abusers start setting their timers to 100s, that's no
problem, we can deal with that!
There are various criteria for our ACL to try applying this timeout -
basically it's used if the call is suspicious, but not sufficiently so
as to cause outright rejection. Criteria are such as:
- unqualified HELO
- HELO is one from a common list of fraudulent HELOs (such as
hotmail.com, compuserve.com, msn.com, yahoo.co.uk...) that doesn't
jive with the calling IP's PTR
- calling host name contains the substring dsl or dial(up|in|-|\.)
Last time I evaluated the efficacy of this feature, it looked as if
only about 1 in 3 of the transactions where the delay was used were
actually convinced by it to go away. So, it's not without its use,
but a bit disappointing.
However, looking at the results now, they're quite a lot better. On a
rough estimate, out of 2,500 delays issued last week, about 1,800 of
them went away. And in the time since the log was rotated, 360 out of
550 went away. I suspect this increased efficacy is because of the
high rate of viruses we're currently being offered.
Those viruses would be rejected in due course (in the DATA ACL), but
not without quite a lot of extra CPU. This way, it seems they (I
mean, those which match the critera for this measure being applied to
them) are going away voluntarily, at an earlier stage. Which is nice.
> My colleague has reported that this trick is successful at reducing the
> amount of spam he sees being delivered into his department.
>
> However, I am concerned that my process tables will fill up with RBL'ed
> hosts connecting to my server and filling up my (smtp_accept_max)
> connections.
We seem to get reasonable results from a per-host max [1]. But I must
admit we're not a very heavily loaded system. Maybe the central
postmaster (hi Chris) would tell a different story.
cheers
[1] To be explicit:
smtp_accept_max = 100
smtp_accept_reserve = 50
smtp_accept_max_per_host = 9
(The reserve hosts are hosts in our own departmental domain, as well
as our backup MX.)
