wayne [wayne(_at_)midwestcs(_dot_)com] wrote:
What I am talking about is only checking for valid syntax on a
token-by-token basis. What I don't like is an SPF record like
"v=spf1 mx <random garbage>" returning "pass" some of the time and
"unknown" other times. This includes things like typos, invalid
syntax, unknown mechanisms, etc.
My reading of the SPF spec is that whether an implementation decides
to check the syntax of the complete record or not is unspecified.
Some implementations MAY return "unknown" anytime there is a
syntax error anywhere in the record, while others MAY return "unknown"
only some of the time.
I absolutely agree.
This is what I meant when I wrote:
| Further, invalid records should be treated the same (be it
| "unknown", "error", or whatever) in *all* cases, i.e.
| regardless of whether some mechanism(s) preceding the error
| could match. This makes errors that are due to
| misconfigurations easily reproducible.
I do not think that this uncertainty is a good thing. When we are
talking about authorization issues, fuzziness and undefined behavior
just gives me the creeps.
It scares me, too.
Personally, I also think that allowing some implementations to accept
mechanisms that are not in the spec and do different things is a bad
idea.
I absolutely agree, as I wrote:
| Making the validity of an SPF record depend on the *parser* is
| a very bad thing to do. No undefined mechanisms should be
| allowed in "v=spf1" records, i.e. no extensibility in
| *specific* versions of SPF! This makes the effect of published SPF
| records predictable.
I cannot stress this enough.
If unknown mechanisms are allowed at all, I think something
like Mark Shewmaker's suggestion in the "Extensibility" thread is a
good idea.
A fallback procedure for unspecified/unknown mechanisms creates a disparity
between how SPF records are interpreted by strict SPF testers compared to
testers which support additional, non-standard mechanisms. Mail messages that
are *only in some cases* accepted by a non-standard mechanism will be either
clearly accepted or clearly rejected *in all cases* by the fallback. This
could even lead to recipients demanding that their MTA admins install SPF
testers which support these non-standard mechanisms, undermining the overall
stability of SPF, and promoting a non-centralized, chaotic evolution of SPF.
See what happened to HTML a few years ago when browsers started supporting
non-standard tags.
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.5.txt
Wiki: http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)���v¼����ߴ� �1I�-�Fqx(_dot_)com