RFC 6409
Message Submission for Mail
RFC 6409: Message Submission for Mail 💌✨
Okay bestie, this one is RFC 6409 🎀, a Standards Track document (it's also STD 72, so it's officially a full Internet Standard, ✨ iconic). It was published in November 2011 by R. Gellens of QUALCOMM Incorporated and J. Klensin, under the IETF 💜. The header says it obsoletes RFC 4409, so it replaces that earlier doc, and it lists no RFCs it updates. The ISSN is 2070-1721 🌸.
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 ...........................20Abstract ✨
This memo splits message submission from message relay 🦋, so each service can run by its own rules (for security, policy, and so on). It also spells out what a submission server has to do.
Message relay doesn't change at all, and it keeps using SMTP over port 25. 📮
When you follow this document, message submission uses the protocol described here, normally over port 587 💖.
Splitting these functions up is seriously worth it, because it lets you apply specific security or policy requirements ✨.
Status of This Memo 🌸
This is an Internet Standards Track document.
This document comes from the Internet Engineering Task Force (IETF). It reflects the consensus of the IETF community 💜. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check out Section 2 of RFC 5741.
Want the current status, any errata, or a way to give feedback on this doc? Head to http://www.rfc-editor.org/info/rfc6409 🔗.
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) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions with regard to this document. Any Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 📜.
1. Introduction ✨
Okay, so SMTP [SMTP-MTA] was originally built as a message transfer protocol 🚚. That means it routes (if needed) and delivers finished, complete messages.
Message Transfer Agents (MTAs) aren't supposed to change the message text, except to add 'Received', 'Return-Path', and other header fields that [SMTP-MTA] requires. But SMTP is now also used a lot as a message submission protocol 💅. That's how Message User Agents (MUAs) get brand-new messages into the MTA routing network. The process that accepts submissions from MUAs is called a "Message Submission Agent" (MSA).
To allow unconstrained communication, SMTP usually isn't authenticated during message relay 🙈.
Authentication and authorization for initial submissions have become way more important 🔥. Security requirements changed, and people expect submission servers to take responsibility for the traffic they originate.
Like, a ton of machines have worms, viruses, or other malicious software that blast out huge amounts of spam 💀. So lots of sites now block outbound traffic on the standard SMTP port (port 25) and send all mail submissions through submission servers instead.
On top of authentication and authorization, the messages being submitted are sometimes finished (complete) and sometimes unfinished (incomplete) in one or more ways 🧩. Unfinished messages might need completing so they conform to the Message Format specification [MESSAGE-FORMAT] and related requirements. For example, a message might be missing a proper 'Date' header field, and its domains might not be fully qualified. Sometimes the MUA just can't generate a finished message (for example, it might not know its time zone). And even when submitted messages are complete, local site policy may want the message text examined or changed in some way, such as hiding local name or address spaces 🙈. These kinds of completions or changes have been shown to cause harm when downstream MTAs (the ones after the first-hop submission MTA) do them, and they're generally considered outside the province of standardized MTA functionality ⚠️.
Splitting messages into submissions and transfers makes it easier for developers and network administrators to:
- 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 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 way for messages to be identified as submissions, and it specifies what actions a submission server must take 💖. Hey, you know what I mean, right? 😭
2. Document Information 🦋
2.1. Definitions of Terms Used in This Memo
A lot of the concepts and terms here are defined in [SMTP-MTA], so familiarity with that doc is assumed 📚.
Fully Qualified
Containing or consisting of a domain that can be globally resolved using the Domain Name Service, meaning it's not a local alias or a 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 🚚.
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 get and process the message according to local conventions. Or, in what's commonly called a split-MUA model, Post Office Protocol [POP3] or IMAP [IMAP4] is used to access delivered messages, while 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] 🔑. Bestie, these are the official requirement words, so they're sacred 🙏.
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 🎯.
Yes, most email clients and servers can be set 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 as MSAs and others as 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. 💅 Ngl, this is a total "know your audience" move.
For example, some sites might set their MTAs to reject all RCPT commands for messages that don't reference local users. They might also set their MSA to reject every submission that doesn't come from an authorized user. Authorization can be based on either the authenticated identity or the submitting endpoint being inside a protected IP environment. 🏰 The gatekeeper is literally checking who's knocking.
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 can't work out a return path for the submitting user, from a valid MAIL FROM, a valid source IP address, or the authenticated identity, then the MSA SHOULD immediately reject the message. 🛑 An immediate rejection is done by returning a 550 code to the MAIL command.
A null return path, meaning MAIL FROM:<>, is permitted, and it 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 then generating a bounce message. 🪃 So if the MSA is going to reject a message for any reason except not being able to find a return path, it can either do an immediate rejection or accept the message and 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 handle delayed bounces properly, the client MUA needs to keep a queue of the messages it has submitted and match bounces to them. Many contemporary MUAs don't have this capability, unfortunately. 😭
3.3. Authorized Submission 🔐
Lots of methods have been used to make sure only authorized users can submit messages. 🗝️ These include authenticated SMTP, IP address restrictions, secure IP and other tunnels, and prior POP authentication.
Authenticated SMTP [SMTP-AUTH] has seen widespread deployment. ✨ It lets the MSA determine an authorization identity for the message submission, one that isn't tied to other protocols. Iconic.
IP address restrictions are very widely implemented, but they don't account for travelers and similar situations. They can also 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. They come with extra perks like 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) before the start of a message submission session 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 and configured for this. The MSA also has to coordinate with the POP server, which can be tricky. There's also a window during which an unauthorized user can submit messages and appear to be a previously authorized user. Since it depends on the MUA's IP addresses, this technique is basically 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 a more precise response code covers it, 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 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 that expansion is particularly risky. Not a vibe. 💀
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. 📚
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 the message body has been submitted, 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 super helpful to notify the administrator when problems are detected with local mail clients. This is another perk of distinguishing submission from relay: system administrators might care about local configuration problems, but not about 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. 🚧 Don't let your logs get spammed into oblivion, bestie.
5.3. Apply Shorter Timeouts ⏱️
The timeouts specified in Section 4.5.3.2 of RFC 5321 [SMTP-MTA] are designed to handle the many types of situations that can happen on the public Internet. The relationship among clients and servers corresponding to this specification is usually much closer and more predictable. 💫 Submission clients behave differently from relay clients in some areas, especially when it comes to tolerance for timeouts. In practice, message submission clients tend to have short timeouts (perhaps 2-5 minutes for a reply to any command). So 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. 🤝 Very cozy, very intentional.
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 if it isn't 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 it's 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 isn't 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 it's appropriate under local conditions, and to help with conformance to 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 [SMTP-MTA]), in one or more domains, compared to the requirements enforced for other addresses. 🧚 Among other benefits, this gives an address of last resort that authorized users can use to report problems that would otherwise stop them from submitting mail. Lifesaver energy. 🆘
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, replacing addresses whose encoding doesn't 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 don't explicitly specify their applicability to this protocol. 📊 Listed are the EHLO keyword, name, an indication of the extension's use on the submit port, and a reference.
+--------------------+----------------------+--------+-----------------+
| Keyword | Name |Sub- | Reference |
| | |mission | |
+--------------------+----------------------+--------+-----------------+
|PIPELINING |Pipelining |SHOULD |[PIPELINING] |7. Interaction with SMTP Extensions (the table's last bit) 🎀
Here's the rest of the extensions crew, all in one tidy table 💅
|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 1Okay bestie, so any future SMTP extension SHOULD explicitly say whether it's valid on the Submission port. That's the rule, no cap 🧚
Some SMTP extensions are especially useful for message submission, and these are the main ones 🌸
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 way more detail than the response codes listed in this memo. Lowkey important: some rejections are tied to a site's security policy, so care should be used not to expose more detail to unauthenticated senders than is needed 🙈
PIPELINING: [PIPELINING] SHOULD be supported by the MSA. 🦋
AUTH: [SMTP-AUTH] lets the MSA validate the authority and figure out the identity of the submitting user, and it MUST be supported by the MSA. This one is non-negotiable, periodt 👑
STARTTLS: [START-TLS] is the most widely used mechanism, at the time this document was written, for letting the MUA and MSA protect message submission integrity and privacy. It's giving security queen energy 💜
Also, any references to the DATA command in this memo also refer to any substitutes for DATA, such as the BDAT command used with [CHUNKING]. So BDAT counts too, iykyk ✨
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, so let's get into the glow-up 🌈
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. Bestie, don't just slap a domain on everything, it's chaos 😭
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. Main character rules, no exceptions 🎀
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. So editing can break a signature, and then the next receivers get suspicious 🫣
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 fake addresses allowed, obviously 🙅♀️
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. Fixing the date is giving tidy girlie 🧼
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, so this one's a little bit of a mood 🙃
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. Policy-girl era 💜
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. So the signing only really works if the pipe in front is locked down too 🫶
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. Aliases are a whole vibe, and you can't just wipe them out 🫠
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. Private-era energy 🕶️
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. Only rewrite what's on the list, babe, no random chaos 🚫
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. Rewriting the destination is a hard no unless the MSA has the info to do it right 💀
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. Splitting the jobs is super smart, ngl 🧠
Separation also can aid in tracking and preventing unsolicited bulk email. Spam is not the vibe 🚫📧
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. Lock the door, check the ID, and don't let randoms in 🔑
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. Okay, this is a red alert moment 🚨😭 Please go check Section 3.3 bestie, it's serious.
Section 3 includes further discussion of issues with some authentication methods. Go read it, it's a whole saga 📖
Section 5.2 includes a cautionary note that unlimited logging can enable certain forms of denial-of-service attacks. Too much logging can be used as a weapon, so keep it in check 💀
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. Table 1 got its glow-up and the registry matches it now ✨
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. Everything's pointing to the right place now 🎯
The entry in the "Service Name and Transport Protocol Port Number Registry" for port 587 has been updated to point to this document. Port 587 is all updated and ready to slay 🌟
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. Thank you, queens 👑
Nathaniel Borenstein and Barry Leiba were instrumental in the development of RFC 4409, the update to RFC 2476. Huge respect 🙌
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. Shoutout to the reviewers 💖
Special thanks to Harald Alvestrand, who got this effort started. The OG starter, legend 🌈
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 📚
okay so these are the bonus reads 🧚 they aren't required to implement the thing, but they're the specs this doc leans on for SMTP extensions, mail formats, auth, and security. here's the whole list, bestie 💅
[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.
[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.
[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.Appendix A. Major Changes from RFC 4409 🎀
okay the protocol here is basically the same as RFC 4409 ✨ no big plot twist. the spec got a glow-up though, with clarifications and updates to match newer docs that came out after 4409. here's the tea 🫶
- updated a bunch of references to newer versions of the specs 📦 and as part of that, RFC 4954 got moved over to a normative reference. the reason: SMTP AUTH is a MUST for RFC 4409 and this specification 🔐
- Section 7 got an update to reflect that the registry exists and is partly filled in 🗂️ Table 1 got one entry fixed and some new ones added. see Section 10 for more info 💜
- new text in Section 5.3 says Submission Servers should respond quickly ⚡
- it now says outright that character encoding changes are permitted 🌈
- it's now clear that changing signed messages may cause problems, so those changes should be carefully considered 🙈
Authors' Addresses 💖
here's who wrote this beauty 🧚 with their contact info:
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.comand that's the whole spec, babe 🌈✨ we did it 😭🫶
📦 where this page comes from
- ietf: rfc6409 2011-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms