< draft-daboo-srv-email-04.txt   draft-daboo-srv-email-05.txt >
Network Working Group C. Daboo Network Working Group C. Daboo
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Intended status: Standards Track March 22, 2010 Updates: 1939,3501 May 12, 2010
Expires: September 23, 2010 (if approved)
Intended status: Standards Track
Expires: November 13, 2010
Use of SRV Records for Locating Email Submission/Access services Use of SRV Records for Locating Email Submission/Access services
draft-daboo-srv-email-04 draft-daboo-srv-email-05
Abstract Abstract
This specification describes how SRV records can be used to locate This specification describes how SRV records can be used to locate
email services. email services.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 37 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 23, 2010. This Internet-Draft will expire on November 13, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . . 3
3. SRV Service Labels . . . . . . . . . . . . . . . . . . . . . . 4 3. SRV Service Labels . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Email Submission . . . . . . . . . . . . . . . . . . . . . 4 3.1. Email Submission . . . . . . . . . . . . . . . . . . . . . 4
3.2. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.3. POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. Priority for Domain Preferences . . . . . . . . . . . . . . 5 3.4. Priority for Domain Preferences . . . . . . . . . . . . . . 5
4. Guidance for MUAs . . . . . . . . . . . . . . . . . . . . . . . 5 4. Guidance for MUAs . . . . . . . . . . . . . . . . . . . . . . . 5
5. Guidance for Service Providers . . . . . . . . . . . . . . . . 6 5. Guidance for Service Providers . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Change History (to be removed prior to Appendix A. Change History (to be removed prior to
publication as an RFC) . . . . . . . . . . . . . . . . 9 publication as an RFC) . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
Internet Email protocols include SMTP [RFC5321], IMAP [RFC3501] and Internet Email protocols include SMTP [RFC5321], IMAP [RFC3501] and
skipping to change at page 4, line 13 skipping to change at page 4, line 13
Email-related terminology from [RFC5598] is used. Email-related terminology from [RFC5598] is used.
3. SRV Service Labels 3. SRV Service Labels
3.1. Email Submission 3.1. Email Submission
This specification adds one SRV service label for message submission This specification adds one SRV service label for message submission
[RFC4409]: [RFC4409]:
submission: Identifies an MSA using [RFC4409]. Note that this submission: Identifies an MSA using [RFC4409]. Note that this
covers connections both with and without transport layer security covers connections both with and without TLS [RFC5246] as defined
[RFC3207]. for SMTP in [RFC3207].
Example: service record Example: service record
_submission._tcp SRV 0 1 587 mail.example.com. _submission._tcp SRV 0 1 587 mail.example.com.
3.2. IMAP 3.2. IMAP
This specification adds two SRV service labels for IMAP [RFC3501]: This specification adds two SRV service labels for IMAP [RFC3501]:
_imap: Identifies an IMAP server that MAY advertise the _imap: Identifies an IMAP server that MAY advertise the
"LOGINDISABLED" capability and MAY require the MUA to use the "LOGINDISABLED" capability and MAY require the MUA to use the
"STARTTLS" command prior to authentication. Although these two "STARTTLS" command prior to authentication. Although these two
extensions are mandatory-to-implement for both MUAs and IMAP extensions are mandatory-to-implement for both MUAs and IMAP
servers, they are not mandatory-to-use by service providers. servers, they are not mandatory-to-use by service providers.
_imaps: Identifies an IMAP server where transport layer security is _imaps: Identifies an IMAP server where TLS [RFC5246] is initiated
initiated directly upon connection to the IMAP server. directly upon connection to the IMAP server.
Example: service record Example: service record
_imap._tcp SRV 0 1 143 imap.example.com. _imap._tcp SRV 0 1 143 imap.example.com.
Example: service record Example: service record
_imaps._tcp SRV 0 1 993 imap.example.com. _imaps._tcp SRV 0 1 993 imap.example.com.
3.3. POP3 3.3. POP3
This specification adds two SRV service labels for POP3 [RFC1939]: This specification adds two SRV service labels for POP3 [RFC1939]:
_pop3: Identifies a POP3 server that MAY require the MUA to use the _pop3: Identifies a POP3 server that MAY require the MUA to use the
"STLS" extension command [RFC2595] prior to authentication. "STLS" extension command [RFC2595] prior to authentication.
_pop3s: Identifies a POP3 server where transport layer security is _pop3s: Identifies a POP3 server where TLS [RFC5246] is initiated
initiated directly upon connection to the POP3 server. directly upon connection to the POP3 server.
Example: service record Example: service record
_pop3._tcp SRV 0 1 110 pop3.example.com. _pop3._tcp SRV 0 1 110 pop3.example.com.
Example: service record Example: service record
_pop3s._tcp SRV 0 1 995 pop3.example.com. _pop3s._tcp SRV 0 1 995 pop3.example.com.
3.4. Priority for Domain Preferences 3.4. Priority for Domain Preferences
skipping to change at page 5, line 29 skipping to change at page 5, line 29
service label, however it is not restricted to choice within only one service label, however it is not restricted to choice within only one
service. service.
Often a site will offer both IMAP and POP3 message store access Often a site will offer both IMAP and POP3 message store access
services for users. However, the site may have a preference for one services for users. However, the site may have a preference for one
over the other that they want to convey to the user to ensure that, over the other that they want to convey to the user to ensure that,
when the user has an MUA capable of using both IMAP and POP3, that when the user has an MUA capable of using both IMAP and POP3, that
the preferred choice is used. the preferred choice is used.
To aid with this choice, sites SHOULD offer both sets of IMAP (_imap To aid with this choice, sites SHOULD offer both sets of IMAP (_imap
and _imaps) and POP3 (_po3 and/or _pop3s) SRV records in their DNS and/or _imaps) and POP3 (_pop3 and/or _pop3s) SRV records in their
and set the priority for those sets of records such that the DNS and set the priority for those sets of records such that the
"preferred" service has a lower priority value than the other. When "preferred" service has a lower priority value than the other. When
an MUA supports both IMAP and POP3 it SHOULD retrieve records for an MUA supports both IMAP and POP3 it SHOULD retrieve records for
both services and then use the service with the lowest priority both services and then use the service with the lowest priority
value. If the priority is the same for both services, MUAs are free value. If the priority is the same for both services, MUAs are free
to choose which ever one is appropriate. to choose which ever one is appropriate. When considering multiple
records for different protocols at the same priority but with
different weights, the client MUST first select the protocol it
intends to use, then perform the weight selection algorithm given in
[RFC2782] on the records associated with the selected protocol.
Example: service records for both IMAP and POP3, with IMAP having a Example: service records for both IMAP and POP3, with IMAP having a
lower priority value (0) then POP3 (10), indicating to the MUA that lower priority value (0) then POP3 (10), indicating to the MUA that
IMAP is preferred over POP3, when the MUA can support either service. IMAP is preferred over POP3, when the MUA can support either service.
_imap._tcp SRV 0 1 143 imap.example.com. _imap._tcp SRV 0 1 143 imap.example.com.
_pop3._tcp SRV 10 1 110 pop3.example.com. _pop3._tcp SRV 10 1 110 pop3.example.com.
4. Guidance for MUAs 4. Guidance for MUAs
skipping to change at page 6, line 14 skipping to change at page 6, line 18
record is not found, the MUA will need to prompt the user to enter record is not found, the MUA will need to prompt the user to enter
the FQDN and port information directly, or use some other heuristic. the FQDN and port information directly, or use some other heuristic.
In the case of multiple SRV records returned for a particular In the case of multiple SRV records returned for a particular
service, the MUA MUST use the priority and weight fields in the service, the MUA MUST use the priority and weight fields in the
record to determine which one to use (as per [RFC2782]). record to determine which one to use (as per [RFC2782]).
MUAs that support both POP3 and IMAP use the procedure in Section 3.4 MUAs that support both POP3 and IMAP use the procedure in Section 3.4
to choose between each service when both are offered. to choose between each service when both are offered.
Subsequent to configuration, the MUA will connect to the service. Subsequent to configuration, the MUA will connect to the service.
When using "imaps" or "pop3s" services, a transport layer security When using "imaps" or "pop3s" services, a TLS [RFC5246] negotiation
negotiation is done immediately upon connection. With "imap", "pop3" is done immediately upon connection. With "imap", "pop3" and
and "submission" services, the "STARTTLS", "STLS" and "STARTTLS" "submission" services, the "STARTTLS", "STLS" and "STARTTLS" commands
commands respectively are used to initiate a protected connection. respectively are used to initiate a protected connection using TLS
When using transport layer security in this way, MUAs SHOULD use the [RFC5246]. When using TLS in this way, MUAs SHOULD use the TLS
TLS Server Name Indication [RFC5246]. Certificate verification MUST Server Name Indication [RFC4366]. Certificate verification MUST use
use the procedure outlined in Section 4.3 of the procedure outlined in Section 4.3 of
[I-D.saintandre-tls-server-id-check] in regard to verification with [I-D.saintandre-tls-server-id-check] in regard to verification with
an SRV RR as the starting point. an SRV RR as the starting point.
Once a suitable connection has been made, and any required protection Once a suitable connection has been made, and any required protection
setup, the MUA will typically need to authenticate with the IMAP, setup, the MUA will typically need to authenticate with the IMAP,
POP3 or SMTP (submission) server. The details of that are governed POP3 or SMTP (submission) server. The details of that are governed
by the specific protocols themselves, though often times a "user by the specific protocols themselves, though often times a "user
identifier" is required for some form of user/password identifier" is required for some form of user/password
authentication. When a user identifier is required, MUAs MUST first authentication. When a user identifier is required, MUAs MUST first
use the full email address provided by the user, and if that results use the full email address provided by the user, and if that results
in an authentication failure, SHOULD fall back to using the "local- in an authentication failure, SHOULD fall back to using the "local-
part" extracted from the email address. This is in line with the part" extracted from the email address. This is in line with the
guidance outlined in Section 5. If both these user identifiers guidance outlined in Section 5. If both these user identifiers
result in authentication failure, the MUA SHOULD prompt the user for result in authentication failure, the MUA SHOULD prompt the user for
a valid identifier. a valid identifier.
Once a successful connection and authentication have been done, MUAs Once a successful connection and authentication have been done, MUAs
SHOULD cache the service details (hostname, port, user identity) that SHOULD cache the service details (hostname, port, user identity) that
were successfully used, and re-use those when connecting again at a were successfully used, and re-use those when connecting again at a
later time. However, if a subsequent connection attempt fails, or later time.
authentication fails, MUAs SHOULD re-try the SRV lookup to "refresh"
the cached data. If a subsequent connection attempt fails, or authentication fails,
MUAs SHOULD re-try the SRV lookup to "refresh" the cached data for
the same protocol the client had chosen earlier. i.e., this means
that the client MUST NOT change from IMAP service to POP3 (or vice
versa) due to changes in the corresponding SRV priorities without
user interaction.
5. Guidance for Service Providers 5. Guidance for Service Providers
Service providers wanting to offer IMAP, POP3 or SMTP (submission) Service providers wanting to offer IMAP, POP3 or SMTP (submission)
services that can be configured by MUAs using SRV records need to services that can be configured by MUAs using SRV records need to
follow certain guidelines to ensure proper operation. follow certain guidelines to ensure proper operation.
a. IMAP, POP3 and SMTP (submission) servers SHOULD be configured to a. IMAP, POP3 and SMTP (submission) servers SHOULD be configured to
allow authentication with email addresses or email local-parts. allow authentication with email addresses or email local-parts.
In the former case, the email addresses MUST NOT conflict with In the former case, the email addresses MUST NOT conflict with
other forms of permitted user login name. In the latter case, other forms of permitted user login name. In the latter case,
the email local-parts need to be unique across the server and the email local-parts need to be unique across the server and
MUST NOT conflict with any login name on the server. MUST NOT conflict with any login name on the server.
b. If the service provider uses transport layer security, the b. If the service provider uses TLS [RFC5246], the service provider
service provider MUST ensure a certificate is installed that can MUST ensure a certificate is installed that can be verified by
be verified by MUAs using the procedure outlined in Section 4.3 MUAs using the procedure outlined in Section 4.3 of
of [I-D.saintandre-tls-server-id-check] in regard to verification [I-D.saintandre-tls-server-id-check] in regard to verification
with an SRV RR as the starting point. If the service provider with an SRV RR as the starting point. If the service provider
hosts multiple domains on the same IP address, then the service hosts multiple domains on the same IP address, then the service
provider MUST enable support for the TLS Server Name Indication provider MUST enable support for the TLS Server Name Indication
[RFC5246]. [RFC4366].
c. Install the appropriate SRV records for the offered services. c. Install the appropriate SRV records for the offered services.
6. Security Considerations 6. Security Considerations
If a user has explicitly requested a connection with transport layer If a user has explicitly requested a connection with transport layer
security (user interfaces sometimes present this choice as a "use security (user interfaces sometimes present this choice as a "use
SSL" or "secure connection" checkbox), the MUA MUST successfully SSL" or "secure connection" checkbox), the MUA MUST successfully
negotiate transport layer security prior to sending an authentication negotiate transport layer security prior to sending an authentication
command. The MUA MAY do this with "imaps", "pop3s", "imap" with command. The MUA MAY do this with "imaps", "pop3s", "imap" with
skipping to change at page 7, line 41 skipping to change at page 7, line 47
subset of these four options for the mail service. subset of these four options for the mail service.
A malicious attacker with access to the DNS server data, or able to A malicious attacker with access to the DNS server data, or able to
get spoofed answers cached in a recursive resolver, can potentially get spoofed answers cached in a recursive resolver, can potentially
cause MUAs to connect to any IMAP, POP3 or submission server chosen cause MUAs to connect to any IMAP, POP3 or submission server chosen
by the attacker. In the absence of a secure DNS option, MUAs SHOULD by the attacker. In the absence of a secure DNS option, MUAs SHOULD
check that the target FQDN returned in the SRV record matches the check that the target FQDN returned in the SRV record matches the
original service domain that was queried. If the target FQDN is not original service domain that was queried. If the target FQDN is not
in the queried domain, MUAs SHOULD verify with the user that the SRV in the queried domain, MUAs SHOULD verify with the user that the SRV
target FQDN is suitable for use before executing any connections to target FQDN is suitable for use before executing any connections to
the host. Alternatively, if transport layer security is being used the host. Alternatively, if TLS [RFC5246] is being used for the
for the email service, MUAs MUST use the procedure outlined in email service, MUAs MUST use the procedure outlined in Section 4.3 of
Section 4.3 of [I-D.saintandre-tls-server-id-check] to verify the [I-D.saintandre-tls-server-id-check] to verify the service.
service.
Implementations of TLS [RFC5246] typically support multiple versions
of the protocol as well as the older Secure Sockets Layer (SSL)
protocol. Because of known security vulnerabilities, email clients
and email servers MUST NOT request, offer, or use SSL 2.0. See
Appendix E.2 of [RFC5246] for further details.
7. IANA Considerations 7. IANA Considerations
This document does not require any actions on the part of IANA. This document does not require any actions on the part of IANA.
8. Acknowledgments 8. Acknowledgments
Thanks to Tony Finch, Ned Freed, Alfred Hoenes, Suresh Krishnan, Thanks to Tony Finch, Ned Freed, Alfred Hoenes, Suresh Krishnan,
Alexey Melnikov, and Chris Newman for feedback and suggestions. Some Alexey Melnikov, and Chris Newman for feedback and suggestions. Some
of this work is based on a previous internet draft by John Klensin of this work is based on a previous internet draft by John Klensin
skipping to change at page 8, line 23 skipping to change at page 8, line 30
9.1. Normative References 9.1. Normative References
[I-D.saintandre-tls-server-id-check] Saint-Andre, P. and J. Hodges, [I-D.saintandre-tls-server-id-check] Saint-Andre, P. and J. Hodges,
"Representation and "Representation and
Verification of Application Verification of Application
Server Identity in Certificates Server Identity in Certificates
Used with Transport Layer Used with Transport Layer
Security (TLS)", draft- Security (TLS)", draft-
saintandre-tls-server-id-check- saintandre-tls-server-id-check-
03 (work in progress), 04 (work in progress),
March 2010. April 2010.
[RFC1939] Myers, J. and M. Rose, "Post [RFC1939] Myers, J. and M. Rose, "Post
Office Protocol - Version 3", Office Protocol - Version 3",
STD 53, RFC 1939, May 1996. STD 53, RFC 1939, May 1996.
[RFC2119] Bradner, S., "Key words for use [RFC2119] Bradner, S., "Key words for use
in RFCs to Indicate Requirement in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, Levels", BCP 14, RFC 2119,
March 1997. March 1997.
skipping to change at page 9, line 5 skipping to change at page 9, line 14
[RFC3207] Hoffman, P., "SMTP Service [RFC3207] Hoffman, P., "SMTP Service
Extension for Secure SMTP over Extension for Secure SMTP over
Transport Layer Security", Transport Layer Security",
RFC 3207, February 2002. RFC 3207, February 2002.
[RFC3501] Crispin, M., "INTERNET MESSAGE [RFC3501] Crispin, M., "INTERNET MESSAGE
ACCESS PROTOCOL - VERSION ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
[RFC4366] Blake-Wilson, S., Nystrom, M.,
Hopwood, D., Mikkelsen, J., and
T. Wright, "Transport Layer
Security (TLS) Extensions",
RFC 4366, April 2006.
[RFC4409] Gellens, R. and J. Klensin, [RFC4409] Gellens, R. and J. Klensin,
"Message Submission for Mail", "Message Submission for Mail",
RFC 4409, April 2006. RFC 4409, April 2006.
[RFC5246] Dierks, T. and E. Rescorla, [RFC5246] Dierks, T. and E. Rescorla,
"The Transport Layer Security "The Transport Layer Security
(TLS) Protocol Version 1.2", (TLS) Protocol Version 1.2",
RFC 5246, August 2008. RFC 5246, August 2008.
[RFC5321] Klensin, J., "Simple Mail [RFC5321] Klensin, J., "Simple Mail
skipping to change at page 9, line 31 skipping to change at page 9, line 46
9.2. Informative References 9.2. Informative References
[RFC5598] Crocker, D., "Internet Mail [RFC5598] Crocker, D., "Internet Mail
Architecture", RFC 5598, Architecture", RFC 5598,
July 2009. July 2009.
Appendix A. Change History (to be removed prior to publication as an Appendix A. Change History (to be removed prior to publication as an
RFC) RFC)
Changes in -05:
1. IESG review: Indicate that this spec updates 1937 and 3501.
2. IESG review: Fixed minor typos found in IESG review.
3. IESG review: Added text explaining how to deal with both SRV
priority and weight.
4. IESG review: Added text to explain client methodology when
dealing with a failed connection to a service and how they re-do
SRV lookup without changing the service.
5. IESG review: Added statement that SSL v2 is not allowed.
6. IESG review: Changed TLS server name indication reference back to
RFC4366.
7. Changing "transport layer security" to TLS when it specifically
refers to RFC5246.
Changes in -04: Changes in -04:
1. Updated reference to draft-saintandre-tls-server-id-check. 1. Updated reference to draft-saintandre-tls-server-id-check.
2. Tweaked 3.4 to indicate that the _XXXs variants of service type 2. Tweaked 3.4 to indicate that the _XXXs variants of service type
are also included in the "weighting" approach. are also included in the "weighting" approach.
3. Tweaked Acknowledgments. 3. Tweaked Acknowledgments.
Changes in -03: Changes in -03:
 End of changes. 18 change blocks. 
36 lines changed or deleted 79 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/