[Top] [All Lists]

Re: current usage of AAAA implicit MX?

2008-04-04 05:40:29

Paul Smith wrote:

Tony Hansen wrote:

Before we can put the issue of AAAA implicit MX to bed, we need to get an answer to the question of how much AAAA implicit MX is already being used in the real world.

I'm not sure that this is that significant anyway.

For a sending server, if it tries an implicit AAAA when it shouldn't, then it's no biggy, it's just wasting its own resources For a receiving server, it shouldn't (assuming any level of sensible internal authorisation procedures) take long to add an MX record if the standard requires it.

+1 Paul.

I see text as simple as:

     SMTP systems implementing IPv6 connections who wish to
     send mail to a IPv4 only systems MUST offer a MX/A records or
     MUST offer a fallback to a A record for the MAIL FROM return
     path address [including any user response address in RFC 2822
     a MUA or automated MTA may use to create a new reply message].

This alone will make sure SMTP developers or open source keepers do not forget that they need to take this account the IPv4-only world that isn't going to go away for a very very long time.

Anyway way to state this:

    For hybrid SMTP client/server (IPv6/IPv4) sessions, the IPv6
    client MUST comply with 2821 SMTP protocol requirements. This
    means the return path or any user response address used in the
    transaction MUST be resolvable using MX/A records or A record


Overall, I think the difficulty of IPv6 considerations for SMTP has been that was unfortunately designed as an alternative to IPv4, rather than extension. Thus, it is difficult to make this a simple transparent transition without radical software changes at multiple OSI layers.

In order to begin to make any sense from an problem-solving engineering standpoint, I believe we must fundamentally first agree the burden is on IPv6 implementations to make sure they are backward compatible. Not the other way around.

So the key issues I am more interesting in seeing addressed, whether its added to 2821bis or not, is what are key concepts for IPv6/IPv4 interfacing for a IPv4 world oblivious to IPv6 systems. This is the critical part I believe needs to be address in 2821bis because backward compatibility is important. Obviously.

I also think a major important concept to revisit is the current requirement and importance of a valid x821 return path and how it applies in an future IPv6 era. If it still a standard 2821 requirement and expectation that the return path be a valid entity, then this alone enforces the requirement for IPv6 mail senders as well. If this is true, then this will help define some semantics for 2821bis.

I bring the return path because I was getting the impression (possibly incorrectly) that:

   a) It may be desirable to be more tolerant of send only
      clients, and

   b) also allow for support of the growth of consumer
      based hosting devices.

I believe many foresee an era where small device hosting is widespread in the consumer market place, whether by choice or by some installed IPv6 ready appliance or device the consumer is using on his computer and the vendor has implemented a borderline unethically practice to broadcast or call home reporting device via SMTP-IPv6.

I can imagine that if the required valid return path concept is not reinforced for the IPv6 era, then IPv6 can be a greater source for spam or malicious behavior against the IPv4 world.

For example, the IPv6 only client/server sessions will see the same security issues (i.e., Domain::IP associations) the IPv4 only client/server world sees now for the last few decades.

However, in a more plausible IPv6 -> IPv4 session growing world, the IPv4 receiver may experience even more unknown return paths and the IPv6 system runs a higher risk of getting blacklisted.

So this real more plausible IPv6 to IPv4 client/server scenario represents the current and greater critical issue that should be discussed.

In short, whatever is done in 2821bis, I believe it is important that we stress the IPv6 mail system if it wishes to contact a SMTP IPv4 system then it must continue to behave as expected by the SMTP x821 protocol and that basically means the sender must have a MX/A record resolution available either directly or via some proxy host.

Whatever is done for the SMTP x821 protocol as we know it today, the burden must not be placed on existing IPv4 systems. The burden must be placed on IPv6.

Finally, I personally not sure if we want to make sure a MX record is required across the board simply because it isn't today in the IPv4 world.

But we raise the bar above the practice of legacy operations, this provides the opportunity for developers to add new zero-false positive logic to handle the new level of possibilities. That means that IPv6 systems who want to contact a IPv4 system MUST have a MX/A record resolution simply because it is expected today.


Hector Santos, CTO