RFC 3834

Recommendations for Automatic Responses to Electronic Mail

📅 published August 2004, from ietf

Recommendations for Automatic Responses to Electronic Mail 💌✨

Request for Comments: 3834 🎀 Author: K. Moore, University of Tennessee 🧚 Category: Standards Track 🌈 Date: August 2004 📅 Obsoletes / Updates: none listed in this header 🫶

Status of this Memo 📝

Okay, so this doc is an Internet standards track protocol for the whole Internet community 🌐, and it's literally asking everyone for discussion and ideas to make it better 💖. If you want to know where it stands in the standardization process, check the current edition of the "Internet Official Protocol Standards" (STD 1) 👑. Distribution of this memo is unlimited, so share it with everyone 🦋.

Copyright (C) The Internet Society (2004) 💜.

Abstract 🌸

Okay, bestie, this memo is basically a set of recommendations for software that automatically replies to incoming emails 📬. We're talking "out of the office" or "vacation" responders 🏖️, mail filtering software 🧹, email-based info services 📚, and all the other auto-responders out there 🤖. The goal is to discourage the messy, unwanted behavior that these programs can cause or make worse 💀, encourage uniform behavior where it makes sense across auto-responders 🫶, and clear up some confusion for the people building these things 🙈. Iconic energy 👑.

1. Introduction ✨

Lowkey, tons of programs that automatically reply to email exist right now 📨. They're all super different in what they do, but several problems have shown up with this whole category 😭. We're talking about a crazy number of useless or unwanted replies 🗑️, responses getting sent to totally inappropriate addresses 🙅‍♀️, and sometimes full-on mail loops or "sorcerer's apprentice" mode 🧙‍♀️🔥. So this memo recommends behavior for these programs to cut down on those problems 💅.

(Note: the term "sorcerer's apprentice mode" is defined as a bug in a protocol where, under some circumstances, the receipt of a message causes multiple messages to be sent, each of which, when received, triggers the same bug.) (From [I1.JARGON]) 🧚 Honestly, the name is kind of dramatic but it fits 💀.

This document is limited in scope to Internet electronic mail messages 📧, and a lot of its recommendations are specifically tailored for the protocol elements and data models used in Internet electronic mail messages and SMTP transport envelopes 🎀. Using these recommendations in other messaging contexts, like instant messaging, SMS, or Usenet, hasn't been considered, and it's outside the scope of this document 🙅‍♀️. Not that deep, not that serious, just wanted you to know the boundaries 🌈.

1.1. Types of automatic responses 🦋

There are several different types of automatic responses 💖. At least two types have been defined in IETF standards 🏆. The first is Delivery Status Notifications [I2.RFC3464], which are meant to report the status of a message delivery by the message transport system 📦. The second is Message Disposition Notifications [I3.RFC3798], which are meant to report the disposition of a message after it reaches a recipient's mailbox 📬. These responses are defined elsewhere and are generally not within the purview of this document 🙈, except that this document recommends specific cases where they should or should not be used 🫶.

Other types of automatic response that are super common include:

  • "Out of office" or "vacation" notices 🏝️, which are meant to tell the sender that the message is unlikely to be read, or acted on, for some amount of time 😴.
  • "Change of address" notices 🏠, meant to tell the sender that the recipient address they used is obsolete and that a different address should be used instead (whether or not the message was forwarded to the current address) 📮.
  • "Challenges" 🛡️, which make the sender prove some amount of intelligence and/or willingness to agree to some conditions before the message gets delivered to the recipient (often to cut down on "spam" or viruses) 🙅‍♀️.
  • Email-based information services 📚, which accept requests (presumably from humans) via email, provide some service, and send responses via email too. Mailing lists that accept subscription requests via email fall into this category 💌.
  • Information services similar to the ones above, except they're meant to accept messages from other programs 🤖.
  • Various kinds of mail filters (including "virus scanners") 🧼, which act on behalf of a recipient to alter the content of messages before forwarding them, and issue responses when a message gets altered 🔥.

