Is there an email header that prevents automatic cannot-deliver responses?

Question

I know that there is no "no-reply" header for emails. But I'd like something a bit different.

I have an app which sends out automated emails (like "thank you for registering, click this link to confirm email address"). Sometimes the target email is incorrect, or the server doesn't respond, or whatever. In that case, my local SMTP server will eventually generate a new "Delivery Delayed" email back to the sender, and in the end - "Delivery Failed". However since the original emails were sent out in an automated fashion, these status notifications are irrelevant.

Worse - if you use a real email address in the "from" field, the real person will receive a "delivery delayed" email for something he never sent.

Is there something I can put in my email headers to specify that these "delivery status notifications" are not necessary?

Answer 1

The only proper and sane way to avoid a reply is to use an empty (<>) return address in the SMTP envelope (i.e. MAIL FROM:<>) -- note this is not a header, but rather part of the SMTP transaction.

However messages that are not error responses (bounces or DSNs) should not generally use empty return addresses.

However, in this scenario one might consider the combination of HTTP request and SMTP response to be one logical transaction with the user, and so violation of the "should" might be justified. Note though that the recipient, and or their MTA and MUA, may treat messages that appear to be bounces or DSNs differently than normal messages and this may impact how they deal with your notification. This may be OK if your message doesn't demand any action on the part of the recipient, but not otherwise. I.e. is it a postcard, or is it a request for action?

The best thing to do is to use a proper application-specific return address on all such automated outgoing notification messages and to forward any bounces or DSNs (incoming messages to that return path which themselves have an empty return path) to a program which will actively do something intelligent with the message (e.g. remove the record with the bounced address from the registration database), and to forward all other non-DSN messages to a human for consideration.

I.e. You really do want DSNs for all your outgoing mail, whether you realize it yet or not! :-)

(BTW, never ever ever use any return address which looks or feels like "no-reply" or anything like it or related to it. Messages with such bogus addresses are likely to be rejected or discarded or ignored, and deservedly so.)