On Tue, Jul 15, 2014 at 5:03 PM, John Denker <jsd@av8n.com> wrote:

http://www.metzdowd.com/pipermail/cryptography/2014-July/022150.html It seems to me that the binary distinction between "metadata" and other data is a crock. As a glaring example of the problem, common protocols for encrypted email encrypt only the main body of the message, leaving /all/ the headers unencrypted. This is a serious security breach, as discussed below [*].

We can do better than this. We need to do better than this.

At first glance, one might think that "data is data" and we should not distinguish "metadata" from other data, but actually I wish to go in the other direction, and distinguish /more/ classes of data. ... Let's be clear: A great deal of the stuff that appears in RFC822 headers is not needed for delivery of the message, and MUST NOT be sent in the clear. ... To say the same thing another way: Assume the law of the jungle. The only privacy rights you have are the ones you can enforce on your own, using the strength of your cryptography.

Well, when you give up those rights by still disclosing your source IP and trusting your 'destination organization' [aka provider] with address info regarding you and who you're mailing... it's not much of a solution. Put in as many classes as you want... besides the body of the message which you control, you can't fix centralized Email. Here's another class of provider and browser based non solutions... https://cpunks.org/pipermail/cypherpunks/2014-July/004894.html There's a thread of this subject ongoing that acknowledges Email can't really be fixed against the issues of the day... and discusses other possible messaging designs towards a next gen solution... https://cpunks.org/pipermail/cypherpunks/2013-December/002638.html https://cpunks.org/pipermail/cypherpunks/2014-July/004900.html The goal is likely one or both of these over an anonymous P2P network... o direct delivery to your recipients online node. o stored delivery to same (push or pull, only exposes destination). More interesting than wasting time on futility of old Email.