Hi,



I have reviewed this document as part of the security directorate's 


ongoing effort to review all IETF documents being processed by the IESG. 


These comments were written primarily for the benefit of the security area 


directors.  Document editors and WG chairs should treat these comments 


just like any other last call comments.






Overall, this looks like a good document and I don't have any concerns 


with it.





I do have a few nits that you may want to look at.

In the Introduction, s/miniml/minimal/



I think that you're missing a comma in the last paragraph:  Perhaps it 


should be (with second comma added):



   This specification defines new SRV service types for the message
   submission, IMAP and POP3 services, to enable simple auto
   configuration of email clients.




Also, the Introduction does not seem to flow very well.  If I may suggest 


the following, which is just a rearrangement of the content:



SUGGESTED:
---
   Internet Email protocols include SMTP [RFC5321], IMAP [RFC3501] and
   POP3 [RFC1939].  Both IMAP and POP3 are mail access protocols used by
   email clients to manipulate email messages after delivery.

   [RFC2782] defines a DNS-based service discovery protocol that has
   been widely adopted as a means of locating particular services within
   a local area network and beyond, using SRV RR records.

   [RFC5321] defines the MX RR record type to locate SMTP services for a
   domain.  However, [RFC4409] defines a "profile" of the SMTP service
   that is specifically used for message submission - which is of direct
   relevance to email clients which typically don't use MX records.

   Typically email clients have required users to enter host name and
   port information for the services they need.  This is not ideal as
   the way in which server information is specified can differ from
   client to client, and can be confusing to users, leading to errors
   when inputting the details.  A better approach would be to require
   minimal information to be entered by a user which would result in
   automatic configuration of appropriate services for that user.  The
   minimal information entered would be the user's email address.

   This specification defines new SRV service types for the message
   submission, IMAP and POP3 services, to enable simple auto
   configuration of email clients.
---

The last sentence in the 4th paragraph of Section 4 is:
   When using transport layer
   security in this way, clients SHOULD use the TLS Server Name
   Indication [RFC4366] and include the service domain name used in the
   SRV record lookup as the name.
Perhaps to fully qualify this, it should be:
   When using transport layer
   security in this way, clients SHOULD use the TLS Server Name
   Indication [RFC4366] and include the service domain name used in the
   SRV record lookup as the name of the server it is contacting.



In most cases the term "server" references the email server, in much the 


same way that "client" refers to the email client.  However, there are 


some cases of "TLS Server" and "DNS Server".  It might be good to qualify 


that.  Perhaps a statement in Section 2 to say, "If not otherwise 


qualified, the term server refers to hosts offering the POP3 or IMAP 


service."






I'm curious as to why you're not asking for an IANA registry be created 


for this.  A quick search shows that there is for IM SRV labels.



  

http://www.iana.org/assignments/im-srv-labels



Regards,
Chris