Hi Daniel!

(I know you follow tails-dev@ somewhat but today I'm writing you with
your "Memory Hole driver" hat and I want to make sure you notice this
message, hence the explicit To header. I've set Reply-To to this list
so you should not get more duplicates.)

At a recent [Tails meeting] we've decided to tweet ([Tails ticket])
about how cool Memory Hole is, about the fact that we would like to
enable ASAP, and the fact that we are currently blocked by the lack of
Memory Hole support in the email client landscape. We hope it will
help motivate email client developers to implement Memory Hole
support. This email is not meant to discuss again whether Tails should
send Memory Hole-protected email by default right now, but instead to
gather input so we maximize the impact of our lobbying in favor of
Memory Hole :)

I would like to coordinate with you because the current Memory Hole
status makes the overall strategy/timeline around it unclear to me:

 - The [draft spec] is incomplete e.g. guidance for email client
   developers is lacking on important aspects such as how to handle
   headers apart of Subject; I suspect the discrepancy wrt.
   headers handling between Enigmail 1.9.9 and 2.0~beta1 is at least
   partly caused by this lack of guidance.

 - Threading, an important email feature, is broken when composing
   replies using the 1.9.x releases of Enigmail, that is currently the
   only implementation of Memory Hole in a widely used desktop email
   client. Thankfully that's fixed in Enigmail 2.0~beta1 but we can't
   expect Debian users to guess they need to install software from the
   'experimental' repo in order to avoid regressions in basic email
   functionality; I think the situation is even worse for users of
   other operating systems, that is the vast majority of
   Thunderbird users.

To maximize the impact of our tweet, I believe these two issues should
be addressed first, that is:

 - The world-famous $someone should ensure we can point to
   a specification that email client developers can follow to do the
   right thing; and in particular, recommendations should require that
   threading must not be broken.

 - A working desktop example should be made widely available, that is
   Enigmail 2.0 should:
   - be released as stable
   - be the default version non-technical users can install via
     whatever installation/upgrade methods the Enigmail project
   - be available for Debian stable users at least via stretch-backports

So my questions are:

 - Does the above make sense to you?

 - Is there anything else you think should happen before we send
   our tweet?

 - Are you in a position to give us a (rough) schedule wrt. when the
   above blockers will be resolved? In particular, do you personally
   plan to work on the specification again in the near future?

Thanks in advance!

[Tails ticket]    https://labs.riseup.net/code/issues/13649
[Tails meeting]   https://tails.boum.org/contribute/meetings/201712/
[draft spec]      

Tails-dev mailing list
To unsubscribe from this list, send an empty email to 

Reply via email to