Re: Value of backup MX
On Tue, 9 Nov 2004, Dale E. Martin wrote:
> > i usually have my backup MX accept everything and then don't treat
> > them specially on the primary. thus, policy is still enforced on the
> > primary, but there is a proper backup path *under my control* should
> > the primary be unreachable for whatever reason.
>
> With this approach you can't bounce RBLed messages at SMTP connect time
> though, right? (I realize that RBLs are semi-controversial, especially at
> the ISP level.)
>
> We recently dropped our secondary MX as it was just being abused to get
> spam past the RBLs on our primary. (I.e. _no_ valid mails were being
> delivered through the secondary MX.) The secondary MX was not under my
> direct control which complicated matters a little as then I could not even
> attempt to make the policy the same on the secondary as it was in the
> primary.
I had the same problem - no control over my MX boxen...
I did manage to reduce (significantly) the number of bounces the MX
must handle, and will soon have it down to virtually none ! And, you
can do this without loss of function (RBL, SMTP time rejection).
I setup sendmail (of course), mime-defang, SA, clamav, and fprot on
the main mail machine.
mime-defang runs as a milter (Mail fILTER), and can do SMTP time
rejections (at helo, mail, rcpt, data...).
The trick was to augment mime-defang such that it has a list of
valid MX (and other forwarding - like d.o) machines.
If a mail is classified as spam, or a virus, or hits an RBL, etc...
I have mime-defang check the MX list and silently DROP mails from
valid relays... but REJECT (5xx) all others.
--
Rick Nelson
<Culus-> I will be known as Ian Black, Ean can be Ian Red, Netgod Ian Blue,
Che gets Ian Yellow, CQ is Ian Purple and Joey is Ian Indigo
-- Some #Debian channel
Reply to: