I was asked to make some comments on the SPF document. These
comments are based on the -01 of draft-mengwong-spf.
Section 2.1:
# If additional records are used, they MAY be published under the
# "_spf" subdomain. See Appendix B for examples.
Allowing for a second location is an invitation to encourage chained
subsequent queries. E.g., looking at the "normal place" and then if
needed the second place.
If the strategy is to ask for all record types and all locations
simultaneously, then we'll have many queries issued per event (and
per answer). Multiple parallel queries are done already and aren't
the death of any protocol, but if taken to extremes can be a problem.
It would be really good to limit the number of places/types sought to
just what is needed.
# Note: Many nameserver implementations will silently split long
# strings in TXT records into several shorter strings.
I don't know if this will be an issue, but if a name server ever
splits into multiple TXT RR's you'll need to make people aware of
that. In DNS terminology, ever since RFC 2181, we've talked about
"sets" of RR's and not single RR's as the unit of work in DNS. RR
sets are sets - no duplicates and no guaranteed ordering, so if there
are multiple TXT RR's involved, spf would have to do it's own
reassembly. This may be a non-issue, but it was one that hung up
review of the OE document on how it experimentally used TXT RR's.
Section 2.2.2:
# If a domain has no SPF record, clients MAY substitute SPF data from
# a parent domain ONLY IF the appropriate parent domain's SPF record
# sets "match_subdomains=yes". For example, if no SPF record is
# found for "workstation.example.com", clients MAY proceed to
# automatically query "example.com". The appropriate parent domain
# to fallback on MUST be determined according to the DNS zone cut.
This relates to something that came up in the early days of DNSSEC.
It's not a good idea to assume that there's any relationship between
the parent and child of a zone cut. In DNS naming, there's a
hierarchy, but that doesn't translate into any other hierarchy of
authority. E.g., the root zone does not represent the center of the
Internet nor the center of email processing.
The point is that it's not wise to let the protocol try to make the
parent of a delegation look like the parent of the child
organization. If you want to allow child zones to follow the parent
zone's rules, then I'd recommend a two part mechanism. Both side
have to consent, it's not fair for just one side to unilaterally rely
or speak for the other.
Section 3:
# Error: indicates an error during lookup; an MTA SHOULD reject the
# message using a transient failure code, such as 450.
#
# Unknown: indicates incomplete processing: an MTA MUST proceed as
# if a domain did not publish SPF data.
Does this include a DNS server failures? E.g., let's say that the
com servers are down but there is an example.com server running. You
can't get to it - but it's not a fault of the example.com
organization. Should mail be dropped in this case? (Or am I
confusing something?)
Section 4.4:
# 4.4 "a"
Does this cover IP4 and IP6?
Section 4.8:
# ... DNS A record query ...
and/or AAAA?
Section 7.1:
# Use of the "t" macro in DNS lookups would greatly reduce the
# effectiveness of DNS caching. The "t" macro is only allowed in
# explanation records. The value of the "t" macro SHOULD NOT change
# during the evaluation of a given SPF record.
With "t = current timestamp in UTC epoch seconds notation" I don't
understand the problem. I'm not questioning the statement, I just
don't see why this is given the text that is present.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis +1-703-227-9854
ARIN Research Engineer
"I can't go to Miami. I'm expecting calls from telemarketers." -
Grandpa Simpson.