[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 RFC 6186

Network Working Group                                           C. Daboo
Internet-Draft                                                Apple Inc.
Intended status: Standards Track                         August 19, 2009
Expires: February 20, 2010


             Use of SRV records for locating email services
                        draft-daboo-srv-email-02

Status of This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on February 20, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This specification describes how SRV records can be used to locate
   email services.




Daboo                   Expires February 20, 2010               [Page 1]

Internet-Draft                SRV for Email                  August 2009


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Conventions Used in This Document . . . . . . . . . . . . . . . 3
   3.  SRV service types . . . . . . . . . . . . . . . . . . . . . . . 3
     3.1.  Email Submission  . . . . . . . . . . . . . . . . . . . . . 3
     3.2.  IMAP  . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     3.3.  POP3  . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Guidance for mail access clients  . . . . . . . . . . . . . . . 4
   5.  Guidance for Service Providers  . . . . . . . . . . . . . . . . 5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
   9.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6
   Appendix A.  Change History (to be removed prior to
                publication as an RFC) . . . . . . . . . . . . . . . . 7



































Daboo                   Expires February 20, 2010               [Page 2]

Internet-Draft                SRV for Email                  August 2009


1.  Introduction

   [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.

   Internet Email protocols include SMTP [RFC5321], IMAP [RFC3501] and
   POP3 [RFC1939].

   [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.

   Both IMAP and POP3 are mail access protocols used by email clients to
   manipulate email messages after delivery.

   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
   miniml 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.

2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  SRV service types

3.1.  Email Submission

   This specification adds one SRV service type for message submission
   [RFC4409]:

   submission:  Identifies a message submission server as defined by
      [RFC4409].  Note that this covers connections both with and
      without transport layer security [RFC3207].





Daboo                   Expires February 20, 2010               [Page 3]

Internet-Draft                SRV for Email                  August 2009


   Example: service record

       _submission._tcp     SRV 0 1 587 mail.example.com.

3.2.  IMAP

   This specification adds two SRV service types for IMAP [RFC3501]:

   imap:  Identifies an IMAP server that MAY advertise the
      "LOGINDISABLED" capability and MAY require the client to use the
      "STARTTLS" command prior to authentication.  Although these two
      extensions are mandatory-to-implement for both clients and
      servers, they are not mandatory-to-use by service providers.

   imaps:  Identifies an IMAP server where transport layer security is
      initiated directly upon connection to the server.

   Example: service record

       _imap._tcp     SRV 0 1 143 imap.example.com.

   Example: service record

       _imaps._tcp     SRV 0 1 993 imap.example.com.

3.3.  POP3

   This specification adds two SRV service types for POP3 [RFC1939]:

   pop3:  Identifies a POP3 server that MAY require the client to use
      the "STLS" extension command [RFC2595] prior to authentication.

   pop3s:  Identifies a POP3 server where transport layer security is
      initiated directly upon connection to the server.

   Example: service record

       _pop3._tcp     SRV 0 1 110 pop3.example.com.

   Example: service record

       _pop3s._tcp     SRV 0 1 995 pop3.example.com.

4.  Guidance for mail access clients

   By using SRV records as above, clients need initially only prompt the
   user for their email address [RFC5322]. "local-part" and "domain"
   portions are then extracted from the email address by the client.



Daboo                   Expires February 20, 2010               [Page 4]

Internet-Draft                SRV for Email                  August 2009


   The client uses the "domain" portion as the service domain to perform
   SRV lookups for the services it wants to configure.  If the SRV
   lookup is successful the host name and port for the service can be
   determined and used to complete client configuration.  If an SRV
   record is not found, the client will need to prompt the user to enter
   host name and port information directly.

   Clients that support both POP3 and IMAP SHOULD check for both
   services using SRV lookups, and for both SSL and non-SSL variants.
   If both POP3 and IMAP services are returned the choice of which to
   configure is up to the client - it could prompt the user to make a
   choice, or pick one based on local policy.

   Subsequent to configuration, the client will connect to the service.
   When using "imaps" or "pop3s" services, a transport layer security
   negotiation is done immediately upon connection.  With "imap" and
   "pop3" services, the "STARTTLS" or "STLS" commands respectively are
   used to initiate a protected connection.  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.

   Once a suitable connection has been made, and any required protection
   setup, the client will typically need to authenticate with the
   server.  The details of that are governed by the specific protocols
   themselves, though often times a "user identifier" is required for
   some form of user/password authentication (such as the SASL "PLAIN"
   mechanism).  When a user identifier is required, clients MUST first
   use the full email address provided by the user, and if that results
   in an authentication failure, SHOULD fall back to using the "local-
   part" extracted from the email address.  This is in line with the
   guidance outlined in Section 5.

5.  Guidance for Service Providers

   Service providers wanting to offer a POP3 or IMAP service that can be
   configured by clients using SRV records need to follow certain
   guidelines to ensure proper operation.

   a.  Servers SHOULD be configured to allow authentication with email
       addresses or email local-parts.  In the former case, the email
       addresses must not conflict with other forms of permitted user
       login name.  In the latter case, the email local-parts need to be
       unique across the server and not conflict with any login name on
       the server.

   b.  If the service provider uses transport layer security, the
       service provider MUST ensure a certificate is installed that



Daboo                   Expires February 20, 2010               [Page 5]

Internet-Draft                SRV for Email                  August 2009


       matches the email domain name used to configure clients.  If the
       service provider hosts multiple domains on the same IP address,
       then the service provider MUST enable support for the TLS Server
       Name Indication [RFC4366].

   c.  Install the appropriate SRV records for the offered services.

6.  Security Considerations

   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 client MUST successfully
   negotiate transport layer security prior to sending an authentication
   command.  The client 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.

   A malicious attacker with access to the DNS server data can
   potentially cause clients to connect to any server chosen by the
   attacker.  In the absence of a secure DNS option, clients SHOULD
   check that the host name returned in the SRV record matches the
   original service domain that was queried.  If the host is not in the
   queried domain, clients SHOULD verify with the user that the SRV host
   name is suitable for use before executing any connections to the
   host.  Alternatively, if transport layer security is being used,
   clients MUST use the service domain used in the SRV record lookup as
   the server name for certificate verification pruposes.

7.  IANA Considerations

   This document does not require any actions on the part of IANA.

8.  Acknowledgments

   Thanks to Alexey Melnikov, and Chris Newman for feedback and
   suggestions.

9.  Normative References

   [RFC1939]  Myers, J. and M. Rose, "Post Office Protocol - Version 3",
              STD 53, RFC 1939, May 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2595]  Newman, C., "Using TLS with IMAP, POP3 and ACAP",
              RFC 2595, June 1999.




Daboo                   Expires February 20, 2010               [Page 6]

Internet-Draft                SRV for Email                  August 2009


   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, February 2002.

   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              4rev1", RFC 3501, March 2003.

   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 4366, April 2006.

   [RFC4409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
              RFC 4409, April 2006.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.

Appendix A.  Change History (to be removed prior to publication as an
             RFC)

   Changes in -02:

   1.  Tweaked text for imap to better describe mandatory-to-implement
       behavior from base spec.

   2.  Tweaked text for pop3 along similar lines as imap.

   3.  Teaked security considerations to account for use of STARTTLS and
       STLS.

   4.  Added examples for imaps and pop3s.

   5.  Re-worked client guidelines.

   6.  Added service provider guidelines.

   Changes in -01:

   1.  Tweaked text for pop3 to make it clearer that STLS is an
       extension.





Daboo                   Expires February 20, 2010               [Page 7]

Internet-Draft                SRV for Email                  August 2009


   2.  Added text to explain that the email address, as well as the
       local-part, may be used as the user identifier.

   3.  Teaked security considerations to account for use of STARTTLS and
       STLS.

Author's Address

   Cyrus Daboo
   Apple Inc.
   1 Infinite Loop
   Cupertino, CA  95014
   USA

   EMail: cyrus@daboo.name
   URI:   http://www.apple.com/



































Daboo                   Expires February 20, 2010               [Page 8]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/