[jamesaepp]

I'm not looking for an argument, I've never noticed this behavior before. Why is this done? People are saying this is some kind of way to combat spamming/spoofing/malicious email but I don't see how that's the case. If the source address of the packets matches a blacklist then you can correlate against that. While not impossible to forge an IP address, it's certainly more trivial to edit the SMTP header (I'm not saying that would avoid detection, mind you).

What benefit do we gain from including the origin's IP address throughout the entire header history?

[d1zzy]

This was done way before Google existed, way before they offered a GMail server or an SMTP interface to their servers. It is done to combat spam, if I get an email that was relayed through their servers I can see which IP connected to their servers to send it. Then every time the email is sent between servers the source IP is again added. It allows to track the real source of an email, remember that email inherently has no authentication, there's no way to really say the From address is authentic. But having a record of all the IP addresses used when transferring the email I can determine that pretty easily.

[jamesaepp]

While yes, email has no implicit authentication and forging an email is trivial, pulling that attack off is super difficult due to modern SPF and DKIM mechanisms. I'm not super familiar with DKIM but I'll use SPF in my example below.

Let's say I'm running an email server for myself for example.com and I receive an email from 192.0.2.1 and it claims to be from [e-mail]. Okay, great. First I consult with my database of blacklists to make sure that 192.0.2.1 isn't blacklisted. If it is, into the trash it goes.

The blacklist reports the address is clear, I move to the next step - SPF. I do a DNS lookup for the txt records under gmail.com and find the one for SPF. But lo and behold, the SPF record does not include 192.0.2.1 as a valid address to submit mail on behalf of gmail.com - this email is likely forged. I drop the mail and submit a report to my favorite blacklist provider(s).

Now, could the DNS have been forged? Yes. With modern DNSSEC, is that likely? I don't think so. Could the packet's source address been forged? Yes, that's pretty easy if you're the ISP or state-sponsored. But if the source address has been forged, there's no way the IP address in the SMTP headers are going to do you any good - the attack is too sophisticated at that point.

If a receiver of mail fails to properly validate the source of the email, that onus is on them as far as I'm concerned, especially so if DNSSEC, SPF, DKIM, etc have all been implemented. While open relays aren't extinct, they sure are easy to detect and most best practices I've read on email say to reject them when detected.

I still don't see how having this trail of user IP addresses is useful. There's nothing implicitly in the message that can be trusted - that's what PKI is for.

[tptacek]

I don't know what you mean by "modern DNSSEC", but virtually none of the most important names on the Internet are (or likely ever will be) signed, so whatever your obstacles to forging an email might be, DNSSEC won't be among them.

[jamesaepp]

>Virtually none of the important names are signed.

Source?

>...Or likely ever will be

Source?

[tptacek]

It's easy to work this out for yourself. Take any list of the most popular zones --- the Moz 500 is the simplest to download --- and then write a simple shell loop to "host -t ds" each of them. You'll see in a minute or so that it is as I say it is. With the exceptions of Cloud Flare, which sells DNSSEC services, and Paypal (but none of Paypal's subsidiaries like Venmo), nobody in the technology industry uses DNSSEC. For that matter, none of the major banks do, either. Look to any industry vertical where companies tend to have significant security teams: none of them use DNSSEC. DNSSEC is virtually absent among major domains on the Internet.

This despite the fact that DNSSEC has been under development for twenty five years, with repeated aggressive pushes for deployment.

Indeed, browsers have experimented with DNSSEC support... and then removed DNSSEC support from their builds when they discovered it was unworkable.

[likpok]

https://dnssec-name-and-shame.com/

This shows the top 25 websites and that none of them have DNSSEC.

As for whether people will in the future, it’s impossible to say for sure. But chrome doesn’t support dnssec, which shows how seriously google takes it.

[jamesaepp]

Thanks for the link, that's quite interesting. While web browsers can implement their own DNS resolver, that's completely irrelevant when we're talking about an MTA. The server(s) the MTA(s) are running on have their own underlying resolvers which can be DNSSEC-compatible, or better yet, if you're using a public resolver like quad9, they validate the DNSSEC for you.

Edit: Not that I'm saying you should trust quad9 full-stop, but it is a nice feature. Anyone could run their own private resolver but most choose not to because of the very same privacy concerns we're talking about in these headers, namely - making your traffic easier to profile.

[zozbot234]

> remember that email inherently has no authentication, there's no way to really say the From address is authentic

SPF and DKIM have changed this quite radically. (Not always for the better, e.g. mailing lists traditionally had a legitimate need to set the From: address on the emails they relay. But one can argue that there's little need for those nowadays.)

[jamesaepp]

Trouble being that SPF and DKIM only work when they've been implemented correctly and they rely on DNS. That requires DNS to be resilient against attacks (DNS isn't foolproof).