In
<Pine(_dot_)LNX(_dot_)4(_dot_)44(_dot_)0412292315280(_dot_)2279-100000(_at_)sokol(_dot_)elan(_dot_)net>
"william(at)elan.net" <william(_at_)elan(_dot_)net> writes:
http://www.schlitt.net/spf/spf_classic_libspf2/draft-schlitt-spf-02.txt
----------------------------------------------------------------------
| 5.0
| This mechanism tests if the DNS reverse mapping for <ip> exists and
| validly points to a domain name within a particular domain.
I seem to have a problem with the word "validly" [snip]
I've changed it to "correctly".
| First the <ip>'s name is looked up using this procedure: perform a
| DNS reverse-mapping for <ip>, looking up the corresponding PTR record
| in "in-addr.arpa." if the address is an IPv4 one and "ip6.arpa." if
| it is an IPv6 address. ^^- insert 'in'
fixed.
General comment for section 6.1 is that you may want to warn about
danger of using redirect in that there is a possibility of recursion,
this is especially appropriate in part of the text warning how redirect
should not go to another domain not within same administrative control.
I don't think this is needed. The process limits make any recursion
harmless, with a well defined error condition should it happen. The
same possiblity of recursion exists with the include: mechanism.
----------------------------------------------------------------------
| 6.2 exp: Explanation
| ...
| Software evaluating check_host() can use this string when to
| communicate information from the publishing domain in the form of a
Grammer errors. Either remove "when" or change to something like
fixed.
----------------------------------------------------------------------
| 7.1 Processing Limits
| ...
General comment on this section:
1. I would say this all belongs into "Security Consideration" rather
then separate regular section
I can see this point. What do other people think?
2. It is not entirely clear what happens when SPF client encounters
an SPF record with more then 10 mechanisms that require A lookup.
Does it give temperror or does it ignore extra ones and try to
resolve first ? In that case if it cant does it give SPF fail?
3. Same question as above but about limit on having to limit number
of includes, etc.
Good catch. I've added text saying that the result MUST be a PermError.
I have also spelled out which mechanisms should be counted against
this process limit instead of requiring people to know when DNS
lookups are required.
----------------------------------------------------------------------
7.2 Received-SPF
I'll read section fully and check ABNF tomorrow. However my general
comment here is that I think it maybe better if SPF considers using
Authentication-Results instead of its own header designed for same
purpose.
I presume you are referring to the
draft-kucherawy-sender-auth-header-00.txt I-D.
I looked at it, and was somewhat disappointed in it. It appears to
have many of the same ABNF problems that earlier versions of the
Received-SPF: ABNF had, and using 15 pages to discuss one header
seemed a little long. Some of the definitions in it don't fit very
well with SPF, for example, the SoftFail definition doesn't really
match. Also, their definition of "neutral" is what SPF calls "none",
and the I-D lacks the SPF equivalent of "neutral". There are no
options to add the equivalent of the Received-SPF key-value-pairs.
Basically, it appears that they have tried to create a generic header,
and as a result, no authentication method will fit exactly. This
doesn't seem like a good idea for authentication results, where clear
and exacting information is required.. If this header was already in
widespread use, it might be productive to use it, but since it is only
an I-D, I don't think we want to tie SPF to it.
I also would like to see it specifically mentioned that Received-SPF
as it is being defined is a TRACE HEADER.
Good point. It appears that RFC2822 calls these "trace fields", so
I've added that language to the spec.
I'll go through reminder of draft text tomorrow, but in case I get too busy
with other things and dont make it in next 2 days, then Happy New Year!
Again, thank you very much for your careful review and comments.
-wayne