https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5842
------- Additional Comments From [EMAIL PROTECTED] 2008-03-03 01:53 ------- (In reply to comment #2) > (In reply to comment #1) > > I say yes, they should be tflags net. it's exactly analogous to the DNSBL > > rules; they are network lookups, which can record their results in a header > > (the > > reuse data), which can then be reused in set 0 if --reuse is specified. > > IMO that makes sense for the SPF rules (although the recorded results are > > put in Received-SPF:). > > I'm not sure I'd consider them exactly analogous. With a mail system that > adds > Received-SPF headers before SA sees the message SPF results are used (in all, > even non-net, scoresets) without SA *ever* doing the actual network checks. ok, not exactly analogous. Just partially ;) > Reuse of the data later in mass-checks, etc, isn't of concern. I'm not aware > of > --reuse applying to spamassassin or spamd. true. > > what do we need to do to record Received-SPF: btw? > > Record Received-SPF? We don't. This would be added by a mail system that > processes the mail before SA sees it. For example, see the headers of any > mail > I've sent to an ASF mailling list. I meant, what do we need to do *in our MTA configurations* ;) Now that I think about it though, I don't do any SPF lookups in any of my MTAs; I leave that to SpamAssassin. So maybe we should add support for recording it (if there isn't a header already there). Then we *can* use this header as a way to #reuse SPF lookups, *and* we are more standards-compliant (since I think that is dictated in the std). That would help with generating scores for set0 at least. In the meantime I think it'd be acceptable to make these a special case. Generate their scores for set2/3, then simply copy those to set0/1. if we don't have the data, we can't trust the GA, but we should be able to trust that the S/O ratios will be the same (since it's the same domains and the same lookup logic!). However that doesn't solve the core issue -- "tflags net". we need to keep the network lookup code running with "tflags net". This is necessary for the --reuse support, so that it knows to set the rule score to 0 when attempting to reuse hits. However as you note, this means the code doesn't run in set0 at all. What I did in the past with the ROUND_THE_WORLD test was to split it into two rules, ROUND_THE_WORLD and ROUND_THE_WORLD_LOCAL; the latter was set0, the former set2. What about doing that with the SPF rules -- adding a duplicate ruleset for SPF_PASS_LOCAL, SPF_NEUTRAL_LOCAL etc.? (better names welcome of course.) We could even move the current set to __SPF_PASS_LOCAL, __SPF_PASS_NET and combine them into a new SPF_PASS meta rule. This would be --reuse-compatible, and clearly delineate set0 and set2 rules. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
