RFC 2476

Message Submission

📅 published December 1998, from ietf

Message Submission 💌

Okay bestie, this one is RFC 2476, and it's called Message Submission ✨. It's a Standards Track doc from the Network Working Group, dated December 1998. The authors are R. Gellens from QUALCOMM and J. Klensin from MCI. The header doesn't list anything it obsoletes or updates, so it's flying solo 🦋

Network Working Group                                        R. Gellens
Request for Comments: 2476                                     QUALCOMM
Category: Standards Track                                    J. Klensin
                                                                    MCI
                                                          December 1998

Status of This Memo ✨

This document is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

Copyright (C) The Internet Society (1998). All Rights Reserved. 💅

Table of Contents 🎀

 1.  Abstract . . . . . . . . . . . . . . . . . . . . . . . . . .  2
 2.  Document Information  . . . . . . . . . . . . . . . . . . .   3
   2.1.  Definitions of Terms Used in this Memo . . . . . . . . .  3
   2.2.  Conventions Used in this Document . . . . . . . . . . .   4
 3.  Message Submission . . . . . . . . . . . . . . . . . . . . .  4
   3.1.  Submission Identification . . . . . . . . . . . . . . .   4
   3.2.  Message Rejection and Bouncing . . . . . . . . . . . . .  4
   3.3.  Authorized Submission . . . . . . . . . . . . . . . . .   5
   3.4.  Enhanced Status Codes  . . . . . . . . . . . . . . . . .  6
 4.  Mandatory Actions . . . . . . . . . . . . . . . . . . . . .   6
   4.1.  General Submission Rejection Code  . . . . . . . . . . .  6
   4.2.  Ensure All Domains are Fully-Qualified  . . . . . . . .   6
 5.  Recommended Actions  . . . . . . . . . . . . . . . . . . . .  7
   5.1.  Enforce Address Syntax  . . . . . . . . . . . . . . . .   7
   5.2.  Log Errors . . . . . . . . . . . . . . . . . . . . . . .  7
 6.  Optional Actions  . . . . . . . . . . . . . . . . . . . . .   7
   6.1.  Enforce Submission Rights  . . . . . . . . . . . . . . .  7
   6.2.  Require Authentication  . . . . . . . . . . . . . . . .   8
   6.3.  Enforce Permissions  . . . . . . . . . . . . . . . . . .  8
   6.4.  Check Message Data  . . . . . . . . . . . . . . . . . .   8
 7.  Interaction with SMTP Extensions . . . . . . . . . . . . . .  8
 8.  Message Modifications . . . . . . . . . . . . . . . . . . .   9
   8.1.  Add 'Sender' . . . . . . . . . . . . . . . . . . . . . .  9
   8.2.  Add 'Date'  . . . . . . . . . . . . . . . . . . . . . .  10
   8.3.  Add 'Message-ID' . . . . . . . . . . . . . . . . . . . . 10
   8.4.  Transfer Encode . . . . . . . . . . . . . . . . . . . .  10
   8.5.  Sign the Message . . . . . . . . . . . . . . . . . . . . 10
   8.6.  Encrypt the Message . . . . . . . . . . . . . . . . . .  10
   8.7.  Resolve Aliases  . . . . . . . . . . . . . . . . . . . . 10
   8.8.  Header Rewriting  . . . . . . . . . . . . . . . . . . .  10
 9.  Security Considerations  . . . . . . . . . . . . . . . . . . 11
10.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . .  11
11.  References . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14
13.  Full Copyright Statement  . . . . . . . . . . . . . . . . .  15

1. Abstract 🌸

Okay so SMTP was originally defined as a message transfer protocol, which means it's the thing that routes (if needed) and delivers finished, complete messages 📮 Message Transfer Agents (MTAs) aren't supposed to mess with the message text, except to add 'Received', 'Return-Path', and other header fields as required by [SMTP-MTA].

BUT, SMTP is now also super widely used as a message submission protocol 👀 That's where message user agents (MUAs) hand brand-new messages over to the MTA routing network. The process that accepts those submissions from MUAs is called a Message Submission Agent (MSA) 💅

