Subject: Re: Faux wildcards

From: Paul Vixie <[email-masked]>
Date: Mon, 17 Jan 2005 06:28:35 +0000

> > > be throwing out a lot of legitimate email.  Far too much email
> > > gets sent using HELO domains with either domain names that are
> > > only viewable inernally, are typos, or are due to
> > > misconfigurations for most people to take this stand.

speaking as someone whose postfix config rejects such mail, i can tell
you that a lot of folks have pointed out that RFC 2821 allows bad HELO
behaviour and that my servers are technically noncompliant.  i agree,
and i usually just provide my fax number along with my apologies for
any inconvenience.

> > All the more reason for enforcing the rules by refusing invalid
> > names.  People will quickly fix the problem if it's preventing mail
> > getting through.
> 
> See if you can get Hotmail to fix their HELO's.  Once they do it,
> then we can get everyone else to fall into line.

it's 2005.  anyone who does something a spammer typically does will
look somewhat like a spammer, and be treated often as a spammer, no
matter what RFC 2821 allows.  in 1995 we could bask in the warmth of
"the spec".  in 2005, every sender has to revise their view of "what
kind of traffic is actually going to get through."

people on hotmail, yahoo, or any dsl or dynamic ip range can't send
me e-mail.  that's not going to change.  i am really quite glad that
i don't have a business requirement to accept such e-mail, and i am
really quite surprised that others who also lack such requirements
still accept such e-mail.  "walks like a duck, quacks like a duck,
BLAM, it's duck soup."

but i digress.  we were talking about dns?  i already pointed out in
private e-mail to dcrocker and jlevine (a while ago) that CSV was a
fine looking proposal and might be a reasonable direction forward,
BUT that the field wasn't level and the selection wouldn't be made on
the basis of technical merit.  ("or else we'd have MAIL-FROM by now.")
SPF has no technical merit that makes it compelling in any way -- it
was born in ignorance and has been muddied by subsequent bandaids.
BUT the marketing was powerful and so there is an installed base and
so SPF actually matters, but not because it's better, or even good,
or even "good enough".  microsoft and yahoo finally realized this,
and are going to use powerful marketing rather than technical arguments
to advance "senderid" and "domainkeys" respectively.  let a thousand
flowers bloom, etc.  SPF will compete on its own terms, which aren't
and never were "technical merit".  why on earth is anybody discussing
SPF's merits as if SPF weren't just a marketing driven juggernaut?
if SPF didn't have an installed base we wouldn't be talking about it
at all, and yet a number of folks here are falling into the trap of
talking about how SPF should best be expanded.  i've recommended that
the authors document SPF as it is, and let expansion come later.  this
is because the installed base deserves an RFC to look at.  whether
expansion comes in the form of rr-specific wildcards, or switching
to domainkeys, is something for others to look at, probably elsewhere.

--
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: Paul Vixie <[email-masked]>
Date: Tue, 18 Jan 2005 21:42:25 +0000

> >> There's no need for "new" wildcards.

i disagree.  we need rrtype-specific wildcards, and nonterminal wildcards.

> >I'm not (yet) sure whether "new" wildcards is a protocol change, or
> >an "ease of use config option" on servers (i.e. an application change)
> 
> It's only a protocol change if you use AXFR or IXFR to synchronize
> servers.  It doesn't affect normal DNS client-server interactions at
> all.

it's a zone behaviour representation issue, so it's a protocol change.  if
it's to be called a protocol, then it will describe the behaviour of servers
in the presence of various kinds of authority data and in response to various
queries.  even if axfr/ixfr isn't used, then the representation needed to
cause this behaviour will still have to be signallable by dynamic updates,
and visible with maintainance queries (such as a query for a literal "*" does
in the current wildcard mechanism), and as others have noted, it will have
an impact on dnssec proofs, of both the positive and negative variety.

even if the protocol change is to say "zones using this new kind of wildcard
cannot be represented in axfr/ixfr or dynamically updated", it'd still be a
protocol change.

right now, a nonterminal "*" is meaningless to the wildcard algorythm.  it
will have to remain meaningless in case someone is using this encoding and
depending on it to be meaningless or "just an asterisk label, not special".

to add nonterminal wildcards or rrtype-specific wildcards, we will have to
define a new encoding that is currently not just meaningless but invalid.
and then we'll have to define negotiation mechanisms as necessary to ensure
that both sides of an axfr/ixfr or multiple MS-A-D masters or both sides of
a dynamic update all agree that the new encoding has a specific new meaning
and is not invalid as it would be to pre-epoch servers.  this means it's a
protocol change.  don't fear protocol changes.  we added EDNS.  we added
dynamic update.  we're adding DNSSEC.  we added TSIG.

and don't fear new rrtypes.  we added SRV and a whole lot of others.  it
takes time and that's too bad but it can be done and should be done and in
the case of SPF-like functionality, apparently it must be done.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Jan 2005 07:11:11 +0000

> Or to put it another way, if you believe that most people update their
> software, why aren't we all using IPv6?

and yet, we'll keep adding new rr types, and they'll mostly work, and
where they don't, they'll put pressure on middlebox vendors.  this is
called "progress."

---

From: Paul Vixie <[email-masked]>
Date: Wed, 19 Jan 2005 07:17:13 +0000

> I'm not saying that we should give up and never ever add a new RR type,
> but I am saying that requiring a new RR is in 2005 a major bar to
> widespread deployment.

we all knew that.  which is why we all recommended a new type be added in
2003.  now it appears that failure to heed will be rewarded by approval of
a bad design, and the lazy can become the victims.