On Mon, 1 Mar 2004, Alan J. Flavell wrote:
> As reported before, we've got some tests in the RCPT-time ACL which
> apply a time delay if the incoming mail offer meets certain criteria -
> criteria which are selected to be suggestive of spamming engines and
> the like.
I am asked in email for some more detail of the ACLs we are using for
this. Well, the recipe is actually bundled up with some other
anti-abuse measures, but, with all usual caveats and a bit of
explanation, here's a sketch of what's going on. I trust that in
extracting and summarising this I haven't introduced any non-obvious
errors. This is all entirely in the RCPT-time ACL.
There are of course also tests which issue outright rejections in the
ACL (e.g DNSrbl tests, blacklisted senders and so on), they aren't
shown here.
There's a bundle of tests which do one, or other, or both of
these things:
1: append to acl_m3, which will trigger the time delay that we're
discussing here
2: cut an X- header, which will be rated by spamassassin later.
The statements which are there for computing the delay are probably
completely unnecessary frills, but I thought it would be fun to
compensate for any time lost in DNSrbl lookups and callouts. So I
start the ACL by noting the tod_epoch, and later compare the saved
value with the tod_epoch to compensate for the time we lost in the
intervening part of the ACL, as I hope will be clear. Just strip that
out and have a fixed delay, if you prefer.
# Near the start of the RCPT ACL, we have this:
warn set acl_m2 = $tod_epoch
# initialise the list of delay reasons:
warn set acl_m3 =
[...]
# Amongst the ACL tests, e.g after the DNSRBL rejections, we have
# these, for example:
# dialup type (other than MAPS RBL, which is an outright reject):
warn hosts = +rbl_hosts
dnslists = dul.dnsbl.sorbs.net
set acl_m3 = $acl_m3 sorbs-dul
[...]
# warn about HELO arguments which are unqualified domains:
# (unless sender is authenticated)
warn hosts = +rbl_hosts
condition = ${if eq{$received_protocol}{asmtp} {no}{yes}}
hosts = ! CONFIG_DIR/helo_accept_junk_hosts
message = X-HELO-warning: That's a nasty HELO: \
$sender_helo_name
log_message = X-HELO-warning: That's a nasty HELO: \
$sender_helo_name
condition = ${if match {$sender_helo_name}\
{\N^[-a-zA-Z0-9]+\.[a-zA-Z0-9]\N}{no}{yes}}
set acl_m3 = $acl_m3 unqual-helo
# (I suspect that the regex in there is suboptimal...)
# Check for a number of commonly spoofed HELOs (listed in the
# file dubious_helo) whose genuine user is known to verify:
warn hosts = +rbl_hosts
condition = ${if eq{$received_protocol}{asmtp} {no}{yes}}
hosts = ! CONFIG_DIR/helo_accept_junk_hosts
condition = ${lookup {$sender_helo_name} lsearch \
{CONFIG_DIR/dubious_helo} {1}{0}}
message = X-HELO-dubious: Your HELO/EHLO does not jive
! verify = helo
set acl_m3 = $acl_m3 helo-no-jive
# check for a calling host name that contains dsl, adsl, dialup etc.:
warn hosts = +rbl_hosts
condition = ${if match{$sender_host_name}\
{\N(^|\W)(a?dsl|dial(up|in|\.|-))\N}{1}{0}}
set acl_m3 = $acl_m3 hostname-dsl-or-dialup
# and various other tests in that general vein - they get twiddled
# as we gain experience.
[...]
# Then, just at the end of the RCPT ACL, we compute the residual
# delay needed to make the time up to "123s" (we're not really using
# 123, it's just a placeholder here) and issues the actual delay,
# if the list of reasons in $acl_m3 is not empty:
warn hosts = +rbl_hosts
set acl_m2 = ${eval:123+$acl_m2-$tod_epoch}
set acl_m2 = ${if <{$acl_m2}{1} {1}{$acl_m2}}
log_message = AJF-Dubious: $sender_host_address \
($sender_host_name) - \
reason: $acl_m3 - sender is $sender_address - \
for $local_part\@$domain - \
delay was $acl_m2 secs
condition = ${if eq{$acl_m3}{} {0}{1}}
delay = ${acl_m2}s
The pattern that then appears in the mainlog is something like this:
2004-03-02 11:07:23 H=(MarineGuy) [61.78.92.162] Warning: AJF-Dubious:
61.78.92.162 () - reason: unqual-helo - sender is FAKE@???
- for OURUSER@??? - delay was XXX secs
, followed, if the ruse has been successful, by:
2004-03-02 11:07:23 unexpected disconnection while reading SMTP
command from (MarineGuy) [61.78.92.162]
There can, in general, be multiple reasons logged, as in:
2004-03-02 04:53:58 H=dialup-free-349.nmsu.edu (computer)
[128.123.221.93] Warning: AJF-Dubious: 128.123.221.93
(dialup-free-349.nmsu.edu) - reason: unqual-helo hostname-dsl-or-dialup -
sender is FOOBAR@??? - for OURUSER@??? -
delay was XXX secs
2004-03-02 04:53:58 unexpected disconnection while reading SMTP
command from dialup-free-349.nmsu.edu (computer) [128.123.221.93]
As I said yesterday, the delay should probably be larger than 60s, but
comfortably less than the 300s limit mentioned by the RFC. If the
malefactors knew that we were all using a specific value, then they
could easily circumvent it, so it's best if we make our own choice, I
suggest.
hope this is vaguely useful. E&OE, YMMV.
At the moment, around two-thirds of the attempts which are treated to
this delay are deciding to back-off, and most of those (by inspection)
don't retry their timed-out transaction (i.e they aren't true MTAs),
although some of them go on to make fresh attempts; while the rest go
on to the next stage of anti-spamming, and some of them are bona fide
- those mails *do* then get through.
However, that "two-thirds" figure is evidently inflated at the moment
by the virus offerings. Under normal circumstances it's more like a
half, or somewhat less. Still worth having, though, IMHO.
