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

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 10 Jan 2005 01:02:56 -0800 (PST)

On Mon, 10 Jan 2005, Stephane Bortzmeyer wrote:

> > There is a new I-D for the SPF email anti-forgery system available
> > for review.
> ...
> > 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.
> 
> There have been apparently no reply. Does it mean that nobody see
> solid problems and that there is a silent and rough consensus that
> the I-D can move forward :-)

I do see some problems, but I already raised them at spf-discuss. 
But since you asked about it on namedroppers, I'll focus just list
what I do not like as far as dns is concerned:

1. The draft says that if SPF record is not found for say "sub.example.com", 
that lookup should be made for zonecut record which would probably be
"example.com". This is done as a way to simulate *.example.com and provide
spf record for all subdomains (especially when they exist unlike "*"), but
I think the problem is that these default SPF record are not identified 
any difernent as with "*" and its just normal spf record for that domain 
that is always the default and one can not turn this off. I have proposed 
instead using special prefix - possibly "*spf*" or just "**" so that
such records are clearly identified, this would also allow in the future 
to add feature to dns server itself that it could substitute default on 
its own instead of forcing client to do 2nd lookup each time.

2. I'm still not perfectly happy that SPF is reusing TXT and especially 
that this draft has changed all examples to use TXT instead of SPF record 
type. In my opinion SPF draft should promote new SPF record type a lot 
more and have clearly defined "exit" strategy of moving away from TXT 
records once new DNS RR has been issued.

-- 
William Leibzon
Elan Networks
[email-masked]

--
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: Dean Anderson <[email-masked]>
Date: Tue, 11 Jan 2005 10:47:35 -0500 (EST)

SPF has been shown not to work, and I've collected about 14 major problems
with it, posted on ietf-mxcomp.  SPF fails to achieve the goals set out,
and makes some problems worse.  The ietf-mxcomp working group (created for
SPF) has shut down.  But some people continue to push SPF ahead anyway.  
I think the reasons are financial. Some have patents and products, and
want an IETF stamp of approval for their marketing literature.

Indeed, I thought you were one of the people who wanted to push it ahead
despite the failures.  Is your post a rhetorical question?

I think the silence (and workgroup dissolution) means that people have
realized that it won't work and that no one has any solutions.

		--Dean

On Mon, 10 Jan 2005, Stephane Bortzmeyer wrote:

> On Mon, Jan 03, 2005 at 08:41:36PM -0600,
>  wayne <[email-masked]> wrote 
>  a message of 47 lines which said:
> 

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 11 Jan 2005 16:52:39 +0100

On Tue, Jan 11, 2005 at 10:47:35AM -0500,
 Dean Anderson <[email-masked]> wrote 
 a message of 47 lines which said:

> SPF has been shown not to work,

This is clearly off-topic for this group. As said by the chairs at
IETF 61, "DNS extensions" should focus on DNS issues, like Paul Vixie
did by addressing the new RR type question.

---

From: wayne <[email-masked]>
Date: Tue, 11 Jan 2005 12:21:45 -0600

[ Moderators note: Post was moderated, either because it was posted by 
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subsrcibers. Please fix your 
   subscription addresses. ]

[note:  I've cc:'ed this to SPF-discuss because I think they will find
it useful.]

>> the I-D can move forward :-)

I wish.  ;-)

> what I do not like as far as dns is concerned:

Yes, William has made a very large number of very helpful comments
about the various SPF drafts.  I've addressed many, but not all of
them. 

> its own instead of forcing client to do 2nd lookup each time.

The idea of using a special subdomain for the default SPF record has
been kicked around before.  I know that Mark Lentczner (another I-D
author), and I talked about it a little bit.  Going back over the
comments I made to you on the SPF-discuss list, I see that I didn't
talk about it.

The reason why I didn't say anything about it was because I don't have
very strong feelings about the subject either way.  Right now, the SPF
I-D makes no mention of any special domain names or sub domains, so
I would kind of like to avoid creating one.  Also, if mandating a
special subdomain will generate complaints about "breaking wildcards",
which is another subject I don't have strong feelings on, but others
do.

Another possiblity would be to create a different record at the top of
the zone, with a different version string of, say, "v=spf1-default".
Then you could do something like "v=spf1-default redirect=%{d}" if you
want to get the current semantics, or "v=spf1-default -all" to deny
all email coming from subdomains without SPF records.  If the default
SPF record is really long and DNS packet space is limited, you could
use "v=spf1-default redirect=*spf*.%{d}" and get the semantics you
suggest.

Note:  These default SPF records are should only be used in cases
where mail claims to come from a subdomain that email normally
shouldn't come from.  The SPF spec says that domain owners should use
explicit SPF records for all other cases.  So, extra DNS lookups
shouldn't be a huge problem.  Legitimate email should never have the
overhead, and spammers would gain no advantage to using them.

> records once new DNS RR has been issued.

As I've mentioned many times, I just don't see any practical migration
strategy for DNS RR usage.  The implicit MX rule of using the A record
is still very much needed after all these years.

The language that is in the draft about using TXT RRs and SPF RRs was
something that Mark Lentczner worked out with "the DNS folks" during
the MARID WG process.  (No, I don't know exactly who "the DNS folks"
were.)   Yes, I did many (but not all) of the examples, but that is
because I don't see why deployment of name servers that support the
SPF RR type for many years.

-wayne