In message <Pine.LNX.4.61.0502061844380.19489@???>,
Alan J. Flavell <a.flavell@???> writes
>On Sun, 6 Feb 2005, Fred Viles wrote:
>
>> On 6 Feb 2005 at 17:24, Alan J. Flavell wrote about
>> "Re: [exim] Re: Report of new spam t":
>>
>> | On Sun, 6 Feb 2005, Richard Clayton wrote:
>> |
>> | > An absolutely key measurement is delivery failures.
>> | >...
>> |
>> | Yes, but based on what? Envelope-sender address? IP address of
>> | offering MTA?
>>
>> Authenticated sender, I would think. Requiring SMTP AUTH is a
>> reasonable presumption.
>
>Oh, right! Then the thread is about detecting problems with outgoing
>mail from your *own* customers - not about detecting incoming mail
>from remote infested sources.
yes :) that's the so-called "new" spam technique in the subject, which
I'd argue is great news because smarthost owners have lots of
opportunity to spot abuse -- and not just simple item counting
interestingly, AOL are claiming to be already doing this (for their own
benefit) on behalf of everyone else by their policies on incoming email
http://www.circleid.com/article/917_0_1_0_C
>I'm afraid I'd slipped into the wrong context.
in practice you can get a lot of mileage from looking for patterns on
incoming email ... where HELO is currently an excellent thing to look
at; most of the viruses vary it -- as do some of the spammers...
... however, real senders will use a small number of HELOs per IP
address (and since so few send from dynamic allocations, you're unlikely
to get significantly burnt by multiple senders on one IP address over a
short period) [no figures this time, I'm still assessing what's
effective; so I wouldn't recommend this as a rejection technique but an
aid to categorisation]
However, this sort of heuristic is useless when email has passed through
an ISP smarthost because the HELO has been cleaned up -- but it is
really useful where this has not happened
>Hope the other points were useful to someone, anyway.
in particular you said:
>A couple of years back, I put a stanza in our RCPT ACL for detecting a
>certain kind dictionary attack. It basically triggered if it reached
>"n" invalid RCPT TO addresses in the same call, without at least "m"
>valid addresses (where n and m were parameters to be chosen, e.g 5 and
>2). But of course it relies on the attacker trying several addressees
>per call. That kind of dictionary attack was very prevalent a couple
>of years back, which prompted me to devise that action; later, it
>seemed to go out of fashion.
... and I can report that setting n=1 is currently very effective indeed
on my private email. Some of the "million address CDs" seem to circulate
with a set of invalid addresses for my domain. Mention _any_ of those on
a multiple receipt email and I _know_ it's junk and refuse to accept it
(I then collect the other local parts that were used and, provided they
aren't valid I had them to the list of "killer" local parts). This has
reduced incoming junk from (literally) tens of thousands to a few
hundred a day. Of course this a fine strategy for me, but doesn't
easily work in a corporate (ie multiple receiver) scenario
the actual implementation works fine in Exim (ought to try and stay on
topic :) ) -- using a 'set acl_m0 = yes' statement to accumulate the
failure requirement and then rejecting the email in ACL that runs after
the DATA is complete -- so there's a bandwidth cost, but not much
- --
richard Richard Clayton
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety. Benjamin Franklin
