Subject: Re: draft-iab-dns-choices-02.txt comments

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 10 Jun 2005 15:13:33 -0700 (PDT)

On Fri, 10 Jun 2005, Dean Anderson wrote:

> I think if we have genuine need for a new RRtype, it can be accomodated.
> However, MARID wasn't a genuine need.

Dean,

I'm not going to go though your arguments, but from what I see the
issue is that DNSEXT is not assigning new RR types in without very very
substantial review and that creates other problems like that that 
proposals like SPF begin to use TXT as basis and then this may become 
widely used on the net.

It should not be for DNSEXT people to decide if concept itself is bad or 
good and argue about it here, you should focus on providing stability for 
dns system and let others run experiments that use dns for specific
applications and if experiment turns out to be usefull the requested RR 
assignment becomes permanent.

But trying to shut down (or not letting it start) the experiment by not 
getting it RR is just wrong and exactly why proposals like SPF or DK 
which attempt to use TXT RR instead of getting new one from the start.

-- 
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: wayne <[email-masked]>
Date: Fri, 10 Jun 2005 17:33:42 -0500

In <[email-masked]> Dean Anderson <[email-masked]> writes:

> 1.Abuser can still forge addresses at domain
> 2.Abuser can use stolen credential

These are out of scope for this list.

> 3.DNS cache problems (more records per domain, same cache size)

This is a choice that receivers can decide on.  If they don't think
the additional DNS cache is worth it, then don't use SPF checks.

> 4.DNS load (more records per domain)

This, indeed, is a problem that I wish didn't exist.  Domain owners
that don't want to deal with SPF will still receive DNS queries.  The
only thing I can suggest is to publish an SPF record that has a very
long TTL which says "v=spf1 ?all".

For domain owners that do want to publish SPF records, then that is
their choice to have more records.

> 5.Ongoing Maintenance issues
> 6.Migration issues
> 7.IP Renumbering issues

Again, this is up to the domain owners who choose to publish SPF
records.  SPF does have quite a few features that make these less of
an issue, at the expense of increased DNS loads.  The choice is up
tothe domain owner.

> 8.Lost non-spam emails
> 9.Lack of universal compliance.*
> 10.Not a basis for trust/reduced filtering
> 11.Makes forgery blowback problem much worse
> 12.Patent issues
> 13.spam-profiteering / charges for SPF services
> 14.Email Source Routing 
> 15.Outbound SMTP Relay Identification

These are out of scope for this list.

The things that are in scope for this list are reasons why I have
twice, without being asked, asked for reviews of the SPF I-D here.  If
it was up to the IESG, no review would have been done here.

-wayne