Carlos E. R. wrote: > The thing is that SA comes with many rules enabled by default whose > policies I don't even know, and which sometimes I came to strongly > distrust and disable - after the "damage".
I think there is a small problem of expectation-setting here. To a large extent, people expect SA to come all ready to go. Just turn it on, and voila you're free of (most) spam. But with e.g. postfix and smartd we don't have the same expectations - we know that some setup is required before postfix will behave as our mail-server and before smartd will do some SMART monitoring for us. The thing with SA is that its ruleset is large and complex and not very transparent, which tends to "scare" people away and into thinking "it's probably allright as it is". > And the SuSE/Novell folks > don't seem to do a good review of those rules. They cannot and they shouldn't have to. Overall, that is the responsibility of the SA folks, but SA has to be individually configured/optimised to max its performance. > No, I meant the www.bondedsender.org people, they have an email for > reports ([EMAIL PROTECTED]). But I'm not a client of > them, I don't know who is the sender, etc. Too many doubts, and > reading their site I'm not clear on them. Yes, I agree, it's confusing. I also don't like that they talk in probabilities, about number of complaints per mail sent etc. Which is why I have "score RCVD_IN_BSP_TRUSTED 0" in my SA config. >> You can't really blame SA for this one - it probably is fairly >> reasonable to trust the bonded-sender guys. > > I don't know. > In fact, I don't think so. Then you should simply disable the rule like I have. Nonetheless, I still think it is _reasonable_ to trust them, but in my case I chose not to. Using the BSP rule is a matter of avoiding false-positives and I don't think the BSP rule does that very well. > How can SA (or any program) know that the received lines it is > examining are true, ie, real and not faked? The bonded sender people > may say that monopost.com people are reliable, but can we know > (automatically, ie, by a program) that the email really came from > their servers? You can always tell where an email came from. The headers are written by your email-program and it knows which client delivered the email. Whether you can trust the rets of the path is another question. But SA is pretty good at checking the emails headers and finding inconsistencies. >> RCVD_IN_WHOIS* - as far as I'm concerned, the completeWhois people >> can't be depended on to deliver quality data, > > Every server should be in whois, no? The good and the bad. It must be > something else. Well, in some cases I have had reports of "invalid IP" although it had a perfectly good whois report. I think the RCVD_IN_WHOIS is dodgy, and I've disabled it. /Per Jessen, Zürich -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
