-----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 Daniel
Taylor
Sent: Monday, May 02, 2005 9:24 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] For SPF council review: Syntax error = Perm
error = Message should be rejected?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Somewhat more constructively (Monday morning and all) perhaps a
rephrasing to MAY reject on error would be good? I'm obviously
partial to the SHOULD wording, but MAY is sufficient for my
concerns.
Since the purpose of the current spec we are reviewing is to codify what has
been deployed as SPF classic, this spec ought to be consistent with all the
pre-MARID specs.
Rejecting messages based on a syntax error in an SPF record has a number of
risks:
1. The response to rejections is, IMO, much more likely to be to get rid of
the SPF record than to try and fix it. "You promised me this SPF thing
would help with our domain being forged and now out e-mail is bouncing! Get
rid of it now!"...
2. If the error is in an included record (or if a change in the included
record causes you to go over the processing limit) then mail will start
getting rejected when the domain's base record is correct and they didn't
change anything. Once again, this will happen about once in many settings
before SPF is history. "You mean that because (insert name of ISP here)
changed something on their SPF record, our mail is getting rejected! Get
rid of it!"
Stuart's suggestion of sending a DSN to inform them of the error seems to
avoid the risks associated with rejections, but still accomplish your goal
of notifying people of errors.
Does that need to be in the spec or can people just do that?
Scott Kitterman