1
2
3
4
5
6
7Internet Engineering Task Force (IETF) C. Daboo
8Request for Comments: 6186 Apple Inc.
9Updates: 1939, 3501 March 2011
10Category: Standards Track
11ISSN: 2070-1721
12
13
14 Use of SRV Records for Locating Email Submission/Access Services
15
16Abstract
17
18 This specification describes how SRV records can be used to locate
19 email services.
20
21Status of This Memo
22
23 This is an Internet Standards Track document.
24
25 This document is a product of the Internet Engineering Task Force
26 (IETF). It represents the consensus of the IETF community. It has
27 received public review and has been approved for publication by the
28 Internet Engineering Steering Group (IESG). Further information on
29 Internet Standards is available in Section 2 of RFC 5741.
30
31 Information about the current status of this document, any errata,
32 and how to provide feedback on it may be obtained at
33 http://www.rfc-editor.org/info/rfc6186.
34
35Copyright Notice
36
37 Copyright (c) 2011 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
39
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents
42 (http://trustee.ietf.org/license-info) in effect on the date of
43 publication of this document. Please review these documents
44 carefully, as they describe your rights and restrictions with respect
45 to this document. Code Components extracted from this document must
46 include Simplified BSD License text as described in Section 4.e of
47 the Trust Legal Provisions and are provided without warranty as
48 described in the Simplified BSD License.
49
50
51
52
53
54
55
56
57
58Daboo Standards Track [Page 1]
59
60RFC 6186 SRV for Email March 2011
61
62
63Table of Contents
64
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
66 2. Conventions Used in This Document . . . . . . . . . . . . . . . 3
67 3. SRV Service Labels . . . . . . . . . . . . . . . . . . . . . . 3
68 3.1. Email Submission . . . . . . . . . . . . . . . . . . . . . 3
69 3.2. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
70 3.3. POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
71 3.4. Priority for Domain Preferences . . . . . . . . . . . . . . 4
72 4. Guidance for MUAs . . . . . . . . . . . . . . . . . . . . . . . 5
73 5. Guidance for Service Providers . . . . . . . . . . . . . . . . 6
74 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
75 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
78 8.2. Informative References . . . . . . . . . . . . . . . . . . 8
79
801. Introduction
81
82 Internet email protocols include SMTP [RFC5321], IMAP [RFC3501], and
83 POP3 [RFC1939]. IMAP and POP3 are both message store access
84 protocols used by message store user agents (MUAs) to manipulate
85 email messages after delivery. [RFC4409] defines a "profile" of the
86 SMTP service that is specifically used for message submission. MUAs
87 are expected to submit messages to mail submission agents (MSAs)
88 using this approach.
89
90 [RFC2782] defines a DNS-based service discovery protocol that has
91 been widely adopted as a means of locating particular services within
92 a local area network and beyond, using DNS SRV resource records
93 (RRs).
94
95 [RFC5321] specifies how to use DNS MX RRs to locate SMTP services for
96 a domain. However, MUAs are expected to use the submission protocol
97 defined in [RFC4409], which does not use MX records.
98
99 Typically MUAs have required users to enter a fully qualified domain
100 name (FQDN) and port information for the services they need. This is
101 not ideal as the way in which server configuration information is
102 specified can differ from MUA to MUA, and can be confusing to users,
103 leading to errors when inputting the details. Alternatively, some
104 MUAs have adopted a complex "auto-discovery" process involving
105 probing a domain to see what services might be available. A better
106 approach to all this would be to require minimal information to be
107 entered by a user that would result in automatic configuration of
108 appropriate services for that user. The minimal information entered
109 would be the user's email address.
110
111
112
113
114Daboo Standards Track [Page 2]
115
116RFC 6186 SRV for Email March 2011
117
118
119 This specification defines new SRV service types for the message
120 submission, IMAP, and POP3 services, to enable simple auto-
121 configuration of MUAs. The priority field of the SRV record can also
122 be used to indicate a preference for one message store access
123 protocol over another.
124
1252. Conventions Used in This Document
126
127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
129 document are to be interpreted as described in [RFC2119].
130
131 Email-related terminology from [RFC5598] is used.
132
1333. SRV Service Labels 8314:692 ../mox-/admin.go:887
134
1353.1. Email Submission
136
137 This specification adds one SRV service label for message submission
138 [RFC4409]:
139
140 submission: Identifies an MSA using [RFC4409]. Note that this
141 covers connections both with and without Transport Layer Security
142 (TLS) [RFC5246] as defined for SMTP in [RFC3207].
143
144 Example: service record
145
146 _submission._tcp SRV 0 1 587 mail.example.com.
147
1483.2. IMAP
149
150 This specification adds two SRV service labels for IMAP [RFC3501]:
151
152 _imap: Identifies an IMAP server that MAY advertise the
153 "LOGINDISABLED" capability and MAY require the MUA to use the
154 "STARTTLS" command prior to authentication. Although these two
155 extensions are mandatory-to-implement for both MUAs and IMAP
156 servers, they are not mandatory-to-use by service providers.
157
158 _imaps: Identifies an IMAP server where TLS [RFC5246] is initiated
159 directly upon connection to the IMAP server.
160
161 Example: service record
162
163 _imap._tcp SRV 0 1 143 imap.example.com.
164
165
166
167
168
169
170Daboo Standards Track [Page 3]
171
172RFC 6186 SRV for Email March 2011
173
174
175 Example: service record
176
177 _imaps._tcp SRV 0 1 993 imap.example.com.
178
1793.3. POP3
180
181 This specification adds two SRV service labels for POP3 [RFC1939]:
182
183 _pop3: Identifies a POP3 server that MAY require the MUA to use the
184 "STLS" extension command [RFC2595] prior to authentication.
185
186 _pop3s: Identifies a POP3 server where TLS [RFC5246] is initiated
187 directly upon connection to the POP3 server.
188
189 Example: service record
190
191 _pop3._tcp SRV 0 1 110 pop3.example.com.
192
193 Example: service record
194
195 _pop3s._tcp SRV 0 1 995 pop3.example.com.
196
1973.4. Priority for Domain Preferences
198
199 The priority field in the SRV RR allows a domain to indicate that
200 some records have a higher preference than others in the DNS query
201 results (determined by those records having a lower-numbered priority
202 value). Typically, this is used for choosing a record from a set for
203 a single service label; however, it is not restricted to choice
204 within only one service.
205
206 Often a site will offer both IMAP and POP3 message store access
207 services for users. However, the site may have a preference for one
208 over the other that they want to convey to the user to ensure that,
209 when the user has an MUA capable of using both IMAP and POP3, the
210 preferred choice is used.
211
212 To aid with this choice, sites SHOULD offer both sets of IMAP (_imap
213 and/or _imaps) and POP3 (_pop3 and/or _pop3s) SRV records in their
214 DNS and set the priority for those sets of records such that the
215 "preferred" service has a lower-numbered priority value than the
216 other. When an MUA supports both IMAP and POP3, it SHOULD retrieve
217 records for both services and then use the service with the lowest
218 priority value. If the priority is the same for both services, MUAs
219 are free to choose whichever one is appropriate. When considering
220 multiple records for different protocols at the same priority but
221 with different weights, the client MUST first select the protocol it
222
223
224
225
226Daboo Standards Track [Page 4]
227
228RFC 6186 SRV for Email March 2011
229
230
231 intends to use, then perform the weight selection algorithm given in
232 [RFC2782] on the records associated with the selected protocol.
233
234 Example: service records for both IMAP and POP3, with IMAP having a
235 lower-numbered priority value (0) than POP3 (10), indicating to the
236 MUA that IMAP is preferred over POP3, when the MUA can support either
237 service.
238
239 _imap._tcp SRV 0 1 143 imap.example.com.
240 _pop3._tcp SRV 10 1 110 pop3.example.com.
241
242 In addition, with SRV RRs it is possible to indicate that a ../mox-/admin.go:892
243 particular service is not supported at all at a particular domain by
244 setting the target of an SRV RR to ".". If such records are present,
245 clients MUST assume that the specified service is not available, and
246 instead make use of the other SRV RRs for the purposes of determining
247 the domain preference.
248
249 Example: service records for IMAP and POP3 with both TLS and non-TLS
250 service types are present. Both IMAP and POP3 non-TLS service types
251 are marked as not available. IMAP (with TLS) has a lower-numbered
252 priority value 0 than POP3 (with TLS) at priority 10, indicating to
253 the MUA that IMAP is preferred over POP3, when the MUA can support
254 either service, and only the TLS versions of the services are
255 available.
256
257 _imap._tcp SRV 0 0 0 .
258 _imaps._tcp SRV 0 1 993 imap.example.com.
259 _pop3._tcp SRV 0 0 0 .
260 _pop3s._tcp SRV 10 1 995 pop3.example.com.
261
2624. Guidance for MUAs
263
264 By using SRV records as above, MUAs need initially only to prompt the
265 user for their email address [RFC5322]. The "local-part" and
266 "domain" portions are then extracted from the email address by the
267 MUA. The MUA uses the "domain" portion as the service domain to
268 perform SRV lookups for the services it wants to configure. If the
269 SRV lookup is successful, the target FQDN and port for the service
270 can be determined and used to complete MUA configuration. If an SRV
271 record is not found, the MUA will need to prompt the user to enter
272 the FQDN and port information directly, or use some other heuristic.
273 In the case of multiple SRV records returned for a particular
274 service, the MUA MUST use the priority and weight fields in the
275 record to determine which one to use (as per [RFC2782]).
276
277 MUAs that support both POP3 and IMAP use the procedure in Section 3.4
278 to choose between each service when both are offered.
279
280
281
282Daboo Standards Track [Page 5]
283
284RFC 6186 SRV for Email March 2011
285
286
287 Subsequent to configuration, the MUA will connect to the service.
288 When using "imaps" or "pop3s" services, a TLS [RFC5246] negotiation
289 is done immediately upon connection. With "imap", "pop3", and
290 "submission" services, the "STARTTLS", "STLS", and "STARTTLS"
291 commands respectively are used to initiate a protected connection
292 using TLS [RFC5246]. When using TLS in this way, MUAs SHOULD use the
293 TLS Server Name Indication [RFC6066]. Certificate verification MUST
294 use the procedure outlined in Section 6 of [RFC6125] in regard to
295 verification with an SRV RR as the starting point.
296
297 Once a suitable connection has been made, and any required protection
298 set up, the MUA will typically need to authenticate with the IMAP,
299 POP3, or SMTP (submission) server. The details of that are governed
300 by the specific protocols themselves, though often times a "user
301 identifier" is required for some form of user/password
302 authentication. When a user identifier is required, MUAs MUST first
303 use the full email address provided by the user, and if that results
304 in an authentication failure, SHOULD fall back to using the "local-
305 part" extracted from the email address. This is in line with the
306 guidance outlined in Section 5. If both these user identifiers
307 result in authentication failure, the MUA SHOULD prompt the user for
308 a valid identifier.
309
310 Once a successful connection and authentication have been done, MUAs
311 SHOULD cache the service details (hostname, port, user identity) that
312 were successfully used, and reuse those when connecting again at a
313 later time.
314
315 If a subsequent connection attempt fails, or authentication fails,
316 MUAs SHOULD re-try the SRV lookup to "refresh" the cached data for
317 the same protocol the client had chosen earlier; i.e., this means
318 that the client MUST NOT change from IMAP service to POP3 (or vice
319 versa) due to changes in the corresponding SRV priorities without
320 user interaction.
321
3225. Guidance for Service Providers
323
324 Service providers wanting to offer IMAP, POP3, or SMTP (submission)
325 services that can be configured by MUAs using SRV records need to
326 follow certain guidelines to ensure proper operation.
327
328 a. IMAP, POP3, and SMTP (submission) servers SHOULD be configured to
329 allow authentication with email addresses or email local-parts.
330 In the former case, the email addresses MUST NOT conflict with
331 other forms of permitted user login name. In the latter case,
332 the email local-parts need to be unique across the server and
333 MUST NOT conflict with any login name on the server.
334
335
336
337
338Daboo Standards Track [Page 6]
339
340RFC 6186 SRV for Email March 2011
341
342
343 b. If the service provider uses TLS [RFC5246], the service provider
344 MUST ensure a certificate is installed that can be verified by
345 MUAs using the procedure outlined in Section 6 of [RFC6125] in
346 regard to verification with an SRV RR as the starting point. If
347 the service provider hosts multiple domains on the same IP
348 address, then the service provider MUST enable support for the
349 TLS Server Name Indication [RFC6066].
350
351 c. Install the appropriate SRV records for the offered services.
352
3536. Security Considerations
354
355 If a user has explicitly requested a connection with a transport
356 layer security mechanism (user interfaces sometimes present this
357 choice as a "use SSL" or "secure connection" checkbox), the MUA MUST
358 successfully negotiate transport layer security prior to sending an
359 authentication command. For example, the MUA MAY do this with
360 "imaps", "pop3s", "imap" with "STARTTLS", or "pop3" with "STLS".
361 Service providers MAY offer any subset of these four options for the
362 mail service.
363
364 A malicious attacker with access to the DNS server data, or able to
365 get spoofed answers cached in a recursive resolver, can potentially
366 cause MUAs to connect to any IMAP, POP3, or submission server chosen
367 by the attacker. In the absence of a secure DNS option, MUAs SHOULD
368 check that the target FQDN returned in the SRV record matches the
369 original service domain that was queried. If the target FQDN is not
370 in the queried domain, MUAs SHOULD verify with the user that the SRV
371 target FQDN is suitable for use before executing any connections to
372 the host. Alternatively, if TLS [RFC5246] is being used for the
373 email service, MUAs MUST use the procedure outlined in Section 6 of
374 [RFC6125] to verify the service.
375
376 Implementations of TLS [RFC5246] typically support multiple versions
377 of the protocol as well as the older Secure Sockets Layer (SSL)
378 protocol. Because of known security vulnerabilities, email clients
379 and email servers MUST NOT request, offer, or use SSL 2.0. See
380 Appendix E.2 of [RFC5246] for further details.
381
3827. Acknowledgments
383
384 Thanks to Tony Finch, Ned Freed, Alfred Hoenes, Suresh Krishnan,
385 Alexey Melnikov, Chris Newman, and Phil Pennock for feedback and
386 suggestions. Some of this work is based on a previously drafted
387 document by John Klensin and Eric Hall.
388
389
390
391
392
393
394Daboo Standards Track [Page 7]
395
396RFC 6186 SRV for Email March 2011
397
398
3998. References
400
4018.1. Normative References
402
403 [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
404 STD 53, RFC 1939, May 1996.
405
406 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
407 Requirement Levels", BCP 14, RFC 2119, March 1997.
408
409 [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
410 RFC 2595, June 1999.
411
412 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
413 specifying the location of services (DNS SRV)", RFC 2782,
414 February 2000.
415
416 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
417 Transport Layer Security", RFC 3207, February 2002.
418
419 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
420 4rev1", RFC 3501, March 2003.
421
422 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail",
423 RFC 4409, April 2006.
424
425 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
426 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
427
428 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
429 October 2008.
430
431 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
432 October 2008.
433
434 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
435 Extension Definitions", RFC 6066, January 2011.
436
437 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
438 Verification of Domain-Based Application Service Identity
439 within Internet Public Key Infrastructure Using X.509
440 (PKIX) Certificates in the Context of Transport Layer
441 Security (TLS)", RFC 6125, March 2011.
442
4438.2. Informative References
444
445 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
446 July 2009.
447
448
449
450Daboo Standards Track [Page 8]
451
452RFC 6186 SRV for Email March 2011
453
454
455Author's Address
456
457 Cyrus Daboo
458 Apple Inc.
459 1 Infinite Loop
460 Cupertino, CA 95014
461 USA
462
463 EMail: cyrus@daboo.name
464 URI: http://www.apple.com/
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506Daboo Standards Track [Page 9]
507
508