Network Working Group C. Daboo
Internet-Draft Apple Inc.
Intended status: Standards Track July 7, 2009
Expires: January 8, 2010
Use of SRV records for locating email services
draft-daboo-srv-email-01
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 8, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
This specification describes how SRV records can be used to locate
email services.
Daboo Expires January 8, 2010 [Page 1]
Internet-Draft SRV for Email July 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . . 3
3. SRV service types . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Email Submission . . . . . . . . . . . . . . . . . . . . . 3
3.2. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Guidance for mail access clients . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Appendix A. Change History (to be removed prior to
publication as an RFC) . . . . . . . . . . . . . . . . 6
Daboo Expires January 8, 2010 [Page 2]
Internet-Draft SRV for Email July 2009
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].
Daboo Expires January 8, 2010 [Page 3]
Internet-Draft SRV for Email July 2009
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 includes support for the
"STARTTLS" extension to optionally allow transport layer security
to be negotiated by the client.
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.
3.3. POP3
This specification adds two SRV service types for POP3 [RFC1939]:
pop3: Identifies a POP3 server that might also include support for
the optional "STLS" extension command [RFC2595] to allow transport
layer security to be negotiated by the client.
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.
4. Guidance for mail access clients
By using SRV records as above, clients need only prompt the user for
their email address [RFC5322]. "local-part" and "domain" portions are
extracted from the email address by the client. The "local-part" or
the full email address is used for the user identifier (used for
authentication with the appropriate service) and the "domain" is used
as the service domain.
The client uses 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
Daboo Expires January 8, 2010 [Page 4]
Internet-Draft SRV for Email July 2009
information directly.
Clients that support both POP3 and IMAP SHOULD check for both
services using SRV lookups. If both 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.
Servers typically use just the "local-part" as the user identifier or
the full email address. Clients should attempt to authenticate with
either the "local-part" or email address first, and if that fails,
try the other next.
5. Security Considerations
If a user has explicitly requested a connection with transport layer
security, the client MUST either use service information returned for
the "imaps" or "pop3s" services, or it can use service information
returned for the "imap" or "pop3" services, but only if the
"STARTTLS" or "STLS" commands are available and complete
successfully.
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.
6. IANA Considerations
This document does not require any actions on the part of IANA.
7. Acknowledgments
Thanks to Alexey Melnikov for feedback and suggestions.
8. 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.
Daboo Expires January 8, 2010 [Page 5]
Internet-Draft SRV for Email July 2009
[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.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
Appendix A. Change History (to be removed prior to publication as an
RFC)
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
Cyrus Daboo
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
USA
EMail: cyrus@daboo.name
URI: http://www.apple.com/
Daboo Expires January 8, 2010 [Page 6]