Since there's such a wide variety of response types out there 🌸, these recommendations split automatic responders into several classes based on the party or service they act on behalf of 👑.

  • "Service Responders" exist to provide access to some service via email requests and responses 🧚. They're permanently associated with one or more email addresses, and when someone sends to one of those addresses, the sender presumably expects an automatic response 💅. An email-based file retrieval service is an example, and so is a calendar service that lets you request appointments by email and replies to those requests 📅.
  • "Personal Responders" exist to make automatic responses on behalf of a single recipient address, in addition to, or instead of, that recipient reading the message 🫶. They operate according to criteria set on a per-recipient basis 🎀. The UNIX "vacation" program is an example 🏖️. A responder that accepts mail sent to a single address, tries to analyze and classify the contents, and then sends a response that depends on that classification is also a Personal Responder 🧠.
  • "Group Responders" exist to make automatic responses on behalf of any of a significant set of recipient addresses (say, every recipient in a particular DNS domain) 🌐, either before a response from the actual recipient, or instead of one 💖. Group Responders are similar to Personal Responders, except the criteria for responding aren't set on a per-recipient basis 🙈. A "virus scanner" program that filtered all mail sent to any recipient on a particular server, and sent responses when a message was rejected or delivered in an altered form, might be an example 🔥.

Appropriate behavior for a responder changes from one class to another 🦋. Something that's fine for a Service Responder (where the sender is expecting an automatic response) might not be fine for a Personal Responder 😬. For example, a Service Responder might send a very long response to a request, or one that isn't in a human-readable format, depending on what that service needs 🤖. But a Personal Responder should assume a human being is reading the response, so it should only send brief responses in plain text 📝.

1.2. Notation and Definitions 💜

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", and "MAY" in this document are to be interpreted as described in [N1.RFC2119] 🫶. Those words are the official vibe-checks for this doc, so read them carefully 🔍.

The term "subject message" is used to refer to a message which causes a response to be sent 📩.

The term "response" refers to a message that is automatically issued on receipt of a subject message by a responder 🤖.

A "responder" is a process that automatically responds to subject messages under some well-defined set of conditions 🧚.

Unless specified otherwise, the term "recipient" refers to the email addresses to which a subject message was delivered (rather than, for instance, the address the response was sent to) 📬. A "recipient" address might be permanently associated with a responder 🎀, or it might be the address of a human being whose mail is, under some conditions, answered by a responder 🙋‍♀️.

2. When (not) to send automatic responses 💅

okay bestie, the very first rule is huge: an automatic responder MUST NOT blindly send a response for every message it gets 🙅‍♀️ it's giving spam cannon. There are always reasons to say nope to some messages: loop prevention, not replying to "spam" or viruses, not getting used to launder or amplify abusive mail, not accidentally revealing personal stuff about the recipient (like an auto-reply saying "yep, they haven't read their mail in ages" 💀), and not getting flooded in a denial-of-service attack 🛡️ The criteria for deciding will be different for every responder, depending on what it's for. Generally, just avoid sending useless or redundant replies, and don't feed mail loops or make DoS attacks easier 🫶

Here are some broad guidelines:

  • Automatic responses SHOULD NOT be issued in response to any message which contains an Auto-Submitted header field (see below), where that field has any value other than no.
  • Personal and Group responses that are meant to tell the sender that the recipient can't read or reply to the message (think "away from my mail" or "too busy" notices) SHOULD NOT send the same response to the same sender more than once within a period of several days, even if that sender sends a bunch of messages 🙃 A 7-day period is RECOMMENDED as a default ✨
  • Personal and Group responses whose purpose is to say the recipient is temporarily away (aka "vacation" and "out of the office" notices) SHOULD NOT be issued unless a valid address for the recipient is explicitly included in a recipient (e.g., To, Cc, Bcc, Resent-To, Resent-Cc, or Resent-Bcc) field of the subject message 🧚 Since one person can have several addresses all forwarded to the same mailbox, recipients SHOULD be able to tell the responder which set of addresses counts as valid for them 💖

