Terry Fielder wrote:
we constantly hear "how things should be" in different
opinions, and sometimes I confuse suggestions with the
realities.
Sometimes I confuse -00...-01pre5 with -01pre6...-01, and I
really try to read most discussions, diffs, IRC logs, <sigh>
A part of the problem is, that the drafts only try to create
this "reality", claiming to describe it. But there are many
"realities", implementations, drafts, different POVs of users,
etc. It's a propaganda trick, e.g. announcing the drafts in
spf-announce or spf-deploy could help that at least Carl is
informed about essential stuff like a new "SHOULD test HELO".
That's an excellent grid. Can we put that into the docs?
Maybe better in a FAQ or a HowTo on the new Web site, if it
always reflects what the actual draft says or means. 4xx or
5xx is not necessarily what really happens, post-SMTP tests
don't have it, and receivers could also ignore any TempError.
Or something like that if certain cells have alternative
responses (don't get mad Frank, recall we are documenting
what SPFv1 *is*, not necessarily what we would like it to
be)
Defining "is" is tricky, who knows how many implementations
exist, based on which spec., maybe allowing to configure the
interpretation of results in wild and wonderful ways. Wayne's
"validating implementation" concept _is_ "new" in a way. But
also necessary for the reliability of the whole v=spf1 idea.
senders are still better off with SPF provided they are OK
with either alternative(s) where applicable for situations.
With post-SMTP tests, which is a polite phrase for "kill FAILs
silently, and while you're at it kill also SOFTFAILs", I want
the expected / intended results as clear as possible.
If a user says "but that should be a PASS, why was it bounced /
rejected / deleted", and the problem was a HELO FAIL, then it
starts to get messy without a clear "read 2.1 in the spec."
He might be still mad, but at least he's wrong. That's not the
moment where a "some receivers do this, others don't, it isn't
specified" helps.
Bye, Frank