6 ms·

The reaction email doesn't have some specific header that can be used to block it?

by megous 2y ago

ppbjj 2y ago
That would be a pretty suboptimal user experience for both parties, don't you think?
- megous 2y ago
  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.
projektfu 2y ago
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.
- AlexandrB 2y ago
  The distance between "didn't care to respond" and a thumbs up emoji response is measured in angstroms.
  - SketchySeaBeast 2y ago
    With a thumbs-up I know they've read it, and that's worth quiet a bit in this asynchronous communication world of ours.
    - ryandrake 2y ago
      We used to (and I believe still) have Read Receipts for this.
      - xboxnolifes 2y ago
        read receipts just mean you opened the message, not that you actually read it. It's a terrible misnomer.
      - m3047 2y ago
        Yes! +1 And it's possible to disable Read Receipts and a lot of people do. A lot of people mangle beacon pixels too.
      - xenophonf 2y ago
        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.
      - toyg 2y ago
        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.
      - projektfu 2y ago
        That was another groupware feature that was great for small orgs and terrible for the general net.
  - projektfu 2y ago
    I suppose it'd be OK if the other side of your TCP connections stopped sending ACKs.
    - megous 2y ago
      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.
      - JumpCrisscross 2y ago
        > 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.
        m3047 2y ago
        Be sure to CC everybody. /s No. The technology isn't built for this.
        projektfu 2y ago
        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.
        m3047 2y ago
        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.
  - HelloMcFly 2y ago
    The distance between "not detectable" and "detectable" is vast and significant, no matter how minute the unit of measurement.
- megous 2y ago
  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.
  - JumpCrisscross 2y ago
    > 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.
    - m3047 2y ago
      > 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.
    - megous 2y ago
      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.
    - projektfu 2y ago
      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.
- walrus01 2y ago
  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.
Arnavion 2y ago
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).

The reaction email doesn't have some specific header that can be used to block it?

by megous 2y ago

The reaction email doesn't have some specific header that can be used to block it?

ppbjj 2y ago

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

megous 2y ago
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.

projektfu 2y ago

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.

AlexandrB 2y ago
The distance between "didn't care to respond" and a thumbs up emoji response is measured in angstroms.
- SketchySeaBeast 2y ago
  With a thumbs-up I know they've read it, and that's worth quiet a bit in this asynchronous communication world of ours.
  - ryandrake 2y ago
    We used to (and I believe still) have Read Receipts for this.
    - xboxnolifes 2y ago
      read receipts just mean you opened the message, not that you actually read it. It's a terrible misnomer.
    - m3047 2y ago
      Yes! +1 And it's possible to disable Read Receipts and a lot of people do. A lot of people mangle beacon pixels too.
    - xenophonf 2y ago
      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.
    - toyg 2y ago
      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.
    - projektfu 2y ago
      That was another groupware feature that was great for small orgs and terrible for the general net.
- projektfu 2y ago
  I suppose it'd be OK if the other side of your TCP connections stopped sending ACKs.
  - megous 2y ago
    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.
    - JumpCrisscross 2y ago
      > 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.
      - m3047 2y ago
        Be sure to CC everybody. /s No. The technology isn't built for this.
        projektfu 2y ago
        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.
        m3047 2y ago
        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.
- HelloMcFly 2y ago
  The distance between "not detectable" and "detectable" is vast and significant, no matter how minute the unit of measurement.
megous 2y ago
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.
- JumpCrisscross 2y ago
  > 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.
  - m3047 2y ago
    > 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.
  - megous 2y ago
    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.
  - projektfu 2y ago
    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.
walrus01 2y ago
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.

Arnavion 2y ago

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