Hi Dan,
My view on all this is based on trust.
True Negative - a test reveals a rejection or failed condition
True Positive - a test reveals a valid or successful condition
A True Positive can not be trusted 100%, where a True Negative has a 100%
trust value:
0 < trust positive < trust negative = 100%
A example if a True Positive would be a SPF compliant spammer who said "wow!
maybe I can sneak in if I add a SPF record!"
In other words, even if a SPF result returns PASS, it can not be trusted
further test is warranted.
A softfail provides absolutely no feedback or value whatsoever. It is has a
trust value that is:
0% < SOFTFAIL <= PASS
Therefore, regardless if a system separates mail into softfail vs pass
folders, both still needs the same amount of additional testing otherwise
you have a loophole.
Note: The only time a true positive (pass) has a 100% trust is when you are
checking local domains. All LMAP proposals offer 100% protection against
local domain spoofing. 100% trust for external domain checks is only
available on a rejection (fail) or true negative.
In my opinion, Meng should reconsider rewriting the functional
specification "definition" of softfail or remove it all together but it too
late and suffers the same consequences RFC 281 did with its "relaxed
loopholes." In my view, SPF should be about one thing; gaining a high trust
query result: NONE, PASS or FAIL. A system who wishes to support SPF
should do so with a failed fallback as the only acceptable format. A system
that offers a NONE or PASS result still requires additional logic to
validate the sender. While migration should be consideration, it MUST be
strongly stated that a SPF system with a softfail result offers no value in
the sender permitted framework. It should noted that SPF clients will view
softfail sites as a system with no trust. Note, this does not suggest that
a softfail recording should not be made or that it could not be used as a
weight for decision making. It simply says that softfail does not offer any
value in validating a system thus it is highly discouraged. My preference
is that it removed from the SPEC so that a huge database of softfail systems
do not accumulate over time. It offers absolute no value whatsoever.
Anyway, that's my take on it.
---
Hector Santos, CTO
WINSERVER "Wildcat! Interactive Net Server"
support: http://www.winserver.com
sales: http://www.santronics.com
----- Original Message -----
From: "Dan Boresjo" <dan(_at_)boresjo(_dot_)demon(_dot_)co(_dot_)uk>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Wednesday, February 18, 2004 6:28 AM
Subject: Re: [spf-discuss] softfail considered harmful
On Wednesday 18 February 2004 09:04, Alex van den Bogaerdt wrote:
Conceptually, my spam folder is on a similar level as my SPF folder is.
Nothing more than a place where messages end up. I have more than one
spam folder. I treat the messages in "spam15" different from those in
"spam5" and those are itself treated different than the messages in my
"SPF" folder. It is _me_ making the choice, and I have been using
fuzzy logic since my birth.
Exactly. If a message ends up in a considered-likely-to-be-spam folder it
is
more likely to be unread or read later. This is what I mean by 'fuzzy
delete'.
However the sender of the mail does not know if it ends up in 'inbox',
'spf-discuss' or 'spam15'. If spam15 messages are often overlooked, this
makes delivery unreliable from the sender's point of view.
"softfail": be prepared for this email to not arrive in [whatever] days.
Maybe the message should be attached to another one (similar to what SA
can do) with a warning notice to the receiver:
Er, no - the sender does not get warning that delivery has been
deprecated,
delayed, deleted or otherwise perjoratively labelled, unless you actually
reject the mail.
See? Deleting is NOT the only possibility.
Anything that reduces the probability of a mail being read is a form of
'fuzzy
deletion'. If the sender is not made aware of the mail's deprecated
status,
mail delivery must be considered unreliable.
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/spf-draft-20040209.txt
Wiki: http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