Use of SRV Records for Locating Email Submission/Access Services
This specification describes how SRV records can be used to locate email services. [STANDARDS-TRACK]
This document is current and has been amended. 2 later RFCs have changed part of it. Nothing on the RFC itself tells you this.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 12 must, 9 should, 4 may.
3.2 IMAP
- MAY_imap: Identifies an IMAP server that MAY advertise the "LOGINDISABLED" capability and MAY require the MUA to use the "STARTTLS" command prior to authentication.
3.3 POP3
- MAY_pop3: Identifies a POP3 server that MAY require the MUA to use the "STLS" extension command [RFC2595] prior to authentication.
3.4 Priority for Domain Preferences
- SHOULDTo 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-numbered priority value than the other.
- SHOULDWhen an MUA supports both IMAP and POP3, it SHOULD retrieve records for both services and then use the service with the lowest priority value.
- MUSTWhen considering multiple records for different protocols at the same priority but with different weights, the client MUST first select the protocol it
- MUSTIf such records are present, clients MUST assume that the specified service is not available, and instead make use of the other SRV RRs for the purposes of determining the domain preference.
4 Guidance for MUAs
- MUSTIn 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 [RFC2782]).
- SHOULDWhen using TLS in this way, MUAs SHOULD use the TLS Server Name Indication [RFC6066].
- MUSTCertificate verification MUST use the procedure outlined in Section 6 of [RFC6125] in regard to verification with an SRV RR as the starting point.
- MUSTWhen 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.
- SHOULDIf both these user identifiers result in authentication failure, the MUA SHOULD prompt the user for a valid identifier.
- SHOULDOnce a successful connection and authentication have been done, MUAs SHOULD cache the service details (hostname, port, user identity) that were successfully used, and reuse those when connecting again at a later time.
- SHOULDIf 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
- SHOULDIMAP, POP3, and SMTP (submission) servers SHOULD be configured to allow authentication with email addresses or email local-parts.
- MUST NOTIn the former case, the email addresses MUST NOT conflict with other forms of permitted user login name.
- MUST NOTIn 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.
- MUSTIf the service provider uses TLS [RFC5246], the service provider MUST ensure a certificate is installed that can be verified by MUAs using the procedure outlined in Section 6 of [RFC6125] in regard to verification with an SRV RR as the starting point.
- MUSTIf the service provider hosts multiple domains on the same IP address, then the service provider MUST enable support for the TLS Server Name Indication [RFC6066].
6 Security Considerations
- MUSTIf a user has explicitly requested a connection with a transport layer security mechanism (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.
- MAYFor example, the MUA MAY do this with "imaps", "pop3s", "imap" with "STARTTLS", or "pop3" with "STLS".
- MAYService providers MAY offer any subset of these four options for the mail service.
- SHOULDIn 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.
- SHOULDIf 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.
- MUSTAlternatively, if TLS [RFC5246] is being used for the email service, MUAs MUST use the procedure outlined in Section 6 of [RFC6125] to verify the service.
- MUST NOTBecause of known security vulnerabilities, email clients and email servers MUST NOT request, offer, or use SSL 2.0.