In <7979306(_at_)pamho(_dot_)net> "Roger Moser"
<Roger(_dot_)Moser(_at_)pamho(_dot_)net> writes:
Meng Weng Wong wrote:
mechanism = 1*ALPHA [ ':' *VCHAR ] *[ '/' *DIGIT ]
modifier = 1*ALPHA '=' *VCHAR
It should be
mechanism = ALPHA *ALPHANUM [ ':' *VCHAR ] [ dual-cidr-length ]
modifier = ALPHA *ALPHANUM '=' *VCHAR
In libspf-alt v0.2, I also allowed '-' and '_' in mechanism names. I
decided to remove this extention in v0.3 until the spec is changed.
Otherwise the mechanisms 'ip4' and 'ip6' would be invalid.
'ip4' and 'ip6' are explicitly stated that they exist, so in v0.3 they
are accepted.
The parser MUST parse the SPF record from left to right.
I suggest that the parser MUST parse the complete SPF record. (This
is already required elsewhere in the spec.) I think allowing
completely random garbage at the end of an SPF record is a bad idea.
But then, when I write programs, I also always use high levels of
warnings (-Wall, etc.), 'use strict', etc., even when the program is
just a scratch program.
For an 'include' mechanism a prefix values MUST NOT be specified.
This fundementally changes the definition of the include mechanism. I
agree that 'include' is a poor choice of names for what it does, but I
don't think it is a good idea to break backwards compatibility.
Suppose a company has the policy: All our customers may send mail from
<our domain> except the dial-in users. It could have following policy:
xyz.com TXT "v=spf1 include:inc.xyz.com -all"
inc.xyz.com TXT "v=spf1 -a:dul.xyz.com/24 a:xyz.com/16 -all"
Redirect may be more appropriate for this kind of thing.
-wayne