4 ms·

Who reads your email?

133 points by binaryanomaly 4y ago

voytec 4y ago
I run my own MTA for some 23+ years now. Google (supposedly) reads only my emails sent by their users and same can be said about other similar services. > The Simple Mail Transfer Protocol (SMTP) relies on MX records in the DNS to identify which server(s) it should hand the mail off to. Not necessarily (this statement is corrected later in the post). One of my domains have no MX records and I use it for email extensively. As per RFC2821, SMTP falls back to A (and AAAA which have not existed back then) when the FQDN does not have corresponding MX record [1]. I have only found it to be an issue with one web service which utilizes hunter.io, which marks my email address as invalid due to lack of an MX record. Real mail services work perfectly fine. They (hunter.io) have the following untruthful statement in their FAQ [2]: >> We check if there are MX records on the domain. If there aren't, the email address can't receive emails. Linked post reflects lack of requirement for the MX record correctly: > As it turns out, no explicit MX record is indeed the most widely found configuration: almost 119 million domains (58% of all domains) are lacking any such resource record. Of those, 76 million (64%) do have an IP address and thus could at least theoretically receive mail [1] https://www.rfc-editor.org/rfc/rfc2821#section-3.6 https://www.rfc-editor.org/rfc/rfc2821#section-3.6 [2] https://hunter.io/email-verifier https://hunter.io/email-verifier
- codetrotter 4y ago
  > SMTP falls back to A (and AAAA which have not existed back then) when the FQDN does not have corresponding MX record I think of it the other way around. Originally, people would specifically say which computer it would be sent to when sending mail, right? And then later came MX records. So in my mind it’s like, ok send mail to this host, except if there are any MX records. If there are, then use those instead.
jeffbee 4y ago
> everymailbox.com domain has 398 MX records Ah yeah, these clowns. I distinctly recall, when rewriting the DNS record cache used internally at Google (note: not the resolver), thinking that surely no MX response would need more than 8KiB, and finding these jokers.
- GauntletWizard 4y ago
  At Google scale, you don't just find edge cases, you find every edge case. I miss the days when Google actually bothered to support them, though.
- ronsor 4y ago
  In their defense, they do call themselves "every mailbox," so you should expect every mail server.
shadowgovt 4y ago
Nowadays? I hope no TLA organizations are making any guesses at what I'm up to based on it because not even I read my email.
nomilk 4y ago
Superb analysis. TL;DR: > pretty much boils down to "Google and Microsoft". Even if your domain doesn't use one of their mail servers, chances are that whoever you are sending mail to does.
jsemrau 4y ago
I was speaking about Paypay in a gMail exchange yesterday and today saw an add about Paypay on my Smart TV (YouTube App). Weird coincidence. The first time ever that I have seen a Paypay ad on Youtube.
- maxpro 4y ago
  why do you think this is a coincidence? I thought there's nothing hidden that Google scans your conversations and targets you with ads. And YouTube is part of Google portfolio... so nothing strange here
