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

[Bernie Hoeneisen <[e-mail]>]

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