SMimeP7M/parse

[chibenwa]

Why?

Some smime messages consists of a p7m attachment that encapsulate the mime structure and their display is suboptimal in the webmail

We wishes to offer essentials for nicer display in the wemails

IE when opening the mail a display similar to the one of thunderbird:

What

Offer a SMimeP7M/parse JMAP route that would allow parsing those messages and expose them as EmailBodyStructure

Note that we also need to handle download of such body parts.

{
  "using": [
    "urn:ietf:params:jmap:core",
    "urn:ietf:params:jmap:mail",
    ""],
  "methodCalls": [[
    "SMimeP7M/parse",
    {
      "accountId": "29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
      "blobIds": [ "p7mPartId" ],
      "fetchTextBodyValues": true,
      "fetchHTMLBodyValues": true,
      "bodyProperties":["partId", "blobId", "size", "name", "type", "charset", "disposition", "cid"]
    },
    "c1"]]
}

Would return:

{
    "sessionState": "${SESSION_STATE.serialize}",
    "methodResponses": [
        [
            "Email/parse",
            {
                "accountId": "29883977c13473ae7cb7678ef767cbfbaffc8a44a6e463d971d23a65c1dc4af6",
                "parsed": {
                    "${messageId.serialize()}_3": {
    "htmlBody": [{
        "charset": "UTF-8",
        "size": 47,
        "partId": "2",
        "blobId": "smimep7m_${messageId.serialize()}?1_1",
        "type": "text/plain"
    }],
                        "bodyValues": {
                            "2": {
                                "value": "test body\\r\\n",
                                "isEncodingProblem": false,
                                "isTruncated": false
                            }
                        },
                        "attachments": [
                            {
                                "partId": "3",
                                "blobId": "smimep7m_${messageId.serialize()}?1_2",
                                "size": 16,
                                "name": "whatever.txt",
                                "type": "text/plain",
                                "charset": "UTF-8",
                                "disposition": "attachment"
                            }
                        ],
                        "size": 797,
                        "blobId": "smimep7m_${messageId.serialize()}",
                        "messageId": [
                            "ed24d4ad-53c0-48c7-2fc9-39f762e4d98d@linagora.com"
                        ]
                    }
                }
            },
            "c1"
        ]
    ]
}

Note that body parts blobId follow the following syntax: smimep7m_{nested-blobid}?{path-to-mimepart within smime message}

So smimep7m_123456?1_2_3 means take message 123456 and interpret it as smimep7m then take the first body part of the first multipart and then the second body of the second multipart and then the trird of the most inner multipart.

Nesting a p7m in a p7m is out of scope.

Subtasks

• Specification
• Implementation

[Arsnael]

@chibenwa So as we are grooming this and team seems a bit confused, to confirm what you want here:

I have an attachment in a mail encapsulating a smime structure and with the jmap request SMimeP7M/parse we should parse and decode it, return the result that then the front would display in the message view correct?

Ok. We obviously should check as well then that the smime signature on the attachment is correct too, and return I guess an error if it's not valid instead?

[chibenwa]

Correct

But we do not need to check signature again: thats done beforehand and result is exposed in mail headers...

[chibenwa]

No no no error if invalid signature or you cannot read smime message with unknown ca for instance

Other mua like tb do not behave this way

[chibenwa]

Unscheduled as our customer also seem to use Content-Type: multipart/signed

Display on the webmail is nice enough.

It's not unlikely webmail display of Content-Type: application/pkcs7-mime; can be disregarded altogether...

I asked @guimard clarifications.