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" (I've never seen the
form of verb "valid" as descriptor before, although I'm sure its perfectly
legal in english as with all other verbs being used in similar form).
Possibly consider changing this to more common synonym like "accurately"
or say that "its a valid pointer to" instead of "validly points to".
| 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'
----------------------------------------------------------------------
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.
----------------------------------------------------------------------
| 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
Software evaluating check_host() can use this string when it needs to
communicate information from the publishing domain in the form of a
----------------------------------------------------------------------
| 7.1 Processing Limits
| ...
| SPF implementation SHOULD limit the total amount of data obtained
| from the DNS queries. For example, when DNS over TCP or EDNS0 are
| available, there may need to be an explicit limit to how much data
| will be accepted to prevent excessive bandwidth usage or memory
| usage, and DoS attacks
Grammer. Change to:
available, there may need to put an explicit limit on how much data
will be accepted to prevent excessive bandwidth usage or memory
usage, and DoS attacks
General comment on this section:
1. I would say this all belongs into "Security Consideration" rather
then separate regular section
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.
----------------------------------------------------------------------
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. In this regard, I would recommend changing from "SHOULD"
add Received-SPF header to "MAY" add Received-SPF or "MAY" use other
mechanism or trace header to record results of SPF verification in
similar way to how its described. At the same it should still say
that recording results in some way (or some header) is "SHOULD"
(i.e. SPF client MAY add Received-SPF for it or MAY add
Authentication-Results header but it SHOULD add at least one).
I also would like to see it specifically mentioned that Received-SPF
as it is being defined is a TRACE HEADER.
----------------------------------------------------------------------
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!
---
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net