On Mon, 2005-05-23 at 02:32 +0200, Alex van den Bogaerdt wrote:
On Sun, May 22, 2005 at 05:14:54PM -0700, Bill Taroli wrote:
I definitely understand the rationale for this, but as a receiving it's
nice to be able to make the decision myself. If I see conditions
resulting in PermError that don't fit my image of 5xx, then I may not
5xx in cases where it might be proper.
Hence my desire for PermError to only be given in cases where 5xx can
make sense.
For instance, if I receive an email whose mail-from domain has an spf
record of:
"v=spf1 aa:example.com -all",
IMHO that should be a PermError and should be rejected.
I'd grudgingly accept it if the spec said that receivers MUST:
o treat this the same way they treat a NONE,
o treat this the same way they treat a SOFTFAIL, or
o return a 5xx reject,
as long as it's clear that this sort of actual, unquestionable error
will commonly result in a 5xx reject.
(And with that in the spec, it's less likely that other parts of the
spec will require PermErrors for things that don't fully justify
always-rejecting.)
Sure. Your box, your rules. Also, the spec says SHOULD, not MUST.
It said that a few weeks ago, but not now.
From
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-01pre5.html#anchor11
| 2.5.7 PermError
|
| A "PermError" result means that the domain's published records |
couldn't be correctly interpreted. Checking software SHOULD
| reject the message with an SMTP reply code of 550 and, if
| supported, the 5.5.2 DSN code.
From
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-01pre6.html#anchor11
| 2.5.7. PermError
|
| A "PermError" result means that the domain's published records |
couldn't be correctly interpreted. Checking software SHOULD
| treat this result similar to the "SoftFail" result. Be aware
| that if the domain owner uses macros (Section 8(Macros)), it
| is possible that this result is due to the checked identities
| having an unexpected format.
I've always understood PermError to imply 5xx rejects, with
implementations not doing so to be suspect.
To change something in the spec of this nature because most
implementations apparently treat it differently is in my mind similar to
allowing in a new mechanism "aa:" if it happened for some random reason
that most implementations accidentally considered it equivalent to "a:".
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com