...... Original Message .......
On Mon, 02 May 2005 22:56:30 -0500 wayne <wayne(_at_)schlitt(_dot_)net> wrote:
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
OK. We have to balance that against the added deployment risks. Here are
some added thoughts:
If the risk is limited to a hole in the macro responses, how about treating
a macro error as the macro mechanism not matching rather than PermError.
Then the parser will trundle on to the end of the record and act
accordingly (-all, ?all, etc.).
If we do that, then Mr. Phisher can't break the record and there is no need
to reject on PermError.
Should a ?all record ever cause a rejection?
The current spec would cause domains that use include: to be at risk. Who
knows, maybe my ISP adds some new servers and changes their SPF record to
add a couple of a: mechanisms and now my record is over the processing
limits (even though their record is legal and I didn't change anything).
Now my mail gets rejected even if it's not sent through that ISP.
Scott Kitterman