[Exim] Bagle, unqualified HELO, time delays

Pàgina inicial
Delete this message
Reply to this message
Autor: Alan J. Flavell
Data:  
A: Exim users list
Assumpte: [Exim] Bagle, unqualified HELO, time delays
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. Without wanting to specify that time delay too closely -
lest the spammers and virus writers start adjusting their engines to
match it - let's just say that it's above 60 secs, and comfortably
less than the 5 minutes which a bona fide MTA should be able to
tolerate at that point.

One of the possible criteria used had been the presentation of an
unqualified HELO domain. As a matter of fact, that hadn't seemed to
give particularly useful results over time, and it had been disabled,
until yesterday.

However, I noticed over the weekend that as each new Bagle signature
came out from Sophos, a new kind of Bagle-like virus would start
arriving and slipping past the scanner, which was quite a nuisance. I
noticed that the infected nodes were presenting an unqualified HELO,
so I started to ask myself whether perhaps that virus's engine would
give-up by the application of such a time delay.

And indeed this seems to be so. Some of the virus attempts were
already being shrugged-off because the offering host appeared to be a
dialup/dynamic address, which was one of the active criteria for using
the time delay. And since I re-enabled the time-delay criterion for
unqualified HELOs, I've had quite a number of instances which closely
resemble the modus operandi of the Bagle virus, but the time delay has
been enough to fend them off, so they never got as far as presenting
the virus to the scanner - neither successfully nor unsuccessfully.

The only cases where Bagle-type viruses arrived since then, was where
they had been forwarded by some other MTA, e.g by a mailing list, a
forwarding file, or as "collateral spam" (misguided MTA trying to
report non-delivery back to the faked envelope sender).

Hope this is useful to someone.