Protected headers can not be disabled in signed mails

Commit c4e6454007ebeb57cfcc55 did not introduce any regression, i.e. the way it works today is as I intended. But I certainly do see your need to disable protected headers for signed mails.

I think it may be a good idea to keep the protected headers but to not display a warning for the headers being changed.

Unlike a changed body, changed headers can be 100% restored by the memory hole (redundancy). Just fix the headers displayed by Thunderbird without telling the user that some list-serve reformatted ed the subject line or reference number.

But keep a notification for a bad signature on the body content. The original body cannot be regained and you need to know if it has been altered, because an altered body is a sign of malicious action. Quoted-printable and Base64 content are immune to normal mail server modifications. Body changes are therefore important and you need a warning.

Maybe I am confused. Is Thomas Huth talking about mail servers changing the contents of the Memory Hole headers written in plain ASCII (with or without Unicode written in tagged segments). Are there are any MUA, MTA or mailing lists or forwarding services which meddle with the contents of the memory hole itself? If so, I had no idea.

Is there are any way to have a backwards-compatible protection of the memory hole headers by writing them in base64?

Actually, I just thought of a solution.

Why not rewrite the Subject Title entirely in Unicode?

Make the whole thing =?UTF-8?B?........?= or =?UTF-8?Q?........?= and use Base64 or Quoted-Printable always. (Right now, the subject line is 7-bit ASCII, if a non-ASCII character is included, it is Quoted Printable or Base64, but using these seems to cause no issues.

I tried writing a Subject line manually this way on a normal e-mail and everyone plays nicely with it, even webmail interfaces.

I just had a look at some of my mails again that got corrupted by mailman, and it seems that mailman actually removes the "Content-Type: multipart/mixed; boundary=..." line from within the protected header! So it's not as simple as encoding the Subject line in unicode :-(

Wow....

Maybe PGP/MIME is just never going to work in certain contexts.

If mailman is removing MIME layers and contents, it or any other service could strip out signatures, section breaks or attachments.

PGP/Inline ideally has format=flowed off (as well as line wrap disabled), because even the Enigmail and PGP clean up of > and trailing whitespace isn't fool-proof.
which is good because mail programs sometimes mess up contents.

However, I did notice that very long lines (~1000+) get turned to Base64, because e-mail can never have long lines. Everyone converts it to Base64 if there is no line wrap. Line wrap also does not apply to scripts like Han Characters (Chinese), so the Base64 convention has been necessary and in use for decades.

Maybe in your case you should use PGP/Inline.

Manually re-write the headers at the beginning of the message body and cleartext sign the message.

Thunderbird and Enigmail do not have some easy-access toggle to force Base64. Maybe you could copy-paste a long line of Chinese at the end of your message in order to trigger the Base64 conversion. Maybe have a text file on your desktop of a 333x repeating 日 character (each one is 3 octets and will trigger 1000 octet line -> full Base64 conversion).

The downsides include your recipients having to glance at the headers and your message body headrs for a match and an extraneous line of Chinese.

Removing the memory hole may work, too, but what is stopping mailman from removing other things? It just seems that plain-text MIME parts are subject to excision and would ruin the signature.

On a pessimistic note, maybe unencrypted PGP mail is never going to work just right. Maybe unencrypted PGP signing will be good for cleartext in text files,word documents and message board posts (we know reddit has been caught doctoring messages, not just editting them,so there is use for this) and good for detached signatures for files. (Either all file attachments go through or none do usually). Unencrypted signing may not work with forwarding services or certain list-serves without my workaround (Inline, f=f off, with long line if Chinese added to force whole message body to Base64).

It sounds like folks are identifying problems with specific mailing list software, and then reporting those problems here on enigmail.

While i appreciate that enigmail may need to grow some special abilities to work around broken mailing lists (or learn to "rewrite" some common manglings heuristically like it does for MS Exchange), i think the most helpful thing would be to get those mailing list managers fixed.

can you link to the bug report for mailman? which versions of mailman have that bug fixed? is there a specific fix needed? maybe we can help the ecosystem by getting that fix backported and corrected.

I agree that mailman should be theoretically be fixed first, but sometimes it is very unlikely that you can hunt down each and every server admin who runs a mailing list out there and force him to install a new version of the software. So it would be very good to have a way in enigmail to either manually temporarily disable the protected headers in signed mails, or e.g. have a way of black-listing certain e-mail addresses for this feature (so you could specify the "bad" mailing lists in that black list and enigmail would not use the protected headers in that case).
I currently worked-around the problem by commenting out "this.writeSecureHeaders()" in mimeEncrypt.js ... but that's of course just a very, very ugly hack. It would be really great to have an official, upstream way to disable this.

I didn't say mailman should "be fixed first" -- i asked the bug reporters to point to the bug reports for the other software.

I know it's hard to get fixes deployed, but it's impossible to get fixes deployed if they aren't written :)

Fixed as far as possible (actually quite a while ago):
1. the "References" field is not longer removed from messages. There is a preference that allows to enable removal of the "References" field.
2. there is a toobar button (hidden by default) that allows to enable/disable Protected Headers for each message