idnits 2.17.1 draft-hall-submit-srv-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2003) is 7619 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2476 (Obsoleted by RFC 4409) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 3377 (Obsoleted by RFC 4510) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Eric A. Hall 3 Document: draft-hall-submit-srv-00.txt John C. Klensin 4 Expires: January, 2004 June 2003 5 Category: Standards Track 7 Message-Submission SRV Resource Record 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts 22 as reference material or to cite them other than as "work in 23 progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This document specifies the use of SRV resource records for 38 locating the message-submission servers associated with a known 39 mail domain. 41 Table of Contents 43 1. Background and Overview...................................2 44 2. Prerequisites and Terminology.............................4 45 3. Message-Submission Resource Records.......................4 46 3.1. SRV Owner Name.........................................4 47 3.2. SRV Resource Record Data...............................5 48 3.3. Address Resource Records...............................5 49 4. Client Processing Algorithm...............................6 50 5. Resource Record Caching...................................8 51 6. Security Considerations...................................8 52 7. IANA Considerations.......................................9 53 8. Author's Address..........................................9 54 9. Normative References......................................9 55 10. Informative References...................................10 56 11. Acknowledgments..........................................10 57 12. Full Copyright Statement.................................10 59 1. Background and Overview 61 Email networks built around Internet technologies typically use a 62 tiered network for outbound transfers, with messaging clients 63 sending non-local messages to a default "submission" server, with 64 that server subsequently performing the message preparation, 65 routing and transfer services on behalf of the local clients. 67 Messaging networks built on this model have historically used the 68 Simple Message Transfer Protocol (SMTP) [RFC2821] and TCP port 25 69 for this "first-hop" transfer purpose, although RFC 2476 [RFC2476] 70 formally defined a variant of SMTP with slightly different 71 behavioral rules as an explicit message submission service for use 72 in these environments. RFC 2476 also reserved TCP port 587 73 specifically for use with the submission service, but also allowed 74 clients and servers to continue using SMTP over TCP port 25 if 75 necessary or desired. 77 Most of the messaging clients which used the submission model have 78 also historically used static configuration data to identify the 79 submission host and port, although a variety of products have 80 attempted to use automated configuration services in an effort to 81 lessen the need for manual administration. For example, some 82 products have used Mail Exchange (MX) resource records associated 83 with the sender's domain to try and locate a submission server, 84 under the assumption that the inbound transfer server(s) would 85 also be appropriate for outbound transfers. Meanwhile, some 86 products have used the Dynamic Host Configuration Protocol (DHCP) 87 [RFC2131], the Interactive Mail Support Protocol (IMSP) and the 88 derivative Application Configuration Access Protocol (ACAP) 89 [RFC2244], and even the Lightweight Directory Access Protocol 90 (LDAP) [RFC3377] to store configuration data centrally, allowing 91 clients to retrieve the submission host and port identifiers when 92 they were started. Unfortunately, many of these services are 93 unable to accommodate messaging networks that don't use TCP port 94 25 for the submission service, or are unable to support users on 95 remote and/or slow networks, or have other issues which make them 96 unsuitable for use with automated configuration management outside 97 of specific environments. 99 Separately, RFC 2782 [RFC2782] introduced a general-purpose 100 mechanism for storing service-specific connection identifiers in 101 the Domain Name System (DNS) [STD13] by way of a generalized 102 Service Location ("SRV") resource record. In that model, a network 103 service can be identified by name, and SRV resource records for 104 that service can be created within the scope of a particular 105 domain, with each SRV resource record identifying the hostname and 106 port number of a server which provides the named service within 107 that domain scope. This approach is well suited to the submission 108 service for a variety of reasons, and is particularly well suited 109 to large-scale and diverse installations who cannot easily support 110 the more generalized configuration services. 112 First of all, each SRV resource record can specify a unique 113 hostname and port number pair, thereby allowing multiple hosts 114 and/or port numbers to be linked to a single submission service. 115 Furthermore, each SRV resource record carries preference and 116 weighting values which allow administrators to specify a 117 "preferred" submission server as well as secondary or tertiary 118 servers if the preferred server becomes unavailable. Finally, the 119 use of DNS for this kind of configuration information facilitates 120 deployment and access in broad scales, especially since DNS is 121 already commonly used for other kinds of connection-level 122 identifiers, and many organizations have already dealt with the 123 policy and architectural considerations surrounding the use of DNS 124 for that kind of information. 126 For all of the reasons listed above, this specification defines 127 the usage of SRV resource records with submission services, for 128 use in environments where this kind of configuration management 129 would be appropriate. Note that this service is not mandatory for 130 any messaging network, and other configuration management systems 131 may continue to be used as necessary or desired. Furthermore, it 132 is important to recognize that this specification does not define 133 any site-to-site routing services, location information for 134 message-retrieval servers, proprietary submission services, or 135 anything other than identifying the SMTP-based submission servers 136 for a messaging network. 138 2. Prerequisites and Terminology 140 Readers of this document are expected to be familiar with the 141 specifications for message submission [RFC2476] and SRV resource 142 records [RFC2782]. 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 145 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 146 in this document are to be interpreted as described in RFC 2119 147 [RFC2119]. 149 3. Message-Submission Resource Records 151 SRV resource records have an owner name which uniquely identifies 152 a particular service within the scope of a particular domain, and 153 also have data structures which provide information about the 154 target hosts and their preference. In addition to the SRV resource 155 records, "target" server hostnames must also be resolved into IP 156 addresses via secondary lookups. 158 3.1. SRV Owner Name 160 The owner name of SRV resource records are a concatenated sequence 161 of labels which identify the service name, the transport protocol 162 associated with that service, and the domain scope, respectively. 164 For message submission SRV resource records, the first two labels 165 in this sequence MUST be "_submission" and "_tcp", while the 166 domain scope sequence MUST be the same as the mail domain which is 167 used by the messaging clients. 169 Note that the domain scope is explicitly defined as a particular 170 "mail domain", and is not tied to a hostname, a subnet, or any 171 other type of domain name. The client algorithm defined in section 172 4 causes messaging clients to use the mail domain element of their 173 return email addresses as the domain scope of the SRV resource 174 record lookups, so the resource records must be associated with 175 the mail domain names in order for the algorithm to succeed. 177 For example, messaging users in the "example.net" mail domain 178 would issues lookups for the SRV resource records bound to the 179 "_submission._tcp.example.net" domain name, while messaging users 180 in the "bna.tn.example.net" mail domain would issue lookups for 181 "_submission._tcp.bna.tn.example.net". SRV resource records would 182 need to be bound to those domain names in order for the messaging 183 clients in those mail domains to locate the resource records. 185 3.2. SRV Resource Record Data 187 The SRV resource record data structure is described in detail in 188 RFC 2782. In brief, the SRV resource record data segment provides 189 multiple fields which identify a target server's hostname, the 190 port number, and priority and weighting data which cumulatively 191 determines the overall preference level of that particular SRV 192 resource record in the set. 194 Note that the client-processing algorithm described in section 4 195 allows a preferred target server to be chosen from among an 196 equally weighted set of answers by allowing the client to 197 determine if any of the servers are in the same sub-domain as the 198 client itself. This mechanism may be useful in those cases where a 199 large and distributed messaging network shares a common mail 200 domain for all of its users, but where that organization still 201 needs to direct the users towards servers which are dedicated to 202 particular sub-domains or regions. 204 In general terms, organizations which choose to support the use of 205 SRV resource records are encouraged to provide multiple resource 206 records with different preference values, thereby allowing clients 207 to automatically discover alternate servers in case the preferred 208 server becomes unreachable or otherwise unavailable. 210 3.3. Address Resource Records 212 Once a preferred server has been determined, its hostname is 213 subsequently resolved to an IP address with a lookup for the IP 214 address resource records associated with the server's domain name. 216 Note that the client-processing algorithm described in section 4 217 allows a preferred target server to be chosen from among an 218 equally weighted set of answers by allowing the client to 219 determine the "closest" server, based on IP addresses. This 220 mechanism may be useful in those cases where a large and 221 distributed messaging network shares a common mail domain for all 222 of its users, but where that organization still needs to direct 223 the users towards servers which are dedicated to particular 224 subnets or regions. 226 For example, some organizations may be able to leverage resolvers 227 which attempt to locate the "closest" server through subnet- 228 mapping or response-time monitors, while other organizations may 229 be able to use load-balancing technologies which control the 230 answer sets that are returned to the clients. Discussion of these 231 technologies is beyond the scope of this document, although 232 administrators should be aware of their potential use. 234 4. Client Processing Algorithm 236 In general terms, messaging clients are expected to generate DNS 237 lookups for the submission-specific SRV resource records 238 associated with the user's known mail domains. Clients SHOULD NOT 239 issue lookups for the domain name associated with the local 240 hostname, SHOULD NOT issue lookups for networks they are attached 241 to, but SHOULD instead only issue lookups for the SRV resource 242 records associated with their known mail domains. 244 If multiple "identities" have been defined on the messaging client 245 which use different mail domains in the return address, the lookup 246 process SHOULD be repeated for each mail domain, unless the user 247 specifies otherwise. 249 Clients which claim to be compliant with this specification SHOULD 250 iterate through the following steps for each eligible identity: 252 a. Determine if a submission server has been defined manually 253 or through another configuration service. If so, give 254 preference to that information, and only continue if the 255 identified servers are unreachable. 257 b. Extract the mail domain element from the user's email 258 address, and append the "_submission" and "_tcp" labels to 259 the left of that domain name. 261 c. Issue a DNS query for the SRV resource records associated 262 with the domain name formed in step 4.b. 264 d. If multiple resource records are returned, sort them 265 according to the rules specified in RFC 2782, and determine 266 the preferred target. 268 1. If multiple candidate targets still exist, the client 269 MAY give preference to any servers which have a 270 hostname that appears to be in the same sub-domain as 271 the client hostname. 273 2. If multiple candidate targets still exist, the client 274 SHOULD give the highest preference to targets which 275 use port 587, and SHOULD give the lowest preference to 276 targets which use port 25. 278 3. If multiple candidate targets still exist, choose one 279 at random. 281 e. Use the port number determined in step 4.d as the port 282 number for the submission server. 284 f. Determine the IP address for the target server. 286 1. If multiple IP addresses are discovered, the client 287 MAY use any services at its disposal to determine the 288 IP address which appears to be the closest match to 289 the local client's IP address. 291 2. If multiple candidate addresses still exist, choose 292 one at random. 294 g. Use the IP address determined in step 4.f as the IP address 295 for the submission server. 297 h. If the currently-preferred server is subsequently 298 determined to be unreachable or unavailable (potentially 299 including any routing errors, TCP errors, or SMTP errors 300 which indicate that the client cannot currently use the 301 server), locate the next-best target. 303 1. If multiple addresses were associated with the 304 currently-preferred server, restart the process at 305 step 4.f to determine the next-best IP address. 307 2. If all of the IP addresses for the currently-preferred 308 target have been tried and multiple SRV resource 309 records were discovered, use the next-preferred SRV 310 resource record from step 4.d. Clients SHOULD NOT try 311 the next-preferred target until all of the IP 312 addresses associated with the currently-preferred 313 target have been tried. 315 3. If all of the IP addresses for all of the SRV resource 316 records have been tried, report the error to the user 317 and exit the algorithm. 319 Note that some DNS resolvers are known to filter and restrict the 320 resource record data which gets returned, and in those cases, the 321 messaging client may need to issue its own "raw" DNS query in 322 order to ensure that all of the information is retrieved and 323 processed correctly. 325 5. Resource Record Caching 327 Submission clients SHOULD NOT store or reuse the discovered 328 configuration information for a length of time greater than the 329 Time-to-Live values associated with the underlying resource 330 records. Instead, clients SHOULD delete the discovered information 331 whenever the underlying resource records have expired, and SHOULD 332 only reissue the queries when the user needs to submit another 333 message. This approach ensures that the messaging client will 334 always get the latest information at the moment which accuracy is 335 most critical. 337 Zone operators SHOULD NOT use excessively small or excessively 338 small Time-to-Live values. As a general rule of thumb (subject to 339 operator-specific requirements, of course), Time-to-Live values 340 between a few hours and a few days tend to work the best. 342 6. Security Considerations 344 Administrators should carefully consider if and how they want to 345 make the resource records described in this document available to 346 users, particularly those users who may be on remote networks. 348 Since this resource record provides information in a predictable 349 form, hostile parties with access to the resource records can 350 learn some operational details about the messaging infrastructure 351 simply by issuing predictable DNS queries. However, the potential 352 risks from exposing operational information about a messaging 353 network to external parties should not be overstated. In the usual 354 case, the same information can be learned by analyzing the 355 Received headers in email messages which have passed through that 356 same network. In this regard, providing this information in a 357 resource record is no more of a risk than providing the 358 information in a Received header of a message which has passed 359 through that network. 361 DNS domain names can be easily spoofed, and this is especially 362 easy when the victim uses a DNS server under the control of a 363 hostile party. By using a relatively simple technique, a hostile 364 party can provide SRV resource records which redirect a user 365 towards a hostile SMTP server, allowing the interloper to read and 366 act upon the user's outbound email at will. Strong authentication 367 services, transfer-layer encryption techniques, and message 368 encryption are usually cited as sufficient defenses against such 369 attacks, in that they can prevent illegitimate sessions from being 370 established and/or can make message contents unreadable. 372 Refer to RFC 2782 for the security considerations associated with 373 the use of SRV resource records in general. 375 Refer to RFC 2476 for the security considerations associated with 376 the use of the message-submission service. 378 7. IANA Considerations 380 This document does not create any IANA considerations. 382 8. Author's Address 384 Eric A. Hall 385 ehall@ehsco.com 387 John C. Klensin 388 john-ietf@jck.com 390 9. Normative References 392 [RFC2119] Bradner, S., "Key words for use in RFCs to 393 Indicate Requirement Levels", BCP 14, RFC 394 2119, March 1997. 396 [RFC2476] Gellens, R., and J. Klensin, "Message 397 Submission", RFC 2476, December 1998. 399 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A 400 DNS RR for specifying the location of services 401 (DNS SRV)", RFC 2782, February 2000. 403 10. Informative References 405 [RFC2131] Droms, R., "Dynamic Host Configuration 406 Protocol", RFC 2131, March 1997. 408 [RFC2244] Newman, C., and J. Myers, "ACAP -- Application 409 Configuration Access Protocol", RFC 2244, 410 November 1997. 412 [RFC2821] J. Klensin, "Simple Mail Transfer Protocol", 413 RFC 2821, April 2001. 415 [RFC3377] Hodges, J., and R. Morgan, "Lightweight 416 Directory Access Protocol (v3): Technical 417 Specification", RFC 3377, September 2002. 419 [STD13] Mockapetris, P. "Domain Names - Concepts and 420 Facilities", STD 13, RFC 1034 and "Domain 421 Names - Implementation and Specification", STD 422 13, RFC 1035, November 1987. 424 11. Acknowledgments 426 Funding for the RFC editor function is currently provided by the 427 Internet Society. 429 12. Full Copyright Statement 431 Copyright (C) The Internet Society (2003). All Rights Reserved. 433 This document and translations of it may be copied and furnished 434 to others, and derivative works that comment on or otherwise 435 explain it or assist in its implementation may be prepared, 436 copied, published and distributed, in whole or in part, without 437 restriction of any kind, provided that the above copyright notice 438 and this paragraph are included on all such copies and derivative 439 works. However, this document itself may not be modified in any 440 way, such as by removing the copyright notice or references to the 441 Internet Society or other Internet organizations, except as needed 442 for the purpose of developing Internet standards in which case the 443 procedures for copyrights defined in the Internet Standards 444 process must be followed, or as required to translate it into 445 languages other than English. 447 The limited permissions granted above are perpetual and will not 448 be revoked by the Internet Society or its successors or assigns. 450 This document and the information contained herein is provided on 451 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 452 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 453 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 454 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 455 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.