spf-discuss
[Top] [All Lists]

RE: Re: For SPF Council review - FAIL PermError vs. NONE NXDOMAIN

2005-06-01 05:48:37
-----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: Tuesday, May 31, 2005 9:36 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: [spf-discuss] Re: For SPF Council review - FAIL PermError vs.
NONE NXDOMAIN


wayne wrote:

1 - PermError is only used to indicate errors in SPF policies,
    this includes cases like redirect=any.invalid or the known
    include:any.invalid NONE => PermError

:: 2 - other cases of NXDOMAIN or domain literals result in NONE

3 - Receivers may treat PermError like FAIL, and TempError
    like SOFTFAIL, SMTP offers error codes 5xx and 4xx resp.

I admit that I'm confused about what you are asking for here.
This appears to me to be mostly a rehash of issues that have
already been decided.

It's ten days old.  Julian dropped his proposal to add NXDOMAIN
to PermError, but you didn't decide it.  Roughly my point 2.

-02pre1 does not yet have redirect=invalid as a PermError like
an include:invalid, roughly the rest of my point 1.

Mark said that a PermError shouldn't be handled like a SOFTFAIL
(4xx), but like either NONE or FAIL.  I want "like FAIL (5xx)",
not like NONE.  As polite and in "sender-policy"-style as you
wish, but still clear enough for any reader.

For TempError you say:

| If the message is rejected during the SMTP transaction for
| this reason, the software SHOULD use an SMTP reply code of
| 451 and, if supported, the 4.4.3 DSN code.

So for PermError just add:

| If the message is rejected during the SMTP transaction for
| this reason, the software SHOULD use an SMTP reply code of
| 550 and, if supported, the 5.5.2 DSN code.

Numbers copied from -01pre2 and not checked.  It's an "if",
and as far as I'm concerned s/SHOULD/can/ is also okay, also
for TempError, SOFTFAIL, and FAIL.

SPF deals with sender policies, good, bad, or ugly.
[...]

Is this also something you want the SPF council to review?

It wasn't, but now that you ask, why not, it's the "philosopy"
behind these points, as invented by you here some months ago.

                       Bye, Frank

WRT Frank's PermError suggestion....

It's a gratuitous incompatibility with the pre-MARID SPF classic design.  We
aren't trying to do protocol design here.  We are trying to document what
exists.  Frank's proposal isn't what exists.  My alternative suggestion
would be to add:

"This indicates incomplete processing: an MTA MUST proceed as if a domain
did not publish SPF data."

Note that except for the word This, that is a quote from
http://spf.pobox.com/spf-draft-200406.txt

OK.  Let's have this debate over again (or not).

Scott K