-----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!"...
This is a valid point with respect to errors, at least initially.
A later version of the spec should be stricter about errors IMO.
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!"
This is a good reason to provide information on what the error was,
otherwise even the DSN will be treated as a nuisance in many settings.
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?
Personally, I think that if it is going to be the preferred method,
it should be in the spec. And sorry to both yourself and Stuart for the
name confusion on my previous message. Too many things at once I think.
- --
Daniel Taylor VP Operations Vocal Laboratories, Inc.
dtaylor(_at_)vocalabs(_dot_)com http://www.vocalabs.com/
(952)941-6580x203
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCdnRm8/QSptFdBtURAqIpAJ0dFDip7cVP31UEXg5xHH/guM+idACfUtsB
sKrRZHL4WqLPvwzLro2hm2M=
=RBFE
-----END PGP SIGNATURE-----