Hacker News Reader

Comment by tkfu | Hacker News Reader

> While it is possible to encrypt certain emails in Gmail with GPG, Google can still read all email meta-data such as email addresses and subject lines. Better use a Gmail alternative that encrypts your entire mailbox and contacts automatically.

This is nonsense. Any email service will be able to see the recipients (and senders) of your messages, because that's how email works. Subject lines too, again, because that's how email works.

E2E encryption of email is a good thing, GPG is hard. These things have be true forever.

View on HN

Yes, email providers must see sender and recipient email addresses, and corresponding server names (and how to reach them). However, if you and your correspondents use ~anonymous email accounts, none of that get's tied to meatspace. And if you're really paranoid, you can have multiple accounts, and mix them up.

About 30 "activist" email providers exchange messages via Tor onion addresses.[0,1] But you still need to trust your provider, unless you trust your OPSEC enough.

Back in the day, we had Mixmaster remailer nyms, with PGP and message delivery to alt.anonymous.messages. You downloaded all messages, and then selected based on public key. But not enough people ever used it, so the anonymity space was tiny. But there is still activity. I recently came across something ~new on Github, but I don't remember exactly what.

0) https://github.com/ehloonion/onionmx/blob/master/sources/map...

1) https://riseup.net/en/email#what-is-special-about-riseup-ema...

> "But you still need to trust your provider"

When it comes to the security or privacy of your messages, if you really, really need it, then you cannot trust your provider and that's the whole point of end-to-end encryption.

If you're an activist whose life would be threatened if those messages got out, then you'd better make sure that any information you leak to your email service provider cannot be tied to you, no matter how much you trust that provider.

> "if you and your correspondents use ~anonymous email accounts"

Note that anonymity is earned by you via the steps you take to open and use that email account.

For example, if you're logging in to that email account from your home IP and you're being targeted by some security organization or crime syndicate with enough resources, who your email provider is will be absolutely irrelevant.

OK, you're right. You can't trust anyone.

> Note that anonymity is earned by you via the steps you take to open and use that email account.

That's what I meant by "unless you trust your OPSEC enough".

However, not all of us are " activist[s] whose life would be threatened if ... messages got out". So I think there is some value in providers who will protect you, if your OPSEC is weak. If nothing else, it's failsafe. Like climbing with a rope.

> However, if you and your correspondents use ~anonymous email accounts, none of that get's tied to meatspace.

Anyone else here remember anon.penent.fi, or am I simply old? :)

* https://en.wikipedia.org/wiki/Penet_remailer

Also, mixmasters:

* https://en.wikipedia.org/wiki/Anonymous_remailer

I think that using anon.penent.fi was one of my first attempts at anonymity. Then I discovered mixmaster remailers and nyms.

I used Private Idaho for Windows, and then Quicksilver. Just a few years ago, I got Quicksilver running in Wine in Whonix. There were (maybe still are?) some nymservers, remailers and news servers running as Tor onions.

It's a pity that anonymous remailers aren't more widely used, but I've been thinking of an 80/20 solution that might be easier to adopt.

Imagine that alice@protonmail wants to send an encrypted message to bob@tutanota and they both have each other's PGP keys. What these email providers could do is offer a reserved email address (such as remailer@) with its own associated PGP public key. (The address and the public key could be stored in the DNS, or retrieved via some HTTPS .well-known URL).

This way alice@protonmail could encrypt a message (including headers) to bob@tutanota using his private key, and then encrypt this inner message as the body of a message sent to remailer@tutanota. ProtonMail would only see that Alice is communicating with a Tutanota user, and Tutanota would only see that Bob is communicating with a ProtonMail user. (For the specific case of webmail providers, you would also want something like SXG [1] combined with Binary Transparency [2] to prevent malicious JavaScript being served).

[1] https://developers.google.com/web/updates/2018/11/signed-exc...

[2] https://wiki.mozilla.org/Security/Binary_Transparency

That is an interesting idea.

However, remailers are vulnerable. For example: https://riseup.net/en/about-us/press/fbi-seizes-anonymous-re...

GPG 2.0 now supports encrypting the Subject line.

It does? As a user I'm interested. How does that work?

While as the parent points out some header info has to remain available to deliver the mail correctly I always thought that it was a huge weakness that the subject wasn't encrypted as it could potentially leak some critical information. I didn't think there was a solution to this problem.

In SMTP only the envelope headers are really required to be unencrypted. The rest, including the actual To, From and Subject fields are part of the payload. You can use milters that look at the payload which can affect email delivery (think anti virus) but that is separate from the protocol itself.

The "envelope headers" are not really part of the email though, they are just SMTP protocol messages (commands) required to get to the point where you can pipe/stream the actual mail body (payload) through. Though every MTA prepends stuff to the payload (Received headers, etc.).

The RFCs for the SMTP protocol call what is read by the server.

Reading RFCs is fun :)

This is probably what they are referring to: https://github.com/autocrypt/memoryhole

The Autocrypt team are doing some great work, and I really hope they prove that OpenPGP can provide the basis for a backwards compatible and secure email system, which works without requiring the user to necessarily understand the underlying cryptography (just as HTTPS has succeeded).

Making email more secure than it currently is seems like quite a low bar to reach, even if perfect security remains impossible to achieve.

https://autocrypt.org/

Hmm...the pgp emails I've received recently either have no subject or the subject is "Encrypted Email".

>Subject lines too, again, because that's how email works.

