Who reads your email?(netmeister.org)
netmeister.org
Who reads your email?
https://www.netmeister.org/blog/mx-diversity.html
15 comments
> 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.
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.
> 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.
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.
In their defense, they do call themselves "every mailbox," so you should expect every mail server.
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.
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.
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.
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-verifi...
[2] https://support.google.com/a/answer/2520500?hl=en
[3] https://www.rfc-editor.org/rfc/rfc6698
[4] https://www.rfc-editor.org/rfc/rfc7671
[5] https://www.eff.org/deeplinks/2020/04/winding-down-starttls-...
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-verifi...
[2] https://support.google.com/a/answer/2520500?hl=en
[3] https://www.rfc-editor.org/rfc/rfc6698
[4] https://www.rfc-editor.org/rfc/rfc7671
[5] https://www.eff.org/deeplinks/2020/04/winding-down-starttls-...
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.
At least someone does, because I avoid it when I can.
An article from long ago about this problem:
https://mako.cc/copyrighteous/google-has-most-of-my-email-be...
https://mako.cc/copyrighteous/google-has-most-of-my-email-be...
> Who reads your email?
A lot of it ... not me!
A lot of it ... not me!
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.
> 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.
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.
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
> 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
[2] https://hunter.io/email-verifier