The UX problem is you send an e-mail, and someone "thumbs up" a response, and then you block the response and assume that they didn't care to respond, while they think they have responded.

The distance between "didn't care to respond" and a thumbs up emoji response is measured in angstroms.

With a thumbs-up I know they've read it, and that's worth quiet a bit in this asynchronous communication world of ours.

We used to (and I believe still) have Read Receipts for this.

Yes! +1 And it's possible to disable Read Receipts and a lot of people do. A lot of people mangle beacon pixels too.

read receipts just mean you opened the message, not that you actually read it. It's a terrible misnomer.

Oh yeah, the thing I always turn off or filter out because the last thing I need is another way spies and hackers and ad men can track every waking moment of my life.

Read Receipts are invasive, because they signal when I read it - which might well not be when I want to reply. I could read an email today and then decide I'll reply tomorrow or next Wednesday, because reasons; but the sender will see the read receipt and just assume I hate their guts for not replying immediately to the Most Important Person In The World (i.e. them).

So I turn them off as a matter of routine on all my accounts.

That was another groupware feature that was great for small orgs and terrible for the general net.

The distance between "not detectable" and "detectable" is vast and significant, no matter how minute the unit of measurement.

I suppose it'd be OK if the other side of your TCP connections stopped sending ACKs.

This is cute, but not how email communication works. There's no need for explicit answer to any email, otherwise people would never stop responding.

> not how email communication works. There's no need for explicit answer to any email

Obviously context dependent. For time-sensitive emails, it’s common to follow up with a call if receipt isn’t acknowledged.

Be sure to CC everybody. /s No. The technology isn't built for this.

I'm pretty sure a large number of e-mail conversations (i.e. not just announcements) end in one person saying, "OK", "Will do", "See you then", "I'm too busy, sorry" or some such response. It's very uncommon to send out an e-mail to someone and ask them to do something or consider something and then assume it has been received without acknowledgement.

Email is used for a lot of things. It could be used as a message broker in batch processing systems. /s (Seriously, there are MIME types for that.)

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.

“Please let me know if you were able to read this attachment.”

Really?

ACK is required for TCP to work, reply is not for email.

No. When you block an email the sender will get a notification email from their mail server that their message was blocked. They will not assume anything for very long.

That's email server dependent. When my mailserver blocks emails, it just drops them onto the floor. The sender doesn't get any sort of notification.

That's not blocking, then. You're just accepting the email and not doing anything with it. It's usually called "blackholing". It's less nice to the senders for obvious reasons.

It's been called blocking for decades, but sure, we can call it whatever you like. From my point of view, it's blocking because it blocks the emails from reaching me.

There's also a perspective of a sender, and if you return "250 Ok/Queued" from your server, you didn't block anything, regardless of what you do with the email afterwards.

> When you block an email the sender will get a notification email from their mail server that their message was blocked

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.

> 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.

Nobody will spam you except your service provider. My mail server will just return error to your service provider when it tries to send email to it over SMTP.

I agree, this is clearly worse, whether it's "your e-mail has been rejected" or "this server is not configured to accept 'reactions'", it's unnecessarily hostile to a user who probably doesn't understand that Microsoft has done something non-standard. And they will probably assume that you don't know what you're doing, because your e-mail doesn't work.

The reaction sender's Exchange server would see it and could decide to not display the rejection to the user, since the Exchange server knows it's "just" a reaction that was rejected.

If a person has something substantive to say to me they can put out the effort to type at least one human written full sentence in reply, either via a message platform like slack, signal, or replying to the email.

I just tested with an Exchange domain and nope, the reaction email has only standard headers and a bunch of x-ms- headers that are the same as for a regular email from that domain. In particular, it has an `x-ms-publictraffictype: Email` header that regular emails also have, and the envelope content-type and inner content-types are also identical (`multipart/alternative` and `text/plain; charset="us-ascii"` / `text/html; charset="us-ascii"` respectively).

That would be a pretty suboptimal user experience for both parties, don't you think?

Depends on what you're optimizing for, how big of a problem not knowing whether someone read your email is to you specifically, and for what kinds of emails/senders this happens.