Note: RFC 2822 section 3.6.3 allows different uses of the Bcc field. Some of those would let the sender of the subject message name the recipient's address as a "Bcc" recipient without a Bcc field showing up in the delivered message, or without the delivered message containing the recipient's address at all 🤯 But, probably because Bcc is rarely used, the "don't respond unless the recipient was explicitly listed in a To, Cc, or Bcc header field" rule has been found to work really well in practice 🎀

  • Personal and Group Responders MAY refuse to generate responses except to known correspondents or addresses of otherwise "trusted" individuals 🔒 Those responders MAY also generate different kinds of responses for "trusted" vs. "untrusted" addresses. This could be useful, for example, to avoid inappropriately sharing personal info with random addresses 🌸
  • Responders MUST NOT generate any response whose destination would be a null address (e.g., an address where SMTP MAIL FROM or Return-Path is <>), since the response would never reach a useful destination 🚫 Responders MAY refuse to generate responses for addresses that are commonly used as return addresses by responders, e.g., ones with local-parts matching owner-*, *-request, MAILER-DAEMON, etc. 🙈 Responders are encouraged to check the destination address for validity before generating the response, so they don't send stuff that can't be delivered or probably isn't useful 💅
  • To avoid responding to spam and certain kinds of attacks, automatic responses from Service Responders SHOULD NOT be sent for extremely malformed requests 🗑️ This may include checking that the subject message has a content-type and content that's appropriate for that service.
  • Because the vast majority of email is unauthenticated, and return addresses are super easy to forge 😭, Service Responders SHOULD NOT return large responses (say, more than a few kilobytes) without specific knowledge that the request was actually authorized by the party associated with the address the response will be sent to. This is how you avoid being used for denial-of-service attacks (aka flooding mailboxes with unwanted content). Similarly, Service Responders SHOULD NOT cause unwanted side-effects (like subscribing the sender to a mailing list) without reasonable assurance that the affected party authorized the request 🚨

NOTE: Since every responder has a different purpose and a different set of potential threats, whether any particular means of authentication is appropriate for a particular responder is not in scope for this document 🧐

  • A responder MAY refuse to send a response to a subject message that contains any header or content making it look like a response wouldn't be appropriate 👀 For example, if the subject message had a Precedence header field [I4.RFC2076] with a value of "list", the responder might guess the traffic came from a mailing list, and wouldn't respond if the response was only meant for personal messages. For similar reasons, a responder MAY ignore any subject message with a List-* field [I5.RFC2369]. (Because Precedence isn't a standard header field, and its use and interpretation vary wildly in the wild, this specification doesn't recommend any particular responder behavior when Precedence is present 🤷‍♀️)

3. Format of automatic responses 🎀

The next sections spell out the details of the automatic response's contents: the header of the response message, the content of the response, and the envelope it gets transmitted in to the email transport system 📮

3.1. Message header

The fields in the message header should be set as follows:

3.1.1. From field

Okay so in human-to-human emails, the From field has a few jobs 💕 It says who wrote the message (or sometimes the party or parties it was sent on behalf of), and it's the default place humans send replies. Unfortunately, some mail systems still send non-delivery reports and other automatic responses to the From address 😤

For automatic responses, the From field matters less for where replies go, because most of the time it's not useful or appropriate for a human (or anyone) to reply to an automatic response 🙃 One exception is when something's wrong with the response. Then it should be possible to give feedback to whoever runs the responder 🫶

So in most cases, the From address in an automatic response needs to be picked based on these criteria:

  • Show which party or agent the response was sent on behalf of,
  • Give an address where a recipient of an inappropriate response can ask for the situation to be fixed, and
  • Reduce the chance of mail loops 🔁

So the following behavior is recommended ✨

  • For responses sent by Service Responders, the From field SHOULD contain an address that can be used to reach the (human) maintainer of that service. The human-readable part of the From field (the display-name before the address) SHOULD contain a name or description of the service so humans can tell what it is 🧚
  • For responses sent by Personal Responders, the From field SHOULD contain the name of the recipient of the subject message (i.e., the user the response is being sent on behalf of) and an address the recipient of the subject message picked to be recognizable to correspondents 💖 Often this will be the same address the sender used to message that recipient.

If a recipient has multiple mail addresses forwarded to the same mailbox (and responder), a Personal Responder MAY use heuristics to guess, based on info in various message header fields, which of those addresses the sender most likely used, and put that address in the From field of the response 🧠 However, it MUST be possible for the recipient the responder is acting for to explicitly specify the human-readable name and address to be used in the From header fields of responses 💅

Note: Due to privacy reasons, it may be inappropriate for responders to disclose an address derived from the recipient's login information (e.g., a POP or IMAP user name or account name on a multiuser computer), or one that reveals the specific name of the computer where the response was generated 🙈 Those also don't necessarily produce a valid public email address for the recipient. For this reason, Personal Responders MUST allow the From field of a Personal Response to be set by the recipient the responder is acting for 🔐

  • For Group Responders, the From address SHOULD contain an email address that could be used to reach the maintainer of that Group Responder. Using the Postmaster address for this purpose is NOT RECOMMENDED 🚫

