Subject: comments on SPF

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Jun 2004 12:28:56 -0400

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.

---

From: wayne <[email-masked]>
Date: Mon, 14 Jun 2004 14:56:12 -0500

> subsequent queries.  E.g., looking at the "normal place" and then if

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.

> 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)

> 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. 

> 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

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.

> 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.

> 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

---

From: Edward Lewis <[email-masked]>
Date: Mon, 14 Jun 2004 16:30:54 -0400

>#   In unusual situations, directives may require additional DNS records.

I guess I had left that off because it didn't make sense to me.  The 
following part of your note does clarify it - perhaps including the 
example in the draft would help.

>spot will direct you to whatever the second place is that you need to

In that case, why not just rely on the DNS RR set, putting multiple 
RR's in the same location?  You'd have to define how to 
reassemble/combine them.

...

In response to the thought of multiple TXT RR's...

>I have investigated this issue some, and from what I can tell, this

Looking at the first item in this reply, perhaps it would be 
something to pursue.  'Course, I'm not a fan of using the TXT record, 
but looking on one place and getting many is preferable to having to 
"chain" lookups to get more.

>allowed to use an SPF record from example.com for

Okay - I tripped over the mixture of "parent domain" and the zone cut.

>#      except where "A" lookups are explicitly specified.

In section 4.8, you mention "A" lookup.  Is AAAA explicitly not done 
in that case?

While looking at that I noticed I marked up 4.6 (but didn't dog ear 
it).  It says "Check all validated hostnames ... If any do ..." 
Instead of checking all, why not check until one is found that 
satisfies the condition?

>evaluation of %{t} is different, it will create a different DNS

I see.  I guess I never say anything that explained the "t" other 
than the definition as equaling the current time stamp and then the 
warning about it's impact on DNS.  Maybe it would be clear to show an 
example or explain a "positive" use for the macro.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: wayne <[email-masked]>
Date: Mon, 14 Jun 2004 17:54:40 -0500

> RR's in the same location?  You'd have to define how to

Because what makes the records "too large" is that they no longer fit
in a 512B UDP packet.  Putting them in a RR set won't help.  Falling
back to TCP is more expensive than several UDP DNS lookups due to the
three-way TCP handshake setup and the four-way TCP teardown.

> In section 4.8, you mention "A" lookup.  Is AAAA explicitly not done

Sorry, I didn't check that reference.

Yes, the exists: mechanism explicitly checks *only* A records, even if
the MTA connection is via IPv6.  This is to maintain compatibility
with already existing DNS blacklists and whitelists.

> Instead of checking all, why not check until one is found that

I'm not sure why Meng phrased this section the way he did, but you can
certainly short-circuit the evaluation.

> I see.  I guess I never say anything that explained the "t" other than
> the definition as equaling the current time stamp and then the warning
> about it's impact on DNS.  Maybe it would be clear to show an example
> or explain a "positive" use for the macro.

Personally, I'm not that attached to the %{t} macro variable, so maybe
I'm underselling it.

The idea is that it would be used in conjunction with the exp=
(explanation) modifier.  While the (macro expanded) explanation text
can be anything, typically it is a URL that someone who had their
email rejected can go to for a more complete explanation.  The
timestamp can be added as an argument to the cgi-script, along with
the IP address, the email address that was used, etc.  The timestamp
could then be used to narrow down the exact email that was sent, or to
format it in a localized format, or whatever.

The %{t} macro variable is an example of something that I think could
be gotten rid of from SPF without any problems, but then, it also is
trivial to implement.

-wayne

---

From: Aredridel <[email-masked]>
Date: Mon, 14 Jun 2004 17:39:23 -0600

> with already existing DNS blacklists and whitelists.

Any reason not to query for ANY?

Ari

---

From: Greg Connor <[email-masked]>
Date: Mon, 14 Jun 2004 20:38:27 -0700

> Any reason not to query for ANY?

I can come up with one, though I don't have a strong preference on this. 
DNSBLs are often set up to return an A record if you are on the list (like 
127.0.0.2) and a TXT record for "more info" (which not all users will care 
about).  Using a A query allows you to get the shortest response, and if 
you want more info, you can query for txt, or some users might want to 
query for ANY at the start, if they are always going to record the TXT if 
present.

It is remotely possible that a directory structure might have TXT records 
for a label but not A records.  In that case, the TXT might contain 
descriptive info about the IP (or whatever you are requesting) but not be 
an "active listing".  I would say if there is no A record it should be 
considered not to exist for purposes of exists: even if there is other data 
there.  So, if someone does an ANY query, they should explicitly check for 
an A in the reply.

--
Greg Connor <[email-masked]>

---

From: Aredridel <[email-masked]>
Date: Mon, 14 Jun 2004 22:41:17 -0600

> > Any reason not to query for ANY?
[clip]

> there.  So, if someone does an ANY query, they should explicitly check for 

Hm. In the interest of future-proofing, it might be nice to specify ANY.
Imagine twenty years from now when IPv4 is finally seen by most as
antique, and AAAA is the normal query. Perhaps the MARID system will not
seem so baroque then as it might otherwise.

Ari

---

From: Edward Lewis <[email-masked]>
Date: Tue, 15 Jun 2004 10:38:22 -0400

>with already existing DNS blacklists and whitelists.

That answers my question.

>Personally, I'm not that attached to the %{t} macro variable, so maybe

;)