In <NGBBLEIJOEEEBMEIAPBKAEECIAAA(_dot_)scott(_at_)kitterman(_dot_)com> Scott
Kitterman <spf2(_at_)kitterman(_dot_)com> writes:
In the pre-MARID specs, a syntax error would result in an unknown result.
Unknown was to be treated exactly like None.
Now, a syntax error results in PermError and SHOULD be rejected.
I feel pretty strongly that rejecting messages from a domain with a
malformed SPF record is a really bad idea. People new to SPF make all kinds
of mistakes. If after the first mistake, they start getting messages
rejected, they'll just give up and go home.
Rejecting messages based on a syntax error makes SPF deployment much more
risky.
Instead of SHOULD reject, it should be treated as None.
First off, I consider any argument in the form of "previous SPF
specifications and implementations did XXX, therefore the current
draft should also" to be a strong argument. Not an absolute given,
but compatibility this is the goal here.
That said, I tend to think that treating errors as if there were no
SPF records to not be a good idea. In particular, if a domain uses
various macro variables in their SPF record, then it is often quite
possible for a phisher/spammer to construct an a situation to cause a
PermError. If a PermError is treated the same as None, then this
creates a huge hole in the sender's policy.
Besides RECOMMENDING doing an SMTP reject (5xx code) for a PermError,
I could see RECOMMENDING that a SMTP temp fail (4xx code) be given for
a PermError. This is what is recommended for the SPF TempError case.
The difference between TempError and PermError is that TempError's can
be caused by things like network outages, or problems with the DNS
setup. PermError's require you to fix your SPF record, or in a few
cases, fix your email.
One problem with SMTP temp fails is that spam can build up, with
continual retrying. Once upon a time, we recommended STMP temp fails
for part of SPF, but because of the buildup of spam, we changed it. I
don't remember exactly what the situation was, I'll try researching
it.
I think all of the following options have been blessed by previous
specs and/or major SPF implementations. In the case of PermError
(aka "unknown"), which should we do?
1) Treat PermError as "None"
2) Treat PermError as "Fail"
3) RECOMMEND PermError be rejected via SMTP 5xx responses
4) RECOMMEND PermError be temporarily rejected via SMTP 4xx responses
By the way, thank you Scott for raising this issue. I hope others
raise any other issues they have. Remember, once the SPF spec becomes
an RFC, you can't change it except by creating a new RFC. This is our
last chance to get it right.
-wayne