Memory Hole discussion / OpenPGP e-mail header protection

Bjarni Runar Einarsson bre at pagekite.net
Tue Jun 23 21:48:48 CEST 2015


Hello!

Thanks Alexander for offering to receive test mail!  Kernal of lavaboom has
as well, I'll probably send my first round of tests tomorrow.

Ruben Pollan <meskio at sindominio.net> wrote:
> Quoting Alexander Strobel (2015-06-23 17:27:29)
> > One question regarding the specs: Did you talk about a version field? I
> > think it might be easier to distinguish between emails from different
> > implementation stages. I think this would also be helpful for debugging
> > purposes after the initial release 1.0 .
> 
> You are right, it might be a good idea. We could add a 'Memory-Hole' header with 
> the version, and this might be the place to add more info if needed in the 
> future. This could be placed at the text/rfc822-headers attachment.

Thanks for bringing this up!

Leaving aside for a moment whether it's a version header or something else,
this does remind me of something from the discussions in April that I forgot in
my rehash:

- There needs to be a way to differentiate Memory-Hole parts from other parts
  that just happen to be of MIME-type text/rfc822-headers.

That marker may include a version identifier as well, but the important thing
is we need a marker of some sort.

It can't really be part of the text/rfc822-headers payload as you suggest,
because that both has performance implications (you need to parse the part
BEFORE you can know what it is) and would make the spec no longer
content-agnostic; in particular we wouldn't be able to discuss the spec itself
over e-mail without breaking things.

Ideally the marker needs to be *inside* the encrypted or signed envelope.

Having spent a little time browsing RFC2045, I think the Content-Type
header of the memory-hole part might be the right place for this.
Something like:

  Content-Type: text/rfc822-headers; charset=us-ascii; memoryhole=v1

AFAICT this fulfills the criteria of being legal according to the relevant
RFCs, not user-configurable (so we're not preventing any legitimate use)
and within the signed or encrypted envelope. I don't yet know whether this
is easy or hard for folks to implement.

Thoughts?

 - Bjarni

-- 
Sent using Mailpile, Free Software from www.mailpile.is
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Encryption key for Bjarni Runar Einarsson.asc
Type: application/pgp-keys
Size: 18318 bytes
Desc: not available
URL: </pipermail/attachments/20150623/7f2b3286/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP Digital Signature
URL: </pipermail/attachments/20150623/7f2b3286/attachment-0001.sig>


More information about the Gnupg-devel mailing list