Although, I'd argue that to be truly proper SA needs to use different limits on "num_check_received" for different circumstances. I've made the argument before that white and black checking needs to check different numbers of received: lines. (white checks you only want to apply to headers you trust, black checks it doesn't matter if you trust it or not as they can only hurt themselves).
Ideally I see three separate cases, although you could split the first one into two separate cases making 4.
1) a whitelist_num_check_received only for whitelist_from_rcvd and negative-scoring RBLs like bondedsender. This should never be more than 1 back from the oldest "server you trust" in your normal delivery path to prevent forgeries of either whitelist_from_rcvds or bondedsenders. However it needs to be configurable.
2) blacklist-style RBLs should be checked against all of them, possibly with some kind of optional num_check_received strictly for performance reasons.
3) dialup RBLs should skip the oldest one or two, but I think it already does this part just fine.
At 10:15 PM 5/27/2003 -0400, Jim and Karin Hunziker wrote:
I want to confirm the Amazon problem. I'm getting spam from someone with forged Amazon headers, and it's getting a -100.0 tacked on. I don't have a whitelist entry for Amazon.com in my user preferences, and the site installation is stock 2.55.
------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
