-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On
Behalf Of Tony Hain
Sent: Thursday, March 27, 2008 9:05 AM
To: 'Keith Moore'
Cc: ietf(_at_)ietf(_dot_)org
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
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf