The IESG has approved the following document: - 'Use of SRV Records for Locating Email Submission/Access services ' <draft-daboo-srv-email-05.txt> as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Alexey Melnikov. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-daboo-srv-email-05.txt Technical Summary This specification defines new SRV service types for the message submission, IMAP and POP3 services, to enable simple auto- configuration of MUAs. The priority field of the SRV record can also be used to indicate a preference for one message store access protocol over another. Working Group Summary This document was reviewed on the ietf-smtp mailing list but is not the product of a working group. Document Quality The documents have been extensively reviewed by people with expertise in email systems. Personnel Ned Freed is the Document Shepherd for this document. Alexey Melnikov is the Responsible Area Director. RFC Editor Note In Section 4, 3rd paragraph, last sentence: Certificate verification MUST use the procedure outlined in Section 4.3 of Replace section 4.3 with section 3. [I-D.saintandre-tls-server-id-check] in regard to verification with an SRV RR as the starting point. In Section 5, 3rd paragraph, 1st sentence: b. If the service provider uses TLS [RFC5246], the service provider MUST ensure a certificate is installed that can be verified by MUAs using the procedure outlined in Section 4.3 of Replace section 4.3 with section 3. [I-D.saintandre-tls-server-id-check] in regard to verification with an SRV RR as the starting point. In Section 6, 2nd paragraph, last sentence: Alternatively, if TLS [RFC5246] is being used for the email service, MUAs MUST use the procedure outlined in Section 4.3 of Replace section 4.3 with section 3. [I-D.saintandre-tls-server-id-check] to verify the service. In Section 6, please replace the 1st paragraph with the following 2 paragraphs: OLD: If a user has explicitly requested a connection with transport layer security (user interfaces sometimes present this choice as a "use SSL" or "secure connection" checkbox), the MUA MUST successfully negotiate transport layer security prior to sending an authentication command. The MUA MAY do this with "imaps", "pop3s", "imap" with "STARTTLS", or "pop3" with "STLS". Service providers MAY offer any subset of these four options for the mail service. NEW: If a user has explicitly requested a connection with a transport layer security mechanism (user interfaces sometimes present this choice as a "use SSL" or "secure connection" checkbox), the MUA MUST successfully negotiate transport layer security prior to sending an authentication command. For example, the MUA MAY do this with "imaps", "pop3s", "imap" with "STARTTLS", or "pop3" with "STLS". Service providers MAY offer any subset of these four options for the mail service. In Section 3.4, please replace "lower priority" with "lower-numbered priority" in 3 places. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