The human-readable part of the From address (the "phrase" before the address, see [N2.RFC2822], section 3.2.6) SHOULD contain an indication of what function the Group Responder performs and who it operates on behalf of (e.g., "Example Agency virus filter") 🌈

3.1.2. Reply-To field

If the responder expects a reply, the Reply-To field of the response SHOULD be set to the address where that reply is expected 💌 That's true even if it's the address of the same or another responder. Responders that ask for replies to be sent to responders MUST prevent mail loops and sorcerer's apprentice mode 🧙‍♀️ Note that because (per the previous section) the From field of the response SHOULD contain the address of a human, if the Reply-To field is used to route replies to a responder, it won't be the same as the address in the From field 👑

Discussion: this assumes the human recipient's user agent will normally send replies to the Reply-To address (if one is present), as recommended by [I6.RFC822] since 1982 🦋 It's still possible for a recipient to reply to the From address if they find that useful, though. This matches the intended use of these fields in [I6.RFC822] and [N2.RFC2822] ✨

3.1.3. To field

The To header field SHOULD indicate the recipient of the response 💜 In general there SHOULD only be one recipient of any automatic response. This keeps the potential for sorcerer's apprentice mode and denial-of-service attacks way low 🛡️

3.1.4. Date field

The Date header field SHOULD indicate the date and time at which the response was generated 📅 This MUST NOT be taken as any indication of the delivery date of the subject message, or of the time the response was sent 🙅‍♀️ bestie, don't mix those up 😭

3.1.5. Subject field

Okay bestie, the Subject field SHOULD contain a brief little hint that the message is an automatic response 💅 and then it can carry the Subject field contents (or a portion of them) from the subject message 🦋. The prefix Auto: MAY be used as that hint ✨. If you use it, the prefix SHOULD be followed by an ASCII SPACE character (0x20) 🎀.

NOTE: this part is a fave 🫶 Just like the (Latin-derived) prefix "Re:" that people use to show a human wrote a reply, mail user agents sometimes translate it or treat it as a sign that the message is a reply. So the (Greek) prefix Auto: may also get translated, or used as a generic sign that the message is an automatic response. BUT the Auto: thing is only there to help humans read the message 🙈 Mail processing software SHOULD NOT assume that Auto: at the start of a Subject field means the message was automatically submitted 💀

Heads up, the Subject field of the subject message might have encoded-words formatted according to [N3.RFC2047] and [N4.RFC2231], and that text MAY be copied into the Subject field of your response 🌸 Usually you don't need to decode and re-encode it. It's usually enough to leave those encoded-words exactly as they were and just stick Auto: (or another indication) in front ✨ Still, it is necessary to make sure that no line in the resulting Subject field that contains an encoded-word is greater than 76 ASCII characters in length (this refers to the encoded form, not the number of characters in the text being encoded). Also, if the responder truncates the Subject from the subject message, it is necessary to avoid truncating Subject text in the middle of an encoded-word 🙏

3.1.6. In-Reply-To and References fields

The In-Reply-To and References fields SHOULD be provided in the header of a response message if there was a Message-ID field in the subject message, according to the rules in [N2.RFC2822] section 3.6.4 🧚

3.1.7. Auto-Submitted field

The Auto-Submitted field, with a value of auto-replied, SHOULD be included in the message header of any automatic response. See section 5 💜

3.1.8. Precedence field

A response MAY include a Precedence field [I4.RFC2076] in order to discourage responses from some kinds of responders which predate this specification 🍓 The field-body of the Precedence field MAY consist of the text junk, list, bulk, or other text deemed appropriate by the responder. Because the Precedence field is non-standard and its interpretation varies widely, the use of Precedence is not specifically recommended by this specification, nor does this specification recommend any particular value for that field 🤷‍♀️

3.2. Message content

In general, messages sent by Personal or Group Responders SHOULD be brief, and in text/plain format ✨ A multipart/alternative construct MAY be used to communicate responses in multiple languages, especially if in doing so it is desirable to use multiple charsets 🌈

Response messages SHOULD NOT include significant content from the subject message 🙅‍♀️ In particular, Personal and Group responses SHOULD NOT contain non-text content from the subject message, and they SHOULD NOT include attachments from the subject message. Neither of these conditions applies to responders that specifically exist for the purpose of altering or translating content sent to them (for instance, a FORTRAN-to-C translator). However, such responders MUST employ measures to avoid being used as a means of laundering or forwarding undesirable content, such as spam or viruses 🚫🦠

