The problem with GPG signatures

For several months now, a blurb appended to almost all my outgoing email messages has asked recipients not to send me GPG signed messages without also GPG encrypting them. In place of explanation, I have been appending a link to Dr. Bernstein's site about the 8BITMIME extension to the SMTP protocol and how strict compliance with the RFC document about 8BITMIME does more harm than good on the internet as it is today.

The problem Bernstein describes is similar but not the same as the one I had. I knew that when I created the blurb but I thought Dr. Bernstein's well known name and authority, attached to the description of a situation where Mail Transfer Agents may (in full compliance with the RFC) modify messages in transit, would suffice to persuade people that unencrypted messages are fragile and so signing them makes little sense. But now, after at least one person (and perhaps more, I don't remember) responded with puzzlement, I think I was wrong. I'll have to provide the exact gory details of my own problem.

Even though I run my own email server, all my incoming messages pass through another gateway server on their way to me. I do this, among other reasons, because I am afraid to accept direct SMTP connections from any source, in particular I am afraid of being presented with a huge bill if my bandwidth usage goes through the roof. But on the gateway server I have just a regular shell account, without root access; on top of that, some configuration files on the gateway server are not even readable by regular users. I thus lack ability to fix problems with the gateway or even to adapt my own configuration on the gateway to work around problems.

So, in particular the gateway server seems to like rewriting message MIME parts which are encoded in the quoted-printable format. Here is a typical pair of examples. This is a piece of quote-printable text copied verbatim from a mailing list archive:

OK, I lied.  All of the signatures were good except for two messages
=66rom Jean-Christophe: =20

But the same message as I received it from the list looks like this:

OK, I lied.  All of the signatures were good except for two messages
from Jean-Christophe:=20=20

As you can see, the gateway replaced the encoded form =66 of the letter f with a literal f; and strangely, conversely it replaced one (but not all) of the horizontal space character occurences with the encoded form, =20. Through numerous time-consuming tests I made sure it was indeed the gateway and not my own server or my Mail User Agent where these transformations happened. Here is a second example -- archive version:

Mutt 1.6.2 (2016-07-01)
=2E..
System: Linux 4.7.2-hardened-r1-160906 (x86_64)
ncurses: ncurses 6.0.20150808 (compiled with 6.0)
libidn: 1.33 (compiled with 1.32)
=2E..
Compiler:

My version:

Mutt 1.6.2 (2016-07-01)
...
System: Linux 4.7.2-hardened-r1-160906 (x86_64)
ncurses: ncurses 6.0.20150808 (compiled with 6.0)
libidn: 1.33 (compiled with 1.32)
...
Compiler:

Here the gateway unencoded the leading periods from their encoded form =2E.

These changes by the gateway are completely harmless with plain text messages. Indeed, reading the MIME RFC you can convince yourself that the decoded text, displayed in the Mail User Agent, will be exactly the same with or without the changes. But the situation is very different with PGP/GPG signed messages. The OpenPGP RFC specifies that signatures are computed over the encoded form of the subject text. (I think that was a unfortunate decision, by the way, but I can at least understand the reasons people cite.) So, if the encoded form changes in transit, the signature you generated from the message as it existed on your system before sending will no longer be valid, and my Mail User Agent will scream at me.

The gateway seems to be more careful with base64-encoded parts which is normally how encrypted messages are transmitted, and that is the reason for my request, now with full explanation available here. I dare to assume that if you already make the effort to sign your messages and are familiar enough with PGP/GPG to do that, encrypting will not add any extra burden to sending your messages. I'm looking forward to them :-)

Oh and By The Way, my GPG key ID is 360A88B2984A8AE4.

Comments !

You can send comments on this post by email. Click here to start composing a comment.