INTERNET-DRAFT Eric A. Hall Document: draft-hall-submit-srv-00.txt John C. Klensin Expires: January, 2004 June 2003 Category: Standards Track Message-Submission SRV Resource Record 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 the use of SRV resource records for locating the message-submission servers associated with a known mail domain. Internet Draft draft-hall-submit-srv-00.txt June 2003 Table of Contents 1. Background and Overview...................................2 2. Prerequisites and Terminology.............................4 3. Message-Submission Resource Records.......................4 3.1. SRV Owner Name.........................................4 3.2. SRV Resource Record Data...............................5 3.3. Address Resource Records...............................5 4. Client Processing Algorithm...............................6 5. Resource Record Caching...................................8 6. Security Considerations...................................8 7. IANA Considerations.......................................9 8. Author's Address..........................................9 9. Normative References......................................9 10. Informative References...................................10 11. Acknowledgments..........................................10 12. Full Copyright Statement.................................10 1. Background and Overview Email networks built around Internet technologies typically use a tiered network for outbound transfers, with messaging clients sending non-local messages to a default "submission" server, with that server subsequently performing the message preparation, routing and transfer services on behalf of the local clients. Messaging networks built on this model have historically used the Simple Message Transfer Protocol (SMTP) [RFC2821] and TCP port 25 for this "first-hop" transfer purpose, although RFC 2476 [RFC2476] formally defined a variant of SMTP with slightly different behavioral rules as an explicit message submission service for use in these environments. RFC 2476 also reserved TCP port 587 specifically for use with the submission service, but also allowed clients and servers to continue using SMTP over TCP port 25 if necessary or desired. Most of the messaging clients which used the submission model have also historically used static configuration data to identify the submission host and port, although a variety of products have attempted to use automated configuration services in an effort to lessen the need for manual administration. For example, some products have used Mail Exchange (MX) resource records associated with the sender's domain to try and locate a submission server, under the assumption that the inbound transfer server(s) would also be appropriate for outbound transfers. Meanwhile, some Hall & Klensin I-D Expires: December 2003 [page 2]
Internet Draft draft-hall-submit-srv-00.txt June 2003 products have used the Dynamic Host Configuration Protocol (DHCP) [RFC2131], the Interactive Mail Support Protocol (IMSP) and the derivative Application Configuration Access Protocol (ACAP) [RFC2244], and even the Lightweight Directory Access Protocol (LDAP) [RFC3377] to store configuration data centrally, allowing clients to retrieve the submission host and port identifiers when they were started. Unfortunately, many of these services are unable to accommodate messaging networks that don't use TCP port 25 for the submission service, or are unable to support users on remote and/or slow networks, or have other issues which make them unsuitable for use with automated configuration management outside of specific environments. Separately, 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 that model, a network service can be identified by name, and SRV resource records for that service can be created within the scope of a particular domain, with each SRV resource record identifying the hostname and port number of a server which provides the named service within that domain scope. This approach is well suited to the submission service for a variety of reasons, and is particularly well suited to large-scale and diverse installations who cannot easily support the more generalized configuration services. First of all, each SRV resource record can specify a unique hostname and port number pair, thereby allowing multiple hosts and/or port numbers to be linked to a single submission service. Furthermore, each SRV resource record carries preference and weighting values which allow administrators to specify a "preferred" submission server as well as secondary or tertiary servers if the preferred server becomes unavailable. Finally, the use of DNS for this kind of configuration information facilitates deployment and access in broad scales, especially since DNS is already commonly used for other kinds of connection-level identifiers, and many organizations have already dealt with the policy and architectural considerations surrounding the use of DNS for that kind of information. For all of the reasons listed above, this specification defines the usage of SRV resource records with submission services, for use in environments where this kind of configuration management would be appropriate. Note that this service is not mandatory for any messaging network, and other configuration management systems may continue to be used as necessary or desired. Furthermore, it Hall & Klensin I-D Expires: December 2003 [page 3]
Internet Draft draft-hall-submit-srv-00.txt June 2003 is important to recognize that this specification does not define any site-to-site routing services, location information for message-retrieval servers, proprietary submission services, or anything other than identifying the SMTP-based submission servers for a messaging network. 2. Prerequisites and Terminology Readers of this document are expected to be familiar with the specifications for message submission [RFC2476] 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. Message-Submission Resource Records SRV resource records have an owner 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. In addition to the SRV resource records, "target" server hostnames must also be resolved into IP addresses via secondary lookups. 3.1. SRV Owner Name The owner 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 message submission SRV resource records, 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. Note that the domain scope is explicitly defined as a particular "mail domain", and is not tied to a hostname, a subnet, or any other type of domain name. The client algorithm defined in section 4 causes messaging clients to use the mail domain element of their return email addresses as the domain scope of the SRV resource record lookups, so the resource records must be associated with the mail domain names in order for the algorithm to succeed. Hall & Klensin I-D Expires: December 2003 [page 4]
Internet Draft draft-hall-submit-srv-00.txt June 2003 For example, messaging users in the "example.net" mail domain would issues lookups for the SRV resource records bound to the "_submission._tcp.example.net" domain name, while messaging users in the "bna.tn.example.net" mail domain would issue lookups for "_submission._tcp.bna.tn.example.net". SRV resource records would need to be bound to those domain names in order for the messaging clients in those mail domains to locate the resource records. 3.2. SRV Resource Record Data The SRV resource record data structure is described in detail in RFC 2782. In brief, the SRV resource record data segment provides multiple fields which identify a target server's hostname, the port number, and priority and weighting data which cumulatively determines the overall preference level of that particular SRV resource record in the set. Note that the client-processing algorithm described in section 4 allows a preferred target server to be chosen from among an equally weighted set of answers by allowing the client to determine if any of the servers are in the same sub-domain as the client itself. 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 the users towards servers which 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 resource records 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 is subsequently resolved to an IP address with a lookup for the IP address resource records associated with the server's domain name. Note that the client-processing algorithm described in section 4 allows a preferred target server to be chosen from among an equally weighted set of answers by allowing the client to determine the "closest" server, based on IP addresses. 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 Hall & Klensin I-D Expires: December 2003 [page 5]
Internet Draft draft-hall-submit-srv-00.txt June 2003 the 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. 4. Client Processing Algorithm In general terms, messaging clients are expected to generate DNS lookups for the submission-specific SRV resource records associated with 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, but SHOULD instead only issue lookups for the SRV resource records associated with their known mail domains. If multiple "identities" have been defined on the messaging client which use different mail domains in the return address, the lookup process SHOULD be repeated for each mail domain, unless the user specifies otherwise. 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. If so, give preference to that information, and only continue if the identified servers are unreachable. 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 step 4.b. Hall & Klensin I-D Expires: December 2003 [page 6]
Internet Draft draft-hall-submit-srv-00.txt June 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, 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. 3. If multiple candidate targets still exist, choose one at random. e. Use the port number determined in step 4.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.f as the IP address for the submission server. h. If the currently-preferred server is subsequently determined to be unreachable or unavailable (potentially including any routing errors, TCP errors, or SMTP errors which indicate that the client cannot currently use the server), locate the next-best target. 1. If multiple addresses were associated with the currently-preferred server, restart the process at step 4.f to determine the next-best IP address. Hall & Klensin I-D Expires: December 2003 [page 7]
Internet Draft draft-hall-submit-srv-00.txt June 2003 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.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. 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 query in order to ensure that all of the information is retrieved and processed correctly. 5. Resource Record Caching Submission clients SHOULD NOT store or reuse 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 only reissue the queries when the user needs to submit another message. This approach ensures that the messaging client will always get the latest information at the moment which accuracy is most critical. 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 Hall & Klensin I-D Expires: December 2003 [page 8]
Internet Draft draft-hall-submit-srv-00.txt June 2003 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. 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. Author's Address Eric A. Hall ehall@ehsco.com John C. Klensin john-ietf@jck.com 9. 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. Hall & Klensin I-D Expires: December 2003 [page 9]
Internet Draft draft-hall-submit-srv-00.txt June 2003 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. 10. 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. 11. Acknowledgments Funding for the RFC editor function is currently provided by the Internet Society. 12. 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. Hall & Klensin I-D Expires: December 2003 [page 10]
Internet Draft draft-hall-submit-srv-00.txt June 2003 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: December 2003 [page 11]