In message <512B6698(_dot_)6000407(_at_)tana(_dot_)it>, Alessandro Vesely
writes:
On Sun 24/Feb/2013 03:22:47 +0100 Ned Freed wrote:
Actually that is an interesting idea. The backup MX could act as an SMTP
proxy as long as it can maintain a connection with the primary. That
would also sort out your observation on address checking.
And when it can't it needs to be prepared to pass as much of the context of
the
original connection to the primary as possible later when the primary becom
es
available again. The IP address is especially important here, of course.
Again, it would be quite helpful if there was a standard for doing this.
Postfix has XCLIENT, we have something called XPEHLO, and there are
probably others out there.
Do those systems provide for keeping recipient lists in sync? 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?
It isn't that hard to keep namespaces in sync. I was doing it 2
decades ago with yellow pages and stock MTA. All the backup MX's
had a copy of the valid names in a yp database which was checked
on rcpt to. Yes it required a little bit of configuration to set
up. You added a account and updated the YP database. That was
pushed / pulled (too long ago to remember which) to all the backup
MXs.
There is a problem of PII leakage if the backup MXes are managed by
different ADMDs. It should be possible to distribute that data in a
crypted form, so that the operators of a backup MX can only learn a
(cleartext) mailbox name upon accepting it as a recipient --or by
playing a dictionary attack. Would that be an acceptable solution?
In order for a backup MX to make the same decisions as the primary,
other data has to be shared as well. For example, black/white lists
and how they're used. It is commendable to share them anyway.
Standardizing this stuff could (re)introduce the habit of exchanging
backup MX services, rather than outsourcing it all together to some
big 3rd party whose principles of operations remain secret.
Thank you
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
--
Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka(_at_)isc(_dot_)org
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp