Thunderbird's hints and history for OpenPGP/MIME (new wiki page)

[Binarus]

On 03.12.2021 12:04, Bernhard Reiter wrote:
> First I wanted to gather some feedback, especially about the following
> section, where I've added a recommendation what to use instead
> of incompatible header encryption:
> 
> 
> | Transport information in a decentral network - just like the writing on the
> | outside of a postal mail envelope - cannot be protected in principle.
> | When reflecting on this, chose  a subject that is plausible in context,
> | but without sensitive contents, to best veil potential unwanted observers.
> | (Your thinking is right: The more sensitive this is, the more you have
> | to build up a plausible context for your unavoidable traces first.)

I didn't read the wiki page yet, but I'd like to comment on that paragraph. I agree in part, but not completely. The idea is nice, but can't be realized in practice.

 From my personal experience, it is very hard and consumes time to find appropriate subject lines. After all, when using OpenPGP in business, recipients invest 5 seconds per message at maximum when scanning the list of received messages to decide what message to read first. "Wrong" subject lines are not helpful in this context. That means that your suggestion may be valid for private communication, but not for business.

Rather, it is often good style and really simplifies things if some important (sensitive) data is in the subject line. As an example, imagine that you are communicating with your health insurance company. The staff there usually is very grateful if they see your insurance number in the subject line, plus a few keywords (in German, for example, "Kündigung", "Leistungsantrag" etc.). Not following this convention costs them time and effort and is bad style.

Apart from that, you'll have some trouble yourself with that strategy. Imagine you have to find a message you have sent two years ago. That could be hard if you have "faked" the subject lines. Furthermore, the recipient will hopefully answer your message one day, and will typically do this by just hitting the "Reply" button. That means the answer comes back with the same "fake" subject line you originally had chosen, and that game will continue until the communication on this subject has ceased. In the end, you have 50 sent messages and 50 received messages with a "wrong" subject line.

Your comparison with snail mail is the right way to understand the issue: Did you ever receive a letter from your health insurance which carried the actual subject on the *outside* of the *envelope* (example subject of a letter from your health insurance: "Payment for your HIV treatment")? I didn't, and I'll have a very serious talk with the sender if I ever do.

*Every* piece of data should be protected, especially in electronic communication, except the transportation data which technically is absolutely necessary to get the transport done. In the same way the postal service does not need to know the content of a letter (including the subject) to transport it from the sender to the recipient, SMTP servers do not need to know the subject to transport messages.

SMTP basically needs only the sender address (strictly looking at it, not even that, but it is important for bounces and replies) and the recipient address. Sad to say that SMTP servers usually dynamically add headers during transport which already can put somebody at risk, but I guess we'll have to live with that for the moment.

A subject line really does not fall into the category of transportation data. SMTP servers don't need to know it to transport the message, and it can (and in most cases, will) contain sensitive data. We shouldn't call something transportation data solely because it is in a header.

I am very grateful that we can finally encrypt the subject line with most OpenPGP implementations since several years. Actually, not being able to do this kept me from using PGP (in E-Mail) for a while. Now I always encrypt the subject line, and so do my communication partners. If there are MUAs out there which can't cope with that, refraining from encrypting the subject would be the wrong reaction. Instead, people using such a MUA should be educated to use another MUA. PGP implementations have undergone changes which were much more "breaking" than encrypted subject lines.

Best regards,

Binarus