ietf-mxcomp
[Top] [All Lists]

A&R BCP & Re: DEPLOY: Permitting '-all' to be used immediately represents a flag day.

2004-09-15 10:14:58


David Woodhouse wrote:

Each of the mailfrom and pra scopes make flawed assumptions about
forwarding practice, and it would be necessary for uninterested
forwarding sites to modify their behaviour in accordance with any new
RFC.
This isn't a problem, because Tony's statement:

If you use -all you must never send email to an alias-fowarding
address

only applies in the mailfrom and pra scopes, and we're going to be checking HELO.
If the HELO check (+ A&R check) passes, the forwarding problem GOES AWAY.

BTW, apropos William Leibzon's post: I think an atomic scoring system, i.e. a system where a bunch of atomic tests are done and results of each assigned a score and the score summed is not optimal. This kind of issue is why I've been pushing for a BCP in this area.
I'm thinking that instead, conditional logic is better, but I'm not sure.
The SA rules that handle habeas are informative here; they have conditional logic: HABEAS_USER means "Has Habeas warrant mark and on User List" (This is conditional logic - it means: if H and U then score=score-8; else nothing.)

HABEAS_INFRINGER means "Has Habeas warrant mark and on Infringer List"  (which 
is conditional logic too)

These are assigned the scores -8 and +16, respectively, by default, if they hit. No score is assigned for <Has Habeas warrant mark but not on either list>. No score is assigned for <Has no Habeas warrant mark but IS on a list>. This is the case in recent SA releases (2.6, 3.0). In 2.4, the tests were atomic, and it seems the conditional logic was a needed enhancement added later. 2.4:

|score HABEAS_SWE                     -4.0
|score HABEAS_HIL                     4.0
In 2.4 there was also
|score HABEAS_VIOLATOR                8.0

|meta HABEAS_VIOLATOR (HABEAS_SWE && HABEAS_HIL) (Err. This is conditional logic too. My bad. Anyway, clearly it's important)


If the HELO check (+ A&R check) passes, but the A&R check provides something other than a yes/no answer, then things get more complicated. Perhaps we should assume this is the case for the BCP. E.g. if the HELO A&R check results in what I'll call a 'weak pass', then further MARID checks would be useful, but if there's a strong pass, then don't do further tests, which would cause false positives, e.g. due to forwarders that don't do SRS or SUBMITTER. Is this complicated logic necesary, or would simple logic and HELO check (+ A&R check) test passes having a relatively large positive score be good enough? I'm pretty sure that the HELO check + A&R check should not be scored separately.

http://old.spamassassin.org/full/3.0.x/dist/rules/50_scores.cf has sensible text for SPF followed by scores that are at odds with the text and are unreasonable:

#
# SPF # Note that the benefit for a valid SPF record is deliberately minimal; it's
# likely that more spammers would quickly move to setting valid SPF records
# otherwise.  The penalties for an *incorrect* record, however, are large.  ;)
#
ifplugin Mail::SpamAssassin::Plugin::SPF
score SPF_PASS -0.001
score SPF_FAIL 0 0.974 0 0.875
score SPF_SOFTFAIL 0.500
score SPF_HELO_PASS -0.001
score SPF_HELO_FAIL 0 0.001 0 0.001
score SPF_HELO_SOFTFAIL 0 0.907 0 3.140
endif # Mail::SpamAssassin::Plugin::SPF



<Prev in Thread] Current Thread [Next in Thread>