Submitted messages can be totally finished, or they can be a little unfinished in some way. Unfinished messages need to be completed so they conform to [MESSAGE-FORMAT] and the later requirements 🙈 For example, a message might be missing a proper 'Date' header field, or its domains might not be fully qualified. Sometimes the MUA just can't produce a finished message (like, it might not know its time zone). Even when a submitted message is complete, local site policy might want the message text examined or modified somehow. These kinds of completions or modifications have been shown to cause harm when downstream MTAs do them (that is, MTAs after the first-hop submission MTA), so they're generally considered outside the scope of standardized MTA functionality ⚠️

Splitting messages into submissions and transfers is lowkey genius because it helps developers and network admins:

  • 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, which keeps each code base more straightforward and allows for different programs for relay and submission 🧩
  • Detect configuration problems with a site's mail clients 🔍
  • Provide a basis for adding enhanced submission services in the future 🚀

This memo describes a low cost, deterministic means for messages to be identified as submissions, and it specifies what actions a submission server is supposed to take 🦋

Public comments should go to the IETF Submit mailing list, <ietf-submit@imc.org>. To subscribe, send a message containing SUBSCRIBE to <ietf-submit-request@imc.org>. Private comments can be sent to the authors 💌

2. Document Information 🎀

2.1. Definitions of Terms Used in this Memo 📚

Fully-Qualified

This means containing or consisting of a domain that can be globally resolved using the global Domain Name Service. In other words, it's not a local alias or a partial specification 🌍

Message Submission Agent (MSA)

A process that conforms to this specification. It acts as a submission server to accept messages from MUAs, and then 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]. It acts as an SMTP server to accept messages from an MSA or another MTA, and then either delivers them or acts as an SMTP client to relay them to another MTA 🫶

Message User Agent (MUA)

A process that acts (usually on behalf of a user) to compose and submit new messages, and to process delivered messages. In the split-MUA model, POP or IMAP is used to access delivered messages 📬

2.2. Conventions Used in this Document 🍓

In examples, "C:" is used to indicate lines sent by the client, and "S:" indicates those sent by the server. Line breaks within a command example are just for editorial purposes 💜

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]. These are the official requirement words, so you'll want to read them exactly as written ✨

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 is ESMTP [SMTP-MTA, ESMTP], with additional restrictions as specified here 🎀

Most email clients and servers can be configured to use port 587 instead of 25, but there are cases where that isn't 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 MTA to reject all RCPT TOs for messages that don't reference local users. They might also configure their MSA to reject all message submissions that don't come from authorized users, based on IP address or authenticated identity 🔐

NOTE: It is better to reject a message than to risk sending one that is damaged. This is especially true for problems that the MUA can correct itself, for example, an invalid 'From' field. 💀

If an MSA can't 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 FROM command 😭

