mailpile
Protected message headers, improvements
This is copied from #156, to track the need for ongoing improvements (see final comment on that issue for context). Some of these might end up in 1.1:
- [ ] Display protection status in UI
- [ ] Obscure more metadata when encrypting
- [x] Only force-display human-readable information
- [ ] Consider tuning how much is obscured by recipient capabilities
- [ ] Detect and preserve benign Subject modifications (mailing lists, bug trackers)
Details
Currently nothing in the user interface indicates that a header was protected. We just silently update what is displayed using the most reliable data available to us from the signed or encrypted part. Is is currently unclear whether notifying the user on conflicts would have a low enough false-positive rate to actually be useful.
We expect both the default obscuring settings and the "minimize metadata" behaviour to change over time and become more aggressive as Memory Hole support (hopefully) becomes more widespread. Ultimately, it should become possible to obscure nearly everything from the unencrypted header, preventing all metadata leakage that isn't actually necessary for correct routing of mail and bounces (the SMTP envelope).
Currently all headers that were obscured are included in the visible text/rfc822-header part; that will need to change over time as we obscure more headers: some headers only contain machine-readable data so displaying them to the recipient is just spammy noise.
Just like we tune Mailpile's default encryption policy depending on the perceived capabilities of the recipients, it would be possible to tune Memory Hole as well. If someone always sends us mail using Mailpile or Enigmail (or some other known-good MUA), it might make sense to use more aggressive strategies to obscure metadata.
Some mailing lists and bug trackers edit the Subject in a useful way. It would probably be worth adding a special case to the code which attempts to detect and not undo these modifications. However it's worth noting that PGP/MIME signatures may not survive processing by such systems anyway, and sending encrypted messages to those systems isn't really something people do.
