1666182 - No way of sending PGP-encrypted mails if recipient and identity don't match

Status: RESOLVED DUPLICATE of bug 1644085

(MailNews Core :: Security: OpenPGP, defect)

Description

[Oliver]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.106 Safari/537.36

Steps to reproduce:

Attempted to send a PGP-encrypted email where none of the identities on the key match the recipient address.

In my case this was on Windows 10 with the 32-bit build.

Actual results:

After I got (seemingly by now automatically) upgraded to Thunderbird 78, I was no longer able to send the email (which worked until before the upgrade).

Expected results:

I have contacts with whom I am in touch via a key that doesn't match the recipient address. I.e. none of the identities on the key contain the recipient key.

This was no problem with Enigmail as it allowed me to simply specify a recipient rule and be done with it.

I was expecting that a forced upgrade would contain the full spectrum of the features of the software that the forced upgrade is claiming to replace. At least I had read somewhere that previous upgrades were held back because of issues related to the replacement of Enigmail.

If you can offer a workaround, that would be brilliant. Can I simply downgrade to the last 68 version and disable automatic updates? Thank you.

Comment 1

[Florian Sammüller]

A similar request which proposes the reintegration of Enigmails per-recipient rules is tracked in bug 1644085. With this feature, a manual/custom key assignment would be possible for various scenarios.

Comment 2

[Oliver]

(In reply to Florian Sammüller from comment #1)

A similar request which proposes the reintegration of Enigmails per-recipient rules is tracked in bug 1644085. With this feature, a manual/custom key assignment would be possible for various scenarios.

Thanks, Florian, for the pointer. Will watch the linked bug 1644085 as well then.

Comment 3

[Magnus Melin [:mkmelin]]

(In reply to Oliver from comment #0)

I was expecting that a forced upgrade would contain the full spectrum of the features of the software that the forced upgrade is claiming to replace.

Thunderbird never claimed it will implement each and everything that enigmail did or did not do. We do hope to support the vast majority of use cases.

The obvious question though, why does the key not match the recipient address?

Comment 4

[Oliver]

(In reply to Magnus Melin [:mkmelin] from comment #3)

Thunderbird never claimed it will implement each and everything that enigmail did or did not do. We do hope to support the vast majority of use cases.

Don't know what the official claim was. As far as I understood it from the bits and pieces Thunderbird/Enigmail communicated to me as a user (I even followed some links and read up on the Wiki), the new Thunderbird version was supposed to replace Enigmail with built-in functionality. That's how it was communicated to me as a user of the software. Quote from Wiki (as of this writing):

As a replacement for Enigmail, the Thunderbird team intends to develop new, integrated support for OpenPGP messaging, and plans to make it available in the Thunderbird 78 release that is planned for summer 2020.
Source

Please excuse me for having taken this as a commitment to providing roughly the same functionality as Enigmail. The initial reports from articles a few weeks back made me anxious of the upcoming change, but since the upgrade had been delayed at the time - apparently due to the developers being unhappy with the state of affairs at the time - I had indeed hoped that it would not be greenlit before it was finished.

It seems the fundamental difference in our points of view is that I was expecting to switch one branch of middle class car for another brand of middle class car (replacement). Perhaps a little fewer or more horse power, perhaps different color, perhaps sedan vs. station wagon, perhaps one with an entertainment system built on Android and the other on VxWorks ... whatever. Minuscule differences really. But your point of view seems to be more along the lines of if (that is: conditions apply 😉) you use it in the city, a bike is a perfectly acceptable replacement for a car. And I agree, it could be! But only under certain conditions (e.g. in the city, not carrying half a ton of stuff around). These conditions - from my point of view - were only insufficiently communicated to us users, which in hindsight left me with a false sense of security about what was going to be featured in the build-in solution.

And so, given the older Thunderbird series 68.x fell out of support with this release, I was filing this ticket both because - I'll readily admit - I saw the switchover as premature and because I am trying to evaluate for myself whether I should wait for these features to appear or move on to a different MUA after more than 15 years with Thunderbird.

(In reply to Magnus Melin [:mkmelin] from comment #3)

The obvious question though, why does the key not match the recipient address?

The fact it exists in Enigmail suggests I'm not the only one with the use case. But here we go. The two cases I have in use, where this happens:

1. no identity on the key (yeah, it happens and yeah there can be good reasons for it, too)
2. different identity (i.e. the key literally mentions a different email address from the one who is the recipient in the MUA) ... and given confidentiality is one of the goals, I'm sure you can imagine use cases without me having to go into more detail

Now whether you can come up with good reasons by your own standards or whether my reasons would meet your standard for being good reasons I cannot tell. However, just because I'm never writing HTML emails doesn't mean I question the availability of the feature for everyone else.

Comment 5

[Peter Müller]

The obvious question though, why does the key not match the recipient address?

As Oliver mentioned above, reasons for this are primarily privacy-related.

Having multiple identities across different infrastructures myself, using a dedicated key for each one is laborious, especially if those should be stored on a smartcard for security reasons. Using one key and setting aliases for it is an information leak and unfortunately out of question for my scenario.

The mentioned Enigmail feature was pretty helpful there, and I would be grateful if it landed in Thunderbird 78.x as well, since it is the only show-stopper preventing me from using Thunderbird > 68.x. :-)

Comment 6

[Wayne Mery (:wsmwk)]

possible duplicates in https://mzl.la/3sf5eMW ?

Comment 7

[Nicolas Falquet]

I think this duplicates Bug#1644085, which was solved already.

Comment 8

[Peter Müller]

Yes, indeed, from my point of view, this is implemented and can be closed.

Thank you for your replies and work. :-)

Comment 9

[Nicolas Falquet]

Oh yeah!