jimimaseye wrote on 10/06/16 1:50 AM: > CONCLUSION: it was working as the book says (even though the book is not > clear WHY the book says what it says).
It's been a very long while since I worked with this code and I have to kind of twist my mind up funny to keep it in my head all at once, but this is how I remember how it came to be: You get an email that contains a chain of Received headers, purporting to tell you the path the email took going from each host to the next. Each header tells you that the host at a particular ip address claims that it received the mail from some other certain ip address. The top-most Received headers will have been inserted by machines in your internal network. You can rely on those headers being accurate. However those headers tell you nothing about the origin of the email. The Received header that is the bottom internal one will tell you where the mail actually came from. You can believe that you know the real ip address of the host outside your internal network that sent you the mail because it appears in the Received header that is generated by a machine in your internal network. Typically that will be one of your MX servers telling you what machine sent it the mail, which is why the MX servers should be listed as "internal". If the ip address that sent you the mail is a known spammer, that can be caught this way. You also know that you can't trust any Received headers below that one because they can be totally fake. Unless... What if you get mail, for example, sent to a gmail address which forwards to your own domain address? Then the bottom Received header in your internal list will show that the mail was received from a known Google mail ip address. If you put the Google addresses on the trusted list, you can know that the Received headers that claim to represent the travels of the mail through Google's servers to yours are not faked. That will lead you to the bottom-most trusted Received header which will tell you the ip address that sent the mail to your gmail address. And that's the ip address that you can check for being a known spammer, and it is the Received headers below that which might be faked. There are some differences in what can be reasoned about internal address vs trusted external addresses. I don't recall the details, but I can see how for example the internal ones can include addresses like 10.0.0.5 which are not legal on the outside Internet. If you see such an address in a Received header that is below the internal ones, then the address tells you nothing. tl;dr Internal addresses identify the machines in your local mail delivery setup. Trusted address identify machines that will not spoof Received headers. Different reasoning can applied to the two. Together they tell you which Received headers to ignore because they may be completely fake. As to why you should have to list all the internal ip addresses again in the list of trusted ones ... Because the people who designed this had to keep all this in their head at one time and they did by thinking "This is the list of internal addresses and I do this with them. This is the list of trusted addresses and I do that with them. This is how I document what I have done. Oh, internal is a subset of trusted, I better write that down when I document it...". And that's how complicated systems end up complicated :) Sidney
