RFC 6186

Use of SRV Records for Locating Email Submission/Access Services

📅 published March 2011, from ietf

RFC 6186: Use of SRV Records for Locating Email Submission/Access Services 💌

Internet Engineering Task Force (IETF) 🎀 Author: C. Daboo, Apple Inc. 🍎 Updates: 1939, 3501 ✨ Date: March 2011 🌸 Category: Standards Track 👑 ISSN: 2070-1721

Abstract 🦋

okay so this spec is all about how SRV records can be used to find email services. bestie, it's giving "how does my email app find the right server without me typing a novel" 💅

Status of This Memo 📜

this is an Internet Standards Track document, so it's official official 😭

it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check Section 2 of RFC 5741 🧚

info about the current status of this document, any errata, and how to give feedback is at http://www.rfc-editor.org/info/rfc6186 💖

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as of the publication date. please actually read these, bestie, because they spell out your rights and restrictions for this document 🫶

if you pull Code Components out of this document, they must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🔥

Table of Contents 🗺️

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Conventions Used in This Document . . . . . . . . . . . . . . . 3
   3.  SRV Service Labels  . . . . . . . . . . . . . . . . . . . . . . 3
     3.1.  Email Submission  . . . . . . . . . . . . . . . . . . . . . 3
     3.2.  IMAP  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     3.3.  POP3  . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     3.4.  Priority for Domain Preferences . . . . . . . . . . . . . . 4
   4.  Guidance for MUAs . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Guidance for Service Providers  . . . . . . . . . . . . . . . . 6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 8

1. Introduction 🧚

okay so internet email runs on a few protocols: SMTP [RFC5321], IMAP [RFC3501], and POP3 [RFC1939]. IMAP and POP3 are both message store access protocols, which is how message store user agents (MUAs) manipulate email after it's delivered 📬

[RFC4409] defines a "profile" of the SMTP service that's used specifically for message submission. MUAs are expected to submit messages to mail submission agents (MSAs) using this approach 💅

[RFC2782] defines a DNS-based service discovery protocol. it's been widely adopted for finding particular services within a local area network and beyond, using DNS SRV resource records (RRs) 🦋

[RFC5321] explains how to use DNS MX RRs to find SMTP services for a domain. but MUAs are expected to use the submission protocol from [RFC4409], which doesn't use MX records. not me being like "wait, so the MX records aren't the move here" 🙈

MUAs have usually made users type in a fully qualified domain name (FQDN) and port for each service they need. it's not ideal, because the way server config gets specified can be different from one MUA to another, and it's confusing, which leads to typos and errors 😭 some MUAs went with a complicated "auto-discovery" thing where they probe a domain to see what services might exist. ngl that's a lot. a better move would be asking the user for minimal info that automatically configures the right services for them. the minimal info is just the user's email address 💖

this specification defines new SRV service types for message submission, IMAP, and POP3 services, so MUAs can auto-configure super simply. the priority field of the SRV record can also show a preference for one message store access protocol over another 🌈

2. Conventions Used in This Document 🎀

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 [RFC2119]. 🫶

email-related terminology from [RFC5598] is used too 🔥

3. SRV Service Labels ✨

3.1. Email Submission 💌

this spec adds one SRV service label for message submission [RFC4409]:

  • submission: identifies an MSA using [RFC4409]. note that this covers connections both with and without Transport Layer Security (TLS) [RFC5246], as defined for SMTP in [RFC3207]. 💖

example service record:

_submission._tcp     SRV 0 1 587 mail.example.com.

3.2. IMAP 🦋

this spec adds two SRV service labels for IMAP [RFC3501]:

  • _imap: identifies an IMAP server that MAY advertise the "LOGINDISABLED" capability and MAY require the MUA to use the "STARTTLS" command prior to authentication. these two extensions are mandatory-to-implement for both MUAs and IMAP servers, but they're not mandatory-to-use by service providers. no pressure, service providers 🧚
  • _imaps: identifies an IMAP server where TLS [RFC5246] is initiated directly upon connection to the IMAP server. 🔥

example service record:

_imap._tcp     SRV 0 1 143 imap.example.com.

example service record:

