The SPF spec can not express the policy you want.
Correct - but I assume that we're discussing this topic because the spec can be
changed?
Set up a process that checks your SPF record periodically.
Doesn't work, because the current spec makes the result of an SPF check
implementation dependent. If I had a copy of all SPF implementations, I could
check for it, otherwise I can't.
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.
No - but that's irrelevant as long as it can do the things we want.
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.
This decision is better than having no spec on the topic, but it surely makes
the SPF include: less useful and very dangerous. What I am suggesting is not to
return to a worse solution, but to go forward to a better solution, that can do
exactly what you just described, for those who want that, while doing exactly
what the SPF publishers want, too. At the same time, it's more intuitive, and
can be much easier controlled because it's more deterministic in its behaviour.
I don't understand why you don't want to improve SPF at no cost?
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.
If you can give me a single example of an SPF record that has been designed for
a loop situation, that wouldn't be improved by my proposal, I would agree. But
I sincerely doubt that you could create even a theoretical example that
supports your opinion.
Lars.