spf-discuss
[Top] [All Lists]

Re: SPF v1 draft for review

2004-10-06 10:55:30
On Wed, 6 Oct 2004, Mark Lentczner wrote:

Friends -

Contributors
------------
The authors of the DMP, RMX and Vixie proposals are listed in the 
references section.  Is that not enough?

I don't think so. I recommend reading my previous to ietf/mxcomp post with 
example of the text the properly enumerates all parties involved:
 http://www.imc.org/ietf-mxcomp/mail-archive/msg03973.html
And see text in responsible-submitter-00 draft and how that lists prior work.

And please remove double-mention of MARID/mxcomp from contributors section.
 
New RR
------
The wording an design of this section was done in conjunction with DNS 
guru types.  It doesn't include the stronger language they desired 
which would have made the new RR type required for both publishers and 
receivers.

It is by design that publishers can choose not to publish the TXT 
format if they wish.  One can only hope for a day when deployment makes 
this a reasonable option.

It is also by design that which order to query the types isn't 
specified.  Implementations may choose to query both simultaneously.

My personal perference is perfectly represented by the following:

 http://www.imc.org/ietf-mxcomp/mail-archive/msg03802.html
 "> > Why not:
  > >    SHOULD publish SPF2
  > >    MAY publish TXT
  > >    MUST publish at least one of the two."
 
 
Repeated Modifiers
------------------
Section 4.6.3 says "The same key MUST NOT appear in more than one 
modifier in a record."  The intent is that modifiers cannot be 
repeated, and any repetition results in a syntax error (PermFail).
Why can they not be repeated?

Modifiers are something that some clients are able to process and some
can not. Its up to the client to be able to decide if repetition of
the modifier is to be considered an error in regards to that modifier
or not. But I don't think this should be disallowed for all modifiers
directly by the protocol draft.
 
As this is a specification, it should not sanction tolerance of 
non-well-formed records, or records with ambiguous semantics (such as 
having two "exp=" sections).  Implementations, will of course, vary in 
their degree of strictness.

Case Sensitivity
----------------
Since the specification is defined using the ABNF of RFC 2234, all 
alphabetic literal characters (those in double quotes) in the syntax 
are case insensitive.  So, yes, "v=spf1" and "V=SPF1" and "v=SpF1" are 
technically all legal and the same.  Similarly, "+a" and "+A" are the 
same.  On the other hand, the characters that make up domain-spec and 
macro-string, as they are specified with percent notation (as in 
%x30-7E), are case sensitive.

I have long suspected that this is NOT really agreed upon understanding 
of SPF v1.  Comments?

It would be good that you specifically mention in the protocol text that
version and operator and modifier names should be treated as being
case-insensetive.

-- 
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net