Re: [exim] Re: Report of new spam technique

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Richard Clayton
Fecha:  
A: David Stone
Cc: exim-users
Asunto: Re: [exim] Re: Report of new spam technique
In message <l03130302be2be6e731cb@???>, David Stone
<dstone@???> writes

>I would be
>interested in alternative measures that can be included into exim,
>though - particularly ones based on traffic patterns, not body content.


An absolutely key measurement is delivery failures. Legitimate email,
from mailing lists etc, will mainly have valid destination addresses and
will tend not to trip detectors at remote sites. However, virus/worm
activity and hijacked machines sending spam will have significantly
higher failure rates... a good rule of thumb (your volumes may vary)
is that 100 failures over 24 hours is unacceptable (and you should be
able to rapidly educate those whose mailing list address files are
poorly maintained).

Basically you leverage the inability of viruses (and spammers) to tell
good addresses from bad PLUS all the fancy detectors running at remote
sites whose results you get to feed back into your decision making :)

There are obvious (bad) interactions with sites that accept all email
(to avoid giving clues to dictionary attackers); with sites that
greylist (when is a failure a failure?) and where the spammers have been
tidying up their lists (and when does that happen?).

On the up side, this heuristic avoids a lot of special case handling for
registering regularly operated mailing lists -- and may well mean you
don't lose the business of customers who have occasionally operated
mailing lists (if they suddenly want to send out 8000 emails about their
new product to their opt-in mailing list, they aren't going to be too
chuffed if you block it solely based on the volume)

I particularly endorse the heuristic for "after the event" log scanning,
but it is applicable to run-time blocking as well -- though you'll need
a good notion of a failure when the remote site will not commit itself
(4xx etc); but if you're shuffling undeliverable email off your main
server to a secondary delivery system then this provides a good cut-off
point to flag a failure.

- -- 
richard                                              Richard Clayton


They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin