-----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: Sunday, May 22, 2005 4:30 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: [spf-discuss] For SPF Council review - FAIL PermError vs. NONE
NXDOMAIN (was: BTFOOM)
Mark wrote:
ACK, PermError != 5xx reject is dangerous, harmful, and bad.
Glad we are in complete agreement on this. :) I have been
saying so as well for the last few days.
Apparently we all agree, but Julian trying to add more cases
into the PermError class on one side, plus Scott on the other
side trying to devaluate PermError to None seriously confused
not only Wayne.
I would say trying to make an error behave like it did in SPF classic and
not like it does for SenderID.
Please find some resolution about this in the Council:
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 NCDOMAIN 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.
If I gave you the impression that we should reject on address
literals, then let me quickly take the opportunity to rectify
that miscommunication.
Good. That was a small bug in lentczner -00, domain literals
somehow ended as a "FAIL malformed domain". Even for the very
harmless case HELO [1.2.3.4] from an IP 1.2.3.4
SPF isn't the place to tell receivers what they might wish to
do if the IP does _not_ match. Or if there's no dot in a HELO
FQDN. SPF deals with sender policies, good, bad, or ugly.
But not with other SMTP errors like malformed domains. After a
bad HELO a client is AFAIK free to RSET and try a better HELO.
Bye, Frank
As it happens, I answered a query to spf.pobox.com today asking for help in
constructing an SPF record. The questioner sent mail from a
secureserver.com mail server, which is part of the godaddy.com
infrastructure. Now the godaddy.com SPF record is still broken as I
mentioned a week or two ago:
godaddy.com text "v=spf1 a:69.64.33.132 a:66.98.160.100 a:64.202.160.108
ip4:64.202.167.0/24 ip4:64.202.166.0/24 ip4:64.202.165.0/24
ip4:64.202.163.0/24 ip4:64.202.189.0/24 ~all"
Since there isn't a .132, .100, or .108 tld, a:69.64.33.132 a:66.98.160.100
a:64.202.160.108 will all return nxdomain.
In this case, I advised that they go complain to godaddy.com to fix their
record, but in the meantime, should all domains that have
include:godaddy.com in their SPF record be rejected?
If I thought people were rejecting on PermError/Unknown, then I'd have had
to advise him not to publish an SPF record until Godaddy gets themselves
fixed. That isn't going to help adoption.
Scott K