In <40DF13D6(_dot_)541B(_at_)xyzzy(_dot_)claranet(_dot_)de> Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> writes:
The problem isn't the missing SOFTPASS but the SOFTFAIL hack:
Actually SOFTFAIL is only for debugging. Maybe MARID removes
it, it's not really necessary, ? is good enough for "unknown",
nobody needs an additional ~ for "unknown, but probably bad".
At least that's my interpretation, and I wasn't here when the
SOFTFAIL was invented.
The SOFTFAIL result has had a somewhat shakey history, but I am a
strong supporter of it. Almost all of what follows is just
cut-and-paste copies of things I've said previously on the subject.
Remember, we can't force domain owners to publish SPF records. It is
my opinion that the jump from neutral to fail is too large. Large
companies/ISP need to be able to give their users some warning before
they switch from neutral to fail. While memos and such can help,
automated systems that add warnings when a softfail is detected can
play a very important part.
While I don't want to see a huge number of softfail records to
accumulate, I strongly believe that if softfail didn't exist, people
whould simply continue to use neutral and never switch to fail.
Currently, the SPF spec says this about softfail:
9.3 Phased Rollout
At an adopting domain, adoption of SPF could occur in phases. A
domain might move through these phases by changing its default
response type from "neutral" to "softfail" to "fail".
3. SPF Record Evaluation
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.
When the lastest draft was being worked on, I suggested this wording
instead:
3. SPF Record Evaluation
Softfail (~): [....]
MTAs SHOULD try to inform the recipient and/or sender of the
email that the SPF check did not pass and that the domain owner
is transitioning to a more strict standard. In the future, such
emails may be rejected and that the sender should take corrective
actions now.
For example, the MTA could modify the Subject: header or insert a
warning into the body of the email, similar to how many anti-spam
and anti-virus filters work. The MTA could also issue an SMTP
temporary failure code (4xx) the first time it receives the
particular email with a message that SPF check resulted in a
softfail.
The issue of whether there should be just a pass/fail, or if there
should be some levels of gray in SPF seems to be an issue that many
reasonable people disagree on. I think most people agree that the
desired result is widespread adoption with generally only pass/fail
results, but there is disagreement about how to reach this goal.
Do categories other than pass/fail encourage domain owners to
transition to SPF and then transition into increasingly strict
enforcement? Or, do these other categories encourage domain owners to
just take the easy steps and never do anything more?
For the record, I think that the SPF categories of accept,
neutral/unknown, softfail and fail is about the right number of
categories. For the record, I don't think one camp will be able to
convince the other camp that they are wrong.
So, while I can see actions that can be taken in response to a
softfail, I don't see what things a softpass would do.
-wayne