Yeah, it's not though.

https://www.enigmail.net/index.php/en/user-manual/handbook-f...

There's nothing about Gmail that prevents you from encrypting your subject lines.

The most important metadata however is whom your communicating with. And there's nothing in GPG that can protect the addresses of your recipients, because it's not possible due to the email protocol.

> because it's not possible due to the email protocol.

Or any other protocol that's not crazy paranoid as anonymous PGP messages on alt.anonymous.messages.

This.

Can we please kill the idea of "safe email" forever. Email leaks like a sieve. In fact, It would be interesting to see if the Carbon Copy (CC:) feature of email violates GDPR.

Don't even get me started on domain spoofing.

I get so much junk every day due to bounce backs of people spoofing my domain to send junk.

SPF, DKIM and DMARC have done (and can do) nothing to help.

Email is broken, and this, sadly, is the price we pay for the federation it provides for a technology of its age.

Are you sure your server is correctly configured? I host my own server on a custom domain and while I do receive a non-negligible amount of spam I don't think I've ever noticed my domain being spoofed.

>SPF, DKIM and DMARC have done (and can do) nothing to help.

Isn't that precisely what these technologies are supposed to help? Why do you say that they can't do anything?

You are right that they are designed to prevent spoofing. The problem is that the recipient server needs to be configured to use it and not all servers do, for reasons spanning false positives to ignorance. So if you have a fairly old or known domain you will get non trivial amounts of backscatter from spoofed email being sent to invalid or otherwise rejected addresses.

Sadly, as the other commenter has pointed out, they rely on the recipient server understanding them.

A lot of the fails I get are due to non-existent recipients, full mailboxes and some that detect it as spam end up replying (to me) just to tell me that they've detected it as spam (which I know already, and would prefer they didn't aggravate the issue by replying).

Bear in mind, I'm not talking about recieving spam directly (I get almost none) I'm talking about "back scatter" from innocent (but perhaps poorly configured) mail servers telling me they couldn't or wouldn't deliver "my" email.

This all goes to randomly generated addresses at my domain (which the spammers using my domain are generating), which I receive at my catch-all and may have to consider disabling, while ensuring my mail server doesn't also notify them that it didn't deliver their bounce back (otherwise I'm perpetuating the issue) all at the risk of losing legitimate emails if they're miss-spelt etc.

Three things:

1. Nothing is ever absolutely safe. Everything can leak at some point or another be it only because someone whipped their phone out and took a picture of the screen.

2. Just because it can not be made 100% safe, doesn't mean no efforts should be undertaken to push things in that direction.

3. Despite being well-spirited, DGPR is a retarded piece of legislation. Bested only by the EU cookie law.

In regards to 3. why exactly is not using CC for mailing lists "retarded" (very poor choice of words by the way). Just because I'm on a mailing list doesn't mean everyone in that mailing list should see my mail address and the fact that I'm subscribed. That is exactly what BCC is for so why not use it?

Eh? Nobody mentioned mailing lists except you. The guy who brought up GDPR was suggesting that the CC feature in itself might be a GDPR violation. You, on the other hand, are talking about a specific use of CC that people broadly agree is wrong, but presenting that as if it's the same thing as what the first guy said.

This is like somebody calling for a law that bans all cars, someone else calling that retarded, and you coming along and saying Why exactly is it retarded not to drive on the pavements? That's what roads are for!

Well it clearly depends on how you use the CC feature, most of the complains about CC have been in regards to mailing lists as that's where obviously unwanted information leaks happen.

"the CC feature in itself might be a GDPR violation" is a, to use your words, "retarded" idea. For starters you can still send emails internally, perfectly fine to use CC there. Also I'm sure there are some legitimate interest cases where CC instead of BCC makes sense too.

This is classic GDPR fear mongering and laziness.

> "the CC feature in itself might be a GDPR violation" is a, to use your words, "retarded" idea

Well, yes, I agree.

> This is classic GDPR fear mongering

Well, no. The person who suggested that it's a violation is anti-email, not anti-GDPR; it's implicit that they think it would be a good thing if the CC feature were inherently illegal.

> 3. Despite being well-spirited, DGPR is a retarded piece of legislation.

Why? As someone (currently) in the EU I'm quite happy with it.

100% agree. I remember a friend who typed in SMTP commands to send his dad a Christmas email from santa@northpole.com.

There are alternatives, they just haven't caught on as an email replacement. For example, I suspect the Extensible Messaging and Presence Protocol (XMPP) can do everything email can do, and it supports E2E encryption. XMPP addresses would still be exposed, as any messaging needs the message routing information decryptable by the server, but much better that email.

    > telnet mailserver.com 25
    HELO me
    MAIL FROM: santa@northpole.com
    RCPT TO: friends@dad.com
    DATA
    You've been a good boy.
    Santa
    .

Syntax error.

Good call, needs more colons.

Spoofing email is trivial but it's also usually trivial to detect, at least if the real provider uses modern technologies like SPF, DKIM and DMARC. I can easily forge an SMTP message from sjobs@apple.com and send it from my computer but it'll be considered junk by any mail service worth using.

The feature itself obviously doesn't (there's many uses of it where sharing the information is intended and legal, e.g. CC-ing multiple people involved with the same thing and knowing each other so it is clear everyone has seen it), but using it wrong can be a violation (e.g. CC-ing all your customers, who have no need to know about each other)

Reply on news.ycombinator.com