_imaps._tcp    SRV 0 1 993 imap.example.com.

3.3. POP3 🌸

this spec adds two SRV service labels for POP3 [RFC1939]:

  • _pop3: identifies a POP3 server that MAY require the MUA to use the "STLS" extension command [RFC2595] prior to authentication. 🍓
  • _pop3s: identifies a POP3 server where TLS [RFC5246] is initiated directly upon connection to the POP3 server. 💜

example service record:

_pop3._tcp     SRV 0 1 110 pop3.example.com.

example service record:

_pop3s._tcp    SRV 0 1 995 pop3.example.com.

3.4. Priority for Domain Preferences 👑

the priority field in the SRV RR lets a domain show that some records are preferred over others in the DNS query results. the records with a lower-numbered priority value win. usually this is for picking one record from a set for a single service label, but it's not limited to just one service 🌈

a lot of sites offer both IMAP and POP3 for their users. but a site may prefer one over the other and want to tell the user that, so that when the user has an MUA that can do both, the preferred one gets used ✨

so to make that choice work, sites SHOULD offer both sets of records, IMAP (_imap and/or _imaps) and POP3 (_pop3 and/or _pop3s), in their DNS, and set priorities so the "preferred" service has a lower-numbered priority value than the other one. 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, MUAs are free to choose whichever one fits 💅

when there are records for different protocols at the same priority but with different weights, the client MUST first select the protocol it intends to use, and then run the weight selection algorithm from [RFC2782] on the records for that selected protocol. this part is so important, bestie 😭🔥

example: service records for both IMAP and POP3, where IMAP has a lower-numbered priority value (0) than POP3 (10). that tells the MUA IMAP is preferred over POP3, when the MUA can support either one:

_imap._tcp     SRV  0 1 143 imap.example.com.
_pop3._tcp     SRV 10 1 110 pop3.example.com.

also, with SRV RRs you can say a particular service isn't supported at all at a domain, by setting the target of an SRV RR to ".". if records like that are present, clients MUST assume the specified service isn't available, and instead use the other SRV RRs to figure out the domain preference 🙈

example: service records for IMAP and POP3 with both TLS and non-TLS service types present. both the IMAP and POP3 non-TLS service types are marked as not available. IMAP (with TLS) has a lower-numbered priority value, 0, than POP3 (with TLS) at priority 10. that tells the MUA IMAP is preferred over POP3, when the MUA can support either one, and only the TLS versions are available 🧚

_imap._tcp     SRV  0 0 0   .
_imaps._tcp    SRV  0 1 993 imap.example.com.
_pop3._tcp     SRV  0 0 0   .
_pop3s._tcp    SRV 10 1 995 pop3.example.com.

4. Guidance for MUAs ✨

okay bestie, so MUAs (mail user agents, aka your email apps 📬) basically only need to ask the user for their email address 💌 [RFC5322]. Then they split it up into the "local-part" and the "domain" 🦋. The MUA uses the "domain" bit as the service domain for its SRV lookups, for whatever services it wants to set up 🌸. If the SRV lookup works, the target FQDN and port for the service can be figured out and used to finish configuring the app 💖. If there's no SRV record found, the MUA has to ask the user to type in the FQDN and port directly, or use some other heuristic 🙈. And if a service has multiple SRV records, the MUA MUST use the priority and weight fields in the record to pick one (as per [RFC2782]) 👑. No cap, that part is non-negotiable 💅.

MUAs that support both POP3 and IMAP use the procedure in Section 3.4 to choose between the two when both are offered 🧚.

After setup, the MUA connects to the service 🎀. For "imaps" or "pop3s", a TLS [RFC5246] negotiation happens immediately on connection 🔒. For "imap", "pop3", and "submission", the "STARTTLS", "STLS", and "STARTTLS" commands respectively are used to start a protected connection using TLS [RFC5246] ✨. When using TLS like this, MUAs SHOULD use the TLS Server Name Indication [RFC6066] 💜. Certificate verification MUST follow the procedure in Section 6 of [RFC6125], starting from an SRV RR 🫶.