Note that when text from the Subject or other fields from the header of the subject message is included in the body of the response, it is necessary to decode any encoded-words that appeared in those fields before including them in the message body, and to use an appropriate content-type, charset, and content-transfer-encoding 💅 In some cases it may be necessary to transliterate text from the charset(s) used in the header of the subject message to the charset(s) used in the body of the response. (It is much easier to implement a responder if text from the header of the subject message never needs to appear in the body of the response 🥹)

3.2.1. Use of DSNs and MDNs instead of this specification

In general, it is appropriate to use Delivery Status Notifications (DSNs) for responses that are generated by the mail transport system as a result of attempts to relay, forward, or deliver mail, and only when the purpose of that response is to provide the sender of the subject message with information about the status of that mail delivery 📬 For instance, a "virus scanner" which is activated by a mail delivery process to filter harmful content prior to delivery could return a DSN with the Action field set to failed with a Status code of 5.7.1 (Delivery not authorized, message refused) if the entire message was not delivered due to security reasons. Or it could return a DSN with the Action field set to relayed or delivered (as appropriate) with a Status code set to 2.6.4 (conversion with loss performed) if the message was relayed or delivered with the presumably harmful content removed 🛡️ The DSN specification [I2.RFC3464], rather than this document, governs the generation and format of DSNs.

Similarly, it is appropriate to use Message Disposition Notifications (MDNs) only for responses generated on the recipient's behalf, which are generated on or after delivery to a recipient's mailbox, and for which the purpose of the response is to indicate the disposition of the message 💌 The MDN specification [I3.RFC3798], rather than this document, governs the generation and format of MDNs.

This document is not intended to alter either the DSN or MDN specifications. Responses that fit within the criteria of DSN or MDN, as defined by the respective specifications, should be generated according to the DSN or MDN specification rather than this document. Responses which do not fit one of these sets of criteria should be generated according to this document 🦋

3.3. Message envelope

The SMTP MAIL FROM address, or other envelope return address used to send the message, SHOULD be chosen in such a way as to make mail loops unlikely 🔁 A loop might occur, for instance, if both sender and recipient of a message each have automatic responders. The recipient's responder sends mail to the sender's responder, which sends mail back to the recipient's responder. Chaos 😭

The primary purpose of the MAIL FROM address is to serve as the destination for delivery status messages and other automatic responses. Since in most cases it is not appropriate to respond to an automatic response, and the responder is not interested in delivery status messages, a MAIL FROM address of <> MAY be used for this purpose 🫥 A MAIL FROM address which is specifically chosen for the purpose of sending automatic responses, and which will not automatically respond to any message sent to it, MAY be used instead of <> 🧚

The RCPT TO address will (of course) be the address of the intended recipient of the response. It is RECOMMENDED that the NOTIFY=NEVER parameter of the RCPT command be specified if the SMTP server supports the DSN option [N5.RFC3461] 💖

4. Where to send automatic responses (and where not to send them) 💌

In general, automatic responses SHOULD be sent to the Return-Path field if generated after delivery. If the response is generated prior to delivery, the response SHOULD be sent to the reverse-path from the SMTP MAIL FROM command, or (in a non-SMTP system) to the envelope return address which serves as the destination for non-delivery reports 📮

If the response is to be generated after delivery, and there is no Return-Path field in the subject message, there is an implementation or configuration error in the SMTP server that delivered the message or gatewayed the message outside of SMTP 🚨 A Personal or Group responder SHOULD NOT deliver a response to any address other than that in the Return-Path field, even if the Return-Path field is missing. It is better to fix the problem with the mail delivery system than to rely on heuristics to guess the appropriate destination of the response. Such heuristics have been known to cause problems in the past 😬

A Service Responder MAY deliver the response to the address(es) from the >From field, or to another address from the request payload, provided this behavior is precisely defined in the specification for that service. Services responders SHOULD NOT use the Reply-To field for this purpose 🎀

The Reply-To field SHOULD NOT be used as the destination for automatic responses from Personal or Group Responders. In general, this field is set by a human sender based on his/her anticipation of how human recipients will respond to the specific content of that message. For instance, a human sender may use Reply-To to request that replies be sent to an entire mailing list. Even for replies from humans, there are cases where it is not appropriate to respond to the Reply-To address, especially if the sender has asked that replies be sent to a group and/or mailing list 📢 Since a Personal or Group Responder operates on behalf of a human recipient, it is safer to assume that any Reply-To field present in the message was set by a human sender on the assumption that any reply would come from a human who had some understanding of the roles of the sender and other recipients. An automatic responder lacks the information necessary to understand those roles. Sending automatic responses to Reply-To addresses can thus result in a large number of people receiving a useless or unwanted message; it can also contribute to mail loops 🙃

