Hi, Evert,
On 23-02-13 18:57, Evert Mouw wrote:
Just an idea... maybe it's silly or not worth investigating, but I
thought it wouldn't hurt to ask for comments.
Thanks, Evert
# Reject messages on backup mail exchangers when primary MX is online
---
TODO:
- Cascading? Like: test all MXs with lower preference number.
- Check with [RFC 5321].
- Error messages: correct numbers? Ask for opinions.
Negative replies can be permanent (5xx codes) or transient (4xx codes).
- Discuss in newsgroup.
- Test.
- Write RFC.
---
Author: Evert Mouw <post(_at_)evert(_dot_)net>
History:
- 2013-02-06 first version
## Problem
Multiple incoming mail servers (Mail eXchangers; MX) may be configured
for a DNS domain. The MX with the highest priority, that is, the
*lowest* preference number, MUST be contacted ([RFC 5321]) by the
mailserver of another domain if that other mailserver wants to send mail.
The MX with the lowest priority number is therefore called the *primary*
MX. The other MXs are *backup* servers. The backup servers will be used
by the sending party if the primary MX cannot be reached for whatever
reason. In practice, reasons might, for example, be related to network
configuration errors or hardware failure.
Spammers have found that sending spam to both the primary MX and one or
multiple backup MXs often works great to increase the number of spam
messages being delivered. Often, backup MXs are less well configured to
stop SPAM. Even if they are well configured, clever spam messages might
be delivered by both the primary and the backup MXs, resulting in
multiple spam messages for a receiver.
Do you have any research results that could underpin this problem
statement? Given the fact that most major ESPs have multiple MX records,
I would expect that they would have minimized the number of MX records a
long time ago, if this was really a big problem. Some figures:
outlook.com has 4 MXs, equal priorities
gmail.com has 5 MXs, different priorities
Postini use 4 MXs for their customer domains, different priorities
MessageLabs use 2 MXs, different priorities
...
If backup MXs are less well configured than their primary MX, the mail
admin is the one to fix this problem. If they are not competent, chances
are small they will read amendments to RFC5321.
/rolf
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp