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

[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": "[email protected]",
        ":name": "Me"
      }
    ],
    ":message-id": "[email protected]",
    ":priority": "normal",
    ":subject": "enveloped-data",
    ":to": [
      {
        ":email": "[email protected]",
        ":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": "[email protected]",
        ":name": "Me"
      }
    ],
    ":message-id": "[email protected]",
    ":priority": "normal",
    ":subject": "enveloped-data",
    ":to": [
      {
        ":email": "[email protected]",
        ":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": "[email protected]",
        ":name": "Me"
      }
    ],
    ":message-id": "[email protected]",
    ":priority": "normal",
    ":subject": "enveloped-data",
    ":to": [
      {
        ":email": "[email protected]",
        ":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.