[ietf-822] Comment on experimental RFC9078

[Karl Ewald <[e-mail]>]

Dear recipient entities,

I was recently made aware of the fact that Microsoft introduced a 
feature similar to the one described in RFC9078 in their Outlook 
product. Source e.g. 
https://techcommunity.microsoft.com/t5/outlook-blog/reactions-in-outlook-public-usability-update-september-2023/ba-p/3928103

The blog post 
https://neilzone.co.uk/2024/07/attempting-to-stop-microsoft-users-sending-reactions-to-email-from-me-by-adding-a-postfix-header/ 
shows that users of MUA not equipped to deal with this "lightweight" 
type of response can easily be annoyed by its casual use "against" them.

(Note that in my opinion, talking about "MUA" is a simplification and 
falls short of the architectural scope of implementing reactions 
usefully. All of MUA and Mail Store and rMDA are likely to play a role 
in handling this type of interaction. That is outside the scope of this 
RFC but something to be aware of. In an open system e.g. based on IMAP, 
implementation details will have to be defined to ensure consistent 
handling, and the recording of reactions with the related mail message, 
e.g. by manipulating the header of a stored message may need to be 
standardized. That's why I will sometimes refer to "mail system" more 
generally below.)

I think for experimental RFC9078 which I read on 
https://datatracker.ietf.org/doc/html/rfc9078 , the following 
conclusions can be inferred from that:

* even users with a capable MUA should have the option to opt out of 
receiving reactions;

* for users with a non-capable MUA, sending reactions to them at all 
seems questionable, but if sent, their presentation should be 
user-friendly and they should be able to opt out.

To address the first issue, I suggest a new header, e.g. (for now) 
X-Reaction-Permitted: true / false

The presence of this header in a mail indicates that its sender mail 
system is capable of handling reactions, or at least aware of this 
mechanism. The content indicates the user's choice.

I would expect that the system would default to the setting "true", but 
allow the individual user to opt out from this service if they do not 
desire this type of interaction.

The absence of this header indicates that the sender's mail system is 
likely not capable of handling reactions, resulting in a more 
heavy-weight presentation of them that may be undesired. A MUA 
supporting reactions should either not offer responding with a reaction 
at all unless it finds this header, or warn the user to use this feature 
cautiously, as the recipient may find it inconvenient.

Still, users without capable MUA who want to ensure that they do not 
receive reactions, can add this header with false in their outgoing mails.


Now, how could a reaction be presented usefully to a non-capable MUA?

I assume the choice to model reactions with the Content-Disposition 
header, instead of creating a new Content-Type, was made so that MUA not 
aware of it would display such mails normally. However, just sending a 
single emoji as the sole content of the body may be considered rude or 
impolite. The In-Reply-to Id is not meant for human consumption, all the 
recipient would have is the Subject header, assuming it was created like 
a normal reply - but the same Subject repeats along a thread, and it may 
be crucial to understand which mail of the thread the reaction refers to 
(consider "let's meet Monday" - "oops, let's make it Tuesday instead" - 
which one does the thumbs-up refer to?). Some MUA may display messages 
in a threaded way, based on the In-Reply-To chain, but we must not rely 
on that.

If a reaction were identified by a Content-Type rather than a 
Content-Disposition, it could be wrapped in a multipart/alternative like 
this:

Content-Type: multipart/alternative
   Content-Type: text/plain; charset=utf-8
   body: <emoji> was the reaction of <sending user> to your message from 
<date&time>
<multipart divider>
   Content-Type: text/reaction; charset=utf-8
   body: <emoji>
<multipart terminator>

This makes it likely that together with the "Subject" header, the 
text/plain version offers a suitable way of identifying the message that 
is subject to the reaction. Quoting the original message would entirely 
defeat the lightweight character of a reaction.

A capable MUA would see the text/reaction part and clear this whole 
multipart section from the message, as described for the 
Content-Disposition handling in the current experimental RFC.

Alternatively, and probably simpler as well as in line with the current 
experimental RFC, the Subject header could be enriched instead: e.g.

Subject: <emoji> to <original subject> from <date&time>

where <emoji> is formatted as an encoded-word utf-8?B (rfc2047). This 
echoes the old practice to embed one-liners in the subject field and not 
provide any text in the body (repeating the emoji in the body is not 
harmful).

I hope you find these comments useful.

Kind regards

Karl Ewald