Subject: [v6ops] Comments on draft-oreirdan-rosenwald-ipv6mail-transition-00

From: SM <[email-masked]>
Date: Sun, 31 Jul 2011 00:21:30 -0700

Hello,

I have a few comments about 
draft-oreirdan-rosenwald-ipv6mail-transition-00.  I am copying this 
message to the V6OPS mailing list as this draft has been discussed 
here previously.  I don't think that the V6OPS WG is a best fit for 
this document.  Its charter mentions groups or areas who have primary 
responsibility for specific protocols.  You could see whether APPSAWG 
would take up this draft.

The draft attempts to cover several angles.  The inbound mail abuse 
angle (Section 11 and 12) could end up being controversial.  I 
suggest keep it separate from the other angles.

In an email context, you can have:

  Inbound mail (SMTP)

  Outbound mail (SMTP)

  Message submission (SUBMIT)

  Message store access (IMAP, POP3)

In Section 1.4, the reference for SMTP should be RFC 5321.

Section 1.5 should use "POP3" instead of "POP".

The draft does not have any mention of IMAP.  It does not make any 
distinction between SMTP and SUBMIT.  draft-ietf-yam-rfc4409bis-02 
mentions that message submission has been split from message relay 
allowing each service to operate according to its own rules.  That 
document designates port 587 for mail submission but also allow sites 
to use port 25.   From Section 12 of 
draft-oreirdan-rosenwald-ipv6mail-transition-00:

  "Submitting of unauthenticated port 25 mail to outbound IPv6 email
   servers MUST be prohibited."

I suggest referencing draft-ietf-yam-rfc4409bis-02 or RFC 4409 
instead putting in such a prohibition.  I am aware of the long and 
inconclusive discussions about port 25.  I'll stay out of that.

Given that there are already several inbound mail servers accessible 
over IPv6, outbound mail can be sent over IPv6.

To receive (inbound) mail over IPv6, it is a matter of the SMTP 
client locating a MX which resolves to a DNS AAAA record.  Obviously, 
the client SMTP and MX will require IPv6 connectivity between 
them.  Sites would have to review their mail infrastructure (e.g. 
mail filters) and see whether that they can implement existing local 
policies in an IPv6 environment.

Message submission should be fairly straight-forward as MUAs fallback 
to IPv6 if the submission server is not accessible over IPv6.  I'll 
ignore IPv6 transport issues as it would be better to discuss about 
that in a separate document.

Message store access and message submission would face the legacy 
issue as MUAs are not updated that often.  That is less of a problem 
for Webmail.

BTW, the draft has references to RFC 4472 and RFC 6186.  These RFCs 
discuss about two different ways to locate the MSA and the message store.

The text in Section 5 about the phases for the transition uses RFC 
2119 key words.  I suggest removing the requirement 
language.  Instead of trying to set dates for a transition, you could 
look at the topic from a different perspective, i.e. an email service 
provider's plan to support IPv6 and how it expects to tackle the 
various issues.

Regards,
-sm