Subject: SPF I-D for review: draft-schlitt-spf-classic-00.txt

From: wayne <[email-masked]>
Date: Mon, 03 Jan 2005 20:41:36 -0600

[ Moderators note: This post needed manual approval.

   Either it was posted by a non-subscribed address, or the posting
   was too large ( > 20000bytes ) for this list.

   With the massive amount of spam, it is easy to miss and therefore
   delete posts that need manual approval.

   Please use your subscribed address to post, or shorten your
   postings by using links instead of attachments. ]

fyi;

There is a new I-D for the SPF email anti-forgery system available for
review.  This draft tries to document the current practices of the
~~1,000,000[1] published SPF records and ~10,000[1] deployed SPF
systems that are checking 20-100million emails per day.

See: http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-00.txt

Discussions about this, and previous, drafts have been taking place on
the [email-masked] mailing list.  To subscribe or read
the archives, see http://spf.pobox.com/mailinglist.html

While I have been reading this mailing list for many months and will
note any comments posted here, sending email to the spf-discuss list
or to me personally is probably better than flooding this list.

I realize that the whole subject of SPF (and similar systems) has a
certain amount of controversy to it, but for the purposes of this
draft, I am very reluctant to try debate these issues.  The goal is to
document a de-facto standard.  Debates about better techniques, why
SPF is evil, etc. are probably best discussed on things like the IRTF
ASRG list, SPAM-L, the NANAE newsgroup, or on spf-discuss on a
separate thread/subject.

While SPF mostly deals with the [2]821 SMTP level, it also relies
heavily on DNS to communicate between the domain owner, and the email
receiver.  This I-D also makes provisions to create a new RR that is
just a clone of the TXT RR type.  While I did not make it to IETF-61,
it is my understanding that Stephane Bortzmeyer made a presentation on
this subject during the DNSEXT session.  I would like to thank
Stephane and the WG chairs for this review, and I would also like to
thank Ed Lewis for the presentation he made at the MARID Interim
Meeting last spring.

-wayne

[1] These numbers are estimates, but pretty solid ones.  I have data
to back them up and they are almost certainly underestimating the real
numbers.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 11 Jan 2005 14:45:01 -0800 (PST)

On Wed, 12 Jan 2005, Don Stokes wrote:

> What's wrong with a wildcard TXT (or better still SPF) RR for such
> subdomains?  Put that in the SPF spec, rather than speculatively heading
> up the three.

"*" wildcards are only useful for hosts that don't exist at all (no dns 
RR of any kind for that hostname), but they will not work for hosts that 
have some RR record which is what SPF people are after.

P.S. Is there some reason you have not read the Ed Lewis's wildcard draft 
that was discussed on this list just couple months ago? 
 
-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 11 Jan 2005 22:11:30 -0800 (PST)

On Wed, 12 Jan 2005, Paul Vixie wrote:

> > > ... how would you propose to discover the "zone cut" you're speaking of?
> > 
> > By checking the authority section:
> 
> did you know that the authority section is optional in positive responses?
> (have you read RFC 2308?)

Positive responses are not a problem - if somebody queries for SPF RR and 
gets it, there is no need to do anything else. If there is no authority 
section for negative response, then client can directly query for SOA.

> > > i know how i had to do it in bind8's res_findzonecut() ...
> > 
> > Personally I'd not mind with having that function becoming part of resolver,
> > that will sure help us out ...
> 
> it has been part of the BIND resolver library since BIND 8.2 or so. but
> you are asking that every SMTP listener possess it and call it on every
> SMTP session, which is a lot of potential extra traffic for all concerned.

Which is exactly why I said that we should make it special prefix that
dns server can recognize it and synthesize the answer. The client can
simulate this with zonecut method but as more dns servers begin to
support it, its no longer a problem in the long run.

---
William Leibzon
Elan Networks
[email-masked]

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 11 Jan 2005 23:10:24 -0800 (PST)

On Wed, 12 Jan 2005, Paul Vixie wrote:

> it is very nearly unthinkable to me that a mail server, as a client of dns,
> should ever have to make an SOA query, under any circumstances, especially
> not fairly common circumstances.  ("positive" includes NOERROR/NODATA.)

As I said, on the tests it appears that dns servers (bind 8 and bind 9 
at least) do provide this information nearly all the time including for 
NOERROR/NODATA, so I don't think querying for SOA is going to be needed 
very often. And yes it does sound weird for non-dns service to query for 
soa,  but its not breaking anything either as far as I can see and querying
for soa can be usefull for more then just dns internal communication, for 
example to find tech/hostmaster address if whois is not available (ok, you 
can go ahead and blame me for this trick and inappropriate use :)

