[mu bug] mu should return the encrypted flag for S/MIME enveloped-data

[Cerebus]

Describe the bug

mu does not recognize S/MIME enveloped messages (Content-Type: application/pkcs7-mime; smime-type=enveloped-data) and does not return the encrypted flag for these messages.

How to Reproduce

1. Receive an encrypted S/MIME message as the whole message (i.e., not multipart/encrypted).
2. Index the message.
3. Retrieve the message flags from mu.

Best practice with S/MIME encryption is to envelope the signature (sign first, then encrypt), which is what message-mode and Outlook does. Basically, the message is sent as enveloped-data, which contains a multipart-signed MIME message (or a plain signed message, depending on the sending MUA configuration [e.g., "opaque signing" on Outlook]). To do otherwise implies a binding between the signing key and the encryption key which is not always true.

See attached sample raw message (all Received & associated stuff removed).

msg.txt

I don't expect mu to decrypt and index content with gpgsm (though it would be nice). Flagging as encrypted is necessary for mu4e-compose-crypto-policy to take effect. When the flag is manually set via mu4e--server-move with "+x", the compose policy works with S/MIME as expected. This is not a viable workaround b/c these flags do not persist when the message is moved between mailboxes, or between mu4e sessions.

Environment
macOS 14.6
Emacs 29.4
mu 1.12.6

Checklist

• you are running either the latest 1.10.x/1.12.x release or master (otherwise, please upgrade).

Thank you!

[Cerebus]

For reference, see the following.

• RFC 8551 Sec 3.2.2 for the type definitions.
• Sec 3.3 for enveloped-only message structure.
• Sec 3.5 for signed-only message structure.

Of the remaining types,certs-only can be safely ignored; you see these as files for moving certs and trust anchors around but rarely as a thing that the MUA needs to parse. As for compressed-data and authEnveloped-data, I can't say I've ever seen these in the wild.

S/MIME has never included multipart/encrypted from RFC 1847 because it allows for separate signer and encryptor -- remember that the enveloped object need not reference the sender in any way (IOW, you can send a message that you cannot read -- see mml-secure-*-encrypt-to-self). When used in this way, the MUA will display the "signed by" and the user will assume that also means "encrypted by", which it does not. In addition, the signature does not have to cover all the MIME parts, so an attacker can modify a message to attach an encrypted object to a multipart/signed message and get the semantic benefits of signing without breaking the signature.

Yes, it's still there in RFC 3156 but it's been forever since anyone updated that spec.

Also note that clear-signed (multipart/signed) and opaque-signed (application/pkcs7-mime; smime-type: signed-data) message formatting is up to the sender, so mu should return signed for both of these. I know it currently marks multipart/signed correctly but I don't know about opaque-signed and I don't currently have an MUA configured to send such.

[Cerebus]

Was poking deeper and while I'm not a C++ guy it seems like it should be working, but I suspect that mime tree isn't traversed for encrypted data unless the top message is multipart.

For a more complete example,
enveloped.txt is the raw message.

And here's the JSON from mu find subject:enveloped-data -o json:

[
  {
    ":path": "/Users/me/Maildir/Sent/cur/1724094095.6b17f735acef1e50.host-pc,U=676:2,S",
    ":size": 1091,
    ":changed": [
      26307,
      38608,
      0
    ],
    ":date": [
      26307,
      38566,
      0
    ],
    ":from": [
      {
        ":email": "me@privacy.net",
        ":name": "Me"
      }
    ],
    ":message-id": "m21q2kqqu1.fsf@privacy.net",
    ":priority": "normal",
    ":subject": "enveloped-data",
    ":to": [
      {
        ":email": "me@privacy.net",
        ":name": "Me"
      }
    ],
    ":maildir": "/Sent",
    ":flags": [
      "seen",
      "attach",
      "personal"
    ]
  },
  {
    ":path": "/Users/me/Maildir/INBOX/new/1724094226.79327_1.HOST-PC,U=832:2,",
    ":size": 7710,
    ":changed": [
      26307,
      38674,
      0
    ],
    ":date": [
      26307,
      38566,
      0
    ],
    ":from": [
      {
        ":email": "me@privacy.net",
        ":name": "Me"
      }
    ],
    ":message-id": "m21q2kqqu1.fsf@privacy.net",
    ":priority": "normal",
    ":subject": "enveloped-data",
    ":to": [
      {
        ":email": "me@privacy.net",
        ":name": "Me"
      }
    ],
    ":maildir": "/INBOX",
    ":flags": {
      "new": "attach",
      "unread": "personal"
    }
  }
]

The encrypted flag is not set. I have a ton of mail that should be returning, and only the test messages I've sent with PGP-MIME are so flagged, which is a multipart message at the top level.

[Cerebus]

FWIW, noticed above that :flags is a bit different for new items, so here's the json after it's seen.

 {
    ":path": "/Users/me/Maildir/INBOX/cur/1724094226.79327_1.HOST-PC,U=832:2,S",
    ":size": 7710,
    ":changed": [
      26307,
      39302,
      0
    ],
    ":date": [
      26307,
      38566,
      0
    ],
    ":from": [
      {
        ":email": "me@privacy.net",
        ":name": "Me"
      }
    ],
    ":message-id": "m21q2kqqu1.fsf@privacy.net",
    ":priority": "normal",
    ":subject": "enveloped-data",
    ":to": [
      {
        ":email": "me@privacy.net",
        ":name": "Me"
      }
    ],
    ":maildir": "/INBOX",
    ":flags": [
      "seen",
      "attach",
      "personal"
    ]
  }

[djcb]

Yeah, the smime part on the top-level wasn't checked. I'll push as fix. Thanks for the details.