4 ms·
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/spoofi
by jamesaepp 7y ago
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 7y agoThis 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.
- zozbot234 7y ago> 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 7y agoTrouble 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).
- jamesaepp 7y agoWhile 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 bob@gmail.com. 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 7y agoI 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 6y ago>Virtually none of the important names are signed. Source? >...Or likely ever will be Source?
- 6y ago