1124 lines
39 KiB
Plaintext
1124 lines
39 KiB
Plaintext
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Internet Engineering Task Force (IETF) R. Gellens
|
|||
|
Request for Comments: 6409 QUALCOMM Incorporated
|
|||
|
STD: 72 J. Klensin
|
|||
|
Obsoletes: 4409 November 2011
|
|||
|
Category: Standards Track
|
|||
|
ISSN: 2070-1721
|
|||
|
|
|||
|
|
|||
|
Message Submission for Mail
|
|||
|
|
|||
|
Abstract
|
|||
|
|
|||
|
This memo splits message submission from message relay, allowing each
|
|||
|
service to operate according to its own rules (for security, policy,
|
|||
|
etc.), and specifies what actions are to be taken by a submission
|
|||
|
server.
|
|||
|
|
|||
|
Message relay is unaffected, and continues to use SMTP over port 25.
|
|||
|
|
|||
|
When conforming to this document, message submission uses the
|
|||
|
protocol specified here, normally over port 587.
|
|||
|
|
|||
|
This separation of function offers a number of benefits, including
|
|||
|
the ability to apply specific security or policy requirements.
|
|||
|
|
|||
|
Status of This Memo
|
|||
|
|
|||
|
This is an Internet Standards Track document.
|
|||
|
|
|||
|
This document is a product of the Internet Engineering Task Force
|
|||
|
(IETF). It represents the consensus of the IETF community. It has
|
|||
|
received public review and has been approved for publication by the
|
|||
|
Internet Engineering Steering Group (IESG). Further information on
|
|||
|
Internet Standards is available in Section 2 of RFC 5741.
|
|||
|
|
|||
|
Information about the current status of this document, any errata,
|
|||
|
and how to provide feedback on it may be obtained at
|
|||
|
http://www.rfc-editor.org/info/rfc6409.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Gellens & Klensin Standards Track [Page 1]
|
|||
|
|
|||
|
RFC 6409 Message Submission for Mail November 2011
|
|||
|
|
|||
|
|
|||
|
Copyright Notice
|
|||
|
|
|||
|
Copyright (c) 2011 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.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Gellens & Klensin Standards Track [Page 2]
|
|||
|
|
|||
|
RFC 6409 Message Submission for Mail November 2011
|
|||
|
|
|||
|
|
|||
|
Table of Contents
|
|||
|
|
|||
|
1. Introduction ....................................................4
|
|||
|
2. Document Information ............................................5
|
|||
|
2.1. Definitions of Terms Used in This Memo .....................5
|
|||
|
2.2. Conventions Used in This Document ..........................6
|
|||
|
3. Message Submission ..............................................6
|
|||
|
3.1. Submission Identification ..................................6
|
|||
|
3.2. Message Rejection and Bouncing .............................6
|
|||
|
3.3. Authorized Submission ......................................7
|
|||
|
4. Mandatory Actions ...............................................8
|
|||
|
4.1. General Submission Rejection Code ..........................8
|
|||
|
4.2. Ensure All Domains Are Fully Qualified .....................8
|
|||
|
4.3. Require Authentication .....................................8
|
|||
|
5. Recommended Actions .............................................9
|
|||
|
5.1. Enforce Address Syntax .....................................9
|
|||
|
5.2. Log Errors .................................................9
|
|||
|
5.3. Apply Shorter Timeouts .....................................9
|
|||
|
6. Optional Actions ...............................................10
|
|||
|
6.1. Enforce Submission Rights .................................10
|
|||
|
6.2. Enforce Permissions .......................................10
|
|||
|
6.3. Check Message Data ........................................10
|
|||
|
6.4. Support for the Postmaster Address ........................10
|
|||
|
6.5. Adjust Character Encodings ................................11
|
|||
|
7. Interaction with SMTP Extensions ...............................12
|
|||
|
8. Message Modifications ..........................................13
|
|||
|
8.1. Add 'Sender' ..............................................14
|
|||
|
8.2. Add 'Date' ................................................14
|
|||
|
8.3. Add 'Message-ID' ..........................................14
|
|||
|
8.4. Transfer Encode ...........................................14
|
|||
|
8.5. Sign the Message ..........................................14
|
|||
|
8.6. Encrypt the Message .......................................14
|
|||
|
8.7. Resolve Aliases ...........................................15
|
|||
|
8.8. Header Rewriting ..........................................15
|
|||
|
9. Security Considerations ........................................15
|
|||
|
10. IANA Considerations ...........................................16
|
|||
|
11. Acknowledgments ...............................................16
|
|||
|
12. References ....................................................17
|
|||
|
12.1. Normative References .....................................17
|
|||
|
12.2. Informative References ...................................17
|
|||
|
Appendix A. Major Changes from RFC 4409 ...........................20
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Gellens & Klensin Standards Track [Page 3]
|
|||
|
|
|||
|
RFC 6409 Message Submission for Mail November 2011
|
|||
|
|
|||
|
|
|||
|
1. Introduction
|
|||
|
|
|||
|
SMTP [SMTP-MTA] was defined as a message *transfer* protocol, that
|
|||
|
is, a means to route (if needed) and deliver finished (complete)
|
|||
|
messages.
|
|||
|
|
|||
|
Message Transfer Agents (MTAs) are not supposed to alter the message
|
|||
|
text, except to add 'Received', 'Return-Path', and other header
|
|||
|
fields as required by [SMTP-MTA]. However, SMTP is now also widely
|
|||
|
used as a message *submission* protocol, that is, a means for Message
|
|||
|
User Agents (MUAs) to introduce new messages into the MTA routing
|
|||
|
network. The process that accepts message submissions from MUAs is
|
|||
|
termed a "Message Submission Agent" (MSA).
|
|||
|
|
|||
|
In order to permit unconstrained communications, SMTP is not often
|
|||
|
authenticated during message relay.
|
|||
|
|
|||
|
Authentication and authorization of initial submissions have become
|
|||
|
increasingly important, driven by changes in security requirements
|
|||
|
and rising expectations that submission servers take responsibility
|
|||
|
for the message traffic they originate.
|
|||
|
|
|||
|
For example, due to the prevalence of machines that have worms,
|
|||
|
viruses, or other malicious software that generate large amounts of
|
|||
|
spam, many sites now prohibit outbound traffic on the standard SMTP
|
|||
|
port (port 25), funneling all mail submissions through submission
|
|||
|
servers.
|
|||
|
|
|||
|
In addition to authentication and authorization issues, messages
|
|||
|
being submitted are, in some cases, finished (complete) messages and,
|
|||
|
in other cases, are unfinished (incomplete) in one or more aspects.
|
|||
|
Unfinished messages may need to be completed to ensure they conform
|
|||
|
to the Message Format specification [MESSAGE-FORMAT] and related
|
|||
|
requirements. For example, the message may lack a proper 'Date'
|
|||
|
header field, and domains might not be fully qualified. In some
|
|||
|
cases, the MUA may be unable to generate finished messages (e.g., it
|
|||
|
might not know its time zone). Even when submitted messages are
|
|||
|
complete, local site policy may dictate that the message text be
|
|||
|
examined or modified in some way, e.g., to conceal local name or
|
|||
|
address spaces. Such completions or modifications have been shown to
|
|||
|
cause harm when performed by downstream MTAs -- that is, MTAs after
|
|||
|
the first-hop submission MTA -- and are, in general, considered to be
|
|||
|
outside the province of standardized MTA functionality.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Gellens & Klensin Standards Track [Page 4]
|
|||
|
|
|||
|
RFC 6409 Message Submission for Mail November 2011
|
|||
|
|
|||
|
|
|||
|
Separating messages into submissions and transfers allows developers
|
|||
|
and network administrators to do the following more easily:
|
|||
|
|
|||
|
o Implement security policies and guard against unauthorized mail
|
|||
|
relaying or injection of unsolicited bulk mail.
|
|||
|
|
|||
|
o Implement authenticated submission, including off-site submission
|
|||
|
by authorized users such as travelers.
|
|||
|
|
|||
|
o Separate the relevant software code differences, thereby making
|
|||
|
each code base more straightforward and allowing for different
|
|||
|
programs for relay and submission.
|
|||
|
|
|||
|
o Detect configuration problems with a site's mail clients.
|
|||
|
|
|||
|
o Provide a basis for adding enhanced submission services.
|
|||
|
|
|||
|
This memo describes a low-cost, deterministic means for messages to
|
|||
|
be identified as submissions, and it specifies what actions are to be
|
|||
|
taken by a submission server.
|
|||
|
|
|||
|
2. Document Information
|
|||
|
|
|||
|
2.1. Definitions of Terms Used in This Memo
|
|||
|
|
|||
|
Many of the concepts and terms used in this document are defined in
|
|||
|
[SMTP-MTA]; familiarity with those documents is assumed here.
|
|||
|
|
|||
|
Fully Qualified
|
|||
|
|
|||
|
Containing or consisting of a domain that can be globally resolved
|
|||
|
using the Domain Name Service, that is, not a local alias or partial
|
|||
|
specification.
|
|||
|
|
|||
|
Message Submission Agent (MSA)
|
|||
|
|
|||
|
A process that conforms to this specification. An MSA acts as a
|
|||
|
submission server to accept messages from MUAs, and it either
|
|||
|
delivers them or acts as an SMTP client to relay them to an MTA.
|
|||
|
|
|||
|
Message Transfer Agent (MTA)
|
|||
|
|
|||
|
A process that conforms to [SMTP-MTA]. An MTA acts as an SMTP server
|
|||
|
to accept messages from an MSA or another MTA, and it either delivers
|
|||
|
them or acts as an SMTP client to relay them to another MTA.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Gellens & Klensin Standards Track [Page 5]
|
|||
|
|
|||
|
RFC 6409 Message Submission for Mail November 2011
|
|||
|
|
|||
|
|
|||
|
Message User Agent (MUA)
|
|||
|
|
|||
|
A process that acts (often on behalf of a user and with a user
|
|||
|
interface) to compose and submit new messages, and to process
|
|||
|
delivered messages.
|
|||
|
|
|||
|
For delivered messages, the receiving MUA may obtain and process the
|
|||
|
message according to local conventions or, in what is commonly
|
|||
|
referred to as a split-MUA model, Post Office Protocol [POP3] or IMAP
|
|||
|
[IMAP4] is used to access delivered messages, whereas the protocol
|
|||
|
defined here (or SMTP) is used to submit messages.
|
|||
|
|
|||
|
2.2. Conventions Used in This Document
|
|||
|
|
|||
|
Examples use the 'example.net' domain.
|
|||
|
|
|||
|
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
|
|||
|
in this document are to be interpreted as defined in [KEYWORDS].
|
|||
|
|
|||
|
3. Message Submission
|
|||
|
|
|||
|
3.1. Submission Identification
|
|||
|
|
|||
|
Port 587 is reserved for email message submission as specified in
|
|||
|
this document. Messages received on this port are defined to be
|
|||
|
submissions. The protocol used is ESMTP [SMTP-MTA], with additional
|
|||
|
restrictions or allowances as specified here.
|
|||
|
|
|||
|
Although most email clients and servers can be configured to use port
|
|||
|
587 instead of 25, there are cases where this is not possible or
|
|||
|
convenient. A site MAY choose to use port 25 for message submission
|
|||
|
by designating some hosts to be MSAs and others to be MTAs.
|
|||
|
|
|||
|
3.2. Message Rejection and Bouncing
|
|||
|
|
|||
|
MTAs and MSAs MAY implement message rejection rules that rely, in
|
|||
|
part, on whether the message is a submission or a relay.
|
|||
|
|
|||
|
For example, some sites might configure their MTAs to reject all RCPT
|
|||
|
commands for messages that do not reference local users, and they
|
|||
|
might configure their MSA to reject all message submissions that do
|
|||
|
not come from authorized users, with authorization based on either
|
|||
|
the authenticated identity or the submitting endpoint being within a
|
|||
|
protected IP environment.
|
|||
|
|
|||
|
NOTE: It is better to reject a message than to risk sending one that
|
|||
|
is damaged. This is especially true for problems that are
|
|||
|
correctable by the MUA, for example, an invalid 'From' field.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Gellens & Klensin Standards Track [Page 6]
|
|||
|
|
|||
|
RFC 6409 Message Submission for Mail November 2011
|
|||
|
|
|||
|
|
|||
|
If an MSA is not able to determine a return path to the submitting
|
|||
|
user, from a valid MAIL FROM, a valid source IP address, or based on
|
|||
|
authenticated identity, then the MSA SHOULD immediately reject the
|
|||
|
message. A message can be immediately rejected by returning a 550
|
|||
|
code to the MAIL command.
|
|||
|
|
|||
|
Note that a null return path, that is, MAIL FROM:<>, is permitted and
|
|||
|
MUST NOT, in itself, be cause for rejecting a message. (MUAs need to
|
|||
|
generate null return-path messages for a variety of reasons,
|
|||
|
including disposition notifications.)
|
|||
|
|
|||
|
Except in the case where the MSA is unable to determine a valid
|
|||
|
return path for the message being submitted, text in this
|
|||
|
specification that instructs an MSA to issue a rejection code MAY be
|
|||
|
complied with by accepting the message and subsequently generating a
|
|||
|
bounce message. (That is, if the MSA is going to reject a message
|
|||
|
for any reason except being unable to determine a return path, it can
|
|||
|
optionally do an immediate rejection or accept the message and then
|
|||
|
mail a bounce.)
|
|||
|
|
|||
|
NOTE: In the normal case of message submission, immediately rejecting
|
|||
|
the message is preferred, as it gives the user and MUA direct
|
|||
|
feedback. To properly handle delayed bounces, the client MUA needs
|
|||
|
to maintain a queue of messages it has submitted and match bounces to
|
|||
|
them. Note that many contemporary MUAs do not have this capability.
|
|||
|
|
|||
|
3.3. Authorized Submission
|
|||
|
|
|||
|
Numerous methods have been used to ensure that only authorized users
|
|||
|
are able to submit messages. These methods include authenticated
|
|||
|
SMTP, IP address restrictions, secure IP and other tunnels, and prior
|
|||
|
POP authentication.
|
|||
|
|
|||
|
Authenticated SMTP [SMTP-AUTH] has seen widespread deployment. It
|
|||
|
allows the MSA to determine an authorization identity for the message
|
|||
|
submission, one that is not tied to other protocols.
|
|||
|
|
|||
|
IP address restrictions are very widely implemented, but they do not
|
|||
|
allow for travelers and similar situations, and they can be easily
|
|||
|
spoofed unless all transport paths between the MUA and MSA are
|
|||
|
trustworthy.
|
|||
|
|
|||
|
Secure IP [IPSEC], and other encrypted and authenticated tunneling
|
|||
|
techniques, can also be used and provide additional benefits of
|
|||
|
protection against eavesdropping and traffic analysis.
|
|||
|
|
|||
|
Requiring a POP [POP3] authentication (from the same IP address)
|
|||
|
within some amount of time (e.g., 20 minutes) prior to the start of a
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Gellens & Klensin Standards Track [Page 7]
|
|||
|
|
|||
|
RFC 6409 Message Submission for Mail November 2011
|
|||
|
|
|||
|
|
|||
|
message submission session has also been used, but this does impose
|
|||
|
restrictions on clients as well as servers, which may cause
|
|||
|
difficulties. Specifically, the client must do a POP authentication
|
|||
|
before an SMTP submission session, and not all clients are capable
|
|||
|
and configured for this. Also, the MSA must coordinate with the POP
|
|||
|
server, which may be difficult. There is also a window during which
|
|||
|
an unauthorized user can submit messages and appear to be a
|
|||
|
previously authorized user. Since it is dependent on the MUA's IP
|
|||
|
addresses, this technique is substantially as subject to IP address
|
|||
|
spoofing as validation based on known IP addresses alone (see above).
|
|||
|
|
|||
|
4. Mandatory Actions
|
|||
|
|
|||
|
An MSA MUST do all of the following:
|
|||
|
|
|||
|
4.1. General Submission Rejection Code
|
|||
|
|
|||
|
Unless covered by a more precise response code, response code 554 is
|
|||
|
to be used to reject a MAIL, RCPT, or DATA command that contains
|
|||
|
something improper.
|
|||
|
|
|||
|
4.2. Ensure All Domains Are Fully Qualified
|
|||
|
|
|||
|
The MSA MUST ensure that all domains in the SMTP envelope are fully
|
|||
|
qualified.
|
|||
|
|
|||
|
If the MSA examines or alters the message text in any way, except to
|
|||
|
add trace header fields [SMTP-MTA], it MUST ensure that all domains
|
|||
|
in address header fields are fully qualified.
|
|||
|
|
|||
|
Reply code 554 is to be used to reject a MAIL, RCPT, or DATA command
|
|||
|
that contains improper domain references.
|
|||
|
|
|||
|
A frequent local convention is to accept single-level domains (e.g.,
|
|||
|
'sales') and then to expand the reference by adding the remaining
|
|||
|
portion of the domain name (e.g., to 'sales.example.net'). Local
|
|||
|
conventions that permit single-level domains SHOULD reject, rather
|
|||
|
than expand, incomplete multi-level domains (e.g., 'squeaky.sales'),
|
|||
|
since such expansion is particularly risky.
|
|||
|
|
|||
|
4.3. Require Authentication
|
|||
|
|
|||
|
The MSA MUST, by default, issue an error response to the MAIL command
|
|||
|
if the session has not been authenticated using [SMTP-AUTH], unless
|
|||
|
it has already independently established authentication or
|
|||
|
authorization (such as being within a protected subnetwork).
|
|||
|
|
|||
|
Section 3.3 discusses authentication mechanisms.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Gellens & Klensin Standards Track [Page 8]
|
|||
|
|
|||
|
RFC 6409 Message Submission for Mail November 2011
|
|||
|
|
|||
|
|
|||
|
Reply code 530 [SMTP-AUTH] is used for this purpose.
|
|||
|
|
|||
|
5. Recommended Actions
|
|||
|
|
|||
|
The MSA SHOULD do all of the following.
|
|||
|
|
|||
|
5.1. Enforce Address Syntax
|
|||
|
|
|||
|
An MSA SHOULD reject messages with illegal syntax in a sender or
|
|||
|
recipient SMTP envelope address.
|
|||
|
|
|||
|
If the MSA examines or alters the message text in any way, except to
|
|||
|
add trace header fields, it SHOULD reject messages with illegal
|
|||
|
address syntax in address header fields.
|
|||
|
|
|||
|
Reply code 501 is to be used to reject a MAIL or RCPT command that
|
|||
|
contains a detectably improper address.
|
|||
|
|
|||
|
When addresses are resolved after submission of the message body,
|
|||
|
reply code 554 (with a suitable enhanced status code from
|
|||
|
[SMTP-CODES]) is used after end-of-data, if the message contains
|
|||
|
invalid addresses in the header.
|
|||
|
|
|||
|
5.2. Log Errors
|
|||
|
|
|||
|
The MSA SHOULD log message errors, especially apparent
|
|||
|
misconfigurations of client software.
|
|||
|
|
|||
|
It can be very helpful to notify the administrator when problems are
|
|||
|
detected with local mail clients. This is another advantage of
|
|||
|
distinguishing submission from relay: system administrators might be
|
|||
|
interested in local configuration problems, but not in client
|
|||
|
problems at other sites.
|
|||
|
|
|||
|
Note that it is important to impose limits on such logging to prevent
|
|||
|
certain forms of denial-of-service (DoS) attacks.
|
|||
|
|
|||
|
5.3. Apply Shorter Timeouts
|
|||
|
|
|||
|
The timeouts specified in Section 4.5.3.2 of RFC 5321 [SMTP-MTA] are
|
|||
|
designed to deal with the many types of situations that can be
|
|||
|
encountered on the public Internet. The relationship among clients
|
|||
|
and servers corresponding to this specification is typically much
|
|||
|
closer and more predictable. Submission clients behave differently
|
|||
|
from relay client in some areas, especially tolerance for timeouts.
|
|||
|
In practice, message submission clients tend to have short timeouts
|
|||
|
(perhaps 2-5 minutes for a reply to any command). Submission servers
|
|||
|
SHOULD respond to any command (even DATA) in fewer than 2 minutes.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Gellens & Klensin Standards Track [Page 9]
|
|||
|
|
|||
|
RFC 6409 Message Submission for Mail November 2011
|
|||
|
|
|||
|
|
|||
|
When the submission server has a close administrative and/or network
|
|||
|
relationship with the submission client(s) -- e.g., with a webmail
|
|||
|
interface calling on a tightly bound submission server -- mutual
|
|||
|
agreement on much shorter timeouts MAY be appropriate.
|
|||
|
|
|||
|
6. Optional Actions
|
|||
|
|
|||
|
The MSA MAY do any of the following.
|
|||
|
|
|||
|
6.1. Enforce Submission Rights
|
|||
|
|
|||
|
The MSA MAY issue an error response to a MAIL command if the address
|
|||
|
in MAIL FROM appears to have insufficient submission rights or is not
|
|||
|
authorized with the authentication used (if the session has been
|
|||
|
authenticated).
|
|||
|
|
|||
|
Reply code 550 with an appropriate enhanced status code per
|
|||
|
[SMTP-CODES], such as 5.7.1, is used for this purpose.
|
|||
|
|
|||
|
6.2. Enforce Permissions
|
|||
|
|
|||
|
The MSA MAY issue an error response to a RCPT command if inconsistent
|
|||
|
with the permissions given to the user (if the session has been
|
|||
|
authenticated).
|
|||
|
|
|||
|
Reply code 550 with an appropriate enhanced status code per
|
|||
|
[SMTP-CODES], such as 5.7.1, is used for this purpose.
|
|||
|
|
|||
|
6.3. Check Message Data
|
|||
|
|
|||
|
The MSA MAY issue an error response to the DATA command or send a
|
|||
|
failure result after end-of-data if the submitted message is
|
|||
|
syntactically invalid, seems inconsistent with permissions given to
|
|||
|
the user (if known), or violates site policy in some way.
|
|||
|
|
|||
|
Reply code 554 is used for syntactic problems in the data. Reply
|
|||
|
code 501 is used if the command itself is not syntactically valid.
|
|||
|
Reply code 550 with an appropriate enhanced status code per
|
|||
|
[SMTP-CODES] (such as 5.7.1) is used to reject based on the
|
|||
|
submitting user. Reply code 550 with an appropriate enhanced status
|
|||
|
code (such as 5.7.0) is used if the message violates site policy.
|
|||
|
|
|||
|
6.4. Support for the Postmaster Address
|
|||
|
|
|||
|
If appropriate under local conditions and to facilitate conformance
|
|||
|
with the "postmaster" requirements of [SMTP-MTA], the MSA MAY permit
|
|||
|
a reduced degree of authentication for mail addressed to the
|
|||
|
"postmaster" (or one of its alternate spelling forms, see
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Gellens & Klensin Standards Track [Page 10]
|
|||
|
|
|||
|
RFC 6409 Message Submission for Mail November 2011
|
|||
|
|
|||
|
|
|||
|
[SMTP-MTA]), in one or more domains, as compared to requirements
|
|||
|
enforced for other addresses. Among other benefits, this provides an
|
|||
|
address of last resort that can be used by authorized users to report
|
|||
|
problems that otherwise prevent them from submitting mail.
|
|||
|
|
|||
|
6.5. Adjust Character Encodings
|
|||
|
|
|||
|
Subject to limits imposed by other protocols and specifications, the
|
|||
|
MSA MAY convert among character sets or string encodings to improve
|
|||
|
message usefulness, likelihood of delivery, or conformance with other
|
|||
|
specifications or recommendations. Such conversions MAY include,
|
|||
|
when necessary, replacement of addresses whose encoding does not
|
|||
|
conform to RFC 5321 with ones that do, using information available
|
|||
|
out of band.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Gellens & Klensin Standards Track [Page 11]
|
|||
|
|
|||
|
RFC 6409 Message Submission for Mail November 2011
|
|||
|
|
|||
|
|
|||
|
7. Interaction with SMTP Extensions
|
|||
|
|
|||
|
The following table lists Standards Track and Experimental SMTP
|
|||
|
extensions whose documents do not explicitly specify their
|
|||
|
applicability to this protocol. Listed are the EHLO keyword, name,
|
|||
|
an indication as to the use of the extension on the submit port, and
|
|||
|
a reference.
|
|||
|
|
|||
|
+--------------------+----------------------+--------+-----------------+
|
|||
|
| Keyword | Name |Sub- | Reference |
|
|||
|
| | |mission | |
|
|||
|
+--------------------+----------------------+--------+-----------------+
|
|||
|
|PIPELINING |Pipelining |SHOULD |[PIPELINING] |
|
|||
|
|ENHANCEDSTATUSCODES |Enhanced Status Codes |SHOULD |[CODES-EXTENSION]|
|
|||
|
|ETRN |Extended Turn |MUST NOT|[ETRN] |
|
|||
|
| ... |Extended Codes |SHOULD |[SMTP-CODES] |
|
|||
|
|DSN |Delivery Status |SHOULD |[DSN] |
|
|||
|
| | Notification | | |
|
|||
|
|SIZE |Message size |MAY |[SIZE] |
|
|||
|
| ... |521 reply code |MUST NOT|[REPLY-521] |
|
|||
|
|CHECKPOINT |Checkpoint/Restart |MAY |[CHECKPOINT] |
|
|||
|
|BINARYMIME |Binary MIME |MAY |[CHUNKING] |
|
|||
|
|CHUNKING |Chunking |MAY |[CHUNKING] |
|
|||
|
|8BITMIME |Use 8-bit data |SHOULD |[RFC6152] |
|
|||
|
|AUTH |Authentication |MUST |[SMTP-AUTH] |
|
|||
|
|STARTTLS |Start TLS |MAY |[START-TLS] |
|
|||
|
|NO-SOLICITING |Notification of |MAY |[RFC3865] |
|
|||
|
| | no soliciting | | |
|
|||
|
|MTRK |Message Tracking |MAY |[MSG-TRACK] |
|
|||
|
|ATRN |On-Demand Relay |MUST NOT|[RFC2645] |
|
|||
|
|DELIVERBY |Deliver By |MAY |[RFC2852] |
|
|||
|
|CONPERM |Content Conversion |MAY |[RFC4141] |
|
|||
|
| | Permission | | |
|
|||
|
|CONNEG |Content Conversion |MAY |[RFC4141] |
|
|||
|
| | Negotiation | | |
|
|||
|
+--------------------+----------------------+--------+-----------------+
|
|||
|
Table 1
|
|||
|
|
|||
|
Future SMTP extensions SHOULD explicitly specify if they are valid on
|
|||
|
the Submission port.
|
|||
|
|
|||
|
Some SMTP extensions are especially useful for message submission:
|
|||
|
|
|||
|
Extended Status Codes [SMTP-CODES] SHOULD be supported and used
|
|||
|
according to [CODES-EXTENSION]. This permits the MSA to notify the
|
|||
|
client of specific configuration or other problems in more detail
|
|||
|
than the response codes listed in this memo. Because some rejections
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Gellens & Klensin Standards Track [Page 12]
|
|||
|
|
|||
|
RFC 6409 Message Submission for Mail November 2011
|
|||
|
|
|||
|
|
|||
|
are related to a site's security policy, care should be used not to
|
|||
|
expose more detail to unauthenticated senders than is needed.
|
|||
|
|
|||
|
[PIPELINING] SHOULD be supported by the MSA.
|
|||
|
|
|||
|
[SMTP-AUTH] allows the MSA to validate the authority and determine
|
|||
|
the identity of the submitting user and MUST be supported by the MSA.
|
|||
|
|
|||
|
[START-TLS] is the most widely used mechanism, at the time this
|
|||
|
document was written, that allows the MUA and MSA to protect message
|
|||
|
submission integrity and privacy.
|
|||
|
|
|||
|
Any references to the DATA command in this memo also refer to any
|
|||
|
substitutes for DATA, such as the BDAT command used with [CHUNKING].
|
|||
|
|
|||
|
8. Message Modifications
|
|||
|
|
|||
|
Sites MAY modify submissions to ensure compliance with standards and
|
|||
|
site policy. This section describes a number of such modifications
|
|||
|
that are often considered useful.
|
|||
|
|
|||
|
NOTE: As a matter of guidance for local decisions to implement
|
|||
|
message modification, a paramount rule is to limit such actions to
|
|||
|
remedies for specific problems that have clear solutions. This is
|
|||
|
especially true with address elements. For example, indiscriminately
|
|||
|
appending a domain to an address or element that lacks one typically
|
|||
|
results in more broken addresses. An unqualified address must be
|
|||
|
verified to be a valid local part in the domain before the domain can
|
|||
|
be safely added.
|
|||
|
|
|||
|
Any message forwarded or delivered by the MSA MUST conform to the
|
|||
|
requirements of [SMTP-MTA] and [MESSAGE-FORMAT] or the requirements
|
|||
|
permitted by extensions that are supported by the MSA and accepted by
|
|||
|
the next-hop server.
|
|||
|
|
|||
|
Message modification can affect the validity of an existing message
|
|||
|
signature, such as by DomainKeys Identified Mail (DKIM) [DKIM],
|
|||
|
Pretty Good Privacy (PGP) [RFC4880], or Secure MIME (S/MIME)
|
|||
|
[RFC5751], and can render the signature invalid. This, in turn, can
|
|||
|
affect message handling by later receivers, such as filtering engines
|
|||
|
that consider the presence or absence of a valid signature.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Gellens & Klensin Standards Track [Page 13]
|
|||
|
|
|||
|
RFC 6409 Message Submission for Mail November 2011
|
|||
|
|
|||
|
|
|||
|
8.1. Add 'Sender'
|
|||
|
|
|||
|
The MSA MAY add or replace the 'Sender' field, if the identity of the
|
|||
|
sender is known and this is not given in the 'From' field.
|
|||
|
|
|||
|
The MSA MUST ensure that any address it places in a 'Sender' field
|
|||
|
is, in fact, a valid mail address.
|
|||
|
|
|||
|
8.2. Add 'Date'
|
|||
|
|
|||
|
The MSA MAY add a 'Date' field to the submitted message, if it lacks
|
|||
|
it, or correct the 'Date' field if it does not conform to
|
|||
|
[MESSAGE-FORMAT] syntax.
|
|||
|
|
|||
|
8.3. Add 'Message-ID'
|
|||
|
|
|||
|
The MSA SHOULD add or replace the 'Message-ID' field, if it lacks it,
|
|||
|
or it is not valid syntax (as defined by [MESSAGE-FORMAT]). Note
|
|||
|
that a number of clients still do not generate 'Message-ID' fields.
|
|||
|
|
|||
|
8.4. Transfer Encode
|
|||
|
|
|||
|
The MSA MAY apply transfer encoding to the message according to MIME
|
|||
|
conventions, if needed and not harmful to the MIME type.
|
|||
|
|
|||
|
8.5. Sign the Message
|
|||
|
|
|||
|
The MSA MAY (digitally) sign or otherwise add authentication
|
|||
|
information to the message.
|
|||
|
|
|||
|
8.6. Encrypt the Message
|
|||
|
|
|||
|
The MSA MAY encrypt the message for transport to reflect
|
|||
|
organizational policies.
|
|||
|
|
|||
|
NOTE: To be useful, the addition of a signature and/or encryption by
|
|||
|
the MSA generally implies that the connection between the MUA and MSA
|
|||
|
must, itself, be secured in some other way, for example, by operating
|
|||
|
inside of a secure environment, by securing the submission connection
|
|||
|
at the transport layer, or by using an [SMTP-AUTH] mechanism that
|
|||
|
provides for session integrity.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Gellens & Klensin Standards Track [Page 14]
|
|||
|
|
|||
|
RFC 6409 Message Submission for Mail November 2011
|
|||
|
|
|||
|
|
|||
|
8.7. Resolve Aliases
|
|||
|
|
|||
|
The MSA MAY resolve and rewrite aliases (e.g., Canonical Name (CNAME)
|
|||
|
records) for domain names, in the SMTP envelope and/or in address
|
|||
|
fields of the header, subject to local policy.
|
|||
|
|
|||
|
NOTE: SMTP [SMTP-MTA] prohibits the use of domain name aliases in
|
|||
|
addresses and the session-opening announcement. As with other SMTP
|
|||
|
requirements, RFC 5321 effectively prohibits an MSA from forwarding
|
|||
|
such messages into the public Internet. Nonetheless, unconditionally
|
|||
|
resolving aliases could be harmful. For example, if www.example.net
|
|||
|
and ftp.example.net are both aliases for mail.example.net, rewriting
|
|||
|
them could lose useful information.
|
|||
|
|
|||
|
8.8. Header Rewriting
|
|||
|
|
|||
|
The MSA MAY rewrite local parts and/or domains in the SMTP envelope
|
|||
|
and, optionally, in address fields of the header, according to local
|
|||
|
policy. For example, a site may prefer to rewrite 'JRU' as
|
|||
|
'J.Random.User' in order to hide login names and/or to rewrite
|
|||
|
'squeaky.sales.example.net' as 'zyx.example.net' to hide machine
|
|||
|
names and make it easier to move users.
|
|||
|
|
|||
|
However, only addresses, local-parts, or domains that match specific
|
|||
|
local MSA configuration settings should be altered. It would be very
|
|||
|
dangerous for the MSA to apply data-independent rewriting rules, such
|
|||
|
as always deleting the first element of a domain name. So, for
|
|||
|
example, a rule that strips the leftmost element of the domain, if
|
|||
|
the complete domain matches '*.foo.example.net', would be acceptable.
|
|||
|
|
|||
|
The MSA MUST NOT rewrite a forward-pointing (destination) address in
|
|||
|
a way that violates the constraints of [SMTP-MTA] on modifications of
|
|||
|
local-parts. Changes to addressing and encoding, carried out in
|
|||
|
conjunction with the action of Section 6.5, do not violate this
|
|||
|
principle if the MSA has sufficient information available to
|
|||
|
successfully and accurately apply the substitution.
|
|||
|
|
|||
|
9. Security Considerations
|
|||
|
|
|||
|
Separation of submission and relay of messages allows a site to
|
|||
|
implement different policies for the two types of services, including
|
|||
|
requiring the use of additional security mechanisms for one or both.
|
|||
|
It can do this in a way that is simpler, both technically and
|
|||
|
administratively. This increases the likelihood that policies will
|
|||
|
be applied correctly.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Gellens & Klensin Standards Track [Page 15]
|
|||
|
|
|||
|
RFC 6409 Message Submission for Mail November 2011
|
|||
|
|
|||
|
|
|||
|
Separation also can aid in tracking and preventing unsolicited bulk
|
|||
|
email.
|
|||
|
|
|||
|
For example, a site could configure its mail servers such that the
|
|||
|
MSA requires authentication before accepting a message, and the MTA
|
|||
|
rejects all RCPT commands for non-local users. This can be an
|
|||
|
important element in a site's total email security policy.
|
|||
|
|
|||
|
If a site fails to require any form of authorization for message
|
|||
|
submissions (see Section 3.3 for discussion), it is allowing open use
|
|||
|
of its resources and name; unsolicited bulk email can be injected
|
|||
|
using its facilities.
|
|||
|
|
|||
|
Section 3 includes further discussion of issues with some
|
|||
|
authentication methods.
|
|||
|
|
|||
|
Section 5.2 includes a cautionary note that unlimited logging can
|
|||
|
enable certain forms of denial-of-service attacks.
|
|||
|
|
|||
|
10. IANA Considerations
|
|||
|
|
|||
|
The entries in Table 1 have been corrected (reference for NO-
|
|||
|
SOLICITING) and extended (ATRN, DELIVERBY, CONPERM, and CONNEG). The
|
|||
|
"SMTP Service Extensions" registry has been updated to reflect the
|
|||
|
changed and new entries. Entries in the registry that do not appear
|
|||
|
in the table above are correct and should not be altered.
|
|||
|
|
|||
|
The entry in the "SMTP Service Extensions" registry for RFC 4409 has
|
|||
|
been updated to reference this document. The original reference for
|
|||
|
Submit (RFC 2476), which should have been corrected earlier, has also
|
|||
|
been updated to point to this document.
|
|||
|
|
|||
|
The entry in the "Service Name and Transport Protocol Port Number
|
|||
|
Registry" for port 587 has been updated to point to this document.
|
|||
|
|
|||
|
11. Acknowledgments
|
|||
|
|
|||
|
The preparation and development of the current version of this
|
|||
|
specification was stimulated by discussions in the IETF YAM and EAI
|
|||
|
Working Groups. Dave Crocker, Subramanian Moonesamy, Barry Leiba,
|
|||
|
John Levine, and others provided text that appeared in this document
|
|||
|
or versions leading up to it.
|
|||
|
|
|||
|
Nathaniel Borenstein and Barry Leiba were instrumental in the
|
|||
|
development of RFC 4409, the update to RFC 2476.
|
|||
|
|
|||
|
The original memo (RFC 2476) was developed, in part, based on
|
|||
|
comments and discussions that took place on and off the IETF-Submit
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Gellens & Klensin Standards Track [Page 16]
|
|||
|
|
|||
|
RFC 6409 Message Submission for Mail November 2011
|
|||
|
|
|||
|
|
|||
|
mailing list. The help of those who took the time to review that
|
|||
|
document and make suggestions is appreciated, especially that of Dave
|
|||
|
Crocker, Ned Freed, Keith Moore, John Myers, and Chris Newman.
|
|||
|
|
|||
|
Special thanks to Harald Alvestrand, who got this effort started.
|
|||
|
|
|||
|
12. References
|
|||
|
|
|||
|
12.1. Normative References
|
|||
|
|
|||
|
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
|
|||
|
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
|||
|
|
|||
|
[SMTP-AUTH] Siemborski, R. and A. Melnikov, "SMTP Service Extension
|
|||
|
for Authentication", RFC 4954, July 2007.
|
|||
|
|
|||
|
[SMTP-MTA] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
|
|||
|
October 2008.
|
|||
|
|
|||
|
12.2. Informative References
|
|||
|
|
|||
|
[CHECKPOINT] Crocker, D. and N. Freed, "SMTP Service Extension for
|
|||
|
Checkpoint/Restart", RFC 1845, September 1995.
|
|||
|
|
|||
|
[CHUNKING] Vaudreuil, G., "SMTP Service Extensions for Transmission
|
|||
|
of Large and Binary MIME Messages", RFC 3030,
|
|||
|
December 2000.
|
|||
|
|
|||
|
[CODES-EXTENSION]
|
|||
|
Freed, N., "SMTP Service Extension for Returning
|
|||
|
Enhanced Error Codes", RFC 2034, October 1996.
|
|||
|
|
|||
|
[DKIM] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
|
|||
|
Identified Mail (DKIM) Signatures", RFC 6376,
|
|||
|
September 2011.
|
|||
|
|
|||
|
[DSN] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
|
|||
|
Extension for Delivery Status Notifications (DSNs)",
|
|||
|
RFC 3461, January 2003.
|
|||
|
|
|||
|
[ETRN] De Winter, J., "SMTP Service Extension for Remote
|
|||
|
Message Queue Starting", RFC 1985, August 1996.
|
|||
|
|
|||
|
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
|
|||
|
4rev1", RFC 3501, March 2003.
|
|||
|
|
|||
|
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the
|
|||
|
Internet Protocol", RFC 4301, December 2005.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Gellens & Klensin Standards Track [Page 17]
|
|||
|
|
|||
|
RFC 6409 Message Submission for Mail November 2011
|
|||
|
|
|||
|
|
|||
|
[MESSAGE-FORMAT]
|
|||
|
Resnick, P., Ed., "Internet Message Format", RFC 5322,
|
|||
|
October 2008.
|
|||
|
|
|||
|
[MSG-TRACK] Allman, E. and T. Hansen, "SMTP Service Extension for
|
|||
|
Message Tracking", RFC 3885, September 2004.
|
|||
|
|
|||
|
[PIPELINING] Freed, N., "SMTP Service Extension for Command
|
|||
|
Pipelining", STD 60, RFC 2920, September 2000.
|
|||
|
|
|||
|
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version
|
|||
|
3", STD 53, RFC 1939, May 1996.
|
|||
|
|
|||
|
[REPLY-521] Durand, A. and F. Dupont, "SMTP 521 Reply Code",
|
|||
|
RFC 1846, September 1995.
|
|||
|
|
|||
|
[RFC2645] Gellens, R., "ON-DEMAND MAIL RELAY (ODMR) SMTP with
|
|||
|
Dynamic IP Addresses", RFC 2645, August 1999.
|
|||
|
|
|||
|
[RFC2852] Newman, D., "Deliver By SMTP Service Extension",
|
|||
|
RFC 2852, June 2000.
|
|||
|
|
|||
|
[RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer
|
|||
|
Protocol (SMTP) Service Extension", RFC 3865,
|
|||
|
September 2004.
|
|||
|
|
|||
|
[RFC4141] Toyoda, K. and D. Crocker, "SMTP and MIME Extensions for
|
|||
|
Content Conversion", RFC 4141, November 2005.
|
|||
|
|
|||
|
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and
|
|||
|
R. Thayer, "OpenPGP Message Format", RFC 4880,
|
|||
|
November 2007.
|
|||
|
|
|||
|
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose
|
|||
|
Internet Mail Extensions (S/MIME) Version 3.2 Message
|
|||
|
Specification", RFC 5751, January 2010.
|
|||
|
|
|||
|
[RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, "SMTP
|
|||
|
Service Extension for 8-bit MIME Transport", STD 71,
|
|||
|
RFC 6152, March 2011.
|
|||
|
|
|||
|
[SIZE] Klensin, J., Freed, N., and K. Moore, "SMTP Service
|
|||
|
Extension for Message Size Declaration", STD 10,
|
|||
|
RFC 1870, November 1995.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Gellens & Klensin Standards Track [Page 18]
|
|||
|
|
|||
|
RFC 6409 Message Submission for Mail November 2011
|
|||
|
|
|||
|
|
|||
|
[SMTP-CODES] Vaudreuil, G., "Enhanced Mail System Status Codes",
|
|||
|
RFC 3463, January 2003.
|
|||
|
|
|||
|
[START-TLS] Hoffman, P., "SMTP Service Extension for Secure SMTP
|
|||
|
over Transport Layer Security", RFC 3207, February 2002.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Gellens & Klensin Standards Track [Page 19]
|
|||
|
|
|||
|
RFC 6409 Message Submission for Mail November 2011
|
|||
|
|
|||
|
|
|||
|
Appendix A. Major Changes from RFC 4409
|
|||
|
|
|||
|
The protocol specified by this document is not substantively
|
|||
|
different from that of RFC 4409. However, the present specification
|
|||
|
contains several clarifications and updates to reflect changes and
|
|||
|
revisions to other documents subsequent to the publication of RFC
|
|||
|
4409. The following specific changes may be of interest to some
|
|||
|
readers.
|
|||
|
|
|||
|
o Updated several references to reflect more recent versions of the
|
|||
|
various specifications. As part of this, reclassified RFC 4954 to
|
|||
|
a normative reference (SMTP AUTH is a MUST for RFC 4409 and this
|
|||
|
specification).
|
|||
|
|
|||
|
o Updated the text in Section 7 to reflect the existence and partial
|
|||
|
population of the registry and the included table (Table 1) to
|
|||
|
correct one entry and add others. See Section 10 for more
|
|||
|
information.
|
|||
|
|
|||
|
o Added new text (Section 5.3) to clarify that Submission Servers
|
|||
|
should respond quickly.
|
|||
|
|
|||
|
o Added text to make it explicit that character encoding changes are
|
|||
|
permitted.
|
|||
|
|
|||
|
o Added text to make it clear that modifications to signed messages
|
|||
|
may cause problems and that they should be carefully considered.
|
|||
|
|
|||
|
Authors' Addresses
|
|||
|
|
|||
|
Randall Gellens
|
|||
|
QUALCOMM Incorporated
|
|||
|
5775 Morehouse Drive
|
|||
|
San Diego, CA 92121-2779
|
|||
|
USA
|
|||
|
|
|||
|
EMail: rg+ietf@qualcomm.com
|
|||
|
|
|||
|
|
|||
|
John C Klensin
|
|||
|
1770 Massachusetts Ave, #322
|
|||
|
Cambridge, MA 02140
|
|||
|
USA
|
|||
|
|
|||
|
Phone: +1 617 491 5735
|
|||
|
EMail: john-ietf@jck.com
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Gellens & Klensin Standards Track [Page 20]
|
|||
|
|