> > > ... are asking that every SMTP listener possess it and call it on every
> i really am pretty sure that the dns servers will be changed to support 
> SPF other than to support a new RRtype when y'all get around to 
> proposing that.

Should I take as that you're willing to support such a feature (synthetic
wildcard for existing hostname but without needed RR) in future versions
of bind? In that case it makes sense for this to become a new dns protocol
feature so that other dns servers would know how to support it too, so I 
think it would be good idea to write it out as ietf document (separate and
not just part of spf draft).

And to make it possible to identify dns records where such new wildcard 
does need to be supported, I think we do need special prefix (and its not 
too late as I don't even know any spf implementation that is doing zonecut  
default checks yet). 

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 12 Jan 2005 10:41:09 +0100

On Wed, Jan 12, 2005 at 06:24:47AM +0000,
 Paul Vixie <[email-masked]> wrote 
 a message of 23 lines which said:

> spf has been a marketing-driven juggernaut since its first day, and
> nothing anybody has been able to say has changed its course by even
> a degree.

Not really, for instance the "DNS walking up to the zone cut" is a
very recent addition, no SPF implementation currently does it.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Jan 2005 14:36:55 +0000

i wrote:

> i really am pretty sure that the dns servers will be changed to support SPF

s/will/won't/.  sorry.  (though it was clear in context, i suppose.)

> other than to support a new RRtype when y'all get around to proposing that.

---

From: Chris Thompson <[email-masked]>
Date: Wed, 12 Jan 2005 22:25:29 +0000 (GMT)

Florian Weimer <[email-masked]> writes:
> * william elan net:
> > Positive responses are not a problem - if somebody queries for SPF
> > RR and gets it, there is no need to do anything else.
> 
> SPF lookup for domains used in Internet mail *always* result in
> positive responses because there exists an MX or A record for that
> domain.  Conforming resolvers do not return an error code in this
> case, but an empty data section.

Despite the RCODE=NOERROR setting, such responses are most naturally 
classified as "negative": see RFC 2308. In particular, an SOA record 
would be in the authority section if the _recommendations_ of that RFC 
are followed, allowing the stab-in-the-dark at the zone boundary being
proposed for SPF.

Disclaimer: this isn't meant to indicate approval for the I-D being
discussed, or indeed for anything whatsoever associated with SPF. :-(

Chris Thompson
Email: [email-masked]

---

From: John Levine <[email-masked]>
Date: 13 Jan 2005 16:49:05 -0000

>> I would surmise that none of your clients use djbdns as their DNS
>> software.  Its cache does correct negative caching, but it doesn't
>> return SOA records as additional or authority data.  You don't have to
>> like djbdns, but enough people use it that you can't wave it off.
>
>It is likely that my code has not been tested on djbdns, but doing
>digs by hand, I could not find any problems.  Pobox.com uses tinydns
>and checking ns1.rightbox.com seems to return SOA records just fine.
>
>Could you please give me some more details?

Tinydns is the server, which returns SOA.  Dnscache is the cache,
which does not, e.g., using my local cache:

$ dig mail.iecc.com a  

; <<>> DiG 8.3 <<>> mail.iecc.com a 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;;      mail.iecc.com, type = A, class = IN

;; ANSWER SECTION:
mail.iecc.com.          23h54m28s IN A  208.31.42.99

;; Total query time: 127 msec
;; FROM: xuxa.iecc.com to SERVER: default -- 208.31.42.32
;; WHEN: Thu Jan 13 11:39:33 2005
;; MSG SIZE  sent: 31  rcvd: 47

$ dig mail.iecc.com txt

; <<>> DiG 8.3 <<>> mail.iecc.com txt 
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;;      mail.iecc.com, type = TXT, class = IN

;; Total query time: 69 msec
;; FROM: xuxa.iecc.com to SERVER: default -- 208.31.42.32
;; WHEN: Thu Jan 13 11:39:29 2005
;; MSG SIZE  sent: 31  rcvd: 31

Normal clients ignore the authority section, so dnscache doesn't
include it.

I don't know anyone who runs a promiscuous dnscache, but if you want
to send me a set of IPs you use, I'd be happy to give you access to
mine for testing.

>> Beyond the faux wildcard issue, there are some other DNS issues with
>> SPF that I'm wondering about.  The most serious is the blizzard of
>> requests that interpreting SPF records can require.
>
>This is also a large concern of mine.  Have you read the current I-D?
>In particular, the processing limits for the number of DNS requests?

Yes.  That's why I mentioned the mysterious failures.  You set up your
SPF to include:bigisp.net, you test it, it works great.  Then
bigisp.net rearranges its mail servers, adds another couple of lookups
to its SPF, and now your SPF has stopped working.  That doesn't strike
me as robust design.

>In practice, very few domains come even close to the process limits.
>(I have done surveys of all SPF records in the .com, .net and .org
>domains.  Results from the surveys were posted on the MARID list.)

Indeed, but "this fixed limit is plenty big" has led to grief more
times than I can count.  It's a KICK ME sign.

>> there anything helpful one could say other than suggesting that they
>> take the bushiness out?
>
>You mean by removing the include: and redirect= mechanisms?  That
>would be a huge incompatiblity, and wouldn't by itself solve the DoS
>problems.

My suggestion has always been that you run the big complicated set
calculations when you construct your SPF record, and then publish the
set of IPs that it finds.  If the result of the calculation changes,
you rerun it and update your DNS data.  That's what my FSP strawman did.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
http://www.taugh.com

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 13 Jan 2005 18:18:10 +0100

in the time since i first proposed the two-label rule, someone pointed out
    CO.UK to me, where it's actually a three-label rule.

And not only that. If example.org is not only a domainname but also
the name of the mx host for this tiny example organisation it should
be a one-label rule :-).  And then I thought about 1.3.e164.arpa...

