RE: Last Call: draft-klensin-rfc2821bis

["Hallam-Baker, Phillip" <[e-mail]>]

The key issue here is whether people who rely on AAAA are likely to
achieve their desired result. Today it does not matter because anyone
who relies on AAAA alone with no A fallback is going to receive almost
no mail.

That in turn is going to depend on whether software implementations are
written to fall back to A record lookup or host name lookup. Before AAAA
they were the same thing.

One software architecture would be to interpret RFC 2821 litterally and
only do A record fallback. I suspect that most people would implement
this by directing to their hostname lookup module which in an IPv6 stack
is going to be A/AAAA agile. So in that case the AAAA fallback is going
to come for free.


Coupled with the fact that DNS servers are probably going to be
configured to push AAAA records with an A record lookup by default in an
IPv6 world I suspect that there is not going to be a problem.


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Tony Hain
> Sent: Thursday, March 27, 2008 9:05 AM
> To: 'Keith Moore'
> Cc: [e-mail]
> Subject: RE: Last Call: draft-klensin-rfc2821bis
> 
> Keith Moore wrote:
> > Tony Hain wrote:
> > > Your arguments make no sense. Any service that has an MX creates 
> > > absolutely no cost, and the fallback to AAAA only makes one last 
> > > attempt to deliver the mail before giving up. Trying to force the 
> > > recipient MTA to publish an MX to avoid delivery failure on the 
> > > sending MTA is useless, and in no way belongs in a 
> standard document.
> > > MX records are an operational optimization, nothing more.
> > 
> > that's completely incorrect.
> > 
> > what MX records mean is that a domain name used on the 
> right hand side 
> > of an email address need have nothing at all to do with any host or 
> > other service that has the same domain name.  in particular the 
> > servers and resources associated with that email address 
> don't have to 
> > share the same host, network, addresses, user community, 
> > administration, or anything else.  (except that the 
> administration of 
> > the DNS zone and RRs associated with that domain is the 
> same for both)
> > 
> > in short, MX records decouple mail domain names from host 
> names.  and 
> > this turns out to be a very useful thing to do.  e.g.
> > 
> > 1. a domain used for mail that doesn't correspond to any actual host
> > 
> > 2. a host that doesn't want to source or receive mail
> > 
> > 3. when it is desirable to associate email and other 
> services with the 
> > same domain name, and yet not have all of those services 
> hosted on the 
> > same cpu or at the same address.
> > 
> > for instance, the email for network-heretics.com and the web server 
> > for the same domain are hosted by entirely different companies on 
> > different networks -- because I couldn't find a hosting 
> company that 
> > did an adequate job of both at a reasonable price.  and yet 
> it's very 
> > useful to have them both associated with the same domain name.
> 
> That is all well and good, but it is completely of value to 
> the receiving MTA, and under their complete control. There is 
> nothing that requires a receiving MTA to follow this model, 
> despite what others may see as value.
> Defining the facility is what the standards need to do. 
> Dictating operational practice without cause is what a 
> standard needs to avoid doing. 
> 
> > 
> > > The function of mail delivery is between IPv4/IPv6 endpoints, and 
> > > how those endpoints find each other is orthogonal to the actual 
> > > service of mail delivery. Having the document state a 
> prioritization 
> > > between
> > > 2 of the possible methods is pushing the edge already
> > 
> > that's an incorrect way to characterize what is going on, 
> because an A 
> > record is only a valid destination for mail to a particular 
> domain if 
> > no MX records exist.  if even a single MX record exists, it's 
> > incorrect to route the mail based on an A record, even if 
> an attempt 
> > to relay the mail via the listed MX resulted in a temporary error.
> > 
> 
> I agree that if an MX exists, the operator of the receiving 
> MTA has stated its expectations, and the sending MTA needs to 
> oblige. That is not the same as mandating that every 
> organization has to follow the same model. If there were some 
> serious technical consequence for lack of the MX record I 
> would be all for specifying its use. Operational practice 
> with A records shows that there is no real issue, and that 
> anything that does come up is under the control of the 
> impacted party with a clear mechanism to resolve it. 
> 
> Again, the text is fine as it is.
> 
> Tony
> 
> 
> 
> _______________________________________________
> IETF mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
> 
_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf