Re: [Exim] Greylisting + multiple MX hosts -> multiple attem…

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Alun
Fecha:  
A: Edgar Lovecraft
Cc: Exim users list
Asunto: Re: [Exim] Greylisting + multiple MX hosts -> multiple attempts
Answering two mails in one...

> Alan J. Flavell wrote:
> > Maybe I'm making this overly complicated (it's happened before ;-) by
> > trying to avoid the MTA causing pointless extra network traffic in such
> > a situation. I suppose I should just let it take its natural course.
> > But for a 60min greylisting, for example, it means (at our initial 15min
> > retry interval) about 4 rounds of retries, times the number of IP
> > addresses in the MX lookups, i.e in this case a dozen retry
> > transactions.


It's hard to quantify this cleanly, but it's worth remembering that Aber
is now passing around 40% less mail through its spam scanners. That's cutting
down on DNSBL lookups, any network traffic that SpamAssassin generates and,
of course, the traffic involved in transferring the spams themselves.
Overall, that's surely a reduction in network traffic (albeit at the cost
of a small increase at your end, since you're presumably not running
greylisting).

Edgar Lovecraft (exim-list@???) said, in message
    <jbm.20040323102204.26638c25@User21>:

>
> I thought the entire idea for greylisting is that 'spamers do not retry',
> so why do the Greylisting Docs suggest such a long period of time before
> the accept??


I chose 1 hour fairly arbitrarily. It's likely that 15 minutes would do the
job just as well at the moment, but we do need to ensure that it really
hurts the spammers. You can get around greylisting by hitting a bunch of
servers, then revisiting them some time later. I chose an hour because I
want there to be a good chance that they've got listed in a DNSBL in the
meantime.

I've got another idea I'd like to try at some point - make the dead time
dependent on the number of greylisted records outstanding against the
incoming IP address. So, if you've only got one sender/recipient pair
outstanding, you get delayed 10 minutes. If there are 1,000 of them,
we ramp up your dead time. That ought to make the "hit & run & come back
again" spammer fail too.

> Ah well, greylisting is a nice idea, I have just not figured out what a
> good balance for its use would be yet, and I do not think that all email
> should be greylisted "just because".


I believe that Aber's got the balance right (after a few tweaks during the
first week we ran it). Not all mail gets greylisted. With my implementation,
around 7.5% of legitimate mail gets delayed. It's only the first mail you
send to someone here that'll get delayed and then, only if they've never
mailed you directly and you're coming from an IP address which hasn't
delivered enough legitimate traffic to us to get itself whitelisted.

Greylisting is the only anti-spam strategy that I've introduced in the past
five years that has caused local users to comment on a sudden decrease in
received spam. That's a good enough "just because" for me :-)

Cheers,
Alun.

--
Alun Jones                       auj@???
Systems Support,                 (01970) 62 2494
Information Services,
University of Wales, Aberystwyth