On Sun, 8 Oct 2006, John Rudd wrote: > > I assume you have a clear idea of what you mean by "first"? The > > Received header that *your* MTA is adding? The Received header that > > the outermost MTA you trust is adding? > > I mean the topmost header that my MTA is adding.
That's the simplest case. You know exactly what is going to be in the Received: header that your MTA is adding, and you explicitly trust that the information isn't forged. > > How robust this is will depend on how complex your mail relay chain > > is. If your trusted ISP has lots of exposed mail servers it may be > > difficult to do it this way. > > We don't trust any ISP. We trust our internal hosts, and that's > it (and, as soon as I can force the policy change, we wont even > trust them; it will be "do SMTP-AUTH or we treat you like a > random host on the net"). That's not what "trust" means in this context. For SA, "trust" means "we know headers from this server are not forged". For this purpose you will *always* trust yourself, and you want to tell SA to trust all the way out to the public-most known-reliable server that receives mail for your domain, or many network tests won't work correctly. For example, if your SA machine is "behind" a publicly-visible MTA, but you don't trust it, then any DNSBL tests performed on the sender address will always be testing the publicly-visible MTA (which is the next hop past the last trusted host) rather than the actual client that originated the message. This probably isn't going to generate any useful information. > We have 3 scanning hosts that are our MX servers. I suppose the > above might work, as I could have the "first.trusted.host" be > "smtp-prod-mx-?[1-4]\.ucsc\.edu". Right. > Though, some of what I want to do is going to be complex enough, > that I may want to do it with a plugin anyway. (checking to see if > the host's IP address segments are contained within the hostname) > Just looking for things like "dhcp", "dsl", "dynamic", etc. in the > hostname could be done with the above, though. >From what you are describing, those servers are publicly visible feeds into your mail system. You should tell SA that they are trusted so that a lot of built-in tests that already do what you want will be enabled and will work properly. For example, you can easily add DNSBL tests against the various public dynamic IP address block DNSBLs, rather than writing rules to check the rDNS name for the IP address that is in a specific Received header. > > 'course, now somebody will chime in with a SA facility for doing this > > neatly that I'm not aware of, and make me look silly (again)... :) > > > > Like: is there a pseudo-header available to rules that is the > > outermost Received header in the trust path? If not, then it might be > > a useful addition. > > That was my hope (that such a thing existed) -- John Hardin KA7OHZ ICQ#15735746 http://www.impsec.org/~jhardin/ [EMAIL PROTECTED] FALaholic #11174 pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 - 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 ----------------------------------------------------------------------- The difference is that Unix has had thirty years of technical types demanding basic functionality of it. And the Macintosh has had fifteen years of interface fascist users shaping its progress. Windows has the hairpin turns of the Microsoft marketing machine and that's all. -- Red Drag Diva -----------------------------------------------------------------------
