spf-discuss
[Top] [All Lists]

RE: People keep misunderstanding what "Pass" and "Neutral" mean

2005-05-25 13:28:22
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of 
Constantine A.
Murenin
Sent: Wednesday, May 25, 2005 4:19 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] People keep misunderstanding what "Pass" and
"Neutral" mean


On 25/05/05, Arjen de Korte <spf+discuss(_at_)de-korte(_dot_)org> wrote:
Julian Mehnle schreef:

[...] the scores for a SPF 'neutral' are set to a virtually
non-scoring
0.001 points by default in this patch. Unless someone actually changes
it from the defaults, I don't believe the patch as it is will
cause any
message to be rejected.
So then what's the point of that SA rule in the first place?

That's an open door. To allow people to add points? There are many more
rules in SA which are set to very low values (0.001 ) or even disabled by
default (set to '0'). People reading the documentation find that they
can change them if they want, while others that install the stuff 'as
is' will not be bitten by them. I considered scoring on SPF 'neutral'
results controversial enough to award it a low score by default. By
doing so it shows up in the list of rules that hit, but will not have
any real influence on the result without adding a custom score for them.
People awarding more than a fractional amount of points in this case are
probably the same that actually considered SMTP rejecting on SPF
'neutral', so we're not loosing anything here.

Still, a part of the comments in the rule's definition reads:

# "Neutral" can be pretty bad too (if the domain owner doesn't want
# to be responsible, who will?)

"Pretty bad", right? ;-)

Right. It can be pretty bad, it doesn't necessarily mean it *is* bad. At
the time of writing that patch (almost a year ago) it was not clear if
the domains publishing '?all' were going to be forged frequently or not.
That's why I wrote *can* be pretty bad. If that wording is too strong,
that's probably due to my poor command of the English language (as a
non-native speaker).

I've just subscribed to the list, so I haven't followed the whole
conversation, sorry if my points have already been mentioned/solved...

I think that we need to distinguish between ?all and ?somedomain.
For example, I sent all of my outgoing messages from my own home
server, while my domain is hosted in a datacentre. In this case,
if I don't want to do any special set-up for my home server, I can
just tell in the spf for my domain "v=spf1 a mx
?ptr:dyn.sprint-hsd.net -all". By this rule, I'm telling everyone
that every piece of mail from China, Korea etc that claims to be
from my domain should be rejected, while mail from the Sprint DSL
network, where my home outgoing mail server is located, is most
likely legitimate.

Yes, that's correct.

In real life, the aforesaid rule should give the correct results
in 98% of the cases of forgery.

Absolutely.

I.e. I think that if an SPF record has just one (let's say no more
than eight) neutral records, that are wildcasting to not more than
/16 networks and not more than second-level domains, then
SPF-parser should treat these Neutral records in the same fashion
as if they were Pass records, minus, let's say, 25% of the
positive non-spam score that an analogous Pass record would give.

Unfortunately trying to automate this judgement about how open the record is
is very challenging.

In this situation, the owner of the domain wants to clearly
exclude all forgery, but at the same time does not want to accept
responsibility for his fellow DSL users from the same network as
he is. That's why he would want to create a neutral record.

My record has a lot of potential for NEUTRAL result for exactly these
reasons.

If you search the archives, here's one convenient spot:

http://www.gossamer-threads.com/lists/spf/discuss/

for the term "SOFTPASS", I think you'll get the gist of the prior
converstations on this topic.


snip

Cheers,
Constantine.


Scott K