ietf-smtp
[Top] [All Lists]

Re: (ngtrans) Re: ipv6-smtp-requirement comments?

2001-11-09 15:01:38

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