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.
First:
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
Second:
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).
Third:
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
option).
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.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com