In
<Pine(_dot_)LNX(_dot_)4(_dot_)44(_dot_)0412282204090(_dot_)2737-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
----------------------------------------------------------------------
Not a serious problem but I'd prefer the last line say (slightly more clear):
sets. (Though some hosts might fall into neither category)
fixed.
----------------------------------------------------------------------
| 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
A while back, someone (Frank?) was complaining about the existance of
the "must" (lowercase) because domain owners can publish SPF records
for only one identity.
Ya can't please everyone.
| 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 ...
I've changed it to:
When publishing via TXT records, beware of other TXT records
published there for other purposes, and that this may cause
problems with size limits (see <xref target="rsize"/>.)
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...
Well, if there was a reasonably large percentage of deployed name
servers that understood the "SPF" RR type, I would agree with you.
However, until that happens, using the non-existant SPF RR type will
just cause confusion and hurt deployment.
RFC's are not forever. In 5-10 years when the number of name servers
supporting the SPF RR type moves about the single digit percentages,
an updated SPF RFC can make note of that.
| 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?
Zonecuts are in spf-draft-200406.
I admit that zonecuts are not widely implemented and this is one thing
that I could see being removed.
(So Wayne - you want to run another experiment to get the numbers?)
I have no easy way of running such an experiement.
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
Zonecut usage can be (effectively) distinguished via:
example.com. TXT "v=spf1 redirect=%{o}._spf.example.com"
example.com._spf.example.com. TXT "v=spf1 <specific record for example.com>"
*._spf.example.com. TXT "v=spf1 <general default>"
Yes, this is as ugly as stuff needed to distinguish HELO checking from
MAIL FROM checking. If we understood the sitution better in 2003, we
would likely have made better choices.
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
minor nit: Those should be ip4:127.0.0.... not a:.
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.
I'm not sure if you are saying that this is a bug or a feature. It is
my opinion that the vast majority of domain owners assume that the SPF
record they enter at the top of the zone will apply to all subdomains.
----------------------------------------------------------------------
| 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.
RFC1035 isn't clear on this subject, but it appears to be always true
that multiple strings in a single TXT record are kept in order, while
multiple TXT records are not. This has been discussed quite a few
times in the past and no exceptions have been found.
----------------------------------------------------------------------
| 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.
This is due to the fact that many (broken) firewalls silently drop TCP
port 53 packets on the (borken) assumption that all DNS traffic is
UDP. I don't think dropping these packets is a good idea, but it is a
reality and this gives another reason to SPF publishers to make their
records short.
----------------------------------------------------------------------
| 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".
The "MUST" is needed to give consistent results.
----------------------------------------------------------------------
| 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".
fixed.
----------------------------------------------------------------------
| 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?
Because other parts of the spec say that there is a default of ?all
and people depend on this.
Ok, enough for today. My commens on text for sections 5.0 and above
will be coming tomorrow...
Thanks again for your comments. Please keep sending more. Also, I
haven't changed everything you have suggested and have given an
explanation of why. If you disagree with these explanations, please
let me know.
I know that Julian has said that he has some comments comming, but I'm
really looking for more comments from other people.
-wayne