Mailing List Archive

On Monday 25 September 2006 16:33, Stuart D. Gathman wrote:
> Suppose an SPF record has a macro syntax error in an unknown modifier:
>
> example1.com IN SPF "v=spf1 foo=%(i)"
> example2.com IN SPF "v=spf1 exp=%(i)"
>
> Should either or both of these be a PermError?
>
> Con: example1.com case not explicitly mentioned that I can find
>
> Pro: *is* explicitly mentioned for exp= modifier. Implementing
> exp= is optional. If macro syntax errors don't apply to *all*
> modifiers, then an implementation may, or may not return
> permerror for example2.com depending on whether they implement exp=

My vote would be example2 is PermError (because it's a known modifier with
known bad syntax). Example1 is unknown modifier. If the modifier is
unknown, it's unknown. That's all one can know.

Scott K

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

In <Pine.LNX.4.44.0609251627470.30274-100000@bmsred.bmsi.com> "Stuart D. Gathman" <stuart@bmsi.com> writes:

> Suppose an SPF record has a macro syntax error in an unknown modifier:
>
> example1.com IN SPF "v=spf1 foo=%(i)"
> example2.com IN SPF "v=spf1 exp=%(i)"
>
> Should either or both of these be a PermError?

I believe that both should be PermError as they do not pass the ABNF
for modifiers and macro variables.


The relevant ANBF is:

modifier = redirect / explanation / unknown-modifier
redirect = "redirect" "=" domain-spec
explanation = "exp" "=" domain-spec
unknown-modifier = name "=" macro-string

macro-string = *( macro-expand / macro-literal )
macro-expand = ( "%{" macro-letter transformers *delimiter "}" )
/ "%%" / "%_" / "%-"
macro-literal = %x21-24 / %x26-7E
; visible characters except "%"
macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
"c" / "r" / "t"
transformers = *DIGIT [ "r" ]
delimiter = "." / "-" / "+" / "," / "/" / "_" / "="

name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )


While the meaning of "foo=" is undefined, the syntax isn't. "foo"
does match the <name> term, but "%(i)" does not match the
<macro-string> term since the '%' is not followed by any of [{%_-].

By the same logic, the spf record "v=spf1 a$b=7" is a PermError
because "a$b" does not match the term <name>.


Note that redirect= and exp= both require <domain-spec>, while unknown
modifiers are free to have any <macro-string>. This is actually one
loophole in the ABNF that prevents a single regular expression from
matching if-and-only-if the SPF record is valid. An SPF record of
"v=spf1 exp=7" is a PermError because "7" isn't a valid <domain-spec>,
but the ANBF/regexp would then fall back to matching "exp" against
<name> and say it is fine.


-wayne


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

On Mon, 25 Sep 2006, wayne wrote:

> In <Pine.LNX.4.44.0609251627470.30274-100000@bmsred.bmsi.com> "Stuart D. Gathman" <stuart@bmsi.com> writes:
>
> > Suppose an SPF record has a macro syntax error in an unknown modifier:
> >
> > example1.com IN SPF "v=spf1 foo=%(i)"
> > example2.com IN SPF "v=spf1 exp=%(i)"
> >
> > Should either or both of these be a PermError?
>
> I believe that both should be PermError as they do not pass the ABNF
> for modifiers and macro variables.
>
>
> The relevant ANBF is:
>
> modifier = redirect / explanation / unknown-modifier

Ah thanks. It *is* explicit. I just get bleary eyed having looked
at this stuff so much for the test suite.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stuart D. Gathman wrote:
> [...] Implementing exp= is optional. [...]

Where does the spec say that?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFGHKIwL7PKlBZWjsRAtJdAJ9y0ncrstw4SMfOHPsOWSwGWVgNegCdE1xd
KO1gbH2evGQ8SMcVEUDjOmU=
=b4ym
-----END PGP SIGNATURE-----

-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com

Stuart D. Gathman wrote:

> example1.com IN SPF "v=spf1 foo=%(i)"
> example2.com IN SPF "v=spf1 exp=%(i)"

> Should either or both of these be a PermError?

Both are invalid "%(". Near the top of page 28:

| A '%' character not followed by a '{', '%', '-', or '_' character is
| a syntax error. So
|
| -exists:%(ir).sbl.spamhaus.example.org
|
| is incorrect and will cause check_host() to return a "PermError".

> Implementing exp= is optional.

You're not forced to honour it, but not implementing it would
be rather radical. There's a problem with the intentional
loophole about syntax errors:

They MUST be reported (= PermError) as soon as you find them,
any you SHOULD parse the entire record before evaluating it.

But you can also evaluate a record left-to-right, and defer
the evaluation of modifiers to "only if necessary". Running
out of mechanisms without match (no "all") if there is a
"redirect=" anywhere is a case where implementations MUST
evalute this modifier.

Unrecognized modifiers MUST be ignored. I guess there are
at least three ways to get this right:

- parse complete record first => any "%(" is a PermError
- parse left to right looking at modifiers only if needed:
-- identify modifiers by presence of "=" => ignore "foo=".
-- look into "exp" only for overall FAIL => ignore "exp=".

But you're still supposed to catch more than one "exp=" as
syntax error on your way left to right. IMO it's simpler
if the test suite reflects the "parse all" recommendation
(SHOULD), the left-to-right business can be tricky.

> an implementation may, or may not return permerror for
> example2.com depending on whether they implement exp=

IMHO that misses the point, ignoring an offered explanation
isn't exactly the same as not implementing it. Of course
"not implementing it" is a specific way of "ignoring it",
but for a general purpose implementation that's dubious at
best.

If you want a test suite for LTR implementations violating
the SHOULD it's tricky. For starters in your example...

> example2.com IN SPF "v=spf1 exp=%(i)"

...there is no FAIL outcome ever, so why bother with the
details of an optionally ignored optional FAIL explanation ?

In a very imaginative interpretation of the spec. you could
claim that an exp= without possible FAIL deserves a warning,
no matter if it's syntactically okay or not.

Frank


-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com