8 ms·

> 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

by tkfu 8y ago

> 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.

alfiedotwtf 8y ago
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.
- alias_neo 8y ago
  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.
  - simias 8y ago
    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?
    - kikoreis 8y ago
      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.
    - alias_neo 8y ago
      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.
- thepangolino 8y ago
  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.
  - lexs 8y ago
    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?
    - XCabbage 8y ago
      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!
      - lexs 8y ago
        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.
        8y ago
- Communitivity 8y ago
  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.
  - StavrosK 8y ago
    > telnet mailserver.com 25 HELO me MAIL FROM: santa@northpole.com RCPT TO: friends@dad.com DATA You've been a good boy. Santa .
    - megous 8y ago
      Syntax error.
      - StavrosK 8y ago
        Good call, needs more colons.
  - simias 8y ago
    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.
- detaro 8y ago
  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)
q3k 8y ago
GPG 2.0 now supports encrypting the Subject line.
- simias 8y ago
  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.
  - kikoreis 8y ago
    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.
    - pas 8y ago
      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.).
  - vlan0 8y ago
    The RFCs for the SMTP protocol call what is read by the server. Reading RFCs is fun :)
  - yosamino 8y ago
    This is probably what they are referring to: https://github.com/autocrypt/memoryhole https://github.com/autocrypt/memoryhole
    - dane-pgp 8y ago
Sir_Substance 8y ago
>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-faq#How_can_I_encrypt_the_Subject.3F https://www.enigmail.net/index.php/en/user-manual/handbook-f...
- bad_user 8y ago
  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.
  - Leace 8y ago
    > 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.
mirimir 8y ago
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.yml https://github.com/ehloonion/onionmx/blob/master/sources/map... 1) https://riseup.net/en/email#what-is-special-about-riseup-email https://riseup.net/en/email#what-is-special-about-riseup-ema...
- bad_user 8y ago
  > "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.
  - mirimir 8y ago
    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.

by tkfu 8y ago

alfiedotwtf 8y ago

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.

alias_neo 8y ago
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.
- simias 8y ago
  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?
  - kikoreis 8y ago
    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.
  - alias_neo 8y ago
    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.
thepangolino 8y ago
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.
- lexs 8y ago
  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?
  - XCabbage 8y ago
    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!
    - lexs 8y ago
      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.
      - 8y ago
Communitivity 8y ago
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.
- StavrosK 8y ago
  > telnet mailserver.com 25 HELO me MAIL FROM: santa@northpole.com RCPT TO: friends@dad.com DATA You've been a good boy. Santa .
  - megous 8y ago
    Syntax error.
    - StavrosK 8y ago
      Good call, needs more colons.
- simias 8y ago
  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.
detaro 8y ago
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)

q3k 8y ago

GPG 2.0 now supports encrypting the Subject line.

simias 8y ago
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.
- kikoreis 8y ago
  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.
  - pas 8y ago
    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.).
- vlan0 8y ago
  The RFCs for the SMTP protocol call what is read by the server. Reading RFCs is fun :)
- yosamino 8y ago
  This is probably what they are referring to: https://github.com/autocrypt/memoryhole https://github.com/autocrypt/memoryhole
  - dane-pgp 8y ago

Sir_Substance 8y ago

>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-faq#How_can_I_encrypt_the_Subject.3F https://www.enigmail.net/index.php/en/user-manual/handbook-f...

bad_user 8y ago
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.
- Leace 8y ago
  > 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.

mirimir 8y ago

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.yml https://github.com/ehloonion/onionmx/blob/master/sources/map... 1) https://riseup.net/en/email#what-is-special-about-riseup-email https://riseup.net/en/email#what-is-special-about-riseup-ema...

bad_user 8y ago
> "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.
- mirimir 8y ago
  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.