One document matched: draft-daboo-srv-email-05.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
<!ENTITY rfc1939 PUBLIC '' 'bibxml/reference.RFC.1939.xml'>
<!ENTITY rfc2119 PUBLIC '' 'bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2595 PUBLIC '' 'bibxml/reference.RFC.2595.xml'>
<!ENTITY rfc2782 PUBLIC '' 'bibxml/reference.RFC.2782.xml'>
<!ENTITY rfc3207 PUBLIC '' 'bibxml/reference.RFC.3207.xml'>
<!ENTITY rfc3501 PUBLIC '' 'bibxml/reference.RFC.3501.xml'>
<!ENTITY rfc4366 PUBLIC '' 'bibxml/reference.RFC.4366.xml'>
<!ENTITY rfc4409 PUBLIC '' 'bibxml/reference.RFC.4409.xml'>
<!ENTITY rfc5246 PUBLIC '' 'bibxml/reference.RFC.5246.xml'>
<!ENTITY rfc5321 PUBLIC '' 'bibxml/reference.RFC.5321.xml'>
<!ENTITY rfc5322 PUBLIC '' 'bibxml/reference.RFC.5322.xml'>
<!ENTITY rfc5598 PUBLIC '' 'bibxml/reference.RFC.5598.xml'>
<!ENTITY idTLSCheck SYSTEM 'bibxml3/reference.I-D.saintandre-tls-server-id-check.xml'>
]>
<?rfc rfcedstyle="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?><!-- default = 3 -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<!-- <?rfc strict="yes"?> -->
<!-- <?rfc comments="yes"?> -->
<!-- <?rfc inline="yes"?> -->
<rfc category="std" ipr='trust200902' docName='draft-daboo-srv-email-05' updates="1939,3501">
<front>
<title abbrev="SRV for Email">Use of SRV Records for Locating Email Submission/Access services</title>
<author initials="C." surname="Daboo" fullname="Cyrus Daboo">
<organization abbrev="Apple Inc.">
Apple Inc.
</organization>
<address>
<postal>
<street>
1 Infinite Loop
</street>
<city>
Cupertino
</city>
<region>
CA
</region>
<code> 95014 </code>
<country>
USA
</country>
</postal>
<email>
cyrus@daboo.name
</email>
<uri>
http://www.apple.com/
</uri>
</address>
</author>
<date />
<area>
Applications
</area>
<abstract>
<t>
This specification describes how SRV records can be used to locate email services.
</t>
</abstract>
</front>
<middle>
<section title='Introduction'>
<t>
Internet Email protocols include <xref target="RFC5321">SMTP</xref>, <xref target="RFC3501">IMAP</xref> and <xref target="RFC1939">POP3</xref>. IMAP and POP3 are both message store access protocols used by message store user agents (MUAs) to manipulate email messages after delivery. <xref target="RFC4409"/> defines a "profile" of the SMTP service that is specifically used for message submission. MUAs are expected to submit messages to mail submission agents (MSAs) using this approach.
</t>
<t>
<xref target="RFC2782"/> defines a DNS-based service discovery protocol that has been widely adopted as a means of locating particular services within a local area network and beyond, using DNS SRV Resource Records (RRs).
</t>
<t>
<xref target="RFC5321"/> specifies how to use DNS MX RRs to locate SMTP services for a domain. However, MUAs are expected to use the submission protocol defined in <xref target="RFC4409"/> which does not use MX records.
</t>
<t>
Typically MUAs have required users to enter a fully qualified domain name (FQDN) and port information for the services they need. This is not ideal as the way in which server configuration information is specified can differ from MUA to MUA, and can be confusing to users, leading to errors when inputting the details. Alternatively, some MUAs have adopted a complex "auto-discovery" process involving probing a domain to see what services might be available. A better approach to all this would be to require minimal information to be entered by a user which would result in automatic configuration of appropriate services for that user. The minimal information entered would be the user's email address.
</t>
<t>
This specification defines new SRV service types for the message submission, IMAP and POP3 services, to enable simple auto-configuration of MUAs. The priority field of the SRV record can also be used to indicate a preference for one message store access protocol over another.
</t>
</section>
<section title='Conventions Used in This Document'>
<t>
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 <xref target='RFC2119' />.
</t>
<t>
Email-related terminology from <xref target='RFC5598'/> is used.
</t>
</section>
<section title='SRV Service Labels'>
<section title='Email Submission'>
<t>
This specification adds one SRV service label for <xref target="RFC4409">message submission</xref>:
<list style="hanging">
<t hangText="submission:">
Identifies an MSA using <xref target="RFC4409"/>. Note that this covers connections both with and without <xref target="RFC5246">TLS</xref> as defined for SMTP in <xref target='RFC3207'/>.
</t>
</list>
<figure>
<preamble>
Example: service record
</preamble>
<artwork>
_submission._tcp SRV 0 1 587 mail.example.com.
</artwork>
</figure>
</t>
</section>
<section title='IMAP'>
<t>
This specification adds two SRV service labels for <xref target="RFC3501">IMAP</xref>:
<list style="hanging">
<t hangText="_imap:">
Identifies an IMAP server that MAY advertise the "LOGINDISABLED" capability and MAY require the MUA to use the "STARTTLS" command prior to authentication. Although these two extensions are mandatory-to-implement for both MUAs and IMAP servers, they are not mandatory-to-use by service providers.
</t>
<t hangText="_imaps:">
Identifies an IMAP server where <xref target="RFC5246">TLS</xref> is initiated directly upon connection to the IMAP server.
</t>
</list>
<figure>
<preamble>
Example: service record
</preamble>
<artwork>
_imap._tcp SRV 0 1 143 imap.example.com.
</artwork>
</figure>
<figure>
<preamble>
Example: service record
</preamble>
<artwork>
_imaps._tcp SRV 0 1 993 imap.example.com.
</artwork>
</figure>
</t>
</section>
<section title='POP3'>
<t>
This specification adds two SRV service labels for <xref target="RFC1939">POP3</xref>:
<list style="hanging">
<t hangText="_pop3:">
Identifies a POP3 server that MAY require the MUA to use the <xref target='RFC2595'>"STLS" extension command</xref> prior to authentication. </t>
<t hangText="_pop3s:">
Identifies a POP3 server where <xref target="RFC5246">TLS</xref> is initiated directly upon connection to the POP3 server.
</t>
</list>
<figure>
<preamble>
Example: service record
</preamble>
<artwork>
_pop3._tcp SRV 0 1 110 pop3.example.com.
</artwork>
</figure>
<figure>
<preamble>
Example: service record
</preamble>
<artwork>
_pop3s._tcp SRV 0 1 995 pop3.example.com.
</artwork>
</figure>
</t>
</section>
<section title='Priority for Domain Preferences' anchor='priority'>
<t>
The priority field in the SRV RR allows a domain to indicate that some records have a higher preference than others in the DNS query results (determined by those records having a lower priority value). Typically, this is used for choosing a record from a set for a single service label, however it is not restricted to choice within only one service.
</t>
<t>
Often a site will offer both IMAP and POP3 message store access 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, when the user has an MUA capable of using both IMAP and POP3, that the preferred choice is used.
</t>
<t>
To aid with this choice, sites SHOULD offer both sets of IMAP (_imap and/or _imaps) and POP3 (_pop3 and/or _pop3s) SRV records in their DNS and set the priority for those sets of records such that the "preferred" service has a lower priority value than the other. When an MUA supports both IMAP and POP3 it SHOULD retrieve records for both services and then use the service with the lowest priority value. If the priority is the same for both services, MUAs are free 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 <xref target="RFC2782"/> on the records associated with the selected protocol.
<figure>
<preamble>
Example: service records for both IMAP and POP3, with IMAP having a lower priority value (0) then POP3 (10), indicating to the MUA that IMAP is preferred over POP3, when the MUA can support either service.
</preamble>
<artwork>
_imap._tcp SRV 0 1 143 imap.example.com.
_pop3._tcp SRV 10 1 110 pop3.example.com.
</artwork>
</figure>
</t>
</section>
</section>
<section title='Guidance for MUAs'>
<t>
By using SRV records as above, MUAs need initially only prompt the user for their <xref target="RFC5322">email address</xref>. The "local-part" and "domain" portions are then extracted from the email address by the MUA. The MUA uses the "domain" portion as the service domain to perform SRV lookups for the services it wants to configure. If the SRV lookup is successful the target FQDN and port for the service can be determined and used to complete MUA configuration. If an SRV 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. In the case of multiple SRV records returned for a particular service, the MUA MUST use the priority and weight fields in the record to determine which one to use (as per <xref target='RFC2782'/>).
</t>
<t>
MUAs that support both POP3 and IMAP use the procedure in <xref target='priority'/> to choose between each service when both are offered.
</t>
<t>
Subsequent to configuration, the MUA will connect to the service. When using "imaps" or "pop3s" services, a <xref target="RFC5246">TLS</xref> negotiation is done immediately upon connection. With "imap", "pop3" and "submission" services, the "STARTTLS", "STLS" and "STARTTLS" commands respectively are used to initiate a protected connection using <xref target="RFC5246">TLS</xref>. When using TLS in this way, MUAs SHOULD use the <xref target="RFC4366">TLS Server Name Indication</xref>. Certificate verification MUST use the procedure outlined in Section 4.3 of <xref target='I-D.saintandre-tls-server-id-check'/> in regard to verification with an SRV RR as the starting point.
</t>
<t>
Once a suitable connection has been made, and any required protection setup, the MUA will typically need to authenticate with the IMAP, POP3 or SMTP (submission) server. The details of that are governed by the specific protocols themselves, though often times a "user identifier" is required for some form of user/password authentication. When a user identifier is required, MUAs MUST first use the full email address provided by the user, and if that results in an authentication failure, SHOULD fall back to using the "local-part" extracted from the email address. This is in line with the guidance outlined in <xref target="service_provider"/>. If both these user identifiers result in authentication failure, the MUA SHOULD prompt the user for a valid identifier.
</t>
<t>
Once a successful connection and authentication have been done, MUAs SHOULD cache the service details (hostname, port, user identity) that were successfully used, and re-use those when connecting again at a later time.
</t>
<t>
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.
</t>
</section>
<section title='Guidance for Service Providers' anchor='service_provider'>
<t>
Service providers wanting to offer IMAP, POP3 or SMTP (submission) services that can be configured by MUAs using SRV records need to follow certain guidelines to ensure proper operation.
</t>
<t>
<list style='letters'>
<t>IMAP, POP3 and SMTP (submission) servers SHOULD be configured to allow authentication with email addresses or email local-parts. In the former case, the email addresses MUST NOT conflict with other forms of permitted user login name. In the latter case, the email local-parts need to be unique across the server and MUST NOT conflict with any login name on the server.</t>
<t>If the service provider uses <xref target="RFC5246">TLS</xref>, the service provider MUST ensure a certificate is installed that can be verified by MUAs using the procedure outlined in Section 4.3 of <xref target='I-D.saintandre-tls-server-id-check'/> in regard to verification with an SRV RR as the starting point. If the service provider hosts multiple domains on the same IP address, then the service provider MUST enable support for the <xref target="RFC4366">TLS Server Name Indication</xref>.</t>
<t>Install the appropriate SRV records for the offered services.</t>
</list>
</t>
</section>
<section title='Security Considerations'>
<t>
If a user has explicitly requested a connection with transport layer security (user interfaces sometimes present this choice as a "use SSL" or "secure connection" checkbox), the MUA MUST successfully negotiate transport layer security prior to sending an authentication command. The MUA MAY do this with "imaps", "pop3s", "imap" with "STARTTLS", or "pop3" with "STLS". Service providers MAY offer any subset of these four options for the mail service.
</t>
<t>
A malicious attacker with access to the DNS server data, or able to get spoofed answers cached in a recursive resolver, can potentially 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 check that the target FQDN returned in the SRV record matches the 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 target FQDN is suitable for use before executing any connections to the host. Alternatively, if <xref target="RFC5246">TLS</xref> is being used for the email service, MUAs MUST use the procedure outlined in Section 4.3 of <xref target='I-D.saintandre-tls-server-id-check'/> to verify the service.
</t>
<t>
Implementations of <xref target="RFC5246">TLS</xref> 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 <xref target="RFC5246"/> for further details.
</t>
</section>
<section title='IANA Considerations'>
<t>
This document does not require any actions on the part of IANA.
</t>
</section>
<section title='Acknowledgments'>
<t>
Thanks to Tony Finch, Ned Freed, Alfred Hoenes, Suresh Krishnan, Alexey Melnikov, and Chris Newman for feedback and suggestions. Some of this work is based on a previous internet draft by John Klensin and Eric Hall.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc1939;
&rfc2119;
&rfc2595;
&rfc2782;
&rfc3207;
&rfc3501;
&rfc4366;
&rfc4409;
&rfc5246;
&rfc5321;
&rfc5322;
&idTLSCheck;
</references>
<references title='Informative References'>
&rfc5598;
</references>
<section title='Change History (to be removed prior to publication as an RFC)'>
<t>Changes in -05:
<list style='numbers'>
<t>IESG review: Indicate that this spec updates 1937 and 3501.</t>
<t>IESG review: Fixed minor typos found in IESG review.</t>
<t>IESG review: Added text explaining how to deal with both SRV priority and weight.</t>
<t>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.</t>
<t>IESG review: Added statement that SSL v2 is not allowed.</t>
<t>IESG review: Changed TLS server name indication reference back to RFC4366.</t>
<t>Changing "transport layer security" to TLS when it specifically refers to RFC5246.</t>
</list>
</t>
<t>Changes in -04:
<list style='numbers'>
<t>Updated reference to draft-saintandre-tls-server-id-check.</t>
<t>Tweaked 3.4 to indicate that the _XXXs variants of service type are also included in the "weighting" approach.</t>
<t>Tweaked Acknowledgments.</t>
</list>
</t>
<t>Changes in -03:
<list style='numbers'>
<t>Added ability to use priority to select one access protocol over another.</t>
<t>Added statement that clients should retry SRV on subsequent connection failure.</t>
<t>Added statement about handling multiple records for the same service.</t>
<t>Stronger use of MUST NOT in Section 5(a).</t>
<t>GENART: Added statement that clients should prompt the user if both email and local-part authentication fail.</t>
<t>Tweaked title.</t>
<t>"Service type" -> "Service label"</t>
<t>"Host name" -> "target FQDN"</t>
<t>Improvements to security considerations wrt DNS attacks.</t>
<t>MUA and service provider guidance now includes submission service.</t>
<t>Added References to draft-saintandre-tls-server-id-check that should define the proper cert validation procedures.</t>
<t>SECDIR: reworked introduction.</t>
<t>Switched to using terminology from RFC5598.</t>
</list>
</t>
<t>Changes in -02:
<list style='numbers'>
<t>Tweaked text for imap to better describe mandatory-to-implement behavior from base spec.</t>
<t>Tweaked text for pop3 along similar lines as imap.</t>
<t>Teaked security considerations to account for use of STARTTLS and STLS.</t>
<t>Added examples for imaps and pop3s.</t>
<t>Re-worked client guidelines.</t>
<t>Added service provider guidelines.</t>
</list>
</t>
<t>Changes in -01:
<list style='numbers'>
<t>Tweaked text for pop3 to make it clearer that STLS is an extension.</t>
<t>Added text to explain that the email address, as well as the local-part, may be used as the user identifier.</t>
<t>Tweaked security considerations to account for use of STARTTLS and STLS.</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:49:45 |