Re: [Exim] Using secondaries for anti-spam (was "Secondary M…

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Alan J. Flavell
Fecha:  
A: Exim users list
Asunto: Re: [Exim] Using secondaries for anti-spam (was "Secondary MX - defer if primary is up")
On Mon, 17 May 2004, Alun wrote:

[discussing the possibility of the secondary MX deferring mail at
times when it knows the primary MX is alive...]

We toyed with this idea some time back, since our departmental mailer
is our primary, and has the main campus mailer as its secondary. We
never did manage to devise an exim callout formula which had quite the
properties we were looking for. In the meantime however the main
campus mailer has instituted a much better system of spam control, so
the issue isn't a hot topic with us any more.[1]

> All this discussion has got me thinking of "yet another bad idea (tm)". What
> if I were to run a secondary MX on an IP alias on one of my primary servers.
> All mail attempted to this IP would be deferred at RCPT time


Sneaky idea!

> (I should mention that aber.ac.uk doesn't have a secondary mx at all
> at the moment).


Without implying one way or the other as to whether you should, one
could still have, in order of ascending MX values, a good primary, a
good secondary, and then third, a spam-trap of the kind that you're
discussing.

Certainly, if starting afresh with a secondary MX setup, one would
want to ensure that primary and secondary had essentially the same
spam policies. But even this doesn't guarantee that every mail
accepted by the secondary will also be acceptable to the primary,
since there might have been new blacklisting entries in the relevant
databases, in the time between the secondary accepting an item, and
the primary coming back on-line.

> Lots of people seem to say that spammers hit the secondary rather than the
> primary on the basis that the checks are less stringent there.


Oh yes, I'm convinced that some noticeable proportion of spammers do
that. It's hard to believe that so many of them would go to our
secondary MX without leaving any trace of an attempt in our own log,
even though the log shows our mailer to be far from busy at the time.

There -are- other patterns of behaviour, though, such as callers
presenting a sender address domain for which we attempt callout - the
callout tempfails, so we defer the caller - and then they rush off to
our secondary MX. Which I suppose we've no grounds for complaining
about.

> If I defer that stuff, nobody gets hurt, but some of my spam might
> go away. The primary should always be reachable when the secondary
> is (after all, it's the same exim process that's handling it all) so
> no legitimate stuff should ever go there. If it did, the temporary
> deferral should cause it to try the primary again. So all I'm doing
> is blocking "secondary mx spam".


Sounds entirely plausible to me. Look forward to seeing the results
;-)

all the best

[1] There is a remaining issue of course: if the campus mailer accepts
something which we then decide to reject, then the campus mailer is
left with a bounce on its hands. Which in these days of counterfeited
sender addresses can be a nuisance in its own right.