Re: [nznog] Continued problems with xtra email

On Sat, 1 Sep 2007, Hamish MacEwan wrote:

On 8/31/07, Joe Abley wrote:

...

[A] --------- [B] \ / X / X / \ / [C]

[A], [B] and [C] are different networks on the Internet. I have a priority-0 MX installed at [A], and another one at [B]. The MX at [A] has a lower number in its RDATA than the one at [B] (i.e. the one at [B] is the backup).

Suppose some device at [C] tries to send me mail, and at the time it chooses to attempt delivery, there's a network problem which prevents traffic from getting through. It instead delivers to the backup MX at [B]. There is no network problem between [B] and [A], so mail is forwarded on straight away.

I'm just curious what reasons, and they may be myriad, explain why SMTP will route around the damage using the MX priority, but TCP/IP won't? Ie, I can send mail where I can't send a packet?

Because the circumstance that Joe is proposing here is one where your TCP/IP connectivity between (C) and (A), even with the usual internet tricksy mutiple-path, dynamically routed, cleverclogs stuff going on, is still broken. Maybe (A)'s route advertisments have flapped a bit recently and been damped. Maybe a couple of big ISPs associated with that network have chosen to de-peer from everyone else and now you can only reach it via an accoustically coupled modem in a goat shed/Data Center in Badbusinessmodelstan. I'm told that sort of thing does actually happen. But the other MX on (B) is still reachable from (C) despite any or all of these possible reasons because it's on a completely different network and probably (if Joe's being sensible - and he always is[1]) one that's been chosen specifcally to be as diverse as possible from (A). This is a pretty common setup for services like MX's, DNS servers, and other stuff that you'd like to have reachable more often than not, where support for multiple servers is built into the protocol itself. JSR [1] Except when there's beer.