INTERNET-DRAFT Eric A. Hall Document: draft-hall-email-srv-00.txt John C. Klensin Expires: May, 2004 November 2003 Category: Standards Track Using SRV Resource Records to Automatically Configure Email Clients Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document specifies SRV resource records for Internet-based message-submission and message-retrieval services, and also defines behavioral rules for messaging clients to use when automatically locating the messaging servers associated with a known mail domain. Internet Draft draft-hall-email-srv-00.txt November 2003 Table of Contents 1. Background and Overview...................................2 2. Prerequisites and Terminology.............................4 3. Messaging Resource Records................................4 3.1. SRV Owner Names........................................5 3.2. SRV Resource Record Data...............................5 3.3. Address Resource Records...............................6 4. Client Processing Algorithms..............................7 4.1. Retrieval Server Lookups...............................8 4.2. Submission Server Lookups.............................10 5. Resource Record Caching..................................11 6. Security Considerations..................................12 7. IANA Considerations......................................13 8. Normative References.....................................13 9. Informative References...................................13 Acknowledgments...............................................14 Authors' Addresses............................................14 Full Copyright Statement......................................14 1. Background and Overview Email networks built around Internet messaging technologies typically use a tiered message-transfer network model. In the common scenario, messaging clients send outgoing email messages to a default "submission" server, with these "first-hop" servers typically performing tasks such as message preparation, routing lookups, and next-hop transfers towards the final destination. Meanwhile, messaging clients which work in the typical model will also usually fetch incoming email messages from a default "retrieval" server, with these "last-hop" servers usually acting as the final delivery system for the user's mail domain. Messaging networks built on this model have historically used the Simple Message Transfer Protocol (SMTP) [RFC2821] and TCP port 25 for the first-hop submission service. However, RFC 2476 [RFC2476] formally defined a variant of SMTP as an explicit message submission service which more accurately reflects the behavioral requirements of the common environment. RFC 2476 also reserved TCP port 587 specifically for use with the formal submission service, but also allows clients and servers to continue using full SMTP over TCP port 25 if necessary or desired. On the retrieval front, there are two standards-track services available for use, which are the Post Office Protocol v3 (POP3) Hall & Klensin I-D Expires: May 2004 [page 2] Internet Draft draft-hall-email-srv-00.txt November 2003 [STD53] and the Internet Message Access Protocol v4rev1 (IMAP4) [RFC3501]. Unlike the submission services, POP3 and IMAP4 are substantially different from each other, using different protocol models, verb dictionaries, and even port numbers (POP3 servers typically use TCP port 110, while IMAP4 servers typically use TCP port 143). Most messaging clients which work in these tiered environments have historically used static configuration data to identify the protocol, hostname and port number for each service, although a variety of products have also attempted to use automated configuration services in an effort to lessen the need for manual administration. For example, some products have used the Dynamic Host Configuration Protocol (DHCP) [RFC2131], the Interactive Mail Support Protocol (IMSP) and the Application Configuration Access Protocol (ACAP) [RFC2244], or even the Lightweight Directory Access Protocol (LDAP) [RFC3377] to store configuration data centrally, allowing clients to fetch the necessary configuration information when they are first loaded. Unfortunately, many of these services are unable to accommodate messaging networks that don't use the default port numbers for the specified service, or are unable to provide recovery information for when the specified server becomes unavailable, are unable to support users on remote networks due to security and bandwidth concerns, or have other issues which make them unsuitable for use with automated configuration management outside of specific environments. Meanwhile, RFC 2782 [RFC2782] introduced a general-purpose mechanism for storing service-specific connection identifiers in the Domain Name System (DNS) [STD13] by way of a generalized Service Location ("SRV") resource record. In the SRV model, a network service can be identified by name within the scope of a particular domain, with multiple SRV resource records identifying the hostnames and port numbers of servers which provide the named service within that domain scope, but with the caveat that these resource records can only provide connection-level information, and cannot provide comprehensive configuration data. This approach can be useful for locating messaging servers in general, but is particularly well-suited to large-scale and diverse installations which cannot easily support the generalized configuration services. In particular, this level of information can be sufficient for automatically initiating messaging sessions (modulo any additional input which may be needed from the user, such as session passwords), determining the servers to use with a new messaging profile, bootstrapping a more-detailed configuration Hall & Klensin I-D Expires: May 2004 [page 3] Internet Draft draft-hall-email-srv-00.txt November 2003 process, or for use as recovery information when a pre-configured messaging server has become unavailable. In support of these kinds of scenarios, this specification defines SRV resource records which can be used to identify the submission and retrieval servers for a particular messaging network, and also defines behavioral rules for messaging clients to use when locating these messaging servers. Specifically, the model put forth in this document uses SRV resource records which are mapped to the domain element of an email address, so that messaging clients can predictably discover the messaging servers that are available to a particular email address. Note that this model assumes that the presence of an email address implies that the user has an account in the associated mail domain, and that the user is therefore authorized to use the servers associated with that domain. In those environments where these assumptions do not reflect the actual messaging network, manual or external configuration data will be needed. 2. Prerequisites and Terminology Readers of this document are expected to be familiar with the specifications for message submission [RFC2476], POP3 [STD53], IMAP4 [RFC3501], and SRV resource records [RFC2782]. 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 RFC 2119 [RFC2119]. 3. Messaging Resource Records SRV resource records have an owner domain name which uniquely identifies a particular service within the scope of a particular domain, and also have data structures which provide information about the target hosts and their preference. Secondarily, the target server hostnames may also need to be resolved into IP addresses via additional lookups. Hall & Klensin I-D Expires: May 2004 [page 4] Internet Draft draft-hall-email-srv-00.txt November 2003 3.1. SRV Owner Names The owner domain name of SRV resource records are a concatenated sequence of labels which identify the service name, the transport protocol associated with that service, and the domain scope, respectively. For SRV resource records which reference submission servers, the first two labels in this sequence MUST be "_submission" and "_tcp", while the domain scope sequence MUST be the same as the mail domain which is used by the messaging clients. For SRV resource records which reference IMAP4 servers, the first two labels in this sequence MUST be "_imap" and "_tcp", while the domain scope sequence MUST be the same as the mail domain which is used by the messaging clients (note that the IANA protocol registration for the IMAP4 service is "imap" and not "imap4"). For SRV resource records which reference POP3 servers, the first two labels in this sequence MUST be "_pop3" and "_tcp", while the domain scope sequence MUST be the same as the mail domain which is used by the messaging clients. Note that the domain scope for these resource records is explicitly defined as the mail domain element of the user's email address, and is not tied to a hostname, a subnet, or any other type of domain name. The client processing algorithms defined in section 4 use the mail domain element of the user's email address as the domain scope of the SRV resource record lookups, so the resource records must be associated with the mail domain name in order for the algorithm to succeed. For example, a messaging client which had been configured to use an email address of "user@example.net" and which needed to locate the submission server for that user would issues lookups for the SRV resource records bound to the "_submission._tcp.example.net" domain name, while an email address of "user@bna.tn.example.net" would cause lookups for "_submission._tcp.bna.tn.example.net" to be issued. 3.2. SRV Resource Record Data The SRV resource record data structure is described in detail in RFC 2782. In summary, the SRV resource record provides fields which identify a target server hostname, the port number of the Hall & Klensin I-D Expires: May 2004 [page 5] Internet Draft draft-hall-email-srv-00.txt November 2003 associated service on that server, and priority and weighting data which reflect the overall preference of each particular server in the answer set. Note that the client-processing algorithms described in section 4 allows a target server to be chosen from among an equally weighted set of answers by determining if any of the servers share the same sub-domain as the messaging client. This mechanism may be useful in those cases where a large and distributed messaging network shares a common mail domain for all of its users, but where that organization still needs to direct specific users towards servers that are dedicated to particular sub-domains or regions. In general terms, organizations which choose to support the use of SRV resource records are encouraged to provide multiple servers with different preference values, thereby allowing clients to automatically discover alternate servers in case the preferred server becomes unreachable or otherwise unavailable. 3.3. Address Resource Records Once a preferred server has been determined, its hostname will need to be resolved into an IP address with a lookup for the IP address resource records associated with the server's domain name. Note that the client processing algorithms described in section 4 allows an IP address to be chosen from among an equally weighted set of answers by allowing the client to determine which of the servers are "closest", based on the IP addresses of the client and the server(s). This mechanism may be useful in those cases where a large and distributed messaging network shares a common mail domain for all of its users, but where that organization still needs to direct specific users towards servers which are dedicated to particular subnets or regions. For example, some organizations may be able to leverage resolvers which attempt to locate the "closest" server through subnet- mapping or response-time monitors, while other organizations may be able to use load-balancing technologies which control the answer sets that are returned to the clients. Discussion of these technologies is beyond the scope of this document, although administrators should be aware of their potential use. Hall & Klensin I-D Expires: May 2004 [page 6] Internet Draft draft-hall-email-srv-00.txt November 2003 4. Client Processing Algorithms This section describes the behavioral rules for messaging clients which need to locate the messaging servers associated with a known mail domain. In general terms, messaging clients are expected to locate the retrieval servers associated with a known mail domain whenever incoming email messages need to be retrieved, and are expected to locate the submission servers associated with a known mail domain whenever outgoing email messages need to be sent. However, this is an extremely simplistic overview of the process, with many potential exceptions. For example, a messaging client may be designed to use retrieval- service extensions to perform message submission (such as using a POP3 "submission" extension), and in those cases, the client would use the SRV resource records associated with the retrieval service rather than the submission service. Furthermore, IMAP4 sessions tend to be fairly long-lived, and may involve distinct connections to different folders, but since changes to the resource record data could theoretically result in different servers being chosen for each specific folder, messaging clients need to reuse the current IP address for all of the active IMAP4 connections instead of issuing new lookups for each session. Once a server has been located, messaging client MAY attempt to automate any login or local configuration processes, as desired. For example, clients MAY attempt to use the local-part element of the email address as a login identifier for a given session, or MAY attempt to probe for any service-specific configuration data such as an IMAP4 namespace or subscription hierarchies. However, attempts to automatically discover the configuration information may have a high likelihood of failure, either because some of the elements may not be predictable or accurate (E.G., the session username may not be identical to the local-part element of the email address), or because different server products may have implemented features in slightly different ways. Since this process is somewhat prone to failure, it is not defined in this specification, although these probes are not prohibited. Notwithstanding all of the above, whenever lookups for messaging servers are generated, the messaging clients are expected to generate DNS lookups for the SRV resource records associated with Hall & Klensin I-D Expires: May 2004 [page 7] Internet Draft draft-hall-email-srv-00.txt November 2003 the user's known mail domains. Clients SHOULD NOT issue lookups for the domain name associated with the local hostname, SHOULD NOT issue lookups for networks they are attached to, and SHOULD only issue lookups for the SRV resource records associated with a known mail domain. If multiple "identities" have been defined which use different mail domains in the return email address, the process SHOULD be repeated for each unique mail domain. Also note that some DNS resolvers are known to filter and restrict the resource record data which gets returned, and in those cases, the messaging client may need to issue its own "raw" DNS queries in order to ensure that all of the information is retrieved and processed correctly. 4.1. Retrieval Server Lookups Messaging clients which support both IMAP4 and POP3 SHOULD first attempt to locate the IMAP4 servers associated with the mail domain, and SHOULD NOT attempt to locate POP3 servers unless no IMAP4 servers can be located. Conversely, a messaging client which only supports one or the other service SHOULD only issue lookups for the retrieval service that the client supports, and SHOULD NOT issue lookups for services that are not supported by the messaging client itself. Clients which claim to be compliant with this specification SHOULD iterate at least once through the following steps for each eligible identity: a. Determine if a retrieval server has been defined manually or through another configuration service, and if that data has been given preference. If so, only continue if those servers are determined to be unreachable or unavailable (potentially including any routing errors, TCP errors, or session errors which indicate that the client cannot currently use the server). b. Extract the mail domain element from the user's email address, and append the "_imap" and "_tcp" labels to the left of that domain name. c. Issue a DNS query for the SRV resource records associated with the domain name formed in the preceding step. Hall & Klensin I-D Expires: May 2004 [page 8] Internet Draft draft-hall-email-srv-00.txt November 2003 d. If multiple resource records are returned, sort them according to the rules specified in RFC 2782, and determine the preferred target. 1. If multiple candidate targets still exist, the client MAY give preference to any servers which have a hostname that appears to be in the same sub-domain as the client hostname. 2. If multiple candidate targets still exist, choose one at random. e. Use the port number determined in step 4.1.d as the port number for the retrieval server. f. Determine the IP address for the target server. 1. If multiple IP addresses are discovered, the client MAY use any services at its disposal to determine the IP address which appears to be the closest match to the local client's IP address. 2. If multiple candidate addresses still exist, choose one at random. g. Use the IP address determined in step 4.1.f as the IP address for the retrieval server. h. If the currently-preferred server is unavailable, locate the next-best target. 1. If multiple addresses were associated with the currently-preferred server, restart the process at step 4.1.f to determine the next-best IP address. 2. If all of the IP addresses for the currently-preferred target have been tried and multiple SRV resource records were discovered, use the next-preferred SRV resource record from step 4.1.d. Clients SHOULD NOT try the next-preferred target until all of the IP addresses associated with the currently-preferred target have been tried. Hall & Klensin I-D Expires: May 2004 [page 9] Internet Draft draft-hall-email-srv-00.txt November 2003 i. If no IMAP4 servers were discovered, extract the mail domain element from the user's email address, append the "_pop3" and "_tcp" labels to the left of that domain name, and restart the process at step 4.1.c. If no POP3 servers were discovered, exit the algorithm and report the failure to the user. 4.2. Submission Server Lookups Since the submission and SMTP services can both be defined through a single SRV resource record, only a single SRV resource record is defined for use with the submission service. Clients which claim to be compliant with this specification SHOULD iterate through the following steps for each eligible identity: a. Determine if a submission server has been defined manually or through another configuration service, and if that data has been given preference. If so, only continue if those servers are determined to be unreachable or unavailable (potentially including any routing errors, TCP errors, or session errors which indicate that the client cannot currently use the server) b. Extract the mail domain element from the user's email address, and append the "_submission" and "_tcp" labels to the left of that domain name. c. Issue a DNS query for the SRV resource records associated with the domain name formed in the preceding step. d. If multiple resource records are returned, sort them according to the rules specified in RFC 2782, and determine the preferred target. 1. If multiple candidate targets still exist, the client MAY give preference to any servers which have a hostname that appears to be in the same sub-domain as the client hostname. 2. If multiple candidate targets still exist, the client SHOULD give the highest preference to targets which use port 587, and SHOULD give the lowest preference to targets which use port 25. Hall & Klensin I-D Expires: May 2004 [page 10] Internet Draft draft-hall-email-srv-00.txt November 2003 3. If multiple candidate targets still exist, choose one at random. e. Use the port number determined in step 4.2.d as the port number for the submission server. f. Determine the IP address for the target server. 1. If multiple IP addresses are discovered, the client MAY use any services at its disposal to determine the IP address which appears to be the closest match to the local client's IP address. 2. If multiple candidate addresses still exist, choose one at random. g. Use the IP address determined in step 4.2.f as the IP address for the submission server. h. If the currently-preferred server is unavailable, locate the next-best target. 1. If multiple addresses were associated with the currently-preferred server, restart the process at step 4.2.f to determine the next-best IP address. 2. If all of the IP addresses for the currently-preferred target have been tried and multiple SRV resource records were discovered, use the next-preferred SRV resource record from step 4.2.d. Clients SHOULD NOT try the next-preferred target until all of the IP addresses associated with the currently-preferred target have been tried. 3. If all of the IP addresses for all of the SRV resource records have been tried, report the error to the user and exit the algorithm. 5. Resource Record Caching Messaging clients SHOULD NOT store the discovered configuration information for a length of time greater than the Time-to-Live values associated with the underlying resource records. Instead, clients SHOULD delete the discovered information whenever the underlying resource records have expired, and SHOULD NOT issue new queries until a new connection needs to be established. This Hall & Klensin I-D Expires: May 2004 [page 11] Internet Draft draft-hall-email-srv-00.txt November 2003 approach ensures that the messaging client will always get the latest information when accuracy is most critical. However, multiple lookups for IMAP4 servers SHOULD NOT be issued unless no connections for that profile are already active. If a profile already has an active (and working) connection established, then all of the other connections for that profile MUST reuse the existing server-specific socket tuple, and additional lookups for that profile MUST NOT be generated unless the current server becomes unavailable. Zone operators SHOULD NOT use excessively small or excessively small Time-to-Live values. As a general rule of thumb (subject to operator-specific requirements, of course), Time-to-Live values between a few hours and a few days tend to work the best. 6. Security Considerations Administrators should carefully consider if and how they want to make the resource records described in this document available to users, particularly those users who may be on remote networks. Since this resource record provides information in a predictable form, hostile parties with access to the resource records can learn some operational details about the messaging infrastructure simply by issuing predictable DNS queries. However, the potential risks from exposing operational information about a messaging network to external parties should not be overstated. In the usual case, the same information can be learned by analyzing the Received headers in email messages which have passed through that same network. In this regard, providing this information in a resource record is no more of a risk than providing the information in a Received header of a message which has passed through that network. DNS domain names can be easily spoofed, and this is especially easy when the victim uses a DNS server under the control of a hostile party. By using a relatively simple technique, a hostile party can provide SRV resource records which redirect a user towards a hostile SMTP server, allowing the interloper to read and act upon the user's outbound email at will. Strong authentication services, transfer-layer encryption techniques, and message encryption are usually cited as sufficient defenses against such attacks, in that they can prevent illegitimate sessions from being established and/or can make message contents unreadable. Hall & Klensin I-D Expires: May 2004 [page 12] Internet Draft draft-hall-email-srv-00.txt November 2003 Refer to RFC 2782 for the security considerations associated with the use of SRV resource records in general. Refer to RFC 2476 for the security considerations associated with the use of the message-submission service. 7. IANA Considerations This document does not create any IANA considerations. 8. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2476] Gellens, R., and J. Klensin, "Message Submission", RFC 2476, December 1998. [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC3501] M. Crispin, "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003. [STD53] Myers, J., and M. Rose, "Post Office Protocol - Version 3", RFC 1939, May 1996. 9. Informative References [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2244] Newman, C., and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997. [RFC2821] J. Klensin, "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC3377] Hodges, J., and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002. [STD13] Mockapetris, P. "Domain Names - Concepts and Facilities", STD 13, RFC 1034 and "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987. Hall & Klensin I-D Expires: May 2004 [page 13] Internet Draft draft-hall-email-srv-00.txt November 2003 Acknowledgments Funding for the RFC editor function is currently provided by the Internet Society. Authors' Addresses Eric A. Hall ehall@ehsco.com John C. Klensin john-ietf@jck.com Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Hall & Klensin I-D Expires: May 2004 [page 14]