Does this addon work with encrypted mails?

[real-yfprojects]

I (sometimes) use Thunderbirds build-in mail encryption via OpenPGP. I noticed that an email was shown as modified although encrypted an signed using OpenPGP. Does this add-on work with Thunderbird build-in encryption feature?

[lieser]

I'm not that familiar with the OpenPGP standard and Thunderbird's build-in encryption feature, but as long the mail stays saved in the original encrypted state, it should not affect any DKIM signature.
The addon should only see the raw encrypted (and DKIM signed) mail, and therefore work together Thunderbird's build-in encryption feature. But I did not yet test it myself if it works.

I would guess that the OpenPGP format for encrypted mail is pretty robust to most common changes done by mail servers, like e.g. breaking long lines by adding additional new lines.

DKIM has two canonicalization modes for signing of the body:

• simple, which only strips empty lines at the end of the mail
• relaxed, which also strips white space at the end of lines, and reduces all sequences of white space to a single space

But in both cases, adding e.g. an additional new line in the middle would already break the DKIM signature.

So although this addon (and DKIM in general) should be compatible with OpenPGP, I expect the outer format of OpenPGP messages to be more robust against changes than DKIM signed messages.

[lieser]

It is clear that the signed data itself can not be changed without breaking the OpenPGP signature. But details matter here: what exactly is signed?

1. Not the complete e-mail body is signed. E.g. changing the MIME boundary for the encrypted attachment should not break the OpenPGP signature. Because OpenPGP only signs the inner encrypted message, not the complete outer e-mail that contains the encrypted message.
2. The encrypted (and signed) data is not attached directly as a raw binary. It is encoded in a certain way (https://datatracker.ietf.org/doc/html/rfc4880#section-6). Part of the decoding is that white space is ignored (https://datatracker.ietf.org/doc/html/rfc4880#section-6.4). Meaning one can add spaces and newlines into the encoded data, whiteout changing the encrypted and signed data. And therefore also not breaking the signature

But both the above would break a DKIM signature, because:

1. It is signing the complete e-mail body
2. Allows fewer white space changes than the encoding used for the OpenPGP attachment.

[real-yfprojects]

I don't know why anyone would modify white space in the body or the mime-boundary but I see how my case is technically possible.

[lieser]

A long line being wrapped after signing by an added new line (and therefor breaking the DKIM signature) is something I already did encounter in practice.
And I don't remember any change about the mime-boundary, but changes to the Content-Type of a MIME part is also something I already did encounter (done by outlook).

To test if this is a problem of the addon, or to see what changed in the email:

1. Use another local verifier, e.g. dkimverify from dkimpy
   • If you do not know how to do that, you can also send me the eml file via mail to check it
2. Ask the sender to send a mail to you and another provider that is not know to change mails (e.g. GMail). Note that it should really be a single mail with multiple recipients, not just the same content in two similar mails. Then save both received mails as a eml file, and compare them (best with a diff tool).
   An alternative is to compare the send with the received email, but that is not as reliable, as changes could be already done by the sending server.

Unless you find the issue I will also try to find some time testing it with OpenPGP myself, to make sure it is not a general issue.

[lieser]

I now did also a small test with Thunderbird's build in OpenPGP myself, and the DKIM signature of an encrypted and signed message verified without problems for me.

[real-yfprojects]

Thank you. I didn't find the time to test that myself.

That means that the email was indeed modified in some (not so relevant) way.