16

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?

Community
  • 1
  • 1
Evan Krall
  • 2,915
  • 3
  • 23
  • 20
  • This link is about forwarding, but there is also an option to disable replies or replies to all recipients: https://www.makeuseof.com/tag/prevent-emails-forwarded-outlook-gmail/ - does somebody know how it works underneath (email header?) – Tomasz Gandor Jul 15 '19 at 13:07

3 Answers3

11

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.

SimonMayer
  • 4,719
  • 4
  • 33
  • 45
  • 2
    I disagree strongly about your interpretation that the mailbox should belong to an author of the message. No-reply emails belong to the author, and expect no conversation... – AlxVallejo Nov 19 '18 at 13:30
5

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…

Community
  • 1
  • 1
Kaspar Etter
  • 3,155
  • 1
  • 14
  • 21
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.

Mikko Rantalainen
  • 14,132
  • 10
  • 74
  • 112
  • “in the tag part”—note that this is *not* a standard feature, and you can’t rely on it to work in general. It’s behaviour that has been adopted by *some* mail servers. But unless you know the configuration of your specific server, it would be wrong to assume that `no-reply@example.com` and `no-reply+eventid@example.com` will end up going to the same mailbox—and test any kind of special-purpose auto-responder, it could easily not work for the + form. Also I don’t like that as a place to encode the information; consider Message-ID (individual) and/or List-ID (category). – Chris Morgan Feb 20 '23 at 03:46
  • @ChrisMorgan You're absolutely correct that according to RFCs the system should work as you describe. And the whole local part including the `+` is supposed to be opaque to the sender. However, in practice you cannot expect any other information but the one in `Reply-To` header to be reflected back to you if the user tries to reply anyway so for improved response to that incorrect reply, all data must be encoded in the address. And because even the `Reply-To` header is broken in some Windows software, you should try to put the whole thing in `From` header. This is what works in practice. – Mikko Rantalainen Feb 20 '23 at 11:46
  • A `Message-ID` will end up in `In-Reply-To` and `References` in responses. Beyond that, you’re very probably using the wrong tools for the entire thing. (There’s also the subject line, which should probably also have as much as you want for categorisation.) – Chris Morgan Feb 25 '23 at 03:08
  • Unfortunately, not all mail agents correctly fill `In-Reply-To` nor `References` headers. And you're right, the case I'm discussing about is a special case about (1) trying to send no-reply emails and (2) having fallback handling in case somebody still replies to said email. And for (2) I'm assuming that the mail agent does only the bare minimum, that is, mirror the original `From` address to `To` field in the reply. – Mikko Rantalainen Mar 04 '23 at 10:17
  • Can you identify any mail agent that doesn’t set either of those headers? (I haven’t done any detailed survey, but all I know do.) – Chris Morgan Mar 11 '23 at 15:49
  • I don't know if any current mail agent fails to do that but I remember fighting multiple agent implementations around years 2005–2010 and I'm fully expecting some vendors to still use broken implementations. As SMTP still uses 7 bit transfer encoding by default, I'm assuming there are still a lot of old stuff running in clients, too. – Mikko Rantalainen Mar 14 '23 at 09:02