In
<222BE5975A4813449559163F8F8CF50361D487(_at_)cohsrv1(_dot_)cohaesio(_dot_)com>
"Lars Dybdahl" <ldy(_at_)cohaesio(_dot_)com> writes:
I think that the vast majority of people would rather have email
delivered with an "unknown" SPF result rather than having valid
email rejected.
SPF is about publishing policies. My policy is, that if there's any
error in the SPF record, the e-mail should be rejected/bounced, so
that I get the knowledge that something is wrong. Other people may
wish to do publish another policy.
The SPF spec can not express the policy you want.
It's just like programming: One of the most important issues in
programming is to make sure that the error message is generated as
close to the error as possible (Dijkstra). Here, I want an error
message as soon as there's something seriously wrong with my SPF
record (like a loop).
Set up a process that checks your SPF record periodically. If you use
unix, you can use cron and spfquery. If the results are not as you
expect, report an error.
I don't see why you would want to take away this freedom of choice and
force all SPF protected domains to be potentially unprotected?
SPF can't do everything.
Be aware, that back in January/February, the issue of what should
happen when an include: failed was discussed. Before then, the SPF
spec was pretty vague. The current semantics to make SPF fail safe,
so that legitimate email will not be rejected due to an SPF error was
very deliberate.
While I understand that you would like something different, and I
understand some of the reasons why, I don't think it would be good to
change the semantics of existing SPF records now, and I don't think it
is worth it to create a new mechanism.
Maybe you can convince others (Meng in particular), but I suspect that
you are going to have to give a fairly detailed proposal about how you
can change things without breaking backwards compatibility.
-wayne