Once there's a suitable connection and any needed protection is set up, the MUA will usually need to authenticate with the IMAP, POP3, or SMTP (submission) server 🔐. The specifics are set by those protocols themselves, though a "user identifier" is often needed for some kind of user/password auth 🌈. When a user identifier is required, MUAs MUST first use the full email address the user gave, and if that causes an authentication failure, they SHOULD fall back to the "local-part" taken from the email address 🦋. This lines up with the guidance in Section 5 🌸. If both of these identifiers fail, the MUA SHOULD prompt the user for a valid identifier 😭.

Once a connection and authentication have both succeeded, MUAs SHOULD cache the service details (hostname, port, user identity) that worked, and reuse them next time they connect 💾✨.

If a later connection attempt fails, or authentication fails, MUAs SHOULD re-try the SRV lookup to "refresh" the cached data for the same protocol the client picked earlier 🔄. In other words, the client MUST NOT switch from IMAP to POP3 (or the other way around) because the SRV priorities changed, unless the user is involved 🙅‍♀️💅.

5. Guidance for Service Providers 🎀

Service providers who want to offer IMAP, POP3, or SMTP (submission) services that MUAs can configure using SRV records need to follow some guidelines so everything runs smoothly 🧁.

a. IMAP, POP3, and SMTP (submission) servers SHOULD be configured to allow authentication with email addresses or email local-parts 💌. In the first case, the email addresses MUST NOT conflict with any other permitted form of user login name 🙅‍♀️. In the second case, the email local-parts need to be unique across the server and MUST NOT conflict with any login name on the server 🫣.

b. If the service provider uses TLS [RFC5246], they MUST make sure a certificate is installed that MUAs can verify using the procedure in Section 6 of [RFC6125], starting from an SRV RR 🔐. If the service provider hosts multiple domains on the same IP address, they MUST enable support for the TLS Server Name Indication [RFC6066] 🌐✨.

c. Install the appropriate SRV records for the offered services 📝💖.

6. Security Considerations 🚨

Okay this section is SERIOUS bestie, read it all 😤🚨

If a user has explicitly asked for a connection with a transport layer security mechanism (some UIs show this as a "use SSL" or "secure connection" checkbox ☑️), the MUA MUST successfully negotiate transport layer security before sending an authentication command 🔒. For example, 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 🎀.

A malicious attacker with access to the DNS server data, or who can get spoofed answers cached in a recursive resolver, can potentially make MUAs connect to any IMAP, POP3, or submission server the attacker picks 😱💀. Without 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 making any connections to the host 🙋‍♀️. Alternatively, if TLS [RFC5246] is being used for the email service, MUAs MUST use the procedure in Section 6 of [RFC6125] to verify the 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. Acknowledgments 💜

Thanks to Tony Finch, Ned Freed, Alfred Hoenes, Suresh Krishnan, Alexey Melnikov, Chris Newman, and Phil Pennock for feedback and suggestions 🙏✨. Some of this work is based on a previously drafted document by John Klensin and Eric Hall 🌸.

8. References 📚

8.1. Normative References

[RFC1939]  Myers, J. and M. Rose, "Post Office Protocol - Version 3",
           STD 53, RFC 1939, May 1996.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2595]  Newman, C., "Using TLS with IMAP, POP3 and ACAP",
           RFC 2595, June 1999.

[RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
           specifying the location of services (DNS SRV)", RFC 2782,
           February 2000.

[RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
           Transport Layer Security", RFC 3207, February 2002.

[RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
           4rev1", RFC 3501, March 2003.

[RFC4409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
           RFC 4409, April 2006.

[RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
           (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
           October 2008.

[RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
           October 2008.

[RFC6066]  Eastlake, D., "Transport Layer Security (TLS) Extensions:
           Extension Definitions", RFC 6066, January 2011.

[RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
           Verification of Domain-Based Application Service Identity
           within Internet Public Key Infrastructure Using X.509
           (PKIX) Certificates in the Context of Transport Layer
           Security (TLS)", RFC 6125, March 2011.

8.2. Informative References

[RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598,
           July 2009.

Author's Address 📮

Cyrus Daboo
Apple Inc.
1 Infinite Loop
Cupertino, CA  95014
USA

EMail: cyrus@daboo.name
URI:   http://www.apple.com/
📦 where this page comes from