In <a0602040dbcf377dd8caa(_at_)[192(_dot_)136(_dot_)136(_dot_)83]> Edward Lewis
<edlewis(_at_)arin(_dot_)net> writes:
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.
You snipped off the first sentence in that paragraph:
# In unusual situations, directives may require additional DNS records.
If, for example, you are hotmail and your list of outgoing IP
addresses is too large to fit in a single 512B UDP DNS packet, you
should split the information into two (or more) records. These
additional records need to be placed somewhere, and the SPF spec
recommends a spot for them.
The vast majority of domains won't need to do this. This doesn't have
anything to do with looking two differen places for stuff, the first
spot will direct you to whatever the second place is that you need to
look.
# 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.
I have investigated this issue some, and from what I can tell, this
doesn't happen.
I must admit, that it I was involved with SPF a long time before I
found out that a single TXT record can have *multiple* substrings.
Each substring is a single byte length, followed by that much data.
So, a TXT record like '@ TXT "hello" "email" "world"' is really three
different substrings, and they are not concatinated together in the
resolver. (See rfc1035 for details)
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. [...]
I don't think this paragraph is very clear, but the idea is that you
would never cross a zone cut boundary, there is no parent/child zone
cut involved. If workstation.example.com is in a *dfferent* zone cut
than example.com (e.g. it has been delegated), then it would not be
allowed to use an SPF record from example.com for
workstation.example.com.
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?)
The "error" result is for DNS server failures and other temporary
failures like running out of process/memory/whatever. In this case,
the email should not be dropped, but the client MTA should be told
(via the 450 STMP code) to try again later.
The "unknown" result is for things like syntax errors and such where
simply retrying later will be unlikely to change anything.
Section 4.4:
# 4.4 "a"
Does this cover IP4 and IP6?
Yes. See section 4.3:
# If the SMTP connection is IPv6, read "AAAA lookup" for "A lookup",
# except where "A" lookups are explicitly specified.
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.
The problem is with using malicoius SPF record such as:
v=spf1 a:%{t}.victim.com a:%{t}.victim.com a:%{t}.victim.com ..."
Such a SPF record could be used for DoS attacks. There is no good
reason to use the timestamp as part of an SPF mechanism, and if each
evaluation of %{t} is different, it will create a different DNS
lookup.
-wayne