[Top] [All Lists]

Re: How does SMTP IPv4 and IPv6 work together

2008-04-06 00:11:18

Robert A. Rosenberg wrote:

At 10:25 -0400 on 04/05/2008, Hector Santos wrote about How does SMTP IPv4 and IPv6 work together:

To me, this all makes common sense.  I think the text in 2821bis should
simply lay down the possibilities as done above.  But I do think the
above can be folded to make it into smaller text.

While I agree 100% with your CONNECTIVITY charts/etc. You are ignoring the question of WHEN/IF AAAA records should/can be used in the absence of EXPLICATE MX that points at the AAAA via its RHS.

No.  I did not ignore implicit nor explicit MX considerations.


It is not a connectivity chart per se. It illustrates the RECORD TYPE that *must* be available in order to be able to communicate via one of two TCP Protocols - IPv4 or IPv6.

There is a DIRECT relationship with the record type (A or AAAA) and these tells the software of what is available for data communications.

     A    --> Implies IPv4 TCP protocol stack and vice versa
     AAAA --> Implies IPv6 TCP protocol stack and vice versa


In successful explicit MX results, there was an explicit exposure of A or AAAA records or BOTH for dual stacks.

The looking at the CHART, it will take you that which records will be useful for the client.

If the requester was a IPv4 client, it doesn't matter if the explicit MX result returns AAAA records among A records because IPv4 client is oblivious (doesn't know about) about AAAA records. It doesn't need it and can't use it, but more importantly he can't probably isn't looking for this records to perform the final MX IP expansion (to get the IP address from the A records).


The CHART tells you what actions can be taken for when a MX fails and now the client will look for the "implicit MX" result A.K.A he will look up the IP address of the email address domain part.

So the question is, how doe he get this raw IP address of the email address domain part?

Well, look at the chart.

If the CLIENT is a IPv4 only system, he only knows how to look up one way - the A record.

IMPORTANT - what I am against is any semantics in 2821bis that attempts to CHANGE the behavior of an IPv4 only system by looking up an AAAA record for which he has NO USE for unless he was IPv6 TCP socket capable.

So the BURDEN is on the IPv6 client on what he should look for first or second?

   A    --> IPv6 client is assuming the target domain is IPv4 ready
            The ODDS are very high that will be IPv4 ready. So he might
            select to try this FIRST.

   AAAA --> IPv6 client is assuming the WORLD is IPv6 ready and will
            take its changes of doing an AAAA record first.  If it
            fails, then he might fall back to A record lookup.

The key point is that it the IPv6 system that will have to make the decision. The practical short term solution is mostly A lookup first because the odds are good most systems will be IPv4 ready even its a dual stack host.

So this is why I believe that the only text that is necessary at this point for 2821bis is:

     IPv6 senders connecting to IPv4 systems MUST be aware that IPv4
     systems are ignorant of IPv6 technology and therefore SHOULD
     make it possible to comply with IPv4 SMTP expectations to allow
     for responses.  This implies that IPv6 senders sending mail to
     IPv6 SHOULD|MUST have explicit MX records or implicit MX A
     record at a minimum.

Unless we are opening up 2821bis and extending it to do a full vetting to include all there about implement a 100% supported IPv6 client/server operations, they we need to discuss many aspects, including, but not exclusive, the following concepts:

  - Operational research on vendors experiences,

  - Understand any new augmented technology explored
    (translators, proxies),

  - Understand all the implementation requirements; at the OS
    level, socket level, and at the routers levels which from
    what I have researched is a real possible problem when a
    hop is not IPv6 ready.

  - Get a handle on the software change requirements at the
    socket level,  this looks pretty straight forward, but
    nonetheless it is still a change requirement.

  - Research all the field testing, nationally and world wide,
    reports, presentations, etc.

  - Collect reported security/threat issues such as the
    known HELO/EHLO IPv6 domain literal buffer overflow threats.

  - Offer some synergism by acknowledging the new issues and
    desires related to proposed MX mandates such as the
    standard track proposal by the DKIM/ASP folks.

    Side Note: We can only do a MX mandate for IPv6 and
    for systems that implement DKIM. This offers maximum
    backward compatibility.

  - Collect world wide industry consensus on whether a implicit
    MX is required or not from a SPAM/Security perspective,
    including getting the best current practice for how systems
    do an implicit MX, e.g., we only do 1 SHOT ATTEMPT at
    delivering mail to an implicit MX address.  If that single
    attempt fails, the transaction is bounced or rejected (admin

In summary:

The burden is on IPv6 system to decide what record type to use for failed explicit MX lookups thus falling back to an implicit MX A or AAAA lookup.

If we want to decide this for the IP6 system in 2821bis, I think we risking getting it wrong because there are a few strategies here

   - A first, AAAA second  - the short term practical approach
   - AAAA first, A second  - the long term ideal apprach

and also, maybe using ANOTHER discovery technology that centralizes all these god darn it Domain Lookups, MX, A, AAAA, SPF, DKIM, ASP or FRODO or whatever!

I hope I covered everything.

What justification do you offer to allow an IPv6 MTA to run without an EXPLICATE MX record?

I have started in my proposed in multiple messages and I repeated it above what I believe is the practical solution here and minimal text for 2821bis without going overboard in trying something we are not sure about yet - for new systems using new technology that WANT to continue to operate and communicate in a IPv4, the MUST|SHOULD use a MX and/or implicit MX A record in order to be compatible with current expectations.

What I am not sure off if we should make that a MUST across the board and use IPv6 (and possibly DKIM/ASP) as a spring board to mandating MX records for both IPv4 and IPv6.

I think I am open to slow deprecating on the implicit MX lookup as I originally posted in my input into this discussion. But thats implementator ultimate decision.

The fact that we allow IPv4 MTAs to run with only an A record is NOT a valid excuse since that was/is permitted due to A-Usage predating the existence of the MX record and thus allowed (although that allowance should have been rescinded years ago).

Agree. But it is what it is and if we force an MX, they might be a big impact. All I know here is that recently the implicit MX played a role in helping my brother setup his mail server. He already had a A record fo this simple single machine domain. But the MX record was yet to be available when I set it up. The mail testing was successful via implicit MX A record lookup and we know the MX record would catch up. It probably did within 1 hour or so.

So is this still a needed concept?  I am the fence on that.


Hector Santos, CTO