Scott Kitterman wrote:
Mark wrote:
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 [...]
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?
Well, I guess it's a balance between that and how much pressure should
be put on godaddy.com to fix their SPF record. It seems that there is a
desire not to affect email delivery when such issues occur, but also not
to let the issue go unnoticed so that administrators might be notified
of the problem and deal with it. A "none" result just doesn't do that.
The more I've read, the more I like "SoftFail" for this. Failing that,
the definition of TempError seems appropriate -- except that it also
seems to imply that a 4xx will result, and one wouldn't expect a problem
like godaddy.com's to fix itself.
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.
If I was looking to add an include= into my SPF policy, I would want to
be sure that it was valid -- and I might remove the include if at some
later point their policy developed problems they didn't fix quickly. I
certainly wouldn't want to refer to a broken policy. I wouldn't extend
that to revoking or not publishing an SPF policy of my own. I perceive
it as a problem that godaddy.com -- despite any pressure it might get
from administrative types on this issue -- isn't feeling more pain for
having a broken record on the face of it. If it were a question of
"<whine>that's hard, so I'm going going to do it</whine>" versus taking
responsibility for implementing policies to encourage/enforce good
behavior, then we'd all be running Microsoft Windows with auto-login
enabled and using WINS globally instead of DNS. ;-)
Bill