Re: [Exim] receiver_verify + spam + mailscanner

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Alan J. Flavell
Ημερομηνία:  
Προς: Exim users list
Αντικείμενο: Re: [Exim] receiver_verify + spam + mailscanner
On Wed, 15 Oct 2003, John Jetmore wrote:

> use call-forward verification on the secondary server - accept the mail if
> the primary server is down or else you destroy the whole backup MX
> concept.


Indeed. However, one might reasonably ask why the sender is trying to
use the backup MX when the primary one is responding, no?[1]

We know just by looking in the logs that many spammers go to our
secondary MX without bothering with the primary one (i.e all the
evidence indicates that our mailer would have responded if they had
tried it, but there is no sign of any call attempt being made - they
just went straight to the backup MX). Maybe some ratware just looks
up MX records and picks one at random - maybe some of them even
deliberately choose a secondary MX in the hope that it will be less
well-defended against spam, who can say?

We've certainly discussed the possibility of the secondary MX issuing
a defer if it knows that the primary is alive: but never quite settled
on a strategy for doing it - without the risk of some kind of
ping-pong developing.

> As a caveat, I haven't actually done any of this yet, I plan to rework my
> system to do this in my copious free time.

                          ^^^^^^^^^^^^^^^^^


Have you considered setting up some kind of donor centre for that?
I'm not the only one around who could use a transfusion ;-))

> The system I actually implemented is a perl daemon that builds db
> lists of valid users and deploys them to the backup servers. Kinda
> kludgy given the elegance of the call-forward solution, but it works
> for now.


Keep in mind that exim's call-forward implements cacheing. Well, OK,
that can be a problem for a while when a new user is added, or an old
one deleted; but on the whole it does the right thing.

cheers

[1] Yes, OK, if you have a reserved list and the backup MX is in it,
then it surely can happen that the backup MX could achieve a
successful call-forward to the primary MX even though the primary MX's
quota for outside connections was temporarily over-committed. (Can't
be -too- simplistic about these things.)