Message Submission for Mail
draft-levine-rfc6409bis-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | John R. Levine , Randall Gellens , Dr. John C. Klensin | ||
| Last updated | 2023-11-17 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-levine-rfc6409bis-00
Network Working Group J. Levine
Internet-Draft Standcore LLC
Intended status: Standards Track R. Gellens
Expires: 20 May 2024 QUALCOMM Incorporated
J. Klensin
17 November 2023
Message Submission for Mail
draft-levine-rfc6409bis-00
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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 20 May 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Levine, et al. Expires 20 May 2024 [Page 1]
Internet-Draft 6409bis November 2023
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Document Information . . . . . . . . . . . . . . . . . . . . 4
2.1. Definitions of Terms Used in This Memo . . . . . . . . . 4
2.2. Conventions Used in This Document . . . . . . . . . . . . 5
3. Message Submission . . . . . . . . . . . . . . . . . . . . . 5
3.1. Submission Identification . . . . . . . . . . . . . . . . 5
3.2. Message Rejection and Bouncing . . . . . . . . . . . . . 5
3.3. Authorized Submission . . . . . . . . . . . . . . . . . . 6
4. Mandatory Actions . . . . . . . . . . . . . . . . . . . . . . 7
4.1. General Submission Rejection Code . . . . . . . . . . . . 7
4.2. Ensure All Domains Are Fully Qualified . . . . . . . . . 7
4.3. Require Authentication . . . . . . . . . . . . . . . . . 8
5. Recommended Actions . . . . . . . . . . . . . . . . . . . . . 8
5.1. Enforce Address Syntax . . . . . . . . . . . . . . . . . 8
5.2. Log Errors . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Apply Shorter Timeouts . . . . . . . . . . . . . . . . . 9
6. Optional Actions . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Enforce Submission Rights . . . . . . . . . . . . . . . . 9
6.2. Enforce Permissions . . . . . . . . . . . . . . . . . . . 9
6.3. Check Message Data . . . . . . . . . . . . . . . . . . . 9
6.4. Support for the Postmaster Address . . . . . . . . . . . 10
6.5. Adjust Character Encodings . . . . . . . . . . . . . . . 10
7. Interaction with SMTP Extensions . . . . . . . . . . . . . . 10
8. Message Modifications . . . . . . . . . . . . . . . . . . . . 12
8.1. Add 'Sender' . . . . . . . . . . . . . . . . . . . . . . 13
8.2. Add 'Date' . . . . . . . . . . . . . . . . . . . . . . . 13
8.3. Add 'Message-ID' . . . . . . . . . . . . . . . . . . . . 13
8.4. Transfer Encode . . . . . . . . . . . . . . . . . . . . . 13
8.5. Sign the Message . . . . . . . . . . . . . . . . . . . . 13
8.6. Encrypt the Message . . . . . . . . . . . . . . . . . . . 13
8.7. Resolve Aliases . . . . . . . . . . . . . . . . . . . . . 13
8.8. Header Rewriting . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
12. Normative References . . . . . . . . . . . . . . . . . . . . 15
13. Informative References . . . . . . . . . . . . . . . . . . . 16
Levine, et al. Expires 20 May 2024 [Page 2]
Internet-Draft 6409bis November 2023
Appendix A. Major Changes from RFC 6409 . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
SMTP [RFC5321] 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 [RFC5321]. 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 [RFC5322] 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.
Levine, et al. Expires 20 May 2024 [Page 3]
Internet-Draft 6409bis November 2023
Separating messages into submissions and transfers allows developers
and network administrators to do the following more easily:
* Implement security policies and guard against unauthorized mail
relaying or injection of unsolicited bulk mail.
* Implement authenticated submission, including off-site submission
by authorized users such as travelers.
* Separate the relevant software code differences, thereby making
each code base more straightforward and allowing for different
programs for relay and submission.
* Detect configuration problems with a site's mail clients.
* 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
[RFC5321]; 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 [RFC5321]. 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.
Message User Agent (MUA)
Levine, et al. Expires 20 May 2024 [Page 4]
Internet-Draft 6409bis November 2023
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 [RFC1939] or
IMAP [RFC9051] 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", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
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 [RFC5321], 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.
Levine, et al. Expires 20 May 2024 [Page 5]
Internet-Draft 6409bis November 2023
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.
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 [RFC4954] 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.
Levine, et al. Expires 20 May 2024 [Page 6]
Internet-Draft 6409bis November 2023
Secure IP [RFC4301], 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 [RFC1939] authentication (from the same IP address)
within some amount of time (e.g., 20 minutes) prior to the start of a
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 [RFC5321], 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.
Levine, et al. Expires 20 May 2024 [Page 7]
Internet-Draft 6409bis November 2023
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 [RFC4954], unless it
has already independently established authentication or authorization
(such as being within a protected subnetwork).
Section Section 3.3 discusses authentication mechanisms.
Reply code 530 [RFC4954] 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 [RFC3463])
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.
Levine, et al. Expires 20 May 2024 [Page 8]
Internet-Draft 6409bis November 2023
5.3. Apply Shorter Timeouts
The timeouts specified in Section 4.5.3.2 of [RFC5321] 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.
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
[RFC3463], 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
[RFC3463], 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.
Levine, et al. Expires 20 May 2024 [Page 9]
Internet-Draft 6409bis November 2023
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 [RFC3463]
(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 [RFC5321], the MSA MAY permit a
reduced degree of authentication for mail addressed to the
"postmaster" (or one of its alternate spelling forms, see [RFC5321]),
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.
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 | Submission | Reference |
+=====================+====================+============+===========+
| PIPELINING | Pipelining | SHOULD | [RFC2920] |
+---------------------+--------------------+------------+-----------+
| ENHANCEDSTATUSCODES | Enhanced Status | SHOULD | [RFC2034] |
| | Codes | | |
+---------------------+--------------------+------------+-----------+
| ETRN | Extended Turn | MUST NOT | [RFC1985] |
+---------------------+--------------------+------------+-----------+
| ... | Extended Codes | SHOULD | [RFC3463] |
+---------------------+--------------------+------------+-----------+
Levine, et al. Expires 20 May 2024 [Page 10]
Internet-Draft 6409bis November 2023
| DSN | Delivery Status | SHOULD | [RFC3461] |
| | Notification | | |
+---------------------+--------------------+------------+-----------+
| SIZE | Message size | MAY | [RFC1870] |
+---------------------+--------------------+------------+-----------+
| ... | 521 reply code | MUST NOT | [RFC1846] |
+---------------------+--------------------+------------+-----------+
| CHECKPOINT | Checkpoint/ | MAY | [RFC1845] |
| | Restart | | |
+---------------------+--------------------+------------+-----------+
| BINARYMIME | Binary MIME | MAY | [RFC3030] |
+---------------------+--------------------+------------+-----------+
| CHUNKING | Chunking | MAY | [RFC3030] |
+---------------------+--------------------+------------+-----------+
| 8BITMIME | Use 8-bit data | SHOULD | [RFC6152] |
+---------------------+--------------------+------------+-----------+
| AUTH | Authentication | MUST | [RFC4954] |
+---------------------+--------------------+------------+-----------+
| STARTTLS | Start TLS | MAY | [RFC3207] |
+---------------------+--------------------+------------+-----------+
| NO-SOLICITING | Notification of | MAY | [RFC3865] |
| | no soliciting | | |
+---------------------+--------------------+------------+-----------+
| MTRK | Message | MAY | [RFC3885] |
| | Tracking | | |
+---------------------+--------------------+------------+-----------+
| ATRN | On-Demand Relay | MUST NOT | [RFC2645] |
+---------------------+--------------------+------------+-----------+
| DELIVERBY | Deliver By | MAY | [RFC2852] |
+---------------------+--------------------+------------+-----------+
| CONPERM | Content | MAY | [RFC4141] |
| | Conversion | | |
| | Permission | | |
+---------------------+--------------------+------------+-----------+
| CONNEG | Content | MAY | [RFC4141] |
| | Conversion | | |
| | 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:
Levine, et al. Expires 20 May 2024 [Page 11]
Internet-Draft 6409bis November 2023
Extended Status Codes [RFC3463] SHOULD be supported and used
according to [RFC2034]. 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 are
related to a site's security policy, care should be used not to
expose more detail to unauthenticated senders than is needed.
PIPELINING [RFC2920] SHOULD be supported by the MSA.
SMTP AUTH [RFC4954] allows the MSA to validate the authority and
determine the identity of the submitting user and MUST be supported
by the MSA.
STARTTLS [RFC3207] 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 [RFC3030].
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 [RFC5321] and [RFC5322] 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) [RFC6376],
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.
Levine, et al. Expires 20 May 2024 [Page 12]
Internet-Draft 6409bis November 2023
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 [RFC5322]
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 [RFC5322]). 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 [RFC4954] mechanism that
provides for session integrity.
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.
Levine, et al. Expires 20 May 2024 [Page 13]
Internet-Draft 6409bis November 2023
NOTE: SMTP [RFC5321] 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 [RFC5321] on modifications of
local-parts. Changes to addressing and encoding, carried out in
conjunction with the action of Section 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.
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.
Levine, et al. Expires 20 May 2024 [Page 14]
Internet-Draft 6409bis November 2023
If a site fails to require any form of authorization for message
submissions (see Section 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 Section 3 includes further discussion of issues with some
authentication methods.
Section 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 previous version of this
specification (RFC 6409) 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
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.
12. Normative References
Levine, et al. Expires 20 May 2024 [Page 15]
Internet-Draft 6409bis November 2023
[RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes",
RFC 3463, DOI 10.17487/RFC3463, January 2003,
<https://www.rfc-editor.org/info/rfc3463>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
13. Informative References
[RFC1845] Crocker, D., Freed, N., and A. Cargille, "SMTP Service
Extension for Checkpoint/Restart", RFC 1845,
DOI 10.17487/RFC1845, September 1995,
<https://www.rfc-editor.org/info/rfc1845>.
[RFC1846] Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846,
DOI 10.17487/RFC1846, September 1995,
<https://www.rfc-editor.org/info/rfc1846>.
[RFC1870] Klensin, J., Freed, N., and K. Moore, "SMTP Service
Extension for Message Size Declaration", STD 10, RFC 1870,
DOI 10.17487/RFC1870, November 1995,
<https://www.rfc-editor.org/info/rfc1870>.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,
<https://www.rfc-editor.org/info/rfc1939>.
[RFC1985] De Winter, J., "SMTP Service Extension for Remote Message
Queue Starting", RFC 1985, DOI 10.17487/RFC1985, August
1996, <https://www.rfc-editor.org/info/rfc1985>.
[RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced
Error Codes", RFC 2034, DOI 10.17487/RFC2034, October
1996, <https://www.rfc-editor.org/info/rfc2034>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2645] Gellens, R., "ON-DEMAND MAIL RELAY (ODMR) SMTP with
Dynamic IP Addresses", RFC 2645, DOI 10.17487/RFC2645,
August 1999, <https://www.rfc-editor.org/info/rfc2645>.
Levine, et al. Expires 20 May 2024 [Page 16]
Internet-Draft 6409bis November 2023
[RFC2852] Newman, D., "Deliver By SMTP Service Extension", RFC 2852,
DOI 10.17487/RFC2852, June 2000,
<https://www.rfc-editor.org/info/rfc2852>.
[RFC2920] Freed, N., "SMTP Service Extension for Command
Pipelining", STD 60, RFC 2920, DOI 10.17487/RFC2920,
September 2000, <https://www.rfc-editor.org/info/rfc2920>.
[RFC3030] Vaudreuil, G., "SMTP Service Extensions for Transmission
of Large and Binary MIME Messages", RFC 3030,
DOI 10.17487/RFC3030, December 2000,
<https://www.rfc-editor.org/info/rfc3030>.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
February 2002, <https://www.rfc-editor.org/info/rfc3207>.
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)",
RFC 3461, DOI 10.17487/RFC3461, January 2003,
<https://www.rfc-editor.org/info/rfc3461>.
[RFC3865] Malamud, C., "A No Soliciting Simple Mail Transfer
Protocol (SMTP) Service Extension", RFC 3865,
DOI 10.17487/RFC3865, September 2004,
<https://www.rfc-editor.org/info/rfc3865>.
[RFC3885] Allman, E. and T. Hansen, "SMTP Service Extension for
Message Tracking", RFC 3885, DOI 10.17487/RFC3885,
September 2004, <https://www.rfc-editor.org/info/rfc3885>.
[RFC4141] Toyoda, K. and D. Crocker, "SMTP and MIME Extensions for
Content Conversion", RFC 4141, DOI 10.17487/RFC4141,
November 2005, <https://www.rfc-editor.org/info/rfc4141>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880,
DOI 10.17487/RFC4880, November 2007,
<https://www.rfc-editor.org/info/rfc4880>.
[RFC4954] Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service
Extension for Authentication", RFC 4954,
DOI 10.17487/RFC4954, July 2007,
<https://www.rfc-editor.org/info/rfc4954>.
Levine, et al. Expires 20 May 2024 [Page 17]
Internet-Draft 6409bis November 2023
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, DOI 10.17487/RFC5751, January
2010, <https://www.rfc-editor.org/info/rfc5751>.
[RFC6152] Klensin, J., Freed, N., Rose, M., and D. Crocker, Ed.,
"SMTP Service Extension for 8-bit MIME Transport", STD 71,
RFC 6152, DOI 10.17487/RFC6152, March 2011,
<https://www.rfc-editor.org/info/rfc6152>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
Access Protocol (IMAP) - Version 4rev2", RFC 9051,
DOI 10.17487/RFC9051, August 2021,
<https://www.rfc-editor.org/info/rfc9051>.
Appendix A. Major Changes from RFC 6409
The protocol specified by this document is not substantively
different from that of RFC 6409. However, the present specification
contains several clarifications and updates to reflect changes and
revisions to other documents subsequent to the its publication.
* Reformat for XML publication
Authors' Addresses
John Levine
Standcore LLC
Email: standards@standcore.com
Randall Gellens
QUALCOMM Incorporated
Email: rg+ietf@qualcomm.com
John C Klensin
Email: john-ietf@jck.com
Levine, et al. Expires 20 May 2024 [Page 18]