159238 - unnecessary multipart/mixed prevent S/Mime status in the UI

Status: NEW

(MailNews Core :: Security: S/MIME, defect)

Description

[Kai Engert [:KaiE:]]

A design decision in Mozilla S/Mime support is: We only display S/Mime status in
the UI to the user, if the outermost message is encrypted/signed.

Some mail user agents send messages, where the outermost message is enclosed in
an unnecessary multipart/mixed wrapper.

The standard (simple) scenario is:

(Case 1)
outermost message
-> encrypted or signed mime type

As of now, the above simple structure is required for S/Mime status to be shown
in the UI.


Other mail user agents send message like this:

(Case 2)
outermost message
-> multipart/mixed
   -> encrypted or signed mime type

When displaying such a message, we do not display S/Mime status in the UI -
although the single content in the message is signed/encrypted.

Explanation:

The multipart/mixed wrapper allows multiple subparts.
When asking around, I was told (ducarroz, glazou) the first part in
multipart/mixed should be considered as the body of the message, where
additional parts are attachments.

So, imagine a message with the same structure, but with multiple parts:
outermost message

(Case 3)
-> multipart/mixed
   -> encrypted or signed mime type
   -> attachment

In this case, the signature/encryption does only apply to the first part, but
not to the attachment. It would be wrong to display a signed/encrypted status in
the UI, because only a part of the message is a S/Mime.


So we have a dillema, because of our decision to only display the outermost
status info, and I don't know yet what we should do. As a result of our
behaviour, people see some S/Mime messages, and are surprised that no S/Mime
information is shown.


For Case 2, it would be legal to display the S/Mime status in the UI.
However, it would be necessary to do more than just look at the mime types of
the message.
We would have to count the number of parts in multipart/mixed.
We could say, a multipart/mixed with exactly one part does not introduce a new
logical nesting level. It only introduces an unnecessary physical transport layer.

A similar situation is:

(Case 2b)
outermost message
-> multipart/mixed
   -> multipart/mixed
      -> encrypted or signed mime type

Or even more levels of multipart/mixed, each with only one part.
(This all is valid MIME.)
We could decide to treat this the same as Case 2.


The first question of this bug is: Should we support Case 2 and its recursions
like Case 2b?


A different issue is the dilemma of messages as in Case 3.
Although some parts of the message are signed/encrypted, we do not inform the
user about it.

Comment 1

[Marco Matarazzo]

IMHO, the point is that we should support, if we can, what the actual user handle.

As my experience shows (but some more trials can be done), the majority of big email clients that do not do "Case 1", do "Case 2" with the sign/encrypt in the very first part of the multipart, before attachments. I never saw anything else, like "Case 2b" or worst (but again, trials can easily be done).

So, an idea would be to support a "Case 2" scenario with the sign/crypt informations in the very first part of the multipart section, and ignore others scenarios. Should we discover that the actual real life cases are two or three, we can make a step forward and support them too. But in fact, we dont need to support all the resulting possible cases, because we'll probably never see them in the wild (or we'll see them with some little REALLY unused mail clients). 

Another idea could be to conquer the world and make all the world's citizens to use Thunderbird, but that's another matter... ;-)