-----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 wayne
Sent: vrijdag 20 mei 2005 9:45
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] BTFOOM
In <428C4460(_dot_)5E7F(_at_)xyzzy(_dot_)claranet(_dot_)de> Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> writes:
Minor stuff from my POV:
[23:38]
<grumpy> 2338:u no
<Julian> 2337u: yes
<csm> 2337u: no
<MarkK> 2338u: yes
<csm> muahahahahahaha
TILT. MarkK tilted the Council flipper. In theory you're
supposed to reflect the Community will, not to play flipper.
I'm not sure what flipper I tilted, but Julian had put the following
motion on the table:
[01:37] <Julian> Motion: SPF shall not be applicable to non-existent
domains or syntactically invalid identities, and shall return PermError in
those cases. The behavior defined in past SPFv1 specification drafts is
inconsistent, so we have to be backwards _in_compatible in one way or
another anyway.
To which I agreed, completely consistent with earlier statements to that
effect. The whole NXDOMAIN issue is simply still up in the air.
The overall problem on this (and similarly) outstanding item(s), as far as
I see it, is the difficulty that the decision to make something a
PermError is always closely related to what should happen on PermError.
Which is to say, declaring a PermError cannot be seen apart from what is
to follow that result; and, conversely, what is declared to follow a
PermError, inevitably affects what we wish to call a PermError. For
example, if we were to ignore PermErrors, then declaring something a
PermError has an entirely different consequence than saying, for instance,
that a PermError should be met with 5.x.x codes.
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx