Re: rfc2821bis-03 Issue 35: remove source routes from example D.3

--On Tuesday, May 01, 2007 6:52 PM +0200 Frank Ellermann 
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
> > "foo.com, having received the message, verifies delivery to
> >  jones(_at_)xyz(_dot_)com is permissible and possible. foo.com now does
> >  a DNS lookup on xyz.com."
> Actually it should verify jones(_at_)xyz at the time when it decides
> to accept the mail, but at this time xyz is down, and so that's
> not possible.  The verification business after it has accepted
> the mail is pointless, it's too late, foo.com can only pray
> that xyz.com eats its spam.
It seems to me that this is the key problem.   Even if we 
(temporarily) ignore the constraints on what can go into 
2821bis, the "backup MX" function -- a server that is not 
expected to receive mail for a particular domain unless the 
servers that normally support that domain are down or otherwise 
offline from the public network -- is an important, even if (one 
hopes) rarely-used, function.  Unlike some other uses of MX 
records, that situation poses both a technical and an 
administrative/ economic problem.  The first is essentially a 
race condition: no matter what measures are taken, if the relay 
(standby MX server) cannot establish connectivity to the server 
for the target domain in real-time, it has no possible way to 
know what addresses are valid there.  The very best it can do is 
to guess on the basis of knowledge obtained while there was 
connectivity.
The administrative/economic one is that there are disincentives 
for the administrators of the relay machine and those of the 
target machine to try to keep up-to-date user lists on the relay 
machine.  It requires more coordination and more resources than 
simply providing a backup MX function, and requires them on a 
regular and continuing basis, even when the target machine is 
almost always available.  It also raises some privacy issues. 
In addition, we don't have any established / standardized way to 
transfer and store the needed information (one could imagine a 
DNS-like "poll for updates" protocol, but, at least to my 
knowledge we don't have one of those.
While there is less of it today than there was a decade ago, we 
also have a situation, especially with some rural areas and 
developing countries, where an MX record points to an 
always-online server that acts as a temporary repository or 
gateway to the distribution server for network that is only 
intermittently connected to the rest of the Internet (i.e., the 
link between the accessible server and the delivery server is 
only occasionally available and may not be accessible to the 
public Internet at all).  The same issues arise as with the 
cases above: having accurate information on the relay about 
deliverable mailboxes is very problematic.  Of course, similar 
or identical issues arise with various long-delay networking 
scenarios.
Speaking personally, and again temporarily ignoring the 
constraints on the 2821bis effort, I'd be much more sympathetic 
to this class of changes that are intended to restrict use of 
NDNs if there were some clear analysis, and possibly tools (the 
privacy issues aside), for dealing with these important cases. 
I'd also be more sympathetic if the proposals were a bit more 
nuanced.  For example, to say that a relay should make 
reasonable best efforts (however those might or might not be 
defined) to verify the address before accepting the mail but, if 
it cannot, may go ahead and try to deliver it, dealing with the 
NDN case if necessary would seem much more plausible to me than 
trying to ban NDNs ... a ban that, if taken seriously, would 
take a large number of areas out of even email connectivity with 
the Internet.
       john