Use of the From field as the destination for automatic responses has some of the same problems as use of Reply-To. In particular, the From field may list multiple addresses, while automatic responses should only be sent to a single address. In general, the From and Reply-To addresses are used in a variety of ways according to differing circumstances, and for this reason Personal or Group Responders cannot reliably assume that an address in the From or Reply-To field is an appropriate destination for the response. For these reasons the From field SHOULD NOT be used as a destination for automatic responses 🙅‍♀️

Similarly, the Sender field SHOULD NOT be used as the destination for automatic responses. This field is intended only to identify the person or entity that sent the message, and is not required to contain an address that is valid for replies 🫠

The Return-Path address is really the only one from the message header that can be expected, as a matter of protocol, to be suitable for automatic responses that were not anticipated by the sender 👑

5. The Auto-Submitted header field 💖

The purpose of the Auto-Submitted header field is to indicate that the message was originated by an automatic process, or an automatic responder, rather than by a human 🤖 It also helps to facilitate automatic filtering of messages from signal paths for which automatically generated messages and automatic responses are not desirable 🌸

5.1. Syntax ✨

okay so the grammar for Auto-Submitted is literally right here, and it's giving neat little legos 🧱💖 It uses the ABNF notation from [N6.RFC2234]:

auto-submitted-field     = "Auto-Submitted:" [CFWS]
                           auto-submitted [CFWS] CRLF

auto-submitted           = ( "no" / "auto-generated" /
                           "auto-replied" / extension )
                           opt-parameter-list

extension                = token

opt-parameter-list       = *( [CFWS] ";" [CFWS] parameter )

The bits CFWS and CRLF come from [N2.RFC2822], and token and parameter come from [N7.RFC2045] (as amended by [N4.RFC2231]). Bestie, that's where all the building blocks live 🫶

Also, a message can only have one Auto-Submitted field in its header. Just the one, no more, no less 🎀

5.2. Semantics

okay the big vibe check here: the Auto-Submitted header field SHOULD NOT be added to messages that a human typed out manually 🙅‍♀️ BUT (and this is the tea) user agents that let senders add arbitrary fields SHOULD NOT stop humans from setting Auto-Submitted, because it's sometimes genuinely useful for testing 🧪✨

Now let's go keyword by keyword, because each one has its own rules 💅

The auto-generated keyword:

  • It SHOULD be used on messages made by automatic (often periodic) processes, like UNIX "cron jobs", that aren't direct replies to other messages ⏰
  • It MUST NOT be used on manually generated messages 🚫
  • It MUST NOT be used on a message sent as a direct reply to another message 🚫
  • It MUST NOT be used to label Delivery Status Notifications (DSNs) [I2.RFC3464], Message Disposition Notifications (MDNs) [I3.RFC3798], or any other reports of message (non)receipt or (non)delivery. 😭 Quick side note: some SMTP implementations that are out in the wild right now use "auto-generated" on non-delivery reports. Those should be changed to use "auto-replied" instead 🔧

The auto-replied keyword:

  • It SHOULD be used on messages sent in direct response to another message by an automatic process 🤖💬
  • It MUST NOT be used on manually-generated messages 🚫
  • It MAY be used on Delivery Status Notifications (DSNs) and Message Disposition Notifications (MDNs) 🌸
  • It MUST NOT be used on messages generated by automatic or periodic processes, except for messages that are automatic responses to other messages 🙈

The no keyword MAY be used to explicitly say a message came from a human, if that somehow turns out to be appropriate 🧑‍💻🎀

Extension keywords might get defined in the future, though it seems unlikely 👀 Their syntax and semantics must be published as RFCs and approved through the IETF Consensus process [N8.RFC2434]. Keywords starting with x- are reserved for experiments and for use among consenting parties 🧪. Recipients of a message with an Auto-Submitted field carrying any keyword other than no MAY assume the message was not manually submitted by a human 🤖

Optional parameters can also be defined through an IETF Consensus process 🗳️ The syntax for them is in here so future folks can add them if they're ever needed. Implementations that follow this spec MUST NOT fail to recognize an Auto-Submitted field and keyword that has syntactically valid optional parameters, but they MAY ignore those parameters if they show up 🫧 Parameter names starting with x- are reserved for experiments and for use among consenting parties too 🧚

