Internet DRAFT - draft-hall-submit-srv
draft-hall-submit-srv
INTERNET-DRAFT Eric A. Hall
Document: draft-hall-submit-srv-00.txt John C. Klensin
Expires: January, 2004 June 2003
Category: Standards Track
Message-Submission SRV Resource Record
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document specifies the use of SRV resource records for
locating the message-submission servers associated with a known
mail domain.
Internet Draft draft-hall-submit-srv-00.txt June 2003
Table of Contents
1. Background and Overview...................................2
2. Prerequisites and Terminology.............................4
3. Message-Submission Resource Records.......................4
3.1. SRV Owner Name.........................................4
3.2. SRV Resource Record Data...............................5
3.3. Address Resource Records...............................5
4. Client Processing Algorithm...............................6
5. Resource Record Caching...................................8
6. Security Considerations...................................8
7. IANA Considerations.......................................9
8. Author's Address..........................................9
9. Normative References......................................9
10. Informative References...................................10
11. Acknowledgments..........................................10
12. Full Copyright Statement.................................10
1. Background and Overview
Email networks built around Internet technologies typically use a
tiered network for outbound transfers, with messaging clients
sending non-local messages to a default "submission" server, with
that server subsequently performing the message preparation,
routing and transfer services on behalf of the local clients.
Messaging networks built on this model have historically used the
Simple Message Transfer Protocol (SMTP) [RFC2821] and TCP port 25
for this "first-hop" transfer purpose, although RFC 2476 [RFC2476]
formally defined a variant of SMTP with slightly different
behavioral rules as an explicit message submission service for use
in these environments. RFC 2476 also reserved TCP port 587
specifically for use with the submission service, but also allowed
clients and servers to continue using SMTP over TCP port 25 if
necessary or desired.
Most of the messaging clients which used the submission model have
also historically used static configuration data to identify the
submission host and port, although a variety of products have
attempted to use automated configuration services in an effort to
lessen the need for manual administration. For example, some
products have used Mail Exchange (MX) resource records associated
with the sender's domain to try and locate a submission server,
under the assumption that the inbound transfer server(s) would
also be appropriate for outbound transfers. Meanwhile, some
Hall & Klensin I-D Expires: December 2003 [page 2]
Internet Draft draft-hall-submit-srv-00.txt June 2003
products have used the Dynamic Host Configuration Protocol (DHCP)
[RFC2131], the Interactive Mail Support Protocol (IMSP) and the
derivative Application Configuration Access Protocol (ACAP)
[RFC2244], and even the Lightweight Directory Access Protocol
(LDAP) [RFC3377] to store configuration data centrally, allowing
clients to retrieve the submission host and port identifiers when
they were started. Unfortunately, many of these services are
unable to accommodate messaging networks that don't use TCP port
25 for the submission service, or are unable to support users on
remote and/or slow networks, or have other issues which make them
unsuitable for use with automated configuration management outside
of specific environments.
Separately, RFC 2782 [RFC2782] introduced a general-purpose
mechanism for storing service-specific connection identifiers in
the Domain Name System (DNS) [STD13] by way of a generalized
Service Location ("SRV") resource record. In that model, a network
service can be identified by name, and SRV resource records for
that service can be created within the scope of a particular
domain, with each SRV resource record identifying the hostname and
port number of a server which provides the named service within
that domain scope. This approach is well suited to the submission
service for a variety of reasons, and is particularly well suited
to large-scale and diverse installations who cannot easily support
the more generalized configuration services.
First of all, each SRV resource record can specify a unique
hostname and port number pair, thereby allowing multiple hosts
and/or port numbers to be linked to a single submission service.
Furthermore, each SRV resource record carries preference and
weighting values which allow administrators to specify a
"preferred" submission server as well as secondary or tertiary
servers if the preferred server becomes unavailable. Finally, the
use of DNS for this kind of configuration information facilitates
deployment and access in broad scales, especially since DNS is
already commonly used for other kinds of connection-level
identifiers, and many organizations have already dealt with the
policy and architectural considerations surrounding the use of DNS
for that kind of information.
For all of the reasons listed above, this specification defines
the usage of SRV resource records with submission services, for
use in environments where this kind of configuration management
would be appropriate. Note that this service is not mandatory for
any messaging network, and other configuration management systems
may continue to be used as necessary or desired. Furthermore, it
Hall & Klensin I-D Expires: December 2003 [page 3]
Internet Draft draft-hall-submit-srv-00.txt June 2003
is important to recognize that this specification does not define
any site-to-site routing services, location information for
message-retrieval servers, proprietary submission services, or
anything other than identifying the SMTP-based submission servers
for a messaging network.
2. Prerequisites and Terminology
Readers of this document are expected to be familiar with the
specifications for message submission [RFC2476] and SRV resource
records [RFC2782].
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 RFC 2119
[RFC2119].
3. Message-Submission Resource Records
SRV resource records have an owner name which uniquely identifies
a particular service within the scope of a particular domain, and
also have data structures which provide information about the
target hosts and their preference. In addition to the SRV resource
records, "target" server hostnames must also be resolved into IP
addresses via secondary lookups.
3.1. SRV Owner Name
The owner name of SRV resource records are a concatenated sequence
of labels which identify the service name, the transport protocol
associated with that service, and the domain scope, respectively.
For message submission SRV resource records, the first two labels
in this sequence MUST be "_submission" and "_tcp", while the
domain scope sequence MUST be the same as the mail domain which is
used by the messaging clients.
Note that the domain scope is explicitly defined as a particular
"mail domain", and is not tied to a hostname, a subnet, or any
other type of domain name. The client algorithm defined in section
4 causes messaging clients to use the mail domain element of their
return email addresses as the domain scope of the SRV resource
record lookups, so the resource records must be associated with
the mail domain names in order for the algorithm to succeed.
Hall & Klensin I-D Expires: December 2003 [page 4]
Internet Draft draft-hall-submit-srv-00.txt June 2003
For example, messaging users in the "example.net" mail domain
would issues lookups for the SRV resource records bound to the
"_submission._tcp.example.net" domain name, while messaging users
in the "bna.tn.example.net" mail domain would issue lookups for
"_submission._tcp.bna.tn.example.net". SRV resource records would
need to be bound to those domain names in order for the messaging
clients in those mail domains to locate the resource records.
3.2. SRV Resource Record Data
The SRV resource record data structure is described in detail in
RFC 2782. In brief, the SRV resource record data segment provides
multiple fields which identify a target server's hostname, the
port number, and priority and weighting data which cumulatively
determines the overall preference level of that particular SRV
resource record in the set.
Note that the client-processing algorithm described in section 4
allows a preferred target server to be chosen from among an
equally weighted set of answers by allowing the client to
determine if any of the servers are in the same sub-domain as the
client itself. This mechanism may be useful in those cases where a
large and distributed messaging network shares a common mail
domain for all of its users, but where that organization still
needs to direct the users towards servers which are dedicated to
particular sub-domains or regions.
In general terms, organizations which choose to support the use of
SRV resource records are encouraged to provide multiple resource
records with different preference values, thereby allowing clients
to automatically discover alternate servers in case the preferred
server becomes unreachable or otherwise unavailable.
3.3. Address Resource Records
Once a preferred server has been determined, its hostname is
subsequently resolved to an IP address with a lookup for the IP
address resource records associated with the server's domain name.
Note that the client-processing algorithm described in section 4
allows a preferred target server to be chosen from among an
equally weighted set of answers by allowing the client to
determine the "closest" server, based on IP addresses. This
mechanism may be useful in those cases where a large and
distributed messaging network shares a common mail domain for all
of its users, but where that organization still needs to direct
Hall & Klensin I-D Expires: December 2003 [page 5]
Internet Draft draft-hall-submit-srv-00.txt June 2003
the users towards servers which are dedicated to particular
subnets or regions.
For example, some organizations may be able to leverage resolvers
which attempt to locate the "closest" server through subnet-
mapping or response-time monitors, while other organizations may
be able to use load-balancing technologies which control the
answer sets that are returned to the clients. Discussion of these
technologies is beyond the scope of this document, although
administrators should be aware of their potential use.
4. Client Processing Algorithm
In general terms, messaging clients are expected to generate DNS
lookups for the submission-specific SRV resource records
associated with the user's known mail domains. Clients SHOULD NOT
issue lookups for the domain name associated with the local
hostname, SHOULD NOT issue lookups for networks they are attached
to, but SHOULD instead only issue lookups for the SRV resource
records associated with their known mail domains.
If multiple "identities" have been defined on the messaging client
which use different mail domains in the return address, the lookup
process SHOULD be repeated for each mail domain, unless the user
specifies otherwise.
Clients which claim to be compliant with this specification SHOULD
iterate through the following steps for each eligible identity:
a. Determine if a submission server has been defined manually
or through another configuration service. If so, give
preference to that information, and only continue if the
identified servers are unreachable.
b. Extract the mail domain element from the user's email
address, and append the "_submission" and "_tcp" labels to
the left of that domain name.
c. Issue a DNS query for the SRV resource records associated
with the domain name formed in step 4.b.
Hall & Klensin I-D Expires: December 2003 [page 6]
Internet Draft draft-hall-submit-srv-00.txt June 2003
d. If multiple resource records are returned, sort them
according to the rules specified in RFC 2782, and determine
the preferred target.
1. If multiple candidate targets still exist, the client
MAY give preference to any servers which have a
hostname that appears to be in the same sub-domain as
the client hostname.
2. If multiple candidate targets still exist, the client
SHOULD give the highest preference to targets which
use port 587, and SHOULD give the lowest preference to
targets which use port 25.
3. If multiple candidate targets still exist, choose one
at random.
e. Use the port number determined in step 4.d as the port
number for the submission server.
f. Determine the IP address for the target server.
1. If multiple IP addresses are discovered, the client
MAY use any services at its disposal to determine the
IP address which appears to be the closest match to
the local client's IP address.
2. If multiple candidate addresses still exist, choose
one at random.
g. Use the IP address determined in step 4.f as the IP address
for the submission server.
h. If the currently-preferred server is subsequently
determined to be unreachable or unavailable (potentially
including any routing errors, TCP errors, or SMTP errors
which indicate that the client cannot currently use the
server), locate the next-best target.
1. If multiple addresses were associated with the
currently-preferred server, restart the process at
step 4.f to determine the next-best IP address.
Hall & Klensin I-D Expires: December 2003 [page 7]
Internet Draft draft-hall-submit-srv-00.txt June 2003
2. If all of the IP addresses for the currently-preferred
target have been tried and multiple SRV resource
records were discovered, use the next-preferred SRV
resource record from step 4.d. Clients SHOULD NOT try
the next-preferred target until all of the IP
addresses associated with the currently-preferred
target have been tried.
3. If all of the IP addresses for all of the SRV resource
records have been tried, report the error to the user
and exit the algorithm.
Note that some DNS resolvers are known to filter and restrict the
resource record data which gets returned, and in those cases, the
messaging client may need to issue its own "raw" DNS query in
order to ensure that all of the information is retrieved and
processed correctly.
5. Resource Record Caching
Submission clients SHOULD NOT store or reuse the discovered
configuration information for a length of time greater than the
Time-to-Live values associated with the underlying resource
records. Instead, clients SHOULD delete the discovered information
whenever the underlying resource records have expired, and SHOULD
only reissue the queries when the user needs to submit another
message. This approach ensures that the messaging client will
always get the latest information at the moment which accuracy is
most critical.
Zone operators SHOULD NOT use excessively small or excessively
small Time-to-Live values. As a general rule of thumb (subject to
operator-specific requirements, of course), Time-to-Live values
between a few hours and a few days tend to work the best.
6. Security Considerations
Administrators should carefully consider if and how they want to
make the resource records described in this document available to
users, particularly those users who may be on remote networks.
Since this resource record provides information in a predictable
form, hostile parties with access to the resource records can
learn some operational details about the messaging infrastructure
simply by issuing predictable DNS queries. However, the potential
risks from exposing operational information about a messaging
Hall & Klensin I-D Expires: December 2003 [page 8]
Internet Draft draft-hall-submit-srv-00.txt June 2003
network to external parties should not be overstated. In the usual
case, the same information can be learned by analyzing the
Received headers in email messages which have passed through that
same network. In this regard, providing this information in a
resource record is no more of a risk than providing the
information in a Received header of a message which has passed
through that network.
DNS domain names can be easily spoofed, and this is especially
easy when the victim uses a DNS server under the control of a
hostile party. By using a relatively simple technique, a hostile
party can provide SRV resource records which redirect a user
towards a hostile SMTP server, allowing the interloper to read and
act upon the user's outbound email at will. Strong authentication
services, transfer-layer encryption techniques, and message
encryption are usually cited as sufficient defenses against such
attacks, in that they can prevent illegitimate sessions from being
established and/or can make message contents unreadable.
Refer to RFC 2782 for the security considerations associated with
the use of SRV resource records in general.
Refer to RFC 2476 for the security considerations associated with
the use of the message-submission service.
7. IANA Considerations
This document does not create any IANA considerations.
8. Author's Address
Eric A. Hall
ehall@ehsco.com
John C. Klensin
john-ietf@jck.com
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC
2119, March 1997.
[RFC2476] Gellens, R., and J. Klensin, "Message
Submission", RFC 2476, December 1998.
Hall & Klensin I-D Expires: December 2003 [page 9]
Internet Draft draft-hall-submit-srv-00.txt June 2003
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A
DNS RR for specifying the location of services
(DNS SRV)", RFC 2782, February 2000.
10. Informative References
[RFC2131] Droms, R., "Dynamic Host Configuration
Protocol", RFC 2131, March 1997.
[RFC2244] Newman, C., and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244,
November 1997.
[RFC2821] J. Klensin, "Simple Mail Transfer Protocol",
RFC 2821, April 2001.
[RFC3377] Hodges, J., and R. Morgan, "Lightweight
Directory Access Protocol (v3): Technical
Specification", RFC 3377, September 2002.
[STD13] Mockapetris, P. "Domain Names - Concepts and
Facilities", STD 13, RFC 1034 and "Domain
Names - Implementation and Specification", STD
13, RFC 1035, November 1987.
11. Acknowledgments
Funding for the RFC editor function is currently provided by the
Internet Society.
12. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
Hall & Klensin I-D Expires: December 2003 [page 10]
Internet Draft draft-hall-submit-srv-00.txt June 2003
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Hall & Klensin I-D Expires: December 2003 [page 11]
