[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of Mark
You are asking them for something they are most unlikely to
grant and
which will be meaningless if granted.
Huh? RFC 2119 ("Best Current Practices"), Section 4, reads:
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.
RFC 2119 was written 8 years ago.
Its 'do as we mean' not 'do as we said'. Since the RFC was written the
use of SHALL and RECOMMENDED have been dropped for standards.
You can use them in Best Current Practices I think.
Heck, I have been asked to write a note to say what the experiment is in
an 'experimental' RFC, like since when was 'see what happens' good
enough.
You can't have a MUST there because it's a receiver side interpretation
of data received. MUST means that the protocol will break if the
statement is not followed.
I don't think that you have the slightest chance of persuading the IESG
that the reason you want to put a MUST NOT there is anything other than
your dispute over patent license terms. As Harald is pointing out the
proposal to go to v=2 suggests that PRA supreceeds the legacy checks.
All you can do here is to put in SHOULD NOT and even that is going to be
ignored. The whole point of a spam filter is that you are flouting the
SMTP spec by throwing the email into the bit bucket. Nothing that is
done can ever be more than a suggestion to the recipient.