And if that blocked message was a reaction I’d assume I can move on: they sent an email, I sent a response, they refused to accept it and then spammed me to boot.
There is a misunderstanding about how this works and how email works:
* Rejecting an email during the SMTP exchange results in the /sending/ server returning a response to the sender. This is NOT spam and it not under the control of the receiver.
* Rejecting an email post-acceptance and sending a reply is called /blowback/ and is typically considered poor practice and a type of spam. (But not UCE.)
* Adding a header to an outgoing message which causes the recipient's email server to possibly generate an email message to the recipient when they reply has nothing to do with the sender. The recipient's email provider is doing this, and the problem is you.
Let's recapitulate:
1) You use Microsoft as an ESP.
2) Somebody sends you a message, received by your ESP with this header.
3) Your ESP takes an action based on this header which results in you receiving feedback.
The whole thing is a shitshow, oblivious to externalities; but whatever.
So I turn them off as a matter of routine on all my accounts.
Obviously context dependent. For time-sensitive emails, it’s common to follow up with a call if receipt isn’t acknowledged.
I'm being surrounded right now by examples in multiple domains where it is clear that the moral of the story is that one person taking an action is different than a company packaging that action up and selling it as a solution to a general problem. This seems to be a lesson which needs to be generally remembered, explored, and learned. Again.
While one person responding "will do!" is appropriate 1:1, it is typically not appropriate to /reply all/ when doing it or to reply to a distribution list when doing it. I mean there are exceptions to everything: "Reply 'will do!' to this all-staff@ message or you're fired." But generally it's a meme, an anti-pattern (and there, I did it again).
Many people have built autoreply systems for email to respond with helpful advice to frequent topics. (Happy to help, I've done it before.) Similarly email clients (MUAs) which have macro / scripting capabilities for filtering or replying are not new.
What's new here? If it can be called new, it's that somebody provided that macro capability and linked it to an optional email header the sender can provide which enables / disables the ability to run macros in the client. In theory; or something. We (or at least I) don't know if it's possible to add your own macros.
I imagine this comes with tools in the client or in alias management to manage "reply all" / "me too": in other words it might be possible for someone to disable macros when responding to messages sent to all-staff@. I expect other extensions which reach across boundaries of control to follow if this one floats, and that's why I consider it a shitshow.
Really?