Enigmail handle protected headers (specifically: subject) only when the protected payload has non-standard protected-headers="v1" attribute. Please note the draft standard[1] requires setting protected-headers="v1" only for legacy display part. And similarly, require MUA to look for protected-header="v1" attribute when looking for legacy display part, not the modern one.
This means when a compliant mail client sent an email with (modern) protected header (without this attribute), Enigmail will display the subject as "..." (the envelope subject value). This is very unfriendly to the user.
While adding the attribute to outgoing messages is harmless (in this case), requiring it in incoming cause compatibility issues.
[1] https://datatracker.ietf.org/doc/draft-autocrypt-lamps-protected-headers/?include_text=1, linked from https://github.com/autocrypt/protected-headers
One example of a MUA like this is mutt.
All fine, but the draft is much younger than the implementation in Enigmail. The implementation in Enigmail does not follow that specification in many ways.
See draft version 2 - the "protected-headers" attribute has been added again. I think it was omitted by mistake.
I see. Anyway IMO it would be good to pursue compliance to the specification. Or at least try to be compatible with other MUAs doing so.
Reading the new revision, protected-headers is mandatory (again), but the legacy-display part may be text/plain. I changed the implementation in Enigmail such that it handles the legacy part properly. But Enigmail will still ignore protected headers that don't have the protected-headers="v1" attribute.
It seems that since this fixEnigmail is unable to handle the protected subject from K-9. It works the other way round. At least on my machine it worked before v2.1.5.
At a first look the the message source seems to be valid, but I have no idea of email encoding honestly. At least the
protected-headersheader "argument" is there within the encrypted part:I don't know if this is a flaw of K-9 or Enigmail. I post it here because behaviour changed with the latest Enigmail version.
I will send a PM to you, Parick Brunschwig, so that you are able to have a look at the full email content.
Regards,
doak
Last edit: doak 2020-01-06
First, this is not a fix, but a real change in functionality.
It's true indeed, if the message is a simple text/plain message, then subject decoding does not work. But I wonder why this wasn't visible before this change (or actually, if it did work, then that was a bug).
In any case I fixed this for the next release.
@pbrunschwig, finally there is a bug fix ... ;)
Thanks a lot for the fast response (and commit)!