Jo Rhett wrote: > > On Oct 17, 2006, at 5:59 PM, Matt Kettler wrote: >> Because there *HAS* to be a local. If there isn't, then the message >> isn't at your server. >> >> This is the whole point. If the message hasn't been Received: by a local >> server, it is by definition not in your network. >> >> By feeding messages to SA without a local Received: header, you are >> explicitly telling SA that the message is still in some other network, >> not yours. So what's SA supposed to do? > > Um... subtract points from the score as a backup approach? :-( > > Seriously, if it is confused then 0 points. But *NEVER* trust > something because it was confused. Erm, just exactly how can it tell this? That's a big part of the problem. SA doesn't have any way of detecting this case. There's no magic "Hey, a Received header is missing!" flag in the message.
The reason SA gets confused is it has no other options. It goes with what's in the headers. There's no other information to work from. Keep in mind that spamd could be running on a different machine than the MTA is (commonly done for load handling in larger sites). Because of this SA can't just look at the IPs of the local interfaces and compare them to the Received: headers. It's quite possible for one spamd server to scan mail for several different MTA servers with different domain names, so it can't even compare the domain part of localhost against the Received: headers. Think about a hosting provider (hostinprovider.com) that provides services to "customer1.com" and "customer2.com". The hosting provideer actually has a dedicated spamd box set up, and allows any of their customers to use it to scan mail. Think about how "spamdbox.hostingprovider.com" views mail being fed to it from three MTAs: "mta.hostingprovider.com", "mta.customer1.com" and "mta.customer2.com". By comparing domains it could figure out the first one.. but it needs to correctly trust the other two as well. There's just no way for SA to detect this without breaking someone else's perfectly valid network. Now do you understand why it's such an absurd suggestion? Your broken input actually looks like perfectly valid input from a different kind of network configuration. SA's not just doing something stupid because it's confused. It's doing something stupid because it looks perfectly correct and normal. > Does your bank give out cash from your bank account when confused? If > so, let me know where you bank... True, but again, how does SA know it's confused to avoid this? If my bank was sufficiently confused they damn well may give out cash. If an imposter showed up with a drivers license claiming to be me, wrote a check to himself from my account.. yeah, they'd cash it if the forgery was good enough. You've done a stellar job of convincing SA it's actually acting on behalf of another network. An excellent forgery. > > But why does it break by subtracting points from the score? There's > no logic in that. I'd agree.. Again, how does SA know it's confused to avoid this? > > Nothing. Nothing or "0" is a good response. "-4.5" as I've seen on > some messages is *NEVER* an appropriate response to confusion. I'd agree.. Again, how does SA know it's confused to avoid this? > > Fine. Misbehave. Reject the message. But don't subtract points from > the score. SA can't reject the message. It's a mail filter. In it's normal aplication a message goes in one side and out the other. It has no ability to "fail", or otherwise return any kind of error. All it can do is modify the content of the message. And again, how does SA know it's confused to even detect this, in order to try to cause some kind of rejection that SA itself isn't capable of? Stop thinking about your specific implementation. SA has a much broader range of implementations it has to support and work correctly for. > > > Ah, but the message has not yet been received. So adding a Received: > header is lying to SA. We're waiting for SA to pass judgement on the > mail before we accept it. Read the Milter spec. Yes, but as others have pointed out, SA isn't a milter, it's not designed to be a milter, and does not expect milter-spec input. It is designed to be called in a generic way by tools in the mail chain after delivery. As such it expects post-receipt input. SA can be adapted to be used by milters, and a billion other things, but don't expect that to change what SA needs for input. I could probably adapt SA to be fed from a squid proxy to scan web page contents, but I don't think I'd start complaining about it not understanding http headers and not conforming to squid's interfaces. > >> The problem isn't SA breaking, it's the fact that a RFC required piece >> of information is missing from the message. > > You really are off your rocker without a clue. Sorry, I thought I was > chatting with someone who grokked reality. No, it is in fact RFC required for the kind of input SA expects to see. SA is not a milter. I do grok reality. Quite well. I see a much larger universe than just your one broken milter. Perhaps you should grok more than your own project sometime. > >> It's complete insanity to try to expect SA to behave properly without a >> local Received: header. > > I never said that I expect SA to "behave properly". I said I wanted > it to not let more spam through. Failing gracefully is the right > response, and failing gracefully in this context is by not altering > the spam score. So, having all your RBL checks not work doesn't count as "letting more spam through"? After all, without that Received: header, SA can't do any RBL checks on the host delivering the mail. Unless of course the delivering system already added its own, but in the case of spam, it's probably not there, or if it is it's not accurate.
