Use of SRV records for locating email services
draft-daboo-srv-email-02

Abstract

This specification describes how SRV records can be used to locate email services.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 19, 2013.

Copyright Notice

Copyright (c) 2012 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Conventions Used in This Document
• 3. SRV service types
• 3.1. Email Submission
• 3.2. IMAP
• 3.3. POP3
• 4. Guidance for mail access clients
• 5. Guidance for Service Providers
• 6. Security Considerations
• 7. IANA Considerations
• 8. Acknowledgments
• 9. References
• Appendix A. Change History (to be removed prior to publication as an RFC)
• Author's Address

1. Introduction

[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 SRV RR records.

Internet Email protocols include SMTP [RFC5321], IMAP [RFC3501] and POP3 [RFC1939].

[RFC5321] defines the MX RR record type to locate SMTP services for a domain. However, [RFC4409] defines a "profile" of the SMTP service that is specifically used for message submission - which is of direct relevance to email clients which typically don't use MX records.

Both IMAP and POP3 are mail access protocols used by email clients to manipulate email messages after delivery.

Typically email clients have required users to enter host name and port information for the services they need. This is not ideal as the way in which server information is specified can differ from client to client, and can be confusing to users, leading to errors when inputting the details. A better approach would be to require miniml 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.

This specification defines new SRV service types for the message submission, IMAP and POP3 services to enable simple auto configuration of email clients.

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].

3. SRV service types

3.1. Email Submission

This specification adds one SRV service type for message submission [RFC4409]:

submission:

Identifies a message submission server as defined by [RFC4409]. Note that this covers connections both with and without transport layer security [RFC3207].

Example: service record

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

3.2. IMAP

This specification adds two SRV service types for IMAP [RFC3501]:

imap:

Identifies an IMAP server that MAY advertise the "LOGINDISABLED" capability and MAY require the client to use the "STARTTLS" command prior to authentication. Although these two extensions are mandatory-to-implement for both clients and servers, they are not mandatory-to-use by service providers.

imaps:

Identifies an IMAP server where transport layer security is initiated directly upon connection to the 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 specification adds two SRV service types for POP3 [RFC1939]:

pop3:

Identifies a POP3 server that MAY require the client to use the "STLS" extension command [RFC2595] prior to authentication.

pop3s:

Identifies a POP3 server where transport layer security is initiated directly upon connection to the 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.
					

4. Guidance for mail access clients

By using SRV records as above, clients need initially only prompt the user for their email address [RFC5322]. "local-part" and "domain" portions are then extracted from the email address by the client. The client 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 host name and port for the service can be determined and used to complete client configuration. If an SRV record is not found, the client will need to prompt the user to enter host name and port information directly.

Clients that support both POP3 and IMAP SHOULD check for both services using SRV lookups, and for both SSL and non-SSL variants. If both POP3 and IMAP services are returned the choice of which to configure is up to the client - it could prompt the user to make a choice, or pick one based on local policy.

Subsequent to configuration, the client will connect to the service. When using "imaps" or "pop3s" services, a transport layer security negotiation is done immediately upon connection. With "imap" and "pop3" services, the "STARTTLS" or "STLS" commands respectively are used to initiate a protected connection. When using transport layer security in this way, clients SHOULD use the TLS Server Name Indication [RFC4366] and include the service domain name used in the SRV record lookup as the name.

Once a suitable connection has been made, and any required protection setup, the client will typically need to authenticate with the 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 (such as the SASL "PLAIN" mechanism). When a user identifier is required, clients 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 Section 5.

5. Guidance for Service Providers

Service providers wanting to offer a POP3 or IMAP service that can be configured by clients using SRV records need to follow certain guidelines to ensure proper operation.

1. 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 not conflict with any login name on the server.
2. If the service provider uses transport layer security, the service provider MUST ensure a certificate is installed that matches the email domain name used to configure clients. If the service provider hosts multiple domains on the same IP address, then the service provider MUST enable support for the TLS Server Name Indication [RFC4366].
3. Install the appropriate SRV records for the offered services.

6. Security Considerations

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 client MUST successfully negotiate transport layer security prior to sending an authentication command. The client 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 can potentially cause clients to connect to any server chosen by the attacker. In the absence of a secure DNS option, clients SHOULD check that the host name returned in the SRV record matches the original service domain that was queried. If the host is not in the queried domain, clients SHOULD verify with the user that the SRV host name is suitable for use before executing any connections to the host. Alternatively, if transport layer security is being used, clients MUST use the service domain used in the SRV record lookup as the server name for certificate verification pruposes.

7. IANA Considerations

This document does not require any actions on the part of IANA.

8. Acknowledgments

Thanks to Alexey Melnikov, and Chris Newman for feedback and suggestions.

9. References

Appendix A. Change History (to be removed prior to publication as an RFC)

Changes in -02:

1. Tweaked text for imap to better describe mandatory-to-implement behavior from base spec.
2. Tweaked text for pop3 along similar lines as imap.
3. Teaked security considerations to account for use of STARTTLS and STLS.
4. Added examples for imaps and pop3s.
5. Re-worked client guidelines.
6. Added service provider guidelines.

Changes in -01:

1. Tweaked text for pop3 to make it clearer that STLS is an extension.
2. Added text to explain that the email address, as well as the local-part, may be used as the user identifier.
3. Teaked security considerations to account for use of STARTTLS and STLS.

Author's Address