Internet DRAFT - draft-hall-email-srv
draft-hall-email-srv
INTERNET-DRAFT Eric A. Hall
Document: draft-hall-email-srv-02.txt John C. Klensin
Expires: January, 2005 July 2004
Category: Experimental
Using SRV Resource Records to Automatically
Configure Email Clients
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.
Abstract
This document specifies SRV resource records for Internet-based
message-submission and message-retrieval services, and also
defines behavioral rules for messaging clients to follow when
these resource records are used to locate the messaging servers
associated with a known mail domain.
Internet Draft draft-hall-email-srv-02.txt July 2004
Table of Contents
1. Background and Overview...................................2
2. Prerequisites and Terminology.............................4
3. Messaging SRV Resource Records............................5
3.1. SRV Owner Names........................................5
3.2. SRV Resource Record Data...............................6
3.3. Address Resource Records...............................7
4. Client Processing Algorithms..............................7
4.1. Retrieval Server Lookups...............................9
4.2. Submission Server Lookups.............................11
5. Resource Record Caching..................................12
6. Security Considerations..................................13
7. IANA Considerations......................................14
8. Normative References.....................................14
9. Informative References...................................15
Acknowledgments...............................................15
Authors' Disclaimer and Addresses.............................15
Full Copyright Statement......................................16
1. Background and Overview
Email networks built around Internet messaging technologies
typically use a tiered message-transfer network model. In the
common scenario, messaging clients send outgoing email messages to
a default "submission" server, with these "first-hop" servers
performing tasks such as message preparation, routing lookups, and
next-hop transfers towards the final destination. Meanwhile,
messaging clients which work in the typical model will also
usually fetch incoming email messages from a default "retrieval"
server, with these "last-hop" servers usually acting as the final
delivery system for the user's mail domain.
Messaging networks built on this model have historically used the
Simple Message Transfer Protocol (SMTP) [RFC2821] and TCP port 25
for the first-hop submission service. However, RFC 2476 [RFC2476]
formally defined a variant of SMTP as an explicit mail-submission
service which more accurately reflects specific behavioral
requirements of the common environment. RFC 2476 also reserved TCP
port 587 specifically for use with the formal submission service,
but also allows clients and servers to continue using full SMTP
over TCP port 25.
On the retrieval front, there are two standards-track services
available for use, which are the Post Office Protocol v3 (POP3)
Hall & Klensin I-D Expires: January 2005 [page 2]
Internet Draft draft-hall-email-srv-02.txt July 2004
[STD53] and the Internet Message Access Protocol v4rev1 (IMAP4)
[RFC3501]. Unlike the submission services, POP3 and IMAP4 are
substantially different from each other, with different protocol
models, command verbs, and port numbers (POP3 servers typically
use TCP port 110, while IMAP4 servers typically use TCP port 143).
Most messaging clients which work in these environments have
historically used static configuration data to identify the
protocol, hostname and port number to identify the submission and
retrieval services, although a variety of products have also
attempted to use automated configuration services in an effort to
lessen the need for manual administration. For example, some
products have used the Dynamic Host Configuration Protocol (DHCP)
[RFC2131], the Interactive Mail Support Protocol (IMSP) and the
Application Configuration Access Protocol (ACAP) [RFC2244], or
even the Lightweight Directory Access Protocol (LDAP) [RFC3377] to
store configuration data centrally, allowing clients to fetch
centrally-managed configuration information when they are first
loaded. Unfortunately, many of these services are unable to
accommodate messaging networks that don't use the default port
numbers for the specified service, are unable to provide recovery
information when a pre-configured server becomes unavailable, are
unable to support users on remote networks due to topology,
security or bandwidth concerns, or have other issues which make
them unsuitable for use outside of specific environments.
Meanwhile, 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 the SRV model, a
network service can be identified by name within the scope of a
particular domain, with multiple SRV resource records identifying
the hostnames and port numbers of servers which provide the named
service within that domain scope, but with the caveat that these
resource records can only provide connection-level information,
and cannot provide user-specific configuration data.
This restriction is also present in other host-based configuration
services (including DHCP and PPP, among others). However, SRV
records have a significant advantage over these other services, in
that DNS lookups are not tied to a particular network medium or
management domain, and the configuration data can be retrieved
from anywhere on the global Internet. In sum, this means that SRV
resource records are useful when hosts need to use application
services operated by a service provider, and are especially useful
when the hosts are not connected to a static 'home' network. This
Hall & Klensin I-D Expires: January 2005 [page 3]
Internet Draft draft-hall-email-srv-02.txt July 2004
includes roaming clients that connect from different networks
(such as an office or home network, or an airport or coffee
house), dial-up clients which connect to different points-of-
presence every time, and even those networks that are isolated
behind a gateway device and therefore under different
administrative control from the service provider.
In support of these kinds of scenarios, this specification defines
SRV resource records which can be used to identify the submission
and retrieval servers for a particular messaging network, and also
defines behavioral rules for messaging clients to use when
locating these servers. Specifically, the model put forth in this
document uses SRV resource records which are mapped to the mail
domain of an email address, so that messaging clients can
predictably discover the messaging servers that are associated
with a particular mail domain, and also defines client-side
algorithms for sorting equally-weighted responses.
Note that this model assumes that the presence of an email address
within a mail domain implies that the user has an account in the
associated mail domain, that the user is authorized to use the
servers associated with that domain, and that such usage is
preferred or necessary (note that these caveats usually apply to
retrieval services more than submission services, since retrieval
services are usually associated with a specific host or cluster).
In those environments where these assumptions do not reflect the
actual messaging network or requirements, some other mechanism
will be needed (potentially including manual configuration).
Furthermore, the usage model described herein is specifically
intended for non-critical configuration, such as bootstrapping a
manual configuration process or for use as recovery information
when a pre-configured server has become unavailable. Although
these mechanisms MAY be used for ongoing configuration management,
there are numerous scenarios which can cause the lookup or parsing
processes to fail, and as such, these mechanisms SHOULD NOT be
relied on for ongoing configuration management.
2. Prerequisites and Terminology
Readers of this document are expected to be familiar with the
specifications for message submission (RFC 2476), POP3 (STD 53),
IMAP4 (RFC 3501), SRV resource records (RFC 2782), and the
terminology of mail transport [RFC2821].
Hall & Klensin I-D Expires: January 2005 [page 4]
Internet Draft draft-hall-email-srv-02.txt July 2004
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. Messaging SRV Resource Records
SRV resource records have an owner domain 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 preferential rankings.
3.1. SRV Owner Names
The owner domain 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 for
that service, respectively.
For SRV resource records which reference submission servers, 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
"_submission" label refers to the submission service name, as
registered with IANA.
For SRV resource records which reference IMAP4 servers, the first
two labels in this sequence MUST be "_imap" 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 IANA registration for
the IMAP4 service is "imap" and not "imap4".
For SRV resource records which reference POP3 servers, the first
two labels in this sequence MUST be "_pop3" 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 for these resource records is
explicitly defined as the mail domain of the user's email address,
and is not tied to a hostname, a subnet, or any other type of
name. The client processing algorithms defined in section 4 of
this document use the mail domain of the user's email address
as the domain scope of the SRV resource record lookups, so the
resource records must be associated with the mail domain name in
order for the algorithm to succeed (additional mapping techniques
Hall & Klensin I-D Expires: January 2005 [page 5]
Internet Draft draft-hall-email-srv-02.txt July 2004
are also provided for those scenarios where the mail domain is
insufficient to be used for matching users to servers).
For example, a messaging client which had been configured to use
an email address of "user@example.net" and which needed to locate
the submission server for that user would issues lookups for the
SRV resource records bound to the "_submission._tcp.example.net"
domain name, while an email address of "user@bna.tn.example.net"
would issue lookups for "_submission._tcp.bna.tn.example.net".
Alternative specifications are free to reuse the SRV identifier
sequences described above, but SHOULD specify different naming
contexts in order to avoid conflicts. For example, specifications
that describe subnet-specific mapping algorithms can freely reuse
the "_smtp._tcp" label sequence, but would best be served by
mapping the sequence to an IN-ADDR.ADDR domain name instead of the
forward domain. Similarly, per-user or per-host algorithms should
make use of fully-qualified domain names which completely identify
the target resource, rather than the domain name of that resourceÆ
authoritative parent.
3.2. SRV Resource Record Data
The SRV resource record data structure is described in detail in
RFC 2782. In summary, the SRV resource record provides fields
which identify a target server hostname, the port number of the
associated service on that server, and priority and weighting data
which reflect the overall preference of each particular server in
the answer set.
Note that the client-processing algorithms described in section 4
of this document allow a target server to be chosen from among an
equally weighted set of answers by determining if any of the
servers share the same subdomain or subnet as the messaging
client. These mechanisms 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 specific users towards servers that are dedicated
to particular subdomains or subnets.
In general terms, organizations which choose to make use of this
specification are encouraged to provide multiple servers with
different preference values, thereby allowing clients to
automatically discover alternate servers in case the preferred
server becomes unreachable or otherwise unavailable.
Hall & Klensin I-D Expires: January 2005 [page 6]
Internet Draft draft-hall-email-srv-02.txt July 2004
This specification does not define any custom handling rules for
the weighting field of the SRV resource record. The default
weightings defined in RFC 2782 are to be used.
3.3. Address Resource Records
Once a preferred server has been selected from the SRV answer set,
its hostname will need to be resolved into an IP address.
Note that the client processing algorithms described in section 4
of this document allow an IP address to be chosen from among an
equally weighted set of answers by allowing the client to
determine which of the servers are "best" or "closest", based on
the IP addresses of the client and the server(s). 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 specific
users towards servers which are dedicated to particular subnets.
For example, some clients or organizations may be able to leverage
resolvers which attempt to locate the "closest" server through the
use of subnet-mapping techniques, or which attempt to locate the
"best" server from response-time monitors or 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 developers and administrators should be
aware of their potential use.
4. Client Processing Algorithms
In general terms, messaging clients are expected to locate the
retrieval servers associated with a known mail domain whenever
incoming email messages need to be retrieved, and are expected to
locate the submission servers associated with a known mail domain
whenever outgoing email messages need to be sent. However, this is
an extremely simplistic overview of the process, with many
potential exceptions.
For example, a messaging client may be designed to use retrieval-
service extensions to perform message submission (such as using a
POP3 or IMAP4 submission extension), and in those cases, the
client would need to use the SRV resource records associated with
the retrieval service rather than the submission service.
Furthermore, IMAP4 sessions tend to be fairly long-lived, and
often involve multiple connections to different folders within a
single folder hierarchy, but since changes to the resource record
Hall & Klensin I-D Expires: January 2005 [page 7]
Internet Draft draft-hall-email-srv-02.txt July 2004
data could theoretically result in different servers being chosen
for each such connection, messaging clients need to reuse the
current IP address for all of the active IMAP4 connections to a
single server instead of issuing new lookups for each session.
There are other common exceptions to the general rule, and in most
cases, common sense should take precedence.
In general terms, the process of locating a server requires two
sub-processes. The first part of the process attempts to locate
the hostnames and port numbers of the preferred servers that are
associated with the mail domain of the primary email address of
each user profile, while the second part of the process attempts
to locate the IP addresses of those servers. Clients that wish to
store this data permanently SHOULD only cache the preferred server
information from the first part of the process. Meanwhile, clients
SHOULD only perform the second part of the process whenever a
connection is actually required (a detailed procedure is discussed
in the algorithms below). In some cases, the entire process may
need to be restarted, such as when routing errors, TCP errors, or
session errors indicate that the client cannot currently use the
preferred server.
Once a connection to a selected server has been successfully
established, messaging client MAY attempt to automate any login or
configuration processes, as desired. For example, clients MAY
attempt to use the local-part element of the email address as a
login identifier for a given session, or MAY attempt to probe for
the available encryption and authentication mechanisms, or MAY
attempt to discover the IMAP4 namespace or subscription hierarchy,
and so forth. However, attempts to automatically discover the
configuration information can have a high likelihood of failure,
either because some of the elements may not be predictable, or
because different server products may have implemented features in
slightly different ways. Since this process is somewhat prone to
failure, it is not defined in this specification, although these
processes are allowed and are generally encouraged. Note that some
parameters will differ between servers (or even between nodes in a
cluster), and as such, if any of the subsequent settings are
cached by the client, most of these settings SHOULD be linked with
a specific server rather than with the user's identity.
Also 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 queries
in order to ensure that all of the information is retrieved and
processed correctly.
Hall & Klensin I-D Expires: January 2005 [page 8]
Internet Draft draft-hall-email-srv-02.txt July 2004
4.1. Retrieval Server Lookups
Messaging clients which support both IMAP4 and POP3 SHOULD first
attempt to locate the IMAP4 servers associated with the mail
domain, and SHOULD NOT attempt to locate POP3 servers unless no
IMAP4 servers can be located or reached.
Messaging clients which only support one or the other service
SHOULD only issue lookups for the retrieval service that the
client supports, and SHOULD NOT issue lookups for services that
are not supported by that messaging client.
Clients which claim to be compliant with this specification SHOULD
iterate at least once through the following steps for each
eligible messaging identity:
a. Determine if a retrieval server has been defined manually
or through another configuration mechanism that has been
given preference over this process. If so, only continue if
those servers are unreachable or otherwise unavailable.
b. If the client is looking for IMAP4 servers, extract the
mail domain from the primary email address associated with
the current profile, and append the "_imap" and "_tcp"
labels to the left of that domain name. If the client is
looking for POP3 servers, append the "_pop3" and "_tcp"
labels to the left of the mail domain name.
c. Issue a DNS query for the SRV resource records associated
with the domain name formed in the preceding step.
d. Determine the hostname of the preferred retrieval server.
1. If multiple candidate servers were returned, use the
sorting rules specified in RFC 2782 to determine the
preferred server(s).
2. If multiple candidate servers still exist, the client
SHOULD give additional preference to any of the
servers which have a hostname that appears to be in
the same subdomain as the client hostname.
Hall & Klensin I-D Expires: January 2005 [page 9]
Internet Draft draft-hall-email-srv-02.txt July 2004
3. If multiple candidate servers still exist, the client
MAY resolve each of the target server hostnames and
use any services at its disposal to determine the
"best" or "closest" IP address, and use the server
associated with that address as the preferred target.
Note that several addresses and targets can be
returned during this process, and it may be imprudent
to perform this process against very large sets.
4. If multiple candidate servers still exist, choose one
at random from the preferred set.
e. Use the port number associated with the server selected in
step 4.1.d as the port number for the retrieval server.
f. Resolve the IP address for the server chosen in step 4.1.d.
Note that this data SHOULD NOT be stored permanently, and
SHOULD only be used to resolve connection requests.
1. If multiple IP addresses are returned, the client MAY
use any services at its disposal to determine the
"best" or "closest" IP address from that set.
2. If multiple candidate addresses still exist, choose
one at random from the preferred set.
g. If a connection to the currently-preferred server cannot be
established, locate the next-best target.
1. If multiple IP addresses are associated with the
currently-preferred server, restart the process at
step 4.1.f to determine the next-best IP address.
2. If all of the IP addresses for the currently-preferred
host have been tried, use the next-preferred host from
step 4.1.d. Clients SHOULD NOT try the next-preferred
host until all of the IP addresses associated with the
currently-preferred host have been tried.
h. If the client is looking for IMAP servers and none were
discovered or are otherwise available, extract the mail
domain from the user's email address, append the "_pop3"
and "_tcp" labels to the left of that domain name, and
restart the process at step 4.1.c. If no POP3 servers were
discovered or are otherwise available, report the failure
to the user and exit.
Hall & Klensin I-D Expires: January 2005 [page 10]
Internet Draft draft-hall-email-srv-02.txt July 2004
4.2. Submission Server Lookups
Unlike the algorithm defined for retrieval servers, submission
services only require a single SRV resource record, and therefore
only require a single lookup process.
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 mechanism that has been
given preference over this process. If so, only continue if
those servers are unreachable or otherwise unavailable.
b. Extract the mail domain from the primary email address
associated with the current connection profile, 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 the preceding step.
d. Determine the hostname of the preferred submission server.
1. If multiple candidate servers were returned, use the
sorting rules specified in RFC 2782 to determine the
preferred server(s).
2. If multiple candidate servers still exist, the client
SHOULD give additional preference to any of the
servers which have a hostname that appears to be in
the same subdomain as the client hostname.
3. If multiple candidate servers still exist, the client
MAY resolve each of the target server hostnames and
use any services at its disposal to determine the
"best" or "closest" IP address, and use the server
associated with that address as the preferred target.
Note that several addresses and targets can be
returned during this process, and it may be imprudent
to perform this process against very large sets.
Hall & Klensin I-D Expires: January 2005 [page 11]
Internet Draft draft-hall-email-srv-02.txt July 2004
4. If multiple candidate servers still exist, the client
SHOULD give a higher preference to targets which use
port 587, and SHOULD give a lower preference to
targets which use port 25.
5. If multiple candidate servers still exist, choose one
at random from the preferred set.
e. Use the port number associated with the server selected in
step 4.2.d as the port number for the submission server.
f. Resolve the IP address for the server chosen in step 4.2.d.
Note that this data SHOULD NOT be stored permanently, and
SHOULD only be used to resolve connection requests.
1. If multiple IP addresses are returned, the client MAY
use any services at its disposal to determine the
"best" or "closest" IP address from that set.
2. If multiple candidate addresses still exist, choose
one at random from the preferred set.
g. If a connection to the currently-preferred server cannot be
established, locate the next-best target.
1. If multiple addresses are associated with the
currently-preferred server, restart the process at
step 4.2.f to determine the next-best IP address.
2. If all of the IP addresses for the currently-preferred
host have been tried, use the next-preferred host from
step 4.2.d. Clients SHOULD NOT try the next-preferred
host until all of the IP addresses associated with the
currently-preferred host have been tried.
h. If no submission servers were discovered or are otherwise
available, report the failure to the user and exit.
5. Resource Record Caching
Messaging clients SHOULD NOT store 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 NOT issue new
queries until a new connection needs to be established. This
Hall & Klensin I-D Expires: January 2005 [page 12]
Internet Draft draft-hall-email-srv-02.txt July 2004
approach ensures that the messaging client will always get the
latest information when accuracy is most critical.
However, clients SHOULD remember which server and IP addresses are
being used for current connections, so that that other servers can
be tried if the current connection fails. Remembering the current
server ensures that the client does not repeatedly select the same
preferred server even though it has already been tried.
Furthermore, multiple lookups for IMAP4 servers SHOULD NOT be
issued if any connections for a given server are already active.
All of the other connections for that server MUST reuse the
existing server-specific socket tuple, and additional lookups for
that profile MUST NOT be generated unless the current server
becomes unavailable.
Zone operators SHOULD NOT use excessively short or excessively
long Time-to-Live values. As a general rule of thumb (subject to
operator-specific requirements, of course), Time-to-Live values of
a few hours 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 on remote networks. Since these resource records provide
information about the internal messaging network in a predictable
form, hostile parties with access to the resource records can
learn some operational details about the infrastructure simply by
issuing predictable DNS queries. However, the potential risks from
this should not be overstated, since the same information can
often 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
Hall & Klensin I-D Expires: January 2005 [page 13]
Internet Draft draft-hall-email-srv-02.txt July 2004
attacks, in that they can prevent illegitimate sessions from being
established and/or can make message contents unreadable.
Clients that attempt to automate logins or which probe for
available authentication mechanisms SHOULD use the strongest
mechanism available, but MAY give preference to mechanisms that
require less input. For example, mechanisms that only require a
username and password MAY be given preference over mechanisms that
require shared secrets or external tokens.
In all cases, clients SHOULD attempt to use the STARTTLS
mechanisms described in RFC 2595 [RFC2595], RFC 3207 [RFC3207] and
RFC 3501 respectively. Note that these mechanisms require that
clients compare the certificate name(s) against the hostname used
in the initial connection request. In those cases where the
algorithms from section 4 are used to seed a manual configuration,
the selected target server's hostname MUST be used for the
certificate comparison operation. In those cases where the client
performs automatic discovery, the mail domain from the seed email
address MUST be used for the comparison operation. Note that
STARTTLS allows server certificates to publish multiple hostnames
and wildcard domain names, and this allows a single server to
match against multiple comparisons.
In those cases where a canonical protocol specification describes
a specific security requirement, that specification MUST be given
precedence over this document.
7. IANA Considerations
This document does not create any IANA considerations.
8. 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.
[RFC2595] C. Newman, "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.
Hall & Klensin I-D Expires: January 2005 [page 14]
Internet Draft draft-hall-email-srv-02.txt July 2004
[RFC2821] J. Klensin, "Simple Mail Transfer Protocol",
RFC 2821, April 2001.
[RFC3207] Hoffman, P., "SMTP Service Extension for
Secure SMTP over Transport Layer Security",
RFC 3207, February 2002.
[RFC3501] M. Crispin, "Internet Message Access Protocol
- Version 4rev1", RFC 3501, March 2003.
[STD53] Myers, J., and M. Rose, "Post Office Protocol
- Version 3", RFC 1939, May 1996.
9. 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.
[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.
Acknowledgments
Funding for the RFC editor function is currently provided by the
Internet Society.
Authors' Disclaimer and Addresses
By submitting this Internet-Draft, I accept the provisions of
Section 3 of RFC 3667.
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been
disclosed, and any of which I become aware will be disclosed, in
accordance with RFC 3668.
Hall & Klensin I-D Expires: January 2005 [page 15]
Internet Draft draft-hall-email-srv-02.txt July 2004
Eric A. Hall
ehall@ehsco.com
John C. Klensin
john-ietf@jck.com
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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: January 2005 [page 16]
