Hacker News Reader

> the MTA's and other mail servers add header fields tha not only uniquely identify sender and recipient but details about the conversation and attachments.

Well this is misleading. While is true that PGP has non-ecrypted header files, MTAs/servers cannot add significant details about conversation, because they do not have any other information that is not already publicly known.

Some non-encrypted details about conversation (e.g. In-Reply-To header) is unencrpypted, but added by originating mail client, not server. Subject is also well-known to be unencrypted.

Attachments, their content, types, filenames and lengths are all parts of messaged data (in OpenPGP) and are therefore encrypted.

Shame, really. I love distributed P2P applications built around dumb, simple techniques or tools. Super complex abstractions are useful but as a project creator it's difficult to rely on new technology if you can't support it yourself.

Email is one of those dumb, old systems I've often wanted to push a ton of stuff into. Ala' the days of Twitter and SMS, The role of email and how widely it's used just seems perfect for dumb distributed applications... if not for the issues you cited.

There are dumb systems you can use, email just happens to be ill suited. Netcat+gpg comes to mind.

Fortunately there is work being done on standardising the encryption of message headers when using PGP:

https://datatracker.ietf.org/doc/draft-autocrypt-lamps-prote...

It should be possible to go a step further, though, if mail providers offered a well-known reserved address like switchboard@domain which Alice could send an encrypted email to, and it would decrypt it to determine that the intended recipient was bob@domain. Ideally, Alice's mail provider would rewrite the sender headers to something generic too, relying on Bob to extract those from the email he decrypts.

That way the sending server would only know the recipient server (not the local-part of the recipient address) and the recipient server would only know the sending server (not the local-part of the sender).

Of course, this would make server-side spam filtering much harder, so it would benefit from some sort of bearer token system for bypassing such filters. The Autocrypt standard already uses special headers for signalling state between sender and recipient, but this header would require the mail provider to detect the new header and change their filtering rules based on it.

And it should be noted that DeltaChat is the most complete Autocrypt implementation, so metadata _is_ encrypted (albeit not all of it)

> The nsa and other actors that inspect email traffic for non-legal reasons love PGP [1]

Hey! You didn't actually link to [1] ! ;)

Sorry, just updated. :)

https://www.theregister.co.uk/2016/01/27/nsa_loves_it_when_y...

> MTA's and other mail servers add header fields tha not only uniquely identify sender and recipient but details about the conversation and attachments.

That really depends on how the server is configured. If the servers used are under the participants' control, then other than Received headers, nothing else should be exposed if the client does not include or encrypts the headers in addition to the body.

So, if the sender were to send an email using the following SMTP session:

  EHLO random_string
  MAIL FROM: <random.email@addr>
  RCPT TO: <recipient@email.addr>
  DATA
  <PGP BLOCK>
  .

then other than the received headers that are added by the MTAs, it wouldn't expose much information at all.

Even if you control your mail server, all of your recipients will also need to run their own mail server. and even then they may slip up and add X-headers. You will need to encrypt the subject and attachment names. If one recipient uses a different client/provider the whole scheme might fall apart.

If you need everyone to run their own mail servers and a specific client then why bother with email at all?

> You will need to encrypt the subject and attachment names.

That's why I specified that the DATA session should consist solely of a PGP encrypted block of text. This means that the headers and body are included and there's no unencrypted text in that phase other than the CRLF.CRLF that terminates it. This means that it wouldn't be possible for the MTA to determine what the subject or attachment names are.

> If you need everyone to run their own mail servers and a specific client then why bother with email at all?

TBF, the article has the following statement:

>> Delta Chat doesn’t have their own servers but uses the most massive and diverse open messaging system ever: the existing e-mail server network.

It can't be considered open if everyone is just using the big mail providers.

There is a Subject header outside if the data section. Some clients add on variations of it or a "thread id" ,"coversation" and such.

Unless you're talking about a protocol other than SMTP, all message headers and the body are sent during the DATA phase.

it should be less than that, if the servers are controlled by competent admins - everything after STARTTLS should be garbage to beholder.

The MTAs are hostile,they are the threat. Email can traverse multiple servers that have nothing to do with the sender or recipient.

Competency won't prevent them from allowing backdoor access or sniffing and selling metadata.

MTAs, if configured correctly, do not talk to anything outside your network that is not specified by MX DNS records. Unless we are talking about emails traversing internal networks and even then competent admins do not transmit data in cleartext, so sniffing is out of question. Of course, some metadata is always leaked, but that is the reality of most internet protocols, HTTPs notwithstanding. Now if we're talking about backdoors, it's a game over in any scenario.

I was thinking more about encryption at rest as opposed to in transit, but you do make a good point.

> you should never use it in place of something modern

A lot of complaints here, but no actual substance.

Exactly what modern tool do you suggest here? And why is it even better? All of the tools today seem insecure anyways.

Ya I agree, I wonder what happened to lavabit's dark mail server / client, they got funding but the development seems to have stalled years ago.