It might be too early to enable Mail Hole in Enigmail

[anonym]

TorBirdy 2.3 sets extensions.enigmail.protectHeaders = true, enabling Mail Hole for all sent emails. However, Mail Hole significantly degrades UX for non-Mail Hole recipients, for example by setting a static subject ("Encrypted Message") and breaking threading by dropping In-Reply-To.
If TorBirdy is designed to only be interoperable with other TorBirdy users, then this makes sense, but if communication with non-TorBirdy users is a use case, then Memory Hole cannot be enabled in this shape, IMHO.

[anonym]

(In fact I recommend a quick 2.3.1 that disables this -- me and another Tails contributor has already been affected by this, having had to resend multiple emails to confused recipients.)

[dkg]

On Fri 2017-08-18 11:52:35 +0000, fred-a-kemp wrote: TorBirdy 2.3 sets `extensions.enigmail.protectHeaders = true`, enabling Mail Hole for *all* sent emails. However, Mail Hole significantly degrades UX for non-Mail Hole recipients, for example by setting a static subject ("Encrypted Message") and breaking threading by dropping In-Reply-To.

I am surprised to hear that the initial implementation of memory-hole drops either In-Reply-To: or References: header. Has anyone reported that as a problem upstream? setting the static subject (and having the actual subject inside the e-mail, viewable by non-memory-hole clients) is a clear *improvement*, not a degradation. Please don't drop that advancement in torbirdy.

…

--dkg

[anonym]

I am surprised to hear that the initial implementation of memory-hole drops either In-Reply-To: or References: header. Has anyone reported that as a problem upstream?

When Memory Hole is enabled I think protecting In-Reply-To and References makes sense since those otherwise would leak thread activity. So not a bug/problem IMHO.

setting the static subject (and having the actual subject inside the
e-mail, viewable by non-memory-hole clients) is a clear improvement,
not a degradation. Please don't drop that advancement in torbirdy.

I agree that Memory Hole is a huge improvement, but only when all participants use it. Those that lack support will unquestionably have a worse UX given the loss of Subject and threading. Or am I missing something? If not, then I argue that we should wait until Memory Hole support is more wide-spread; I fear enabling it now will be counter productive given that it makes OpenPGP even more inconvenient to use and adopt than it already is. (Case in point: we've already had some inconvenience within the Tails project, and if us cryptonerds have problems, I think it's safe to assume average users will as well.)

[anonym]

Tails ticket: https://labs.riseup.net/code/issues/13649

Since this repo isn't used any more I propose we move the discussion there.

[intrigeri]

I am surprised to hear that the initial implementation of memory-hole drops either In-Reply-To: or References: header. Has anyone reported that as a problem upstream?

When Memory Hole is enabled I think protecting In-Reply-To and References makes sense since those otherwise would leak thread activity. So not a bug/problem IMHO.

A few clarifications and updates:

• I've never heard about Memory Hole protecting the two headers that have been discussed here (like it does with the Subject). So far the claim has been that it dropped them.
• I've just tested on Debian sid (Enigmail 1.9.9-2) and I see that with Memory Hole enabled, no In-Reply-To and References header is added to an email composed by clicking the "Reply" button. Moreover, any such existing header (in the email being replied to) is dropped. This effectively breaks threads. But I have good news! This is fixed with 2.0~beta1-1 from Debian experimental that preserves these headers and updates them as expected => with this beta version threading works fine :)

[intrigeri]

Moved this discussion to https://trac.torproject.org/projects/tor/ticket/28493 and added a few updates.