http://www.schlitt.net/spf/spf_classic_libspf2/draft-schlitt-spf-02.txt
----------------------------------------------------------------------
| 3. SPF Records
|
| An SPF record declares which hosts are, and are not, authorized to
| use a domain name for the "HELO" or "MAIL FROM" identity. Loosely,
| the record partitions all hosts into permitted and not-permitted
| sets. (Though some hosts might fall into other categories.)
Not a serious problem but I'd prefer the last line say (slightly more clear):
sets. (Though some hosts might fall into neither category)
----------------------------------------------------------------------
| 3.1 Publishing
|
| Domain owners wishing to be SPF compliant must publish SPF records
| for the hosts that are used in both the MAIL FROM and HELO
| identities.
It might make sense to change "must" to MUST, i.e.:
Domain owners wishing to be SPF compliant MUST publish SPF records
| When published via TXT records, there may be other TXT records for
To me the above did not sound complete sentence, may I suggest rewording:
When publishing via TXT records, beware, that there may be other TXT
records for ...
Note that in general I'd like to see number of examples with "TXT"
minimzed in preference for SPF record type - IETF will tell you same
thing as well...
----------------------------------------------------------------------
| An SPF record published at the zone cut for the domain will be used
| as a default for all other domains and subdomains within the zone.
| See Section 4.5 for details. Domain owners SHOULD publish SPF
| records for hosts used for the HELO and MAIL FROM identities instead
| of using the zone cut default because the fallback requires
| additional DNS lookups. The zone cut default does reduce the need to
| publish SPF records for non-email related hosts, such as
| www.example.com.
Ok. When did we decide that there is a consensus that SPF will support
zonecut spf records for subdomains? And as usual I'm also not so sure
that existing implementations are actually making any checks in zone cuts
(So Wayne - you want to run another experiment to get the numbers?) and
as we're doing SPF draft of the current practice I don't want it included
if its not being done.
Now my personal opinion is that its ok to do it but we must make these
"zonecut" records distinguishable from all other SPF records and to do
so we may want to use special global modifier (i.e. like op=subdomains
or subdomains=true) or do lookup on special subdomain (i.e. like
" *spf* IN SPF ...." - note that *spf* is host name and will not be
considered wildcard even if it consists of multiple ones...).
If we do not make it distinguishable I feel that many dns administrators
will not remember about zonecut SPF tests and many do add SPF record
directly for their domain and I think for majority the domain is in
fact the zone, i.e. most often the situation somebody might have is like:
@ IN SOA ... (...)
IN NS ..
IN MX 0 mail
IN A 127.0.0.10
IN SPF "v=spf1 a:127.0.0.0/24 -all"
mail IN A 127.0.0.10
mail IN SPF "v=spf1 a:127.0.0.10 -all"
star IN A 127.0.5.1
----------------------------------------------------------------------
And person will forget that the main "spf" also applies to "star" which here
happened to be on different subnet and thus would fail spf lookup because
main spf record at zone cut does not include that net. I'm dns administrator
for close to a thousand domains and can tell that I would not have entered
SPF record for each and every subdomain record - only for primary zone and
for known mail servers - others I would just not know for sure or would
have had to contact many people to find out for sure when they are setup
for a client.
----------------------------------------------------------------------
| 3.1.3 Multiple Strings
|
| A text DNS record (either TXT and SPF RR types) can be composed of
| more than one string. If a published record contains multiple
| strings, then the record MUST be treated as if those strings are
| concatenated together without adding spaces. For example:
It is my understanding that if multiple strings are used there is no
gurantee that you will get them in right order from dns resolver. In
practice this is probably not true and they will come in right order
but I think we need to look at dns specs closely and if necessary add
a disclaimer.
----------------------------------------------------------------------
| 3.1.4 Record Size
| ...
| DNS answers should fit in UDP packets. Note that when computing the
| sizes for queries of the TXT format, one must take into account any
| other TXT records published at the domain name. Records that are too
| long to fit in a single UDP packet MAY be silently ignored.
You mean that SPF implementations may ignore any SPF records that cause
dropping to TCP? Hmmm.. Somehow I have a problem with that but more
importantly I think its none of our business to specify this in SPF
protocol spec.
----------------------------------------------------------------------
| 4.5 Selecting Records
| ...
| If no matching records are returned for the <domain;>, the SPF client
| MUST find the Zone Cut as defined in [RFC2181] section 6 and repeat
| the above steps. The <domain>'s zone origin is then searched for SPF
| records. If an SPF record is found at the zone origin, the <domain>
| is set to the zone origin as if a "redirect" modifier was executed.
Zonecuts again, so its related to what I wrote above and this paragraph
may need to be deleted entirely. If its not deleted however, I do not
believe its appropriate to have "MUST" for lookup on zonecut, more
approriate maybe "SHOULD" or "MAY".
----------------------------------------------------------------------
| 4.6.1 Term Evaluation
|
| There are two types of terms: mechanisms and modifiers. A record
| contains an ordered list of these mechanisms and modifiers:
To make more clear gramaticly, I would prefer "these" be changed to "the
following" or possibly "the following ABNF specified".
----------------------------------------------------------------------
| 4.7 Default Result
|
| If none of the mechanisms match and there is no "redirect" modifier,
| then the check_host() returns a result of "Neutral". If there is a
| "redirect" modifier, check_host() proceeds as defined in Section 6.1.
|
| Note that records SHOULD always either use a "redirect" modifier or
| an "all" mechanism to explicitly terminate processing.
Why is it SHOULD and not MUST?
----------------------------------------------------------------------
Ok, enough for today. My commens on text for sections 5.0 and above
will be coming tomorrow...
---
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net