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.
Ya know, I've been pondering this some more, along with Shew's recent
post about what to do with HELO checking.
In the draft-mengwong-spf-0[01] drafts, none of the SPF results (fail,
pass, unknown, etc.) are documented as saying that MTAs SHOULD reject
a message. In the draft-lentzcner-spf-00 draft, and continued on into
the draft-schlitt-spf-classic-0[01] drafts, only the PermError result
is document as the MTA SHOULD reject the message. Even Fail says "The
checking software can choose to mark the mail based on this, or to
reject the mail outright."
I still think that syntax errors, including bad domains on the
include: mechanism, should result in PermError, rather than None.
However, my immediate reaction to what Shew asked about with respect
to the HELO checking is that "mail admins can do whatever they want to
do with the SPF result for either or both of the SPF HELO/MAILFROM
checks. Their server, their rules." I think the SPF *result* needs
to be consistent, as that determines the sender's policy for a
particular email, but if people want to start rejecting on "None" or
accepting email on "Fail", that is up to them.
As Scott points out, people are probably not rejecting on PermError
(or "Unknown"). I know that I'm not directly rejecting on them. Due
to running the T-FWL, I am more tolerant of accepting questionable
messages now that I was 2 years ago. All email gets flagged with SPF
results, and SPF results are factored into the SpamAssassin score, but
I do not directly reject on PermError.
Should the language in the PermError section be toned down to match
the flexibility of the other SPF results? Does it really make sense
to say that PermError SHOULD be rejected when Fail doesn't?
See
http://www.schlitt.net/spf/spf_classic/draft-schlitt-spf-classic-01pre5.html#op-result
-wayne