[Top] [All Lists]

Re: Last Call: draft-klensin-rfc2821bis

2008-03-26 00:28:52
On Wed, Mar 26, 2008 at 12:10:38AM -0700, SM wrote:
At 19:32 25-03-2008, Bill Manning wrote:
        er...  what about zones w/ A & AAAA rr's and no MX's?
        when I pull the A rr's, you are telling me that SMTP
        stops working?  That is so broken.

SMTP will still work as the above case is covered by the implicit MX rule.

        presuming the existance of an MX...  (thats the "implicit"
        part of the "rule").

The implicit MX rule creates an ambiguity during the transition from 
IPv4 to IPv6.  That's discussed in Section 5.2 of the draft:

   "The appropriate actions to be taken will either depend on local
    circumstances, such as performance of the relevant networks and any
    conversions that might be necessary, or will be obvious
    (e.g., an IPv6-only client need not attempt to look up
    A RRs or attempt to reach IPv4-only servers). Designers of
    SMTP implementations that might run in IPv6 or dual stack
    environments should study the procedures above, especially the
    comments about multihomed hosts, and, preferably, provide mechanisms
    to facilitate operational tuning and mail interoperability between
    IPv4 and IPv6 systems while considering local circumstances."

        what this daft is trying to do is force the presumptive
        existance of an MX in a zone into an explict rule that 
        forces the existance of an MX, else SMTP fails.

We could look at the question by asking whether the fallback MX 
behavior should be an operational decision.  But then we would be 
treating IPv4 and IPv6 differently.

        IPv4 and IPv6 are different.



IETF mailing list


Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

IETF mailing list