-----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 Frank
Ellermann
Sent: vrijdag 20 mei 2005 10:25
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: [spf-discuss] Re: internet draft:
draft-schlitt-spf-classic-01.txt
I don't get the new PermError = Softfail => 4xx logic, should
the sender simply try again without first fixing his policy?
At the last Council meeting, I had it put on record that I am opposed to
PermError = 'softfail'. My rationale is, that for PermError there are
really only two reasonable ways to proceed: either you ignore a PermError
altogether (not recommended, as far as I'm concerned), or you reject with
5.x.x codes. And since you cannot 5.x.x. a 'softfail', I believe the two
should not be the same. Plus, 'softfail' is a policy result, whereas
PermError is the result of a non-transient configuration error.
Of course, you understand, that my whole rationale is predicated on the
premiss that a PermError = 5.x.x response. If you do not agree with that
premiss, then an entirely different situation exists, of course. :)
BTW, my [Discuss] on archaic source routes had nothing at all
to do with a PermError for these constructs.
Actually I think it's a non-issue, the syntax for a Return-Path
is 100% clear, for MAIL FROM it's almost identical (optionally
some ESMTP stuff after the closing ">")
MAIL FROM:<@foo.com:relay!Jones%my(_dot_)box(_dot_)example(_at_)XYZ(_dot_)COM>
1 - strip "MAIL FROM:<"
@foo.com:relay!Jones%my(_dot_)box(_dot_)example(_at_)XYZ(_dot_)COM>
2 - strip @-source route stuff (MUST accept, SHOULD ignore),
if anything at all it starts with "@" and ends with ":"
relay!Jones%my(_dot_)box(_dot_)example(_at_)XYZ(_dot_)COM>
3 - find end of local part, an "@" excl. any quoted "@"
relay!Jones%my.box.example@
XYZ.COM>
4 - get rid of ">" after FQDN, pass the stuff to checkhost()
relay!Jones%my(_dot_)box(_dot_)example(_at_)XYZ(_dot_)COM
5 - don't even think about what "!" or "%" might be. And my
[Discuss] was about mentioning this point (5) at all in
the draft, not about handling it as error. It was also
about mentioning (5) _together_ with (2) as "archaic" near
to "optional".
No big deal, but I wanted to clarify this, reading the IRC log
I got the impression that it wasn't absolutely clear, that (5)
is not only archaic but irrelevant, while (2) is a simple MUST.
Thanks for this lucid clarification.
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx