On Thu, 7 Apr 2005, Hallam-Baker, Phillip wrote:
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.
Which is right about the start of when current common thread of RFCs
(2000+) was started.
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.
They were never seriously used before or after mention in RFC21119, one
reason maybe is that SHALL while being used in Britain is almost unused
in US english and majority of RFC writers are from US or otherwise by
people more familiar with US english. And RECOMMENDED was always equivalent
to SHOULD anyway. But all that does not change common usage of MUST, SHOULD,
MAY and "NOT RECOMMENDED" which are present in almost every RFC.
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 may have been that you were asked to write a note of what goal of the
experiment is and how it is to be achieved through the experiment which
is quite fair thing to ask if it is not clear.
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.
The reason for MUST is that people who enter v=spf1 records do it for
reasons expressed in SPF documents as part of the participation of what
IESG calls experiment. But if others treat results differently and
unexpectedly then it dissolves the value of the experiment and may get
some people to stop participating in it (if their emails are rejected
improperly) and in the end it all means that it interferes with original
intent of the experiment and makes it difficult to estimate result of
such experiment.
These are all more then good enough reasons for MUST NOT and its definitely
up to experiment document authors and to its participants control that.
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.
There are of course companies that ignore RFCs but its not seen as a good
thing and it regularly backfires on them too. Nobody says that standards
(especially email) are perfect but we would not be able to send email or
do other things on the internet if rfc ignorance by product vendors was
common. Additionally when talking about experimental work like SPF then
its assumed that if somebody wants to participate in experiment they would
do it the way it was intended (and if they don't like it, they are more
then welcome to start their own experiment).
And as far as spam filter, you have to understand the difference between
rejecting email and using some filtering rule as part of larger system to
determine what is spam. SPF is not really anti-spam and its result is thus
a way to actually reject email if its forged (and that applies only to
those who are willing participant in this system). SPF may possibly be
used in other ways giving higher statistical probability of spam or not
spam or as white-listing (this is more common) but this different use for
filtering is personal preference and not something that we can expect for
adaption for standard process.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net