On 02/25/2013 05:27 PM, Ned Freed wrote:
Do those systems provide for keeping recipient lists in sync?
That's a totally separate problem. And yes, it is a problem, and there
are various ways to solve it, and it maybe makes sense to standardize one of
them. Or not - it's a fundamentally harder problem to solve, with a lot
more variabless.
It is
too easy to abuse of a backup forced to accept any recipient. OTOH, a
backup could stay disconnected from the primary for quite some time,
possibly transmitting mail to yet another backup which is able to
connect to the primary. So it may make sense to have a copy of the
mailbox names at the backup MX. What are the alternatives?
Again, you're talking about a different problem. Let's please focus on the
problem at hand, which is the transfer context from a secondary to a primary.
IMO these two problems are interrelated. The more a backup MX is
configured with the settings and policies of the primary, the less the
need for context transfer.
At one side of the spectrum: if configuration of backup MX is
'identical' to that of the primary (complete address list, DNS
blacklists, greylisting, SIZE policy, max. number of recipients policy,
transfer rate etc.) the dirty job will have been done by the backup MX
and messages that pass the backup MX can be transferred without a
problem to the primary. There are companies which have offices in
multiple countries/continents which have the ability to implement
'identical' backup and primary.
At the other side of the spectrum there is the situation where the
backup MX has little 'knowledge' or none at all, about the configuration
specifics of the primary. In that situation the second problem prevails:
how to transfer context of the original connection from backup MX to
primary.
In real life, most backup/primary MX setups are somewhere in between
those two extremes. Which means, both problems will be present to a
greater or lesser extent:
1. how to provide 'configuration context' from primary to backup MX
2. how to transfer 'connection context' from backup MX to primary
As for the second problem, talking about context transfer, the following
comes to mind:
- original source IP address
- original EHLO/HELO identity
- RFC5321.MailFrom information
- RFC5321.RcptTo information
- Results of SPF and DKIM verification
- Date/time of receipt at backup MX
- et cetera
Having said that, I still have not seen figures about how big this
problem really is. And _what_ exactly the problem is. Is it that backup
MXs attract spam? Do they and if so, how do we know that? Is it that the
use of a backup MX causes spam to be accepted, that would have otherwise
been blocked when it had been sent directly via the primary? Is it that
backup MXs causes backscatter? Let's first try to define the problem(s)
and then start to think about solutions.
/rolf
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp