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

Dear LAMPS list

Please be informed that I just sent the follwing Email to the IETF 
DISPATCH list to address a wider Email community with a matter that is 
also relevant to the Header Protection discussion in LAMPS.

  https://mailarchive.ietf.org/arch/msg/dispatch/GeaPjbvCllw5Gg1MhRlpqAfHwuU/

This discussion is expected to happen on the DISPATCH Mailing list and you 
are invited to share your experience there.

cheers,
  Bernie

PS: I am almost certain Jim Schaad has some relevant experience on this to 
share with us.

---------- Forwarded message ----------
Date: Fri, 2 Oct 2020 17:56:35
From: Bernie Hoeneisen <bernie@ietf.hoeneisen.ch>
To: IETF DISPATCH list <dispatch@ietf.org>
Subject: [dispatch] Improve UX in Encrypted Email (distinguish between forwarded
      and otherwise wrapped messages)

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

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch