Peter J. Holzer wrote:
If you are doing any serious anti-spam filtering you really want the
same filter rules on all your MXs.
..^^^^
For the backup MX example earlier in this thread I'd say that an MX
should be stricter if its priority is numerically higher. Something
as in
<6(_dot_)2(_dot_)5(_dot_)6(_dot_)2(_dot_)20070501174012(_dot_)02d86970(_at_)resistor(_dot_)net>
can't work:
| The main problem is that the backup MX may have a less restrictive
| filtering policy than the lower numbered MX.
And as Hector mentioned elsewhere the spammers will make sure that
this setup is fixed before it's seriously needed (= primary MX down).
You especially don't want an "accept everything" policy on the
lowest-priority MX because spammers do expect and exploit that.
(Hmm, is that another recommendation that should go into the RFC if
it isn't already there? "If there are multiple MX for a domain, they
SHOULD implement the same policy for accepting or rejecting mail. In
particular, a lower priority MX should not accept mail that a higher
priority MX rejects")
Yes, but I'd say "for MXs with a different priority the MX with the
numerically higher priority SHOULD be at least as restrictive with
respect to accepting mails for the domain in question as the MX with
the numerically lower priority."
The "SHOULD" is clearly justified, because it would cause unnecessary
backscatter otherwise. Admittedly it's not possible to define what
"restrictive" precisely means. A backup MX at third party will use
its own definition of "restrictive", and to determine what's "more
restrictive" would need a statistical evaluation. But I think the
meaning should be clear for implementors and admins.
Frank