Re: [apps-discuss] Feedback on draft-moonesamy-smtp-ipv6-00

[S Moonesamy <[e-mail]>]

Hello,

I'll summarize the feedback on draft-moonesamy-smtp-ipv6-00.  As 
usual, please correct me if I misinterpreted your comments.

Frank Ellermann [1] commented about the removal of the MX examples 
and mentioned that it helped him understand what RFC 3974 was 
about.  He suggested discussing the IPv6-only behaviour if IPv4 
addresses are reachable by some mapping mechanism.

John Levine [2] commented on step (9):

   "In step (9), you say "If a transient failure condition is reported,
    try the next MX RR" which looks wrong to me.  If you get a 4xx, you
    requeue the message and try it again later."

Tony Finch [5] mentioned that it "is a point of repeated disagreement 
and there is no accepted consensus".  Ned Freed [6] mentioned that 
"the point in the dialogue at which the 4yz is returned can also be a 
factor.  It's one thing to retry on a different A after getting a 4yz 
host temporarily unavailable response to EHLO; it's rather different 
to retry a different A after getting a 4yz user is over quota 
response to the final dot".

Murray Kucherawy [3] mentioned that the "SMTP Sender Algorithm in a 
Dual-Stack Environment" in RFC 3974, which has been removed in the 
draft, is useful for illustration.  He also asked whether the draft 
resolves the aspects of RFC3974 that were in conflict with what RFC5321 says.

I suggested the following text change for step (9):

(9)  Attempt to deliver the email over the connection established, as
      specified in RFC 5321.  If a transient failure condition is
      reported, try again as defined in RFC 5321 Section 4.5.4.1.

As John Levine [4] pointed out, "different MTAs have rather different 
retry strategies, both different timeouts, and different rules for 
how they retry, e.g., retry the same target host, retry starting at 
the same MX distance, retry from scratch.  Whether some or all of the 
hosts are on IPv6 doesn't change any of that".  The amended text does 
not prescribe a particular strategy.

Tony Finch [7] asked: with respect to dual stack, what is missing 
from section 5 of RFC 5321?

Dave Crocker [8] would like to see some very explicit discussion of 
"what details need to be covered that are not covered by 5321 (and to 
help get the consensus, what details in the new draft are redundant 
with which details in 5321".

RFC 3974 has been implemented in Exim, MS Exchange, Postfix and 
Sendmail.  RFC 5321 did not change the status of RFC 3974 (currently 
Informational, with an IESG Note).  Section 5.2 of RFC 5321 discusses 
about IPv6 and MX Records and mentions that the recommendations in 
RFC 3974 appear to be inconsistent with RFC 5321.

 From the note in step (5) in RFC 3974:

   "To encourage the transition from IPv4 SMTP to IPv6 SMTP, AAAA records
    should take precedence."

This has been changed in the draft to:

   "To encourage the transition from IPv4 to IPv6, AAAA RRs may take 
precedence."

The major change is the removal of the DNS-specific discussion (e.g. 
SERVFAIL, the note in step (4)), align the algorithm in RFC 3974 with 
the current standard and fix step (9).  I left the comment from 
Murray about providing more current operational experience open.  It 
may go into the appendix together with the MX examples (see Frank's 
comment).  I'll leave it to the editor of RFC 5321 to comment on 
whether the level of detail, e.g. the algorithm, would fit in a 
revision of that RFC.

RFC 5321 covers dual stack.  It also has the requirement "MUST be 
reported as an error" which is applicable for IPv6-only hosts trying 
to reach IPv4-only hosts.  Instead of a mapping mechanism, it is 
easier to make use of existing MX functionality by listing a 
dual-stack host to provide an alternate route to the destination.

Regards,
S. Moonesamy

1. msg-id: CAHhFybqtrwGN=[e-mail]
2. msg-id: [e-mail]
3. msg-id: 
[e-mail]
4. msg-id: [e-mail]
5. msg-id: [e-mail]
6. msg-id: [e-mail]
7. msg-id: [e-mail]
8. msg-id: [e-mail]