On Fri, 2004-06-25 at 13:40, spf(_at_)kitterman(_dot_)com wrote:
Yes, you may and should apply local policy, but that's not the distinction
I'm seeking here. I want to be able to say that yes, this is a permitted
sender for my domain, but I don't vouch for 100% of the e-mail that comes
from this sender.
Answer #1:
==========
Let me suggest an alternate name for what you're wanting: SOFTPASS.
PASS -> SOFTPASS -> NEUTRAL -> SOFTFAIL -> FAIL
However, there are only two valid reasons to add another possible spf
result IMHO:
1. A more finely-grained answer would be useful to recipients.
2. The existence of a more finely-grained answer helps convince
senders to publish SPF records.
The fact that a sender might just enjoy being able to publish another
bit of information is by itself irrelevant.
To give a silly example, if there were a proposal to extend the standard
so that a sender could state the color their mailserver is painted,
well, that's obviously not something a receiver would find useful, so it
fails reason (1) above. However, if for some quirk of MTA-admin
personality, it would mean that overnight we'd have a million more spf
records, then that's a success for reason (2) above, and reason enough
to add it to the standard.
I suggest that PERMITTED or SOFTPASS meets neither reason to
add-to-the-standard.
SOFTFAIL's current description is:
Softfail (~): the message does not meet a domain's strict
definition of legitimacy, but the domain cannot confidently state
that the message is a forgery. MTAs SHOULD accept the message
but MAY subject it to a higher transaction cost, deeper scrutiny,
or an unfavourable score.
I'm sure you can come up with a very similar definition for SOFTPASS,
and thus be able to position your proposal as a symmetric counterpart
of SOFTFAIL. Then you would end up with something all nicely symmetric,
and people will be more able to understand why you might feel the urge
to publish this sort of description.
But that's not enough.
For instance, it still wouldn't address why the SOFTPASS distinction
would really be _useful_to_receivers_.
From a recipient's point of view, PASS==not_a_forgery, FAIL==Forgery,
NEUTRAL=="I don't know, so treat me the same as a non-spf email". A
finer grain of answer a bit above or below NEUTRAL aren't so useful for
a receiver--it's still effectively a form of "I don't know".
For a while, softfail was pulled out of the spec for just that reason (I
think--I may be wrong on this), and put back in, *not* because it would
be useful for receivers, but because it would help convince domain
owners with potential domains-in-transition to publish spf records where
those owners wouldn't otherwise publish records.
softfail's existence breaks a clean conceptual model of possible spf
answers--but that breakage was a pragmatic compromise to help spf
adoption.
SOFTPASS would be of little if any use for receivers. (It's probably
just as annoying as SOFTFAIL.) So any argument based on receiver
utility is probably not going to fly.
That leaves Sender-adoption: So, would breaking the model further by
adding something between NEUTRAL and PASS help convince people to
publish SPF records?
Having just a few hundred more folks adopt wouldn't be enough--you'd
want to find it reasonable to think that it would affect SPF adoption in
such a dramatic enough way that it's worth the extra annoyance from the
receivers' point of view.
I don't think the addition of SOFTPASS can meet that bar.
Surprising Answer #2:
=====================
Currently we can imagine:
PASS -> NEUTRAL-or-no-spf-at-all -> SOFTFAIL -> FAIL
But looking at the actual, specific definition of SOFTFAIL, you could
imagine an alternate model:
PASS -> SOFTFAIL -> NEUTRAL-or-no-spf-at-all -> SOFTFAIL -> FAIL
That is, _from_the_receiver's_point_of_view, PERMITTED or SOFTPASS
results in about the same response as SOFTFAIL.
So in a sense, if you don't want to use NEUTRAL, you almost already have
a PERMITTED or SOFTPASS--just use SOFTFAIL instead of NEUTRAL. (!)
(I have to admit that this is something I didn't expect. It sort of
comes from the ambiguity in the wording of the softfail definition--"may
subject it to a higher transaction cost.."--higher than what? If you
just assume it's higher than that of PASS, then the above odd result
just falls out.
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com