[Exim] Re: Bagle, unqualified HELO, time delays

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Alan J. Flavell
Datum:  
To: Exim users list
Betreff: [Exim] Re: Bagle, unqualified HELO, time delays
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.