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.
That MUST necessarily has to be interpreted in the context of the SMTP
client. That context may be entirely different from the context the
mail exchanger is operating in. More specifically, it's entirely possible
for a mail exchanger providing secondary MX to be able to see the primary
MX but for the client connected to the secondary not to be able to. There
are also a myriad of configurations that could lead a client to fail on sending
to a primary in such a way that it will fall back to the secondary. Indeed,
there are many sites out there that depend on such configurations.
As such, a check to see if the primary is visible from the secondary and
if it is failing the mail is *NOT* justified by the cited text. That doesn't
mean it's illegal to do - you can reject mail on the basis of flipping a coin
if you want to - but if you're looking to the standards to actually condone
this, you can forget it.
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.
Which can be and often is asymmetric in nature.
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.
That's only true if you let it be true. There is no reason for the insertion
of a secondary to interrupt the flow of information to the primary, so
the information available once the message does get to the primary should
be the same, resulting in the same accept/reject/discard decision being
made.
True, it requires a certain amount of finesse, and some standards in this area
would definitely help, but there is nothing intrinsicly impossible to do here.
That said, there is a real problem here, and that's the limits on the
ability to perform address checking on the secondary. This can result in
mail to invalid addresses being accepted when it shouldn't be.
This is a considerably harder problem, but it also can be addressed. And
once again some standards would help.
Many mail administrators have responded by removing the backup MXs
alltogether. The added costs of more spam, electricity and maintenance
cost does not rationalize the availability of a backup MX. When the
primary MX is offline, than the mails for the domain will be queued by
the mailservers of the sending parties.
This has major drawbacks. First, it places the costs of the storage and
retries to the sending party while that party is not responsible for the
downtime of the receiving mailserver. Second, when the primary MX is
offline for too long, messages might be lost. Third, messages might be
delayed for a long time, even after the primary MX did come back online.
The proper way to address this issue is to deny the use of a backup MX
when the primary MX is online.
Not even close. See above. At most the role of a check of the primary would
be the adjust spam filters and perhaps some rate limiting.
I'm not going to bother to respond to your specific proposals since IMO the
entire goal here is wrongminded.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp