idnits 2.17.1 draft-daboo-srv-email-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3501, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC1939, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1939, updated by this document, for RFC5378 checks: 1995-05-15) -- 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 (May 12, 2010) is 5069 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) == Outdated reference: A later version (-14) exists of draft-saintandre-tls-server-id-check-04 ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) ** Obsolete normative reference: RFC 4409 (Obsoleted by RFC 6409) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Daboo 3 Internet-Draft Apple Inc. 4 Updates: 1939,3501 May 12, 2010 5 (if approved) 6 Intended status: Standards Track 7 Expires: November 13, 2010 9 Use of SRV Records for Locating Email Submission/Access services 10 draft-daboo-srv-email-05 12 Abstract 14 This specification describes how SRV records can be used to locate 15 email services. 17 Status of This Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on November 13, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Conventions Used in This Document . . . . . . . . . . . . . . . 3 59 3. SRV Service Labels . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Email Submission . . . . . . . . . . . . . . . . . . . . . 4 61 3.2. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.3. POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.4. Priority for Domain Preferences . . . . . . . . . . . . . . 5 64 4. Guidance for MUAs . . . . . . . . . . . . . . . . . . . . . . . 5 65 5. Guidance for Service Providers . . . . . . . . . . . . . . . . 7 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 68 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 72 Appendix A. Change History (to be removed prior to 73 publication as an RFC) . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 Internet Email protocols include SMTP [RFC5321], IMAP [RFC3501] and 78 POP3 [RFC1939]. IMAP and POP3 are both message store access 79 protocols used by message store user agents (MUAs) to manipulate 80 email messages after delivery. [RFC4409] defines a "profile" of the 81 SMTP service that is specifically used for message submission. MUAs 82 are expected to submit messages to mail submission agents (MSAs) 83 using this approach. 85 [RFC2782] defines a DNS-based service discovery protocol that has 86 been widely adopted as a means of locating particular services within 87 a local area network and beyond, using DNS SRV Resource Records 88 (RRs). 90 [RFC5321] specifies how to use DNS MX RRs to locate SMTP services for 91 a domain. However, MUAs are expected to use the submission protocol 92 defined in [RFC4409] which does not use MX records. 94 Typically MUAs have required users to enter a fully qualified domain 95 name (FQDN) and port information for the services they need. This is 96 not ideal as the way in which server configuration information is 97 specified can differ from MUA to MUA, and can be confusing to users, 98 leading to errors when inputting the details. Alternatively, some 99 MUAs have adopted a complex "auto-discovery" process involving 100 probing a domain to see what services might be available. A better 101 approach to all this would be to require minimal information to be 102 entered by a user which would result in automatic configuration of 103 appropriate services for that user. The minimal information entered 104 would be the user's email address. 106 This specification defines new SRV service types for the message 107 submission, IMAP and POP3 services, to enable simple auto- 108 configuration of MUAs. The priority field of the SRV record can also 109 be used to indicate a preference for one message store access 110 protocol over another. 112 2. Conventions Used in This Document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 Email-related terminology from [RFC5598] is used. 120 3. SRV Service Labels 122 3.1. Email Submission 124 This specification adds one SRV service label for message submission 125 [RFC4409]: 127 submission: Identifies an MSA using [RFC4409]. Note that this 128 covers connections both with and without TLS [RFC5246] as defined 129 for SMTP in [RFC3207]. 131 Example: service record 133 _submission._tcp SRV 0 1 587 mail.example.com. 135 3.2. IMAP 137 This specification adds two SRV service labels for IMAP [RFC3501]: 139 _imap: Identifies an IMAP server that MAY advertise the 140 "LOGINDISABLED" capability and MAY require the MUA to use the 141 "STARTTLS" command prior to authentication. Although these two 142 extensions are mandatory-to-implement for both MUAs and IMAP 143 servers, they are not mandatory-to-use by service providers. 145 _imaps: Identifies an IMAP server where TLS [RFC5246] is initiated 146 directly upon connection to the IMAP server. 148 Example: service record 150 _imap._tcp SRV 0 1 143 imap.example.com. 152 Example: service record 154 _imaps._tcp SRV 0 1 993 imap.example.com. 156 3.3. POP3 158 This specification adds two SRV service labels for POP3 [RFC1939]: 160 _pop3: Identifies a POP3 server that MAY require the MUA to use the 161 "STLS" extension command [RFC2595] prior to authentication. 163 _pop3s: Identifies a POP3 server where TLS [RFC5246] is initiated 164 directly upon connection to the POP3 server. 166 Example: service record 168 _pop3._tcp SRV 0 1 110 pop3.example.com. 170 Example: service record 172 _pop3s._tcp SRV 0 1 995 pop3.example.com. 174 3.4. Priority for Domain Preferences 176 The priority field in the SRV RR allows a domain to indicate that 177 some records have a higher preference than others in the DNS query 178 results (determined by those records having a lower priority value). 179 Typically, this is used for choosing a record from a set for a single 180 service label, however it is not restricted to choice within only one 181 service. 183 Often a site will offer both IMAP and POP3 message store access 184 services for users. However, the site may have a preference for one 185 over the other that they want to convey to the user to ensure that, 186 when the user has an MUA capable of using both IMAP and POP3, that 187 the preferred choice is used. 189 To aid with this choice, sites SHOULD offer both sets of IMAP (_imap 190 and/or _imaps) and POP3 (_pop3 and/or _pop3s) SRV records in their 191 DNS and set the priority for those sets of records such that the 192 "preferred" service has a lower priority value than the other. When 193 an MUA supports both IMAP and POP3 it SHOULD retrieve records for 194 both services and then use the service with the lowest priority 195 value. If the priority is the same for both services, MUAs are free 196 to choose which ever one is appropriate. When considering multiple 197 records for different protocols at the same priority but with 198 different weights, the client MUST first select the protocol it 199 intends to use, then perform the weight selection algorithm given in 200 [RFC2782] on the records associated with the selected protocol. 202 Example: service records for both IMAP and POP3, with IMAP having a 203 lower priority value (0) then POP3 (10), indicating to the MUA that 204 IMAP is preferred over POP3, when the MUA can support either service. 206 _imap._tcp SRV 0 1 143 imap.example.com. 207 _pop3._tcp SRV 10 1 110 pop3.example.com. 209 4. Guidance for MUAs 211 By using SRV records as above, MUAs need initially only prompt the 212 user for their email address [RFC5322]. The "local-part" and 213 "domain" portions are then extracted from the email address by the 214 MUA. The MUA uses the "domain" portion as the service domain to 215 perform SRV lookups for the services it wants to configure. If the 216 SRV lookup is successful the target FQDN and port for the service can 217 be determined and used to complete MUA configuration. If an SRV 218 record is not found, the MUA will need to prompt the user to enter 219 the FQDN and port information directly, or use some other heuristic. 220 In the case of multiple SRV records returned for a particular 221 service, the MUA MUST use the priority and weight fields in the 222 record to determine which one to use (as per [RFC2782]). 224 MUAs that support both POP3 and IMAP use the procedure in Section 3.4 225 to choose between each service when both are offered. 227 Subsequent to configuration, the MUA will connect to the service. 228 When using "imaps" or "pop3s" services, a TLS [RFC5246] negotiation 229 is done immediately upon connection. With "imap", "pop3" and 230 "submission" services, the "STARTTLS", "STLS" and "STARTTLS" commands 231 respectively are used to initiate a protected connection using TLS 232 [RFC5246]. When using TLS in this way, MUAs SHOULD use the TLS 233 Server Name Indication [RFC4366]. Certificate verification MUST use 234 the procedure outlined in Section 4.3 of 235 [I-D.saintandre-tls-server-id-check] in regard to verification with 236 an SRV RR as the starting point. 238 Once a suitable connection has been made, and any required protection 239 setup, the MUA will typically need to authenticate with the IMAP, 240 POP3 or SMTP (submission) server. The details of that are governed 241 by the specific protocols themselves, though often times a "user 242 identifier" is required for some form of user/password 243 authentication. When a user identifier is required, MUAs MUST first 244 use the full email address provided by the user, and if that results 245 in an authentication failure, SHOULD fall back to using the "local- 246 part" extracted from the email address. This is in line with the 247 guidance outlined in Section 5. If both these user identifiers 248 result in authentication failure, the MUA SHOULD prompt the user for 249 a valid identifier. 251 Once a successful connection and authentication have been done, MUAs 252 SHOULD cache the service details (hostname, port, user identity) that 253 were successfully used, and re-use those when connecting again at a 254 later time. 256 If a subsequent connection attempt fails, or authentication fails, 257 MUAs SHOULD re-try the SRV lookup to "refresh" the cached data for 258 the same protocol the client had chosen earlier. i.e., this means 259 that the client MUST NOT change from IMAP service to POP3 (or vice 260 versa) due to changes in the corresponding SRV priorities without 261 user interaction. 263 5. Guidance for Service Providers 265 Service providers wanting to offer IMAP, POP3 or SMTP (submission) 266 services that can be configured by MUAs using SRV records need to 267 follow certain guidelines to ensure proper operation. 269 a. IMAP, POP3 and SMTP (submission) servers SHOULD be configured to 270 allow authentication with email addresses or email local-parts. 271 In the former case, the email addresses MUST NOT conflict with 272 other forms of permitted user login name. In the latter case, 273 the email local-parts need to be unique across the server and 274 MUST NOT conflict with any login name on the server. 276 b. If the service provider uses TLS [RFC5246], the service provider 277 MUST ensure a certificate is installed that can be verified by 278 MUAs using the procedure outlined in Section 4.3 of 279 [I-D.saintandre-tls-server-id-check] in regard to verification 280 with an SRV RR as the starting point. If the service provider 281 hosts multiple domains on the same IP address, then the service 282 provider MUST enable support for the TLS Server Name Indication 283 [RFC4366]. 285 c. Install the appropriate SRV records for the offered services. 287 6. Security Considerations 289 If a user has explicitly requested a connection with transport layer 290 security (user interfaces sometimes present this choice as a "use 291 SSL" or "secure connection" checkbox), the MUA MUST successfully 292 negotiate transport layer security prior to sending an authentication 293 command. The MUA MAY do this with "imaps", "pop3s", "imap" with 294 "STARTTLS", or "pop3" with "STLS". Service providers MAY offer any 295 subset of these four options for the mail service. 297 A malicious attacker with access to the DNS server data, or able to 298 get spoofed answers cached in a recursive resolver, can potentially 299 cause MUAs to connect to any IMAP, POP3 or submission server chosen 300 by the attacker. In the absence of a secure DNS option, MUAs SHOULD 301 check that the target FQDN returned in the SRV record matches the 302 original service domain that was queried. If the target FQDN is not 303 in the queried domain, MUAs SHOULD verify with the user that the SRV 304 target FQDN is suitable for use before executing any connections to 305 the host. Alternatively, if TLS [RFC5246] is being used for the 306 email service, MUAs MUST use the procedure outlined in Section 4.3 of 307 [I-D.saintandre-tls-server-id-check] to verify the service. 309 Implementations of TLS [RFC5246] typically support multiple versions 310 of the protocol as well as the older Secure Sockets Layer (SSL) 311 protocol. Because of known security vulnerabilities, email clients 312 and email servers MUST NOT request, offer, or use SSL 2.0. See 313 Appendix E.2 of [RFC5246] for further details. 315 7. IANA Considerations 317 This document does not require any actions on the part of IANA. 319 8. Acknowledgments 321 Thanks to Tony Finch, Ned Freed, Alfred Hoenes, Suresh Krishnan, 322 Alexey Melnikov, and Chris Newman for feedback and suggestions. Some 323 of this work is based on a previous internet draft by John Klensin 324 and Eric Hall. 326 9. References 328 9.1. Normative References 330 [I-D.saintandre-tls-server-id-check] Saint-Andre, P. and J. Hodges, 331 "Representation and 332 Verification of Application 333 Server Identity in Certificates 334 Used with Transport Layer 335 Security (TLS)", draft- 336 saintandre-tls-server-id-check- 337 04 (work in progress), 338 April 2010. 340 [RFC1939] Myers, J. and M. Rose, "Post 341 Office Protocol - Version 3", 342 STD 53, RFC 1939, May 1996. 344 [RFC2119] Bradner, S., "Key words for use 345 in RFCs to Indicate Requirement 346 Levels", BCP 14, RFC 2119, 347 March 1997. 349 [RFC2595] Newman, C., "Using TLS with 350 IMAP, POP3 and ACAP", RFC 2595, 351 June 1999. 353 [RFC2782] Gulbrandsen, A., Vixie, P., and 354 L. Esibov, "A DNS RR for 355 specifying the location of 356 services (DNS SRV)", RFC 2782, 357 February 2000. 359 [RFC3207] Hoffman, P., "SMTP Service 360 Extension for Secure SMTP over 361 Transport Layer Security", 362 RFC 3207, February 2002. 364 [RFC3501] Crispin, M., "INTERNET MESSAGE 365 ACCESS PROTOCOL - VERSION 366 4rev1", RFC 3501, March 2003. 368 [RFC4366] Blake-Wilson, S., Nystrom, M., 369 Hopwood, D., Mikkelsen, J., and 370 T. Wright, "Transport Layer 371 Security (TLS) Extensions", 372 RFC 4366, April 2006. 374 [RFC4409] Gellens, R. and J. Klensin, 375 "Message Submission for Mail", 376 RFC 4409, April 2006. 378 [RFC5246] Dierks, T. and E. Rescorla, 379 "The Transport Layer Security 380 (TLS) Protocol Version 1.2", 381 RFC 5246, August 2008. 383 [RFC5321] Klensin, J., "Simple Mail 384 Transfer Protocol", RFC 5321, 385 October 2008. 387 [RFC5322] Resnick, P., Ed., "Internet 388 Message Format", RFC 5322, 389 October 2008. 391 9.2. Informative References 393 [RFC5598] Crocker, D., "Internet Mail 394 Architecture", RFC 5598, 395 July 2009. 397 Appendix A. Change History (to be removed prior to publication as an 398 RFC) 400 Changes in -05: 402 1. IESG review: Indicate that this spec updates 1937 and 3501. 404 2. IESG review: Fixed minor typos found in IESG review. 406 3. IESG review: Added text explaining how to deal with both SRV 407 priority and weight. 409 4. IESG review: Added text to explain client methodology when 410 dealing with a failed connection to a service and how they re-do 411 SRV lookup without changing the service. 413 5. IESG review: Added statement that SSL v2 is not allowed. 415 6. IESG review: Changed TLS server name indication reference back to 416 RFC4366. 418 7. Changing "transport layer security" to TLS when it specifically 419 refers to RFC5246. 421 Changes in -04: 423 1. Updated reference to draft-saintandre-tls-server-id-check. 425 2. Tweaked 3.4 to indicate that the _XXXs variants of service type 426 are also included in the "weighting" approach. 428 3. Tweaked Acknowledgments. 430 Changes in -03: 432 1. Added ability to use priority to select one access protocol over 433 another. 435 2. Added statement that clients should retry SRV on subsequent 436 connection failure. 438 3. Added statement about handling multiple records for the same 439 service. 441 4. Stronger use of MUST NOT in Section 5(a). 443 5. GENART: Added statement that clients should prompt the user if 444 both email and local-part authentication fail. 446 6. Tweaked title. 448 7. "Service type" -> "Service label" 450 8. "Host name" -> "target FQDN" 452 9. Improvements to security considerations wrt DNS attacks. 454 10. MUA and service provider guidance now includes submission 455 service. 457 11. Added References to draft-saintandre-tls-server-id-check that 458 should define the proper cert validation procedures. 460 12. SECDIR: reworked introduction. 462 13. Switched to using terminology from RFC5598. 464 Changes in -02: 466 1. Tweaked text for imap to better describe mandatory-to-implement 467 behavior from base spec. 469 2. Tweaked text for pop3 along similar lines as imap. 471 3. Teaked security considerations to account for use of STARTTLS and 472 STLS. 474 4. Added examples for imaps and pop3s. 476 5. Re-worked client guidelines. 478 6. Added service provider guidelines. 480 Changes in -01: 482 1. Tweaked text for pop3 to make it clearer that STLS is an 483 extension. 485 2. Added text to explain that the email address, as well as the 486 local-part, may be used as the user identifier. 488 3. Tweaked security considerations to account for use of STARTTLS 489 and STLS. 491 Author's Address 493 Cyrus Daboo 494 Apple Inc. 495 1 Infinite Loop 496 Cupertino, CA 95014 497 USA 499 EMail: cyrus@daboo.name 500 URI: http://www.apple.com/