Protocol Action: 'Use of SRV Records for Locating Email Submission/Access services' to Proposed Standard

The IESG <iesg-secretary@ietf.org> Wed, 16 June 2010 20:22 UTC

Return-Path: <wwwrun@core3.amsl.com>
X-Original-To: ietf-announce@ietf.org
Delivered-To: ietf-announce@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 8CE033A68FC; Wed, 16 Jun 2010 13:22:44 -0700 (PDT)
X-idtracker: yes
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Protocol Action: 'Use of SRV Records for Locating Email Submission/Access services' to Proposed Standard
Message-Id: <20100616202244.8CE033A68FC@core3.amsl.com>
Date: Wed, 16 Jun 2010 13:22:44 -0700
Cc: Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-announce>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Jun 2010 20:22:44 -0000

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.