ZunarJ5 4y ago
At least someone does, because I avoid it when I can.
yosito 4y ago
It would be interesting to evaluate whether my nameserver provider (Cloudflare) or my mail provider (Fastmail) are sharing access to my emails with anyone else. I chose these providers because I don't want Google reading my emails. I assume that because it's a cleartext protocol and Fastmail operates in Australia that all of my emails are accessible in theory to state actors.
- torton 4y ago
  It is misleading to call email a plaintext protocol, because most email operations are encrypted in current practice (same as web browsing, despite HTTP 1 being a plaintext protocol). SMTP (the delivery email protocol) began supporting encrypted transport in 2002, which means that for over a decade most email has been encrypted in transit [5] (as well as during retrieval, because of POPS/IMAPS and HTTPS-secured webmail). The method is TLS (same protocol used by HTTPS, all of our web browsing traffic). Competent mail servers and services, such as exim [1] and GMail [2], let you choose to abort delivery if the destination server does not support encryption (or, since you are concerned about state actors, if there's a STARTTLS-stripping server in the middle). Furthermore, DANE [3] and TLSA [4] can be used (requiring DNSSEC to be set up for the domain) to bind a mail server record to a specific TLS certificate, further reducing meddling opportunities by state-level actors and allowing a "we do allow insecure mail delivery, but since this destination has DANE it is implied they have TLS and we will fail delivery if TLS cannot be established with this destination with the DANE-specified parameters". [1] https://www.skytale.net/blog/archives/32-Outgoing-TLS-verification-in-exim.html https://www.skytale.net/blog/archives/32-Outgoing-TLS-verifi... [2] https://support.google.com/a/answer/2520500?hl=en https://support.google.com/a/answer/2520500?hl=en [3] https://www.rfc-editor.org/rfc/rfc6698 https://www.rfc-editor.org/rfc/rfc6698 [4] https://www.rfc-editor.org/rfc/rfc7671 https://www.rfc-editor.org/rfc/rfc7671 [5] https://www.eff.org/deeplinks/2020/04/winding-down-starttls-everywhere-project-and-future-secure-email https://www.eff.org/deeplinks/2020/04/winding-down-starttls-...
  - bigDinosaur 4y ago
    I assume the person to whom you are replying was thinking more along the lines of end-to-end encryption. Email is very rarely end-to-end encrypted, and none of its standards relate to end-to-end encryption so you have to do it with other methods which are notoriously difficult to use correctly.
kazinator 4y ago
> Who reads your email? A lot of it ... not me!
pabs3 4y ago
An article from long ago about this problem: https://mako.cc/copyrighteous/google-has-most-of-my-email-because-it-has-all-of-yours https://mako.cc/copyrighteous/google-has-most-of-my-email-be...

133 points by binaryanomaly 4y ago

I run my own MTA for some 23+ years now. Google (supposedly) reads only my emails sent by their users and same can be said about other similar services. > The Simple Mail Transfer Protocol (SMTP) relies on MX records in the DNS to identify which server(s) it should hand the mail off to. Not necessarily (this statement is corrected later in the post). One of my domains have no MX records and I use it for email extensively. As per RFC2821, SMTP falls back to A (and AAAA which have not existed back then) when the FQDN does not have corresponding MX record [1]. I have only found it to be an issue with one web service which utilizes hunter.io, which marks my email address as invalid due to lack of an MX record. Real mail services work perfectly fine. They (hunter.io) have the following untruthful statement in their FAQ [2]: >> We check if there are MX records on the domain. If there aren't, the email address can't receive emails. Linked post reflects lack of requirement for the MX record correctly: > As it turns out, no explicit MX record is indeed the most widely found configuration: almost 119 million domains (58% of all domains) are lacking any such resource record. Of those, 76 million (64%) do have an IP address and thus could at least theoretically receive mail [1] https://www.rfc-editor.org/rfc/rfc2821#section-3.6 https://www.rfc-editor.org/rfc/rfc2821#section-3.6 [2] https://hunter.io/email-verifier https://hunter.io/email-verifier

codetrotter 4y ago
> SMTP falls back to A (and AAAA which have not existed back then) when the FQDN does not have corresponding MX record I think of it the other way around. Originally, people would specifically say which computer it would be sent to when sending mail, right? And then later came MX records. So in my mind it’s like, ok send mail to this host, except if there are any MX records. If there are, then use those instead.

jeffbee 4y ago

> everymailbox.com domain has 398 MX records Ah yeah, these clowns. I distinctly recall, when rewriting the DNS record cache used internally at Google (note: not the resolver), thinking that surely no MX response would need more than 8KiB, and finding these jokers.

GauntletWizard 4y ago
At Google scale, you don't just find edge cases, you find every edge case. I miss the days when Google actually bothered to support them, though.
ronsor 4y ago
In their defense, they do call themselves "every mailbox," so you should expect every mail server.

shadowgovt 4y ago

Nowadays? I hope no TLA organizations are making any guesses at what I'm up to based on it because not even I read my email.

nomilk 4y ago

Superb analysis. TL;DR: > pretty much boils down to "Google and Microsoft". Even if your domain doesn't use one of their mail servers, chances are that whoever you are sending mail to does.

jsemrau 4y ago

I was speaking about Paypay in a gMail exchange yesterday and today saw an add about Paypay on my Smart TV (YouTube App). Weird coincidence. The first time ever that I have seen a Paypay ad on Youtube.

maxpro 4y ago
why do you think this is a coincidence? I thought there's nothing hidden that Google scans your conversations and targets you with ads. And YouTube is part of Google portfolio... so nothing strange here

ZunarJ5 4y ago

At least someone does, because I avoid it when I can.

yosito 4y ago

It would be interesting to evaluate whether my nameserver provider (Cloudflare) or my mail provider (Fastmail) are sharing access to my emails with anyone else. I chose these providers because I don't want Google reading my emails. I assume that because it's a cleartext protocol and Fastmail operates in Australia that all of my emails are accessible in theory to state actors.

torton 4y ago
It is misleading to call email a plaintext protocol, because most email operations are encrypted in current practice (same as web browsing, despite HTTP 1 being a plaintext protocol). SMTP (the delivery email protocol) began supporting encrypted transport in 2002, which means that for over a decade most email has been encrypted in transit [5] (as well as during retrieval, because of POPS/IMAPS and HTTPS-secured webmail). The method is TLS (same protocol used by HTTPS, all of our web browsing traffic). Competent mail servers and services, such as exim [1] and GMail [2], let you choose to abort delivery if the destination server does not support encryption (or, since you are concerned about state actors, if there's a STARTTLS-stripping server in the middle). Furthermore, DANE [3] and TLSA [4] can be used (requiring DNSSEC to be set up for the domain) to bind a mail server record to a specific TLS certificate, further reducing meddling opportunities by state-level actors and allowing a "we do allow insecure mail delivery, but since this destination has DANE it is implied they have TLS and we will fail delivery if TLS cannot be established with this destination with the DANE-specified parameters". [1] https://www.skytale.net/blog/archives/32-Outgoing-TLS-verification-in-exim.html https://www.skytale.net/blog/archives/32-Outgoing-TLS-verifi... [2] https://support.google.com/a/answer/2520500?hl=en https://support.google.com/a/answer/2520500?hl=en [3] https://www.rfc-editor.org/rfc/rfc6698 https://www.rfc-editor.org/rfc/rfc6698 [4] https://www.rfc-editor.org/rfc/rfc7671 https://www.rfc-editor.org/rfc/rfc7671 [5] https://www.eff.org/deeplinks/2020/04/winding-down-starttls-everywhere-project-and-future-secure-email https://www.eff.org/deeplinks/2020/04/winding-down-starttls-...
- bigDinosaur 4y ago
  I assume the person to whom you are replying was thinking more along the lines of end-to-end encryption. Email is very rarely end-to-end encrypted, and none of its standards relate to end-to-end encryption so you have to do it with other methods which are notoriously difficult to use correctly.

kazinator 4y ago

> Who reads your email? A lot of it ... not me!

pabs3 4y ago

An article from long ago about this problem: https://mako.cc/copyrighteous/google-has-most-of-my-email-because-it-has-all-of-yours https://mako.cc/copyrighteous/google-has-most-of-my-email-be...