-----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 Mark
Shewmaker
Sent: Friday, June 25, 2004 3:26 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Possible New Mechanism Prefix
Answer #1:
==========
Let me suggest an alternate name for what you're wanting: SOFTPASS.
PASS -> SOFTPASS -> NEUTRAL -> SOFTFAIL -> FAIL
Yes, that would make sense too. Makes no difference to me which you would
pick. I think PERMITTED is more descriptive, while SOFTPASS is more
SYMMETRICAL. I think descriptive is more important, but it's not a big
deal.
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.
Agree those are good, but I would add a third one:
3. The existence of a more finely grained answer reduces the risk of
senders publishing records that cause forgeries to get SPF PASS.
I have spent an inordinate amount of time trying to understand how to
effectively deploy an SPF record that fully describes the permitted senders
for my domain (not there yet) so that I can publish -all. This distinction
between PASS==Not a forgery and it not meaning Pass==The sender is permitted
is a subtle one that I believe many people will miss.
Number 3 is critical because the first time someone gets RBLed because they
published an SPF record that caused a false positive it's going to make news
and people are going to pull back from SPF. Actually, you could argue that
my number 3 is really part of number 2, but it is an important point either
way.
snip
I suggest that PERMITTED or SOFTPASS meets neither reason to
add-to-the-standard.
I disagree and I'll get to that in a minute.
snip
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.
I do think it meets the bar. SPF has been getting a lot of press lately.
On the MARID list there are a lot of people seriously opposed to SPF (I'm
not one of them) just waiting to poke holes in it. It isn't going to take
very many instances of false positives for people to find SPF scary.
Currently there isn't a lot of risk, because the technology is in it's
infancy, but as it spreads, this is going to happen with the current design.
When it happens, it will get press and people will pull back.
If we add this nuance then the wizard (or its equivalent) can ask, "Is it
{the mail source in question} under control of the same organization as
{domain for which SPF records are being created}?" or something like that.
Based on the answer, the mechanism would give a PASS or a
SOFTPASS/PERMITTED. Note that this could also be done with neutral, but
that causes other problems.
If we stick with NEUTRAL and don't add another prefix, then the
documentation ought to explain in big bold letters somewhere that if your
MTA is a shared resource, you probably ought not to be using PASS, you ought
to use NEUTRAL. Otherwise there are going to be false positives.
The effect of this will be (as SPF becomes more widely adopted) lots of
NEUTRAL results. As SPF gets beyond the early adopters and into more
general use, a larger fraction of the SPF publishers will be users of shared
MTAs. Over time then, more and more results will come back NEUTRAL.
Now back to the receiver side of the question. Are MTA admins going to
start questioning putting the time and computing resources into SPF when a
significant fraction of the time it is going to come back saying, carry on
as if there was no SPF. In terms of receiver policy, I'd expect most
recievers to assume a SOFTPASS/PERMITTED result was not a forgery unless it
came from a spammish MTA. This gets us back to the next step after SPF. To
work on the SPAM problem once we have SPF in place we need to work on
reputation and accredidation. SOFTPASS/PERMITTED will be very useful for
the receiver once we get into that regime.
Today this isn't a big deal, but I believe that over time it will become
more important.
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.
I read the spec as meaning higher than NEUTRAL/No SPF record.
Anyway, I'm not giving up on SPF either way. I do think that for SPFv2 (or
whatever it gets called) this would provide a benifit more than porportional
to the added complexity it brings.
Scott Kitterman