Page MenuHome GnuPG

GpgOL: Add handling for content type message/rfc822
Closed, ResolvedPublic

Description

GpgOL only supports a subset of the various Mail RFCs. There is currently no special handling for the message content type and its rfc822 subtype. None of the message types defined in RFC2046 are supported. Forwarding a mail in outlook results in a binary attachment containing the MAPI data and is displayed as an attachment. Third party messages with the content type message/rfc822 but no filename / name or Content-Disposition header are ignored. While Outlook itself converts such encapsulated messages to MAPI and displays them like a file attachment with the subject and the size as the filename.

Since GpgOL can't display any embedded signature or encryption status and there is no UI to display an encapsulated mail our implementation can only do it the same way. The parser needs to be extended for that case to split out the embedded part into either a file attachment with the type EML, containing the MIME strutcture, or into a .msg binary Attachment containing the mail as a MAPI IMessage object. The latter approach seems to me the most sensible since otherwise a signed mail with an encapsulated mail would behave differently then an unsigned mail and we try to avoid that, if possible.

Event Timeline

aheinecke created this task.
aheinecke changed the task status from Open to Testing.EditedFri, Aug 23, 1:25 PM
aheinecke removed aheinecke as the assignee of this task.

I tested all scenarios I could think of with multiple embedded mails and mails which had themself embedded mails. signed, unsigned, s/mime and openpgp.

My recommendation would be to include this change together with the other changes from today even in a minor release since any changes are behind:

else if (ctx->nesting_level >= 1 &&
         !strcmp (ctmain, "message") &&
         !strcmp (ctsub, "rfc822"))
  {
    /* This is an encapsulated / attached MIME message which
       we need to treat as a blob to avoid confusing the current
       mimeparser state. */
    ctx->in_encapsulated_msg = 1;
  }

And so only take effect at all if there is a nested message/rfc822 in the mail. And yes ctmain and ctsub are gurarnteed not to be null there.

werner mentioned this in Unknown Object (Maniphest Task).Wed, Aug 28, 11:51 AM
ebo added a project: vsd32 (vsd-3.2.3).
ebo moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
ebo added a subscriber: ebo.

For an additional quick test I forwarded a signed+encrypted mail from KMail as attachment, the mail containing the attachment was a) signed only, b) signed+encrypted.

Both were shown as "mailsubject.eml" attachments which could be opened and decrypted via Kleopatra.

Tested with VS-Desktop-3.2.93.8-Beta