okay, I have fairly extensive comments about this document. most of them
do not address specific text in the document, for reasons which I hope
will become apparent to those who are willing to wade through the text below.
executive summary: it's a very good idea to have a document like this, but
I recommend delaying the publication this document until it undergoes
some restructuring and/or having it co-edited by an email expert.
in the first place, you really need to allow for a mechanism by which
v4-only hosts can communicate with v6-only hosts in the absence of
MX records. in the second place there are just too many subtleties
involved in email routing to get this right by simple editing of the
current document.
---------------------------------------------------------------------------
1. in the "summary of IPv4 MX operation",
both RFC 2822 section 5 and RFC 1035 should be referenced
and the document should make clear to the reader that these
are the standard specifications for MX lookup.
it is somewhat risky to re-state the algorithm in this document
at all, because there are some subtleties to it. and they only
get worse when you add IPv6 in the mix.
2. because there is a lot of uncertainty about the relationship
between IPv4 and IPv6, it would probably help if the document
were to state a few things up front:
- IPv4 and IPv6 share a common domain name space. a service
or host named by a domain name may be reachable via IPv4,
IPv6, or both. subject only to differences in reachability,
a service that is accessible via both IPv4 and IPv6 and which
can operate using either, should not be affected by whether
it is accessed via IPv4 or IPv6. since email can operate over
both IPv4 and IPv6 this principle holds for email -
user(_at_)example(_dot_)com refers to the same recipient and mail box
regardless of whether the mail travels via IPv4 or IPv6 or
a mixture of the two.
- we explicitly assume that everybody wants to be able to send
mail to everybody, regardless of whether they are reachable
via IPv4 or IPv6 or both. to the extent that a sender or
a receiver wishes to impose policy on who can send mail to whom,
we assume that IPv4 vs. IPv6 is not a factor in that policy.
- we specifically want to make sure there are easy ways to
exchange mail between IPv4-only and IPv6-only hosts.
however, we should not assume that every mail domain that has IPv4
access can get IPv6 access (even though with 6to4 this should be easy);
nor should we assume that every mail domain that has IPv6 access
can get IPv4 access.
it is therefore necessary to specify means by which IPv4-only
hosts can send mail to domains that lack IPv4 connectivity;
and by which IPv6-only hosts can send mail to domains that lack
IPv6 connectivity.
it is worth remembering that the MX mechanism was created
and originally used to handle a very similar case - providing
a means for hosts without IP access to receive Internet email.
for this reason, using MX to specify transit between IPv4 and
IPv6 turns out to be fairly straightforward. however there
are some subtle operational concerns that need to be mentioned.
- this specification can only apply to MTAs that implement it;
it cannot affect pre-existing MTAs. however it is permitted
to affect new MTAs, even those that are run on IPv4-only hosts,
and there are things that even an IPv4- or IPv6-only MTA can
do to ease delivery to the other kind of host.
in particular,
since IPv6 addresses can be looked up using IPv4 DNS queries, and
IPv4 addresses can be looked up using IPv6 DNS queries, a new MTA
can distinguish between "no addresses" and "no addresses
which are reachable" and treat the two cases differently.
the first is a DNS configuration error, and the second is the
inability to find a route from source to destination.
the IPv4- or IPv6-only MTA may wish to employ one or more external
"last resort" relays which can deliver to the other kind of MTA.
3. So here is (informally) how I would modify the MX routing algorithm:
definitions:
"relaying MTA" is the MTA which is attempting to relay a message
"recipient domain" is the domain named in the recipient address
"mail exchanger" or "MX" is a host which is listed in DNS as
a mail exchanger for the recipient domain.
"remote MTA" is a message transfer agent running on a mail exchanger.
"MX domain" is the domain name listed for a mail exchanger.
"MX address" is any of the IPv4 or IPv6 addresses listed in DNS
for an MX domain.
so these are instructions for a relaying MTA:
+ if there are no MXes listed in DNS for the recipient domain
- an IPv4-capable relaying MTA SHOULD attempt to relay to each of
the IPv4 addresses listed for the recipient domain (via A records),
until it finds one which will accept the message, or it gets a
permanent error from the remote MTA, or it times out.
- an IPv6-capable relaying MTA SHOULD attempt to relay to each of the
IPv6 addresses listed for the recipient domain (via AAAA or A6
records), until it finds one which will accept the message, or it
gets a permanent error from the remote MTA, or it times out.
- a relaying MTA with both v4 and v6 connectivity SHOULD
attempt to relay to each (v4 or v6) address listed in DNS for the
recipient domain (via A or AAAA or A6 records) until it finds one
which will accept the message, or it gets a permanent error from
the remote MTA, or it times out.
- the order in which connections should be attempted within
a list of (v4 or v6) addresses obtained in this manner
is unspecified, and MAY be a configurable parameter
of the relaying MTA.
- if a v4-only relaying MTA finds no v4 addresses, or a v6-only
relaying MTA finds no v6 addresses, the relaying MTA MAY relay
such traffic to an explicitly-configured "external" MTA which
has connectivity to the other kind of IP and which has agreed
to forward traffic from the sending host or network to recipients
using the other kind of IP. if no external relay has been configured,
the message should be bounced with an "5.4.4" (unable to route)
error. if the external relay were unreachable after several attempts
and the relaying MTA gave up, the message should be bounced with a
"4.4.1" (no answer from host) or "4.4.2" (bad connection) error,
as appropriate.
- if no addresses of any kind were found for the recipient domain,
this would be a "5.1.2" (bad destination system address) error.
(this is exactly what you should get in an IPv4-only world if you
try to send to a recipient at a domain without any MX or A records
listed for that domain.)
note however a subtlety - if any of the A or AAAA or A6 lookups
failed for temporary reasons - such as no response from any DNS
server - the condition would be treated as a temporary error,
and the MTA should retry at a later time until it decided to give
up. under such conditions the error should be "4.4.3 (directory
server failure)"
+ if there is at least one MX listed in DNS for the recipient domain,
- sort the MX list according to increasing preference
- attempt delivery to each of the MX domains in order of
increasing preference, until either
- the list of domains is exhausted
- the message is accepted by the remote MTA
- the message is rejected by the remote MTA with a permanent
failure error.
- for each domain in the ordered MX list the relaying MTA SHOULD
attempt to contact an SMTP server at that domain using
all IPv4 or IPv6 addresses listed for the remote MTA which are
reachable by the relaying MTA. within a particular domain on the
ordered MX list, the order in which the (IPv4 or IPv6) addresses
are chosen is unspecified, and MAY be a configurable parameter
of the relaying MTA.
however, precedence SHOULD be followed. so a relaying MTA which
has both IPv4 and IPv6 connectivity SHOULD attempt to deliver
to a MX domain with lower preference before attempting to deliver
to an MX domain with higher preference, even if the one with higher
preference has better connectivity or the one with lower preference
lacks the kind of connectivity preferred by the relaying MTA.
- if after exhausting the list of MX domains, a relaying MTA
with only IPv4 connectivity finds there were only IPv6 MX
addresses, or a relaying MTA with only IPv6 connectivity
finds that there were only IPv4 MX addresses, the relaying MTA
MAY relay the message to an explicitly-configured, "external"
MTA which has connectivity to the other kind of IP and
which has agreed to relay such traffic for the sending host.
if no external relay has been configured, the message should be
bounced with an "5.4.4" (unable to route) error. if the external
relay were unreachable after several attempts and the relaying
MTA gave up, the message should be bounced with a "4.4.1" (no
answer from host) or "4.4.2" (bad connection) error, as appropriate.
- if no addresses of any kind are available (meaning that
lookups on each of the MX domains return no address records
of any kind), the "5.4.3" (directory server failure) error is
the closest defined code for this condition. (this is a
misconfiguration of DNS rather than a malfunction, and 5.4.3
is really intended for malfunctions. ideally there would be
a separate code to distinguish directory misconfiguration from
directory server malfunction)
"5.1.2" SHOULD NOT be used for this case. If no MX records
exist for a recipient domain, and no address records exist for
that domain either, then it can be assumed that the domain is not
intended for use in email addresses. However, if one or more MX
records exist for a recipient domain then it is reasonable to
assume that the domain is intended to be valid for email addresses,
and that there has been a failure of the zone administrator to
provide address records for those MX domains.
4. with the above in mind, it is possible to construct operational
recommendations for senders and receivers to maximize the potential
for exchanging mail between IPv4 and IPv6:
- all sites:
it is RECOMMENDED that all sites employ MTAs which meet these
recommendations for v4/v6 mail routing, even if the site only
supports IPv4 or IPv6 connectivity.
the primary burden on a site that wishes to be receive mail from
IPv4 hosts is to provide at least one MX with v4 connectivity and to
list those MXes and their IPv4 addresses in DNS.
similarly, the primary burden on a site that wishes to receive mail
from IPv6 hosts is to provide at least one MX with v6 connectivity
and to list those MXes and their IPv6 addresses in DNS. (note that
any site with IPv4 connectivity and global IPv4 addresses can
establish IPv6 connectivity using 6to4 without needing to establish
a separate connection)
any other means of routing mail between v4 and v6 sites should be
considered a secondary, rather than a primary, mechanism.
- v6-only sites:
it is RECOMMENDED that v6-only sites provide at least one MX
for their recipient domains which is reachable via IPv4.
this MX MAY be external to the recipient site.
if it is desired to use this MX only when the sender has no v6
connectivity, the MX which accepts v4 traffic can be listed with
a higher preference than all other MXes.
this MX *must* either have some reliable means to relay mail to the
primary MX server, or it must otherwise handle incoming mail equivalently
to the primary MX server. the mechanism by which this is accomplished is
unspecified. one mechanism which will work is to provide at least
one dual-stack MTA with both v4 and v6 connectivity as a mail exchanger.
other mechanisms may also be feasible.
it is RECOMMENDED that v6-only sites find some means of reaching
v4-only MTAs, by routing all externally-bound v4-only mail to an
external MTA which has agreed to relay such traffic.
realistically, given the "head start" that IPv4 mail has had over
IPv6, it will generally be necessary for IPv6 sites to make arrangements
for *both* incoming and outgoing IPv4 mail transfer.
- v4-only sites:
it is RECOMMENDED that v4-only sites provide at least one MX
for their recipient domains which is reachable via IPv6.
this MX MAY be external to the recipient site.
if it is desired to use this MX only when the sender has no v4
connectivity, the MX which accepts v6 traffic can be listed with
a higher preference than all other MXes.
this MX *must* either have some reliable means to relay mail to the
primary MX server, or it must otherwise handle incoming mail equivalently
to the primary MX server. the mechanism by which this is accomplished is
unspecified. one mechanism which will work is to provide at least
one dual-stack MTA with both v4 and v6 connectivity as a mail exchanger.
other mechanisms may also be feasible.
(note that any site with v4 connectivity and globally-usable addresses
can establish Ipv6 connectivity for such an MX, without needing to
set up a separate connection, using 6to4.)
- sites with both IPv4 and IPv6 connectivity
it is RECOMMENDED that sites with IPv4 and IPv6 connectivity provide
one or more MXes that are reachable by v4 and one or more MXes that
are reachable by v6.
these MXes MAY be located on the same, or different, hosts. however,
different hosts supporting MTAs SHOULD be listed under different
domains. all of the v4 or v6 addresses listed for a particular MX
domain SHOULD reach same host. (this is needed for fail-over from
one SMTP server to another to work correctly)
- ISPs
ISPs are encouraged to provide mechansisms to:
- allow their IPv4-only customers to send mail to IPv6-only sites
- allow their IPv6-only customers to send mail to IPv4-only sites
- allow their IPv4-only customers to receive mail from IPv6-only sites
- allow their IPv6-only customers to receive mail from IPv4-only sites
support for outbound mail (from the ISP's customers to sites that
would otherwise be unreachable) MAY be implemented by the ISP
providing one or more external MTAs which can relay mail from the
customer's network to a destination network which would otherwise be
unreachable by the customer. due to spamming and other concerns,
such MTAs SHOULD NOT be configured (or expected) to handle traffic
from arbitrary sources to arbitrary destinations, but ONLY cross-realm
(v4 to v6 or vice versa) traffic from that ISP's customers. it would
be reasonable for the ISP to require that a standard (non-proprietary)
SMTP AUTH mechanism be used to verify the customer's authenticity.
other mechanisms for providing that connectivity might also be feasable.
if an ISP provides outgoing cross-realm relaying for its customers,
each customer must configure its own MTAs to use those relays.
ISPs MUST NOT modify DNS responses to automatically include such MXes
in the results seen by customers' MTAs.
support for inbound mail (to the ISP's customers) can be provided by
the ISP providing one or more MTAs that are willing to act as secondary
mail exhangers for the ISP's customers, and which the customer advertises
in its DNS records. these MTAs MAY be ordinary MTAs with dual-stack
capability, or they MAY be v4-to-v6 (or vice versa) protocol translators
which are explicitly configured to reach the customer's MTA.
such MTAs SHOULD NOT be configured (or expected) to handle traffic from
arbitrary sources to arbitrary destinations, but ONLY cross-realm (v4
to v6 or vice versa) traffic destined for that ISP's customers.
in order to prevent this from being exploited by spammers, it would be
reasonable for the ISP to assign a separate address and domain per
customer to be used for such purposes, and or MTAs provided by the
ISP to refuse to accept incoming mail that did not have the proper
destination IP address for that customer.
if an ISP provides incoming cross-realm MX relaying for its customers,
each customer must configure its own DNS zones to use those MXes.
ISPs MUST NOT modify responses from customers' DNS servers to automatically
include such MXes.
--------------------------------------------------------------------------
*whew*
I don't claim to have all of the above details correct, but I think that
the *right* solution looks more-or-less like this. and I do think we
need to specify about this level of detail.
I don't think that we can expect all customers to provide their own MXes
for both IPv4 and IPv6, and I don't think we can come up with a
"one size fits all" solution for connectivity. ISPs will in some cases
need to bridge the gap, but they are often in a good position to know
what their customers need.
Keith