Seth Goodman wrote:
"v=spf1 ip4:192.168.0.1 ip4:192.168.0.3 ip4:192.168.0.5 -all"
"v=spf1 192.168.0.1 192.168.0.3 192.168.0.5 -all"
Oops, yes, now I got it.
Along the same lines, I liked previous suggestions for contiguous
ranges that do not align with bit masks (192.168.0.5:192.168.0.9 or
192.168.0.5:192.168.0.9 or 192.168.0.5-9). Like most syntax, it's
personal preference.
Interesting. We'd need something also working for IPv6, for this and
other reasons overloading a colon is straight out. But ".." (2 dots)
might be possible.
best guess shouldn't be implicit in the standard.
Yes, the idea (removing "+a") was "+mx", not "+mx/24". I mentioned
"best guess" and CBV only as evidence that MX-queries are not unheard
of for receivers. An SPF PASS for a MAIL FROM without MX or A would
be bogus, that could help to justify an implicit MX rule.
My definition of "host" is "LDH + IP", does that
match your definition ?
That's an A record that refers to a host.
Or an AAAA record. Or it's an alias of something with an IP. Minus
names matched by a wildcard, that would be at best a vanity host.
It looks like there would be both confusion and unintended
consequences if you made a: and mx: implicit.
Arrgghh, no wonder that I misunderstood you, you also misunderstood
me completely. When I wrote "implicit" it wasn't about "strip the
mx: from mx:an.example resulting in an.example".
What I meant was this: Treat "v=spf3 ..." policies implicitly like
"v=spf1 +mx ...", and get rid of the complete mx-mechanism in v=spf3.
It was not about the characters "mx" or "mx:".
Of course we agree that all FQDNs mentioned in a policy need an SPF
mechanism like xyz:, "bare FQDNs" would be horrible.
I mistakenly thought that "op" stood for "operation".
Originally it was "other protocols" before I twisted it into option
or optional property. Sometimes it degenerates into "old proposal" ;-)
I don't know if any others had trouble with it, but if so, maybe
"opt" would be better. If it only occurs once in a record, then
"options" is not so bad.
Maybe, but too late to change it, I've removed the "do not deploy"
caveat when it was published as I-D. And the ten SPF drafts before
the I-D go back to late 2004, almost always mentioned or announced
here. To some degree (164 matches) also discussed here:
http://search.gmane.org/?query=op%3D&group=gmane.mail.spam.spf.discuss
Frank
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735