Last but not least, the comment construct from [N2.RFC2822] can be used to explain why a message was submitted automatically 💜 It's like leaving a little sticky note ✨

6. Security Considerations 🔐

okay bestie, I need you to take this part seriously 😭 Automatic responders open the door to several kinds of attack, including:

  • Using these responders to relay harmful or abusive content (worms, viruses, spam, and spymail) to spread it further or to hide where it really came from 💀
  • Using these responders to launch denial-of-service attacks, either by making them relay messages to huge numbers of addresses, by flooding individual mailboxes with tons of unwanted content, or by doing both 🌊
  • Deliberately or accidentally using these responders to build mail loops or "sorcerer's apprentice mode", which eats up the resources of the mail transport system 🍝
  • Using these responders to figure out whether recipient addresses are valid, especially when that info isn't otherwise provided (for example, through SMTP RCPT or VRFY command responses) and isn't meant to be shared 🕵️‍♀️
  • Using these responders to get personal info about recipients, including details about how recently they've used their mailbox or what they've been up to lately 👀
  • On top of all that, the responder itself can get attacked by someone sending it huge numbers of requests 🫠

This document tries to make responders less vulnerable to this stuff, mainly by:

  • Recommending that responders not relay significant content from the subject message, which keeps them from being used to launder or amplify content the attacker picked 🧼
  • Recommending that responders clearly mark their responses with the Auto-Submitted: auto-replied header field so they're easy to tell apart from messages a human wrote (partly to cut down on loops and denial-of-service attacks) 🏷️
  • Recommending that Personal and Group Responders limit how many responses go to any one individual in a given period of time (which also caps the damage from loops) ⏳
  • Recommending that responders answer at most one address per incoming message (to cut down on deliberate or accidental denial-of-service through "multiplication" or sorcerer's apprentice mode) ✂️
  • Recommending that responses from Personal and Group Responders should be brief and in plain text format (so mail responders can't be used to carry harmful content or hide where it came from) 📝

But here's the catch: email addresses are super easy to forge, so attacks are still possible for any email responder that doesn't limit access and require authentication before it sends a response 🥲 The measures above can shrink the damage, but they can't fully stop attacks.

This section is about the vulnerabilities that come with automatically responding to mail. Other vulnerabilities belong to some mail-based services that auto-respond to emails, but those don't happen because the server answers incoming messages automatically 🙅‍♀️ In general, any network-based service (including the ones you reach through email) needs enough security to keep it from being used to access, in an inappropriate or destructive way, the resources it can reach 🔒

It's also been noted that Personal and Group Responders sometimes disclose recipients' personal info by mistake. That can happen automatically (like when a Group Responder automatically includes a recipient's personal or mobile phone number as alternate contact info) or "manually" 📱 Automatically generated info SHOULD NOT include personal info about the recipient that isn't already known to, or easily available to, the sender of the subject message 🚫 And user interfaces that let recipients type in response text SHOULD make it crystal clear that this info will be visible not only to local colleagues but to the entire Internet, including potential attackers 📣🌐

7. Example: vacation program 🏖️

This section shows how these recommendations might apply to a made-up "vacation" program. Its job is to reply to a single recipient's mail while they're busy or away and can't answer personally 🌴 This is only an illustration and is not a normative part of this standard, so it's just vibes 🦋

The vacation program is a Personal Responder 💁‍♀️

The vacation program refuses to respond to any message that:

  • appears to be spam (for example, if the sender or some intermediary labelled it as advertising or potential spam) 🗑️
  • appears to contain a virus (for example, if it has an executable attachment) 🦠
  • contains an Auto-Submitted header field 🤖
  • has already been sent a response within the previous 7 days 📅
  • doesn't contain one of the recipient's addresses in a To, CC, Bcc, Resent-To, Resent-CC, or Resent-Bcc field 🙅‍♀️
  • contains a Precedence field with a value of "list", "junk", or "bulk" 📬
  • doesn't have a Return-Path address, or 🫥
  • has a Return-Path address of <>, or a Return-Path address in a form that non-delivery reports often use 💀

Here's how the vacation response is formatted 💖

  • The From header field is set to a name and email address specified by the user on whose behalf the responses are sent. (On some systems it may be reasonable to have a default From setting for vacation responses, based on the user's account name and the system's domain name.) 🎀
  • The Reply-To field is set only if the user on whose behalf the responses are sent has explicitly configured it. For example, a user might direct replies to a secretary or co-worker who's been delegated to handle important matters while they're away 🧑‍💼
  • The To field contains the address of the recipient of the response, taken from the Return-Path field of the subject message 📮
  • The Date field contains the date and time when the response was generated 🗓️
  • The Subject field contains Auto: followed by a string chosen by the user on whose behalf the responses are sent. A default setting like "away from my mail" might be appropriate. If the Subject field has non-ASCII characters, those get encoded per [N3.RFC2047] 🌈
  • The In-Reply-To and References fields are generated from the subject message per [N2.RFC2822] 🧵
  • The Auto-Submitted field has the value auto-replied 🏷️
  • The message body contains some text specified by the user on whose behalf the response is sent. It also includes a brief summary of the subject message: From, To, Subject, Date, and a few lines of message text from the subject message. No attachments or non-text bodyparts are included in the response 📝✨

The SMTP MAIL FROM address in the message envelope is <> 💌 The RCPT TO address in the message envelope is the address of the user the response is going to. NOTIFY=NEVER is also set on the RCPT TO line if the SMTP server permits it 🔔

8. IANA Considerations 🗂️

Section 5 of this document defines two new extension mechanisms: new keywords for the Auto-Submitted header field, and new optional parameters for the Auto-Submitted field 🧩 If new keywords or parameters ever get approved (through an IETF Consensus process), it may be appropriate for IANA to create a registry of them 📚✨

9. Acknowledgments ✨

okay so in the mid-1990s Jeroen Houttuin of TERENA wrote a bunch of internet-drafts called "Behavior of Mail Based Servers," and one of them was all about "Answering Servers" 🧚. As far as this author knows, none of them were ever formally published, but they gave the first well-reasoned argument (that this author knows of) for how these servers should talk to email systems and protocols. iconic 💅

the Auto-Submitted field idea comes from the X.400/MHS mail system [I7.X420] 🌸. Then [I8.RFC2156] defined an "Autosubmitted" field for when you're gatewaying between X.400 and Internet mail. Jacob Palme wrote an internet-draft about using the "Auto-Submitted" field for Internet mail that got through Last Call with no real objections, but it got stuck while people tried to sort out some non-substantial objections 😭. The definition of Auto-Submitted in this document is basically that one, just slightly simplified, with some text taken straight from it 🫶.

huge thanks to everyone who gave suggestions for this document: Russ Allbery, Adam Costello, Ned Freed, Lawrence Greenfield, Arnt Gulbrandsen, Eric Hall, Tony Hansen, Vivek Khera, Dan Kohn, Bruce Lilly, Charles Lindsey, der Mouse, Lyndon Nerenberg, Richard Rognlie, Markus Stumpf, Florian Weimer, and Dan Wing 💖🎀

10. References

10.1. Normative References

  • [N1.RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑
  • [N2.RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001. 📨
  • [N3.RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. 🌈
  • [N4.RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997. 🧩
  • [N5.RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003. 📬
  • [N6.RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. 🍓
  • [N7.RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. 🦋
  • [N8.RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 📋

10.2. Informative References

  • [I1.JARGON] "Sorcerer's apprentice mode", originally from the Jargon file once maintained at MIT-AI and SAIL; now collected at various places on the net. See e.g., http://www.jargon.net/ 🧙
  • [I2.RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003. 📦
  • [I3.RFC3798] Hansen, T. and G. Vaudreuil, Eds., "Message Disposition Notifications", RFC 3798, May 2004. ✅
  • [I4.RFC2076] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997. 🏷️
  • [I5.RFC2369] Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, July 1998. 📣
  • [I6.RFC822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. 🕰️
  • [I7.X420] CCITT Recommendation X.420 (1992 E). Information technology - Message Handling Systems (MHS): Interpersonal messaging system, 1992. 🏛️
  • [I8.RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998. 🔁

Author's Address

Keith Moore
Innovative Computing Laboratory
University of Tennessee, Knoxville
1122 Volunteer Blvd, #203
Knoxville, TN 37996-3450

EMail: moore@cs.utk.edu

Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 📜

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ⚠️

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. It also doesn't represent that it has made any independent effort to identify any such rights. 🧠 Info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr. 🔍

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please send that info to the IETF at ietf-ipr@ietf.org. 💌

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society. 🫶🌈

📦 where this page comes from