-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This thread really belongs on spf-discuss, so please follow up there.
Before I comment on Wayne's ideas, I'd like to point out the suggestions I
made in March 2006:
http://thread.gmane.org/gmane.mail.spam.spf.discuss/20730
Wayne Schlitt wrote:
> [...] I can think of a few more that I really would like to see changed:
>
> * macro expansions that create DNS labels that are longer than 63
> characters should be truncated to 63 characters.
Agreed.
> * Similarly, creating empty lables due to marco expansion, especially
> with the split char stuff, should remove the empty labels.
I have a very bad gut feeling about this proposal. Perhaps empty labels
should cause a PermError, or fall back to a default label, e.g. "_".
> * I would be very tempted to get rid of the split characters entirely
> and replace them with a default set. [...]
Probably a good idea.
> * Get rid of the distinctionn between ip4: ip6: and a:. This is a
> common source of errors when people construct SPF records and they
> can all be unambigous distinguished. This is one case were
> Caller-ID got it right, Microsoft used one XML tag for both A and
> IP4. Strangly, MS used a seperate tag when a CIDR notation was
> needed, which SPF got right.
The distinction between "ip4:" and "ip6:" is obviously useless, but I think
that "a:" should stay separate. I know it will eternally cause confusion
with some folks, but specifying a hostname, and thereby requesting a DNS
lookup, is simply a different matter from directly specifying an IP
address and should be made explicit. If some people have a problem with
that, they need to learn about DNS.
> * rename include: to something like if-pass. It is *really* badly
> named right now and causes a lot of confusion.
Why not just name it "if:" (less confusing) and provide "include:" as a
deprecated (confusing but backwards compatible) alternative?
> Stuff I feel less certain about:
>
> * redirect= used to be a mechanism, and was changed to a modifier. I
> think it might be best to converted it back to being a mechanism.
> Then, no modifiers would ever change the SPF result.
Answering Frank's question what modifiers were supposed to modify if not
the SPF result: modifiers could be seen as having side effects _only_. At
least that was the rationale behind tolerating unknown mechanisms and not
erroring out on them.
Thus I agree that "redirect" should be a mechanism.
> In libspf2, I accepted both redirect: and redirect=. If redirect: had
> a prefix (+, -, ?), it would be used as the default result if the
> target didn't exist.
Too magical!
> I could also see the prefix being ignored or having a special case of
> redirect: being one mechanism that doesn't have a prefix.
Interesting idea. (Let's call it "qualifier", not "prefix", though.)
> * maybe create a call: mechanism that works like you would expect
> include: to work: It would return the SPF result of whatever the
> other record was, and only not match if there wasn't a -all or
> something on the end. [...]
What would the point of that be?
> * There should be ways of specifing older versions or other scopes. I
> think these can both be handled unambigiously by putting /<version>
> or /<scope> tags on the end of the include:, redirect= and, if we
> add it, call:.
An interesting theoretical idea, however I don't see the point.
On a related note, though, I think that we shouldn't say "v=spf7/<scopes>",
but introduce a positional "s=" modifier that specifies the scopes for the
following mechanisms until the next "s=" or the end of the record.
> Ok, that said, I really don't think we should do anything serious with
> SPFng until the IETF allows us to create a WG that can put SPFng on
> the standard track. That is, about 1.5 years from now. Collecting
> ideas is a good idea though.
Who said the IETF wants us to daze for another "1.5 years from now"? That
may be a misconception.
Unrelated to what the IETF wants, I seriously doubt that we can afford to
wait anytime near that long with another revision of SPF. We ought to
offer the policy semantics that people are going to miss with DKIM, and
(IMO) more importantly (althouth people don't yet recognize it), PGP and
S/MIME.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFEE/dwL7PKlBZWjsRAjSBAJoCkyFegKDehRvWPB+cDaZNEKBoWQCdFrAJ
t54ON9gx5o26PXEg52vmaHw=
=hmGC
-----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
Hash: SHA1
This thread really belongs on spf-discuss, so please follow up there.
Before I comment on Wayne's ideas, I'd like to point out the suggestions I
made in March 2006:
http://thread.gmane.org/gmane.mail.spam.spf.discuss/20730
Wayne Schlitt wrote:
> [...] I can think of a few more that I really would like to see changed:
>
> * macro expansions that create DNS labels that are longer than 63
> characters should be truncated to 63 characters.
Agreed.
> * Similarly, creating empty lables due to marco expansion, especially
> with the split char stuff, should remove the empty labels.
I have a very bad gut feeling about this proposal. Perhaps empty labels
should cause a PermError, or fall back to a default label, e.g. "_".
> * I would be very tempted to get rid of the split characters entirely
> and replace them with a default set. [...]
Probably a good idea.
> * Get rid of the distinctionn between ip4: ip6: and a:. This is a
> common source of errors when people construct SPF records and they
> can all be unambigous distinguished. This is one case were
> Caller-ID got it right, Microsoft used one XML tag for both A and
> IP4. Strangly, MS used a seperate tag when a CIDR notation was
> needed, which SPF got right.
The distinction between "ip4:" and "ip6:" is obviously useless, but I think
that "a:" should stay separate. I know it will eternally cause confusion
with some folks, but specifying a hostname, and thereby requesting a DNS
lookup, is simply a different matter from directly specifying an IP
address and should be made explicit. If some people have a problem with
that, they need to learn about DNS.
> * rename include: to something like if-pass. It is *really* badly
> named right now and causes a lot of confusion.
Why not just name it "if:" (less confusing) and provide "include:" as a
deprecated (confusing but backwards compatible) alternative?
> Stuff I feel less certain about:
>
> * redirect= used to be a mechanism, and was changed to a modifier. I
> think it might be best to converted it back to being a mechanism.
> Then, no modifiers would ever change the SPF result.
Answering Frank's question what modifiers were supposed to modify if not
the SPF result: modifiers could be seen as having side effects _only_. At
least that was the rationale behind tolerating unknown mechanisms and not
erroring out on them.
Thus I agree that "redirect" should be a mechanism.
> In libspf2, I accepted both redirect: and redirect=. If redirect: had
> a prefix (+, -, ?), it would be used as the default result if the
> target didn't exist.
Too magical!
> I could also see the prefix being ignored or having a special case of
> redirect: being one mechanism that doesn't have a prefix.
Interesting idea. (Let's call it "qualifier", not "prefix", though.)
> * maybe create a call: mechanism that works like you would expect
> include: to work: It would return the SPF result of whatever the
> other record was, and only not match if there wasn't a -all or
> something on the end. [...]
What would the point of that be?
> * There should be ways of specifing older versions or other scopes. I
> think these can both be handled unambigiously by putting /<version>
> or /<scope> tags on the end of the include:, redirect= and, if we
> add it, call:.
An interesting theoretical idea, however I don't see the point.
On a related note, though, I think that we shouldn't say "v=spf7/<scopes>",
but introduce a positional "s=" modifier that specifies the scopes for the
following mechanisms until the next "s=" or the end of the record.
> Ok, that said, I really don't think we should do anything serious with
> SPFng until the IETF allows us to create a WG that can put SPFng on
> the standard track. That is, about 1.5 years from now. Collecting
> ideas is a good idea though.
Who said the IETF wants us to daze for another "1.5 years from now"? That
may be a misconception.
Unrelated to what the IETF wants, I seriously doubt that we can afford to
wait anytime near that long with another revision of SPF. We ought to
offer the policy semantics that people are going to miss with DKIM, and
(IMO) more importantly (althouth people don't yet recognize it), PGP and
S/MIME.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
iD8DBQFFEE/dwL7PKlBZWjsRAjSBAJoCkyFegKDehRvWPB+cDaZNEKBoWQCdFrAJ
t54ON9gx5o26PXEg52vmaHw=
=hmGC
-----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