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
fallback.
Reasoning:
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.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com