On Thu, Feb 19, 2004 at 10:52:25AM -0600, Dustin D. Trammell wrote:
I think the contrary was actually the original point. Consider the
scenario where you have a small business that actually does manage its
own mail host handling both inbound and outbound mail, however it also
receives secondary MX service from it's upstream ISP, should it's
primary MX be unavailable. The ISP's server just stores and forwards
mail for the small business' domains to the small business' primary MX
when it does again become available. In this scenario, you have an
outbound and inbound mail host under the administrative control of the
small business, and a secondary MX under the administrative control of
the upstream ISP. I believe the issue was, should the ISP trust the
company enough to accept a shared secret from the company, or should the
company trust the ISP enough to accept a shared secret from the ISP?
Either way, your sharing a secret across an administrative boundary.
I don't see that it's necessary at all. A backup MX just receives the mail,
queues it, and forwards it to the primary MX when it is back up. It can do
so without any validation of the recipient address local-part. The primary
MX will reject the bounce if it's invalid.
It might save a little work and bandwidth if the backup MX did this
filtering, but I don't see the point. The same is true for mail to
unknownuser(_at_)example(_dot_)com; the backup MX is unlikely to have an
authoritative
list of local-parts, so it will accept the message regardless and forward it
to the primary, which will bounce the bad username.
What
may be even more of a concern is how to rotate secrets in a synchronized
manner between mail hosts.
That's easy; you just have a parallel-running period where you test both the
old secret and new secret on incoming mail, and accept either.
Regards,
Brian.