Subject: [dispatch] Improve UX in Encrypted Email (distinguish between forwarded and otherwise wrapped messages)

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 2 Oct 2020 17:56:35 +0200 (CEST)

Hi,

We are seeking advise from the Email community regarding the following:

In the LAMPS WG we are working on so called "Header Protection" for Emails 
to achieve better privacy. This concerns in particular (but not only) the 
Subject Header Field that is often left unencrypted in otherwise encrypted 
email.

The mechnism used for Protection of Header Fields is to wrap a whole email 
(including the Header Section) into another email and apply protection to 
the former.

At the receiving side certain Email clients do not render such 
signed/encrypted emails correctly to the user, leading to "weired 
artefacts" and thus bad User Experience (UX). Such clients do not 
distinguish between forwarded mail and signed/encrypted emails (wrapped in 
a similar way as forwarded messages).

Alexey came up with a proposal to help such email clients to make this 
distinction (with the intention to improve UX). Together with Alexey I
wrote up this proposal to an early draft version:

   https://tools.ietf.org/html/draft-melnikov-iana-reg-forwarded-00

This I-D suggests a new Content-Type Header Field Parameter "forwarded": 
If set to "yes", the contained message was forwarded; if set to "no", the 
message was "wrapped" for signature/encryption with Header Protection.

However, I am concerned that the (binary) scope of the Content-Type Header 
Field Parameter may be too narrow, as there a potentially more cases an 
email message is transported in the Body part of another email message and 
such a Parameter may be helpful, such as:

- Rejected (non deliveries / bounces)

- ML-hold (message to be assessed by a mailing list admin)

- ML-discard-action (mailing list admin reply to this will discard)

- ML-digest-item (mailing list digest item;
   digest is a collection of multiple emails)

- even more?

I am seeking advice (mainly from implemeters of MUAs) on:

1) Is it helpful/useful/needed to enhance such a Parameter for these
    additional cases?

2) Have there been problems in the past to distingish such cases
    from "forwarded" messages?

We'd appeciate your feedback (preferably within the next 10 days)!

cheers,
  Bernie

--

http://ucom.ch/
Modern Telephony Solutions and Tech Consulting for Internet Technology

---

From: "John Levine" <[email-masked]>
Date: 2 Oct 2020 13:19:42 -0400

>such a Parameter may be helpful, such as: ...

>1) Is it helpful/useful/needed to enhance such a Parameter for these

Probably not. Since a receiving system cannot trust senders to
accurately label the messages, it's hard to see what they would do
with the labels.

I looked at the draft and while I have my doubts about how useful it
will be, since there are implementations it seems at worst harmless.

R's,
John

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 02 Oct 2020 23:44:51 -0400

> message was "wrapped" for signature/encryption with Header Protection.

There's a category problem:  What you're trying to capture is "What is
the significance of this body part within the whole structure?"  It does
not describe the *type* of the contents of the body part.

I've noticed this before in SIP, the idea that if you know the *type* of
a body part, then you know its *significance*.  That works in the
simplest cases, but it's like saying that you can always tell which
parameter in a function call means what if you know their types.

What we need is a new "Content-Semantics" header for parts of multipart
bodies which describes the semantics of this part within the whole.
E.g., "contained encrypted content" or "forwarded message".

Dale

---

From: "John Levine" <[email-masked]>
Date: 3 Oct 2020 15:08:37 -0000

In article <[email-masked]>,
>E.g., "contained encrypted content" or "forwarded message".

But you still have the problem that you can't count on senders to
label their messages correctly. I can promise you that if word gets
around that mail labeled "forwarded message" has a 1% better open rate
than otherwise, all spam will have that label.

R's,
John
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Bernie Hoeneisen <[email-masked]>
Date: Tue, 13 Oct 2020 23:22:50 +0200 (CEST)

Hi John

IMHO the point you make can be made to almost any addition to the email 
standard: It may be misused by the evil side.

I fail to grasp what benefit a spamer could gain by specifying whether 
an encapsulated message is a forwarded or a wrapped message.
Marking an encapsulate messaged as "forwarded" makes it even less 
likely that the user gets the content to see.
Explicitely marking an encapsulated message as "not-forwarded" does not 
make any sense, as one may as well just not encapsulate the message. There 
is no difference on whether or not it is displayed to the user.

Have I missed anything?

cheers,
  Bernie

--

http://ucom.ch/

On Sat, 3 Oct 2020, John Levine wrote:

> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Bernie Hoeneisen <[email-masked]>
Date: Tue, 13 Oct 2020 23:56:27 +0200 (CEST)

Hi Dale

> E.g., "contained encrypted content" or "forwarded message".

No sure how exactely you suggest to apply such a header. The use case 
also includes situations that are not multipart, such as
Content-Type: message/RFC822.

In the following example, the upper part with Content-Type: message/rfc822 
is an "outer" message containing a forwarded message with Content-Type: 
text/plain (lower part). The suggestion in the I-D would look as follows:

   [...]
   Content-Type: message/rfc822; forwarded=yes

   Content-Type: text/plain; charset="us-ascii"
   [...]

Can you please clarify whether your suggestion would be to use:

   [...]
   Content-Type: message/rfc822
   Content-Semantics: forwarded

   Content-Type: text/plain; charset="us-ascii"
   [...]

or:

   [...]
   Content-Type: message/rfc822

   Content-Type: text/plain; charset="us-ascii"
   Content-Semantics: forwarded
   [...]

?

cheers,
  Bernie