Note that a null return path, that is, MAIL FROM:<>, is permitted and MUST be accepted. (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 tells an MSA to issue a rejection code MAY be complied with by accepting the message and then generating a bounce message. (In other words, if the MSA is going to reject a message for any reason except not being able to determine a return path, it can either 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, because it gives the user and MUA direct feedback. To properly handle delayed bounces, the client MUA must maintain a queue of messages it has submitted, and match bounces to them 🧾

3.3. Authorized Submission 🔑

Honestly there are so many ways people have tried to make sure only authorized users can submit messages 😩 These methods include authenticated SMTP, IP address restrictions, secure IP, and prior POP authentication 🌈

Authenticated SMTP [SMTP-AUTH] has been proposed. It lets the MSA determine an authorization identity for the message submission, and that identity isn't tied to other protocols 🧚

IP address restrictions are very widely implemented, but they don't work well for travellers and similar situations, and they can be spoofed 🙈

Secure IP [IPSEC] can also be used. It has the extra perk of protecting against eavesdropping and traffic analysis 🛡️

Requiring a POP [POP3] authentication (from the same IP address) within some amount of time (for example, 20 minutes) before a message submission session starts has also been used. But this imposes 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 of or configured for this. Also, the MSA has to coordinate with the POP server, which may be difficult. There's also a window where an unauthorized user can submit messages and appear to be a prior authorized user 👀

3.4. Enhanced Status Codes ✨

This memo suggests a few enhanced status codes [SMTP-CODES] for submission-specific rejections. Here are the ones it uses, bestie 💅

  • 5.6.0 Bad content. Okay so this one means the content of the header or text is improper 🙈
  • 5.6.2 Bad domain or address. An invalid or improper domain or address in MAIL FROM, RCPT TO, or DATA 🌸
  • 5.7.1 Not allowed. This one's giving "no access" energy 🔒 The address in MAIL FROM appears to have insufficient submission rights, or is invalid, or is not authorized with the authentication used. The address in a RCPT TO command is inconsistent with the permissions given to the user. The message data is rejected based on the submitting user.
  • 5.7.0 Site policy. The message appears to violate site policy in some way 🚫

4. Mandatory Actions 👑

An MSA MUST do all of these:

4.1. General Submission Rejection Code

Unless a more precise response code covers it, response code 554 is the one to use when rejecting a MAIL FROM, RCPT TO, or DATA command that contains something improper. And if no other code is more specific, enhanced status code 5.6.0 is the move ✨

4.2. Ensure All Domains are Fully-Qualified

The MSA MUST ensure that all domains in the envelope are fully-qualified. Non-negotiable, bestie 🫶

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 used to reject a MAIL FROM, RCPT TO, or DATA command that contains improper domain references.

NOTE: A frequent local convention is to accept single-level domains (for example, sales) and then expand the reference by adding the remaining portion of the domain name (for example, to sales.example.net). Local conventions that permit single-level domains SHOULD reject, rather than expand, incomplete multi-level domains, since such expansion is particularly risky 💀

The MSA SHOULD do all of these:

5.1. Enforce Address Syntax

An MSA SHOULD reject messages with illegal syntax in a sender or recipient 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 used to reject a MAIL FROM or RCPT TO command that contains a detectably improper address.

When addresses are resolved after the message body has been submitted, reply code 554 with enhanced status code 5.6.2 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 📝

Note: 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 🍓

6. Optional Actions 🦋

The MSA MAY do any of these:

6.1. Enforce Submission Rights

The MSA MAY issue an error response to the MAIL FROM 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 enhanced status code 5.7.1 is used for this purpose.

6.2. Require Authentication

The MSA MAY issue an error response to the MAIL FROM command if the session has not been authenticated.

Section 3.3 discusses authentication mechanisms, so go check that out 🔐

Reply code 530 [SMTP-AUTH] is used for this purpose.

6.3. Enforce Permissions

The MSA MAY issue an error response to the RCPT TO command if it is inconsistent with the permissions given to the user (if the session has been authenticated).

Reply code 550 with enhanced status code 5.7.1 is used for this purpose.

6.4. 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, or 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 enhanced status code 5.7.1 is used to reject based on the submitting user. Reply code 550 with enhanced status code 5.7.0 is used if the message violates site policy 💖

7. Interaction with SMTP Extensions 🎀

Okay, here's the table of the current standards-track and Experimental SMTP extensions. It lists the RFC, the name, how the extension is used on the submit port, and a reference 💅

RFC   Name             Submission  Reference
----  ---------------  ----------  ------------------
2197  Pipelining         SHOULD    [PIPELINING]
2034  Error Codes        SHOULD    [CODES-EXTENSION]
1985  ETRN              MUST NOT   [ETRN]
1893  Extended Codes     SHOULD    [SMTP-CODES]
1891  DSN                SHOULD    [DSN]
1870  Size                MAY      [SIZE]
1846  521               MUST NOT   [521REPLY]
1845  Checkpoint          MAY      [Checkpoint]
1830  Binary              MAY      [CHUNKING]
1652  8-bit MIME         SHOULD    [8BITMIME]
----  Authentication     ------    [SMTP-AUTH]

Future SMTP extensions should explicitly specify if they are valid on the Submission port 👀

Some SMTP extensions are especially useful for message submission, though:

Extended Status Codes [SMTP-CODES] SHOULD be supported and used according to [CODES-EXTENSION]. This lets the MSA tell the client about 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 than is needed to correct the problem 🔥

[PIPELINING] SHOULD be supported by the MSA.

[SMTP-AUTH] allows the MSA to validate the authority and determine the identity of the submitting user 🪪

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 which 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 🙅‍♀️

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. No skipping this one 💅

8.2. Add 'Date'

The MSA MAY add a Date field to the submitted message, if it lacks one, or correct the Date field if it does not conform to [MESSAGE-FORMAT] syntax 🗓️

8.3. Add 'Message-ID'

The MSA MAY add or replace the Message-ID field, if it lacks one, or if it is not valid syntax (as defined by [MESSAGE-FORMAT]) 🆔

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, e.g., 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 🛡️

8.7. Resolve Aliases

The MSA MAY resolve aliases (CNAME records) for domain names, in the envelope and optionally in address fields of the header, subject to local policy 🔗

NOTE: 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 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 logon names, and/or to rewrite squeeky.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 which 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 which strips the left-most element of the domain if the complete domain matches *.foo.example.net would be acceptable 🚨

9. Security Considerations 🔐

Separation of submission and relay of messages can allow a site to implement different policies for the two types of services, including requiring use of additional security mechanisms for one or both. It can do this in a way which 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 MSA to require authentication before accepting a message, and could configure its MTA to reject all RCPT TOs 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. 😱🚨

10. Acknowledgments 🫶

This updated memo has been revised in part based on comments and discussions which took place on and off the IETF-Submit mailing list. The help of those who took the time to review the draft 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 💜

11. References 📚

okay bestie, this is the reading list 🤓 every spec quotes its sources, so here they all are, complete, with all their details. the names in brackets are the tags the document uses to cite them ✨

  • [521REPLY] Durand, A. and F. Dupont, "SMTP 521 Reply Code", RFC 1846, September 1995.
  • [8BITMIME] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
  • [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
  • [CHECKPOINT] Crocker, D., Freed, N. and A. Cargille, "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 1830, August 1995.
  • [CODES-EXTENSION] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
  • [DSN] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996.
  • [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
  • [ETRN] De Winter, J., "SMTP Service Extension for Remote Message Queue Starting", RFC 1985, August 1996.
  • [HEADERS] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997.
  • [IPSEC] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, August 1995.
  • [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [MESSAGE-FORMAT] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982; Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
  • [PIPELINING] Freed, N., "SMTP Service Extension for Command Pipelining", RFC 2197, September 1997.
  • [POP3] Myers, J. and M. Rose, "Post Office Protocol -- Version 3", STD 53, RFC 1939, May 1996.
  • [SIZE] Klensin, J., Freed, N. and K. Moore, "SMTP Service Extension for Message Size Declaration", STD 10, RFC 1870, November 1995.
  • [SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", Work in Progress.
  • [SMTP-CODES] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996.
  • [SMTP-MTA] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982; Partridge, C., "Mail Routing and the Domain System", STD 14, RFC 974, January 1986; Braden, R., Editor, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.

12. Authors' Addresses 📮

here are the two humans who wrote this, with their contact details exactly as they appear in the document 💌

Randall Gellens
QUALCOMM Incorporated
6455 Lusk Blvd.
San Diego, CA  92121-2779
U.S.A.

Phone: +1 619 651 5115
Fax:   +1 619 651 5334
EMail: Randy@Qualcomm.Com


John C. Klensin
MCI Telecommunications
800 Boylston St, 7th floor
Boston, MA 02199
USA

Phone: +1 617 960 1011
EMail: klensin@mci.net

okay the legal bit, but make it cute 🎀

Copyright (C) The Internet Society (1998). All Rights Reserved. ✨

anyone can copy this document and share it with friends, and anyone can make derivative works that comment on or explain it or help people implement it. you can publish and distribute those in whole or in part, with no restrictions of any kind, as long as the copyright notice and this paragraph stay on every copy and derivative work 💜

the one catch is that this document itself can't be modified in any way. you can't remove the copyright notice or the references to the Internet Society or other Internet organizations. the exceptions are when you need to develop Internet standards, where the copyright procedures in the Internet Standards process have to be followed, or when you need to translate it into a language other than English 🌸

the limited permissions above are perpetual, and the Internet Society or its successors or assigns will not revoke them 🦋

and the disclaimer, verbatim because it's important 🫶

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💅

📦 where this page comes from