Is there a "no-reply" email header?

Question

I often see automated emails postfixed with a message like

Amazon:

*Please note: this e-mail was sent from an address that cannot accept incoming e-mail. Please use the link above if you need to contact us again about this same issue.

Twitter:

Please do not reply to this message; it was sent from an unmonitored email address. This message is a service email related to your use of Twitter.

Google Checkout:

Need help? Visit the Google Checkout help center. Please do not reply to this message.

Directly underneath this warning, Gmail shows me a reply input field. It seems to me that there should be some sort of header that could be attached to such automated emails that would tell the recipient's email client to not allow replies.

Is there such a header? If not, has it ever been discussed by the groups that control email formats?

Answer 1

It seems that Thunderbird shows a built-in warning message if From address is of form no-reply@example.com. (The message I noticed this with also had To with no-reply@example.com and my email address in Cc field only. I haven't tested if this is important.)

As far as I know, the form no-reply@example.com has not been defined in any RFC.

Update: It appears that this behavior has been implemented in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1342809 and the actual implementation is a regex

/^(.*[._-])?(do[._-]?not|no)[._-]?reply([._-].*)?@/

If that matches, a confirmation prompt is displayed:

Reply Not Supported

The reply address ({ $email }) does not appear to be a monitored address. Messages to this address will likely not be read by anyone.

[Reply Anyway] [Cancel]

This seems sensible enough for me and maybe other vendors could agree here. Note that this causes all the following to show the warning before allowing a reply:

service-name-no-reply@example.com
donot-reply@example.com
noreply.xyz@example.com
no-reply-userid@example.com

Unfortunately, it doesn't match

no-reply+eventid@example.com

so you have to use something like

no-reply-productname+eventid@example.com

if you want to encode extra information in the tag part.

Update: Note that none of this is specified in any RFC related to email so this is about what works in practice instead of in theory.

Answer 2

RFC 6854 updates RFC 5322 to allow the group construct to be used in the From field as well (among other things). A group can be empty, which is likely the only way you've ever seen the group syntax being used: undisclosed-recipients:;.

Section 1 of the RFC explicitly lists "no-reply" among the motivations for allowing the group construct in the From field:

The use cases for the "From:" field have evolved. There are numerous instances of automated systems that wish to send email but cannot handle replies, and a "From:" field with no usable addresses would be extremely useful for that purpose.

It provides the following example: From: Automated System:;

However, at the end of the same section, the RFC also says:

This document recommends against the general use of group syntax in these fields at this time

In section 3, the RFC clarifies that the group syntax in the From field is only for Limited Use.

Personally, I think this method should not be used – unless we're certain that all relevant clients display the originating domain in some other way (reconstructed from the Return-Path or a new header). Otherwise, this defeats all the efforts towards domain authentication (SPF, DKIM, and DMARC). Introducing an additional header field which causes clients to simply hide the reply button seems the much better approach to me.

The RFC comments on this aspect in section 5:

Some protocols attempt to validate the originator address by matching the "From:" address to a particular verified domain (for one such protocol, see the Author Domain Signing Practices (ADSP) document [RFC5617]). Such protocols will not be applicable to messages that lack an actual email address (whether real or fake) in the "From:" field. Local policy will determine how such messages are handled, and senders, therefore, need to be aware that using groups in the "From:" might adversely affect deliverability of the message.

What a failed opportunity…

Answer 3

Is there such a header?

No. I'm pretty sure there isn't anything like that; and even if there is, it'd be non-standard and not widely supported, so it'd be pretty much useless at the moment. Even if it were to become standard, any such header would presumably just be informational; and for backwards-compatibility, support would have to be entirely optional for email clients. Clients would be slow to implement it, and many users would still be on old versions of mail clients.

If not, has it ever been discussed by the groups that control email formats?

Probably. People have had a long time to suggest all manner of things with email, but my gut feeling is that it would never be implemented; well... not unless there is a fundamental shift in the ideas of what email is designed to do. I'm sure Google would be much happier if you didn't even have a "Reply" button when they email you, so if anyone is pushing for it, it'll be the people who are already sending from donotreply@...

Email is designed to be sent from real mailboxes. RFC 2822 and RFC 5322 say:

In all cases, the "From:" field SHOULD NOT contain any mailbox that does not belong to the author(s) of the message.

To me, that is a clear indication that email is designed as a method for conversation, rather than broadcast.

Probably the biggest killer to any change would be the little bit above that line, which would need to be entirely redefined; which would cause more problems than would be solved:

The originator fields also provide the information required when replying to a message. When the "Reply-To:" field is present, it indicates the address(es) to which the author of the message suggests that replies be sent. In the absence of the "Reply-To:" field, replies SHOULD by default be sent to the mailbox(es) specified in the "From:" field unless otherwise specified by the person composing the reply.