But the basic lesson is that the number of labels don't tell you
anything about the structure og the name space.

	jaap

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 13 Jan 2005 16:07:43 -0800 (PST)

I've gone through list of all popular dns servers listed at 
http://mydns.bboy.net/survey/ and tested if they return SOA with
NODATA or not. For the servers that have at least 0.1% market
penetration (BIND8, BIND9, djb TinyDNS, Microsoft DNS, MyDNS,
PowerDNS, SimpleDNS+, PlantDNS, UltraDNS, NSD) - they all do!.

John points an interesting picture of how it works different with dns 
caching servers so I'd like to know if there is a webpage that lists 
different caching servers implementations so I could do more tests
(as well as if there is way to find location for at least one of
 those caching servers - i.e. like fpdns helped me to locate dns
 servers to test on)

---

From: Dean Anderson <[email-masked]>
Date: Fri, 14 Jan 2005 04:04:32 -0500 (EST)

On Thu, 13 Jan 2005, Edward Lewis wrote:

> Time for a periodic rant.
> 
> >We all agree there are broken software and hasty implementors. But the
> >bug in the mentioned program is so huge, there is nothing the draft
> >authors could have done against it.
> 
> Why isn't such a situation brought to the attention of the IETF?
> 
> The IETF is supposed to design "good" protocols and to develop 
> "clear" documents.  ("Good" manifested in achieving Proposed 
> Standard, "clear" manifested in achieving Draft Standard.)

How about "good" as in SOLVING PROBLEMS, not just making patent holders
money selling defective products?

I was told that the fact that discussing that SPF standarization is dead
(dead for good technical reasons) is off-topic.  In some sense, the debate
of that point is off-topic. That conclusion was made by another working
group and it is certainly off-topic to try to rehash that conclusion.

And supposing SPF _email_operation_ is offtopic, then about 50 of the last
75 messages are also off-topic. This group isn't here to solve SPF bugs,
but rather to determine if SPF has negative impact on DNS operation.

Certainly, this discussion is worthy of a dilbert cartoon...

Pretty obviously, there are several "on-topic" issues:

1) DNS cache impact
2) DNS server load issues
3) Is SPF a gratuitous change to DNS if SPF won't be standardized

There has been almost no discussion of the above.

What is off-topic to DNS is:

1) mail client bugs which reject email
2) implementation of mail clients
3) implemenation of mail servers.
4) mail protocol issues
5) whether the SPF Working group made a mistake

Here are some relevant facts that shouldn't be ignored:

	1) THE SPF WORKING GROUP CONCLUDED THAT SPF HAS INSURMOUNTABLE
TECHNICAL PROBLEMS
	2) THAT THE SPF WORKING GROUP HAS DISSOLVED AS A RESULT OF THESE 
TECHNICAL INSURMOUNTABLE PROBLEMS

These facts, particularly the last one, are of relevance to the DNSEXT
working group. It is not topical to debate the merits of the IETF-MXCOMP
(SPF) working group findings. However, they cannot be ignored.  It is not
the purpose of this group to consider the merits of SPF.  However, this
working group should respect the findings of other working groups.  The
conclusions of other working groups are relevant to this groups' work.

That being the case, there is little point in considering its impact on
DNS, as its not part of the IETF protocol suite.

We know by the continued zeal of SPF proponents in spite of the
dissolution of the SPF working group, that these SPF zealots will have no
interest in any negative DNS effects, anyway.  Any inconvenient findings
will be ignored.

With that in mind, I'm interested to know what the "hoped-for" outcome of 
this discussion is going to be?  What's the best that could happen?

Is it just that proponents of SPF hope to reverse their failure in the SPF
working group and get this working group to standardize their proposals
(without analyzing them in detail)?

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000