[jamesaepp]

Can someone break down what this means for me? I'm assuming an example of say Thunderbird as the MUA connects to gmail's servers with SMTP over TLS or using STARTTLS and happens to include this header of the client's public OR (not xor) private IP address as per specification(s).

What's unclear for me it whether this is then stripped by gmail's MSA/MTA before being routed towards the destination. From how I'm reading the article in the OP, it seems to imply that the recipient of the message would know the sender's IP address. If this is the case then I'd say that's of some concern, but it seems people are saying this is NOT the case. Can someone please expand on the exact test setup?

[dfox]

Any random MTA including gmail's that receives your message over SMTP prepends Received header to your message that contains where the message was received from and that somewhat obviously includes the IP address where the message came from. It works as intended and if you at all care about privacy implications of that (whatever that might be) you simply should not use email/SMTP.

[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?

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