https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5842
------- Additional Comments From [EMAIL PROTECTED] 2008-03-03 20:37 ------- (In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > what do we need to do to record Received-SPF: btw? > I meant, what do we need to do *in our MTA configurations* ;) Pick a milter, any milter: http://svn.perl.org/viewvc/qpsmtpd/trunk/plugins/sender_permitted_from?view=markup http://www.openspf.org/Implementations > 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. "It is RECOMMENDED that SMTP receivers record the result of SPF processing in the message header." We could, I guess. It'd give us a positive indication that the SPF checks were actually done for domains that don't publish SPF records. > 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. 1/3 and 0/2 :) > 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!). Yeah, we're probably going to have to do some copying. I'm not sure who's corpus was responsible for the scores that were generated for 3.2. > 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. Really? Isn't that what #reuse is supposed to be taking care of? Why a dual dependency on both #reuse and "tflags net"? > 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.) I *really* want to avoid different rules like above. It'll confuse people and cause those who aren't confused to write metas to combine the two versions. > 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. This might complicate score generation further. :( ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
