spf-discuss
[Top] [All Lists]

[spf-discuss] Design bugs in v=spf1 (was: Issue tracker for 4408bis)

2006-09-19 13:18:04
-----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-----

-------
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/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com