On Fri, 6 May 2005, David MacQuigg wrote:
You're still angry from when Verisign tried to put wildcard in .com/.net
zones - that is not exactly correct use of wildcards. You have to be
careful what you use them for and how and make certain that administrator
of parent domain has full right to make decisions for ANY child subdomains
(no matter wildcarded or not).
.com has the technical *ability*, not the legal *right* to capture email to
me(_at_)mycompany(_dot_)com(_dot_) At least that's my understanding of US law. Someone tell
me if that's wrong.
I suspect its not an easy question to answer. ICANN and Verisign
obviously disagreed on this point and the question addressed by
further legal proceeding was different.
That statement is not correct. Neither CSV nor DK any more or less
incompatible with DNS. And it would also be true that use of _namehack
does not make problem of wildcards any bigger or smaller then what
it is with SPF. I had a long post on this subject during MARID already,
don't have time to search archives, perhaps somebody else can.
As I understand it, a domain name like _client._smtp.*.mydomain.com is
illegal in a zone file.
No, that is not true. This in fact has already been discussed on this list
before, you have misunderstanding due to not knowing the difference
between hostnames and domains. I'll refer you to the real source however:
http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00591.html
Then *.mydomain.com is legal, and a query for SPF records on any name
under mydomain.com should work.
*.mydomain.com is legal hostname and carries no special meaning
* when applied to domain name specification has special meaning as wildcard
In other words you can query directly for '*' and it you get the answer on
that specific record but for dns protocol its used expansion default
record for use with unknown domain zones that are not specifically
subdeligated from parent.
Don't be in such a hurry to post about subject unless you're already
well familiar with it to be able to do it. This will save you from
unnecessary flames....
Then I will never learn anything. One hour of the right kind of discussion
is worth ten hours of reading a book. Flames don't bother me, except that
they very quickly make discussions unproductive.
There is a difference between posting and asking a question and posting as
if you think that must/should be so. Also make clear when you're referring
to your opinion on the matter or when you have technical knowledge about
the subject.
Plus some forums have certain basic requirements (not necessarily officially
published, but generally understand by everyone involved) about understanding
of the subject of technical matters expected from participants, so that
discussion on the forum productive (this is true of most ietf lists, btw).
If you are are on such forum, it is good to take some time to hear what
is being said and make sure you understand the arguments and what they
are about, if it seems that you do not understand what is being said but
everyone else does, its probably good idea to familiarize yourself more
with this subject and possibly move to lower-level forum where people learn.
DNS has worked remarkably well, and it really is the best way to provide
an email authentication service.
I'm curious what you base such a statement on? Its not all clear to me
even though I've a have done considerable research on the subject by now.
I assume you are objecting to the second statement. Again, I'm not an expert
in DNS, but I can't imagine a more efficient way to provide a packet of
information about any domain on the planet. UDP instead of TCP. Record
caching. Redundancy. Mature technology, already deployed.
Lets Compare to HTTP: redundancy, caching, mature technology. Ok, maybe
its not UDP but you know there are limitations to UDP as well...
There is no reason deployment should necessarily involve existing
protocol, IETF has commented several times that such reasoning is
not convincing to overloading one protocol and that its better to
develop new protocol that maybe based on existing one but then goes
towards direction that specific protocol needs. That is what happened
to SIP which was originally based on HTTP. The IAB specifially said
they wait people stop using HTTP for everything they can think of and
make better architectural decisions:
http://www.faqs.org/rfcs/rfc3426.html
And the above is especially true about DNS because of its importance
to the stability of the internet, there are a lot of other protocols
that depend on it and overloading of it may be more dangerous then HTTP.
That said again nothing stops you from building new protocol that is
UDP based and works similar to dns. In fact SES chose that and so did
SIQ proposal.
Saying some of them seem apathetic is not dismissing what they say.
My apologies. Their apathy is usually way to dismiss the subject hoping
it'd go away or resolve on its own. Trust me - its better then direct
opposition.
I understand their objection to SPF. I'm just disappointed to see no
alternative proposal. DNS is the key to the solution. The DNS folks
should have jumped on this long ago.
In 2002 first RMX proposals came up on namedropprss from dns folks.
No jumping then and not much now either - not their style I guess...
And I happen to agree with them somewhat because SPF seems to have been
put together out of plaster of multiple pieces in a way as to make it
most convenient and most marketable to users. This is not necessarily the
best way to create a security infrastructure, in fact if you look at
Microsoft which often has used same principles with their extensions
and programming in Windows, you'll see that such marketing and
user-convenience principles can later lead to wide-ranging security
implications and that can become a problem that is very hard to manage when
such design is widely used by everyone and then the problem can effect 100s
of millions of internet users and take long time to fix.
The question really is if they are overestimating the problems in spf1 too
much or not (they probably are - dns designers are extremely cautious).
If there is a one-in-ten chance that what they worry about will happen, we
should fix it. Radu has a possible solution with his "mask" proposal.
I've put that into a "Quick Reject" method QR1 which could run
Mask is not that much useful considering more serious underlying problems.
QR is not going to happen now either as people want something now and not
another year of design and then re-deployment and what we have now is
SPF1/Classic. As I said, work on what you think is good to have, but don't
put much hopes on immediate deployment until spf3 is really taken as work
item on this list.
As far DNS - I perosnally think DNS folk are too cautious. DNS problems
are nothing new and operations & isp people have long history of working
them out (which most of you're are not even aware of unless you attend
correct conferences) and these are not the main stopoever right now.
As far as widerange redesign for spf3, the reason we are not working on
it is because spf community still has not recovered from political chaos
caused by SID and MARID and SPF Council has been slow dealing with that
and finalizing push of spf1 through ietf. They have not provided directions
and there is yet no opportunity for open discussions for future spf version
design yet. I was personally hoping we could get started on Unified SPF and
spf version x (x>1) from this february if not earlier.
You gotta understand how bad this sounds to the non-techie politicians and
lawyers at the FTC who are ready to kick butt. I just hope their next
solution isn't as ineffective as CAN-SPAM. I'm hoping to get them focused an
a simple neutral "standard" that will not require changing everything in SPF,
but will allow the industry to move forward, even while we diddle with the
details.
Its not good idea to work out technical problems under political pressure,
ends up byteing you in the xxx later and results are solution that is not
the best you could have for the problem at hand and may even cause more
problems. I'm happy that politicans express interest in anti-spam matters,
but I think they should stand back for a little bit, especially from
techical matters - the issue is known and being worked on more seriously now.
I also have some hope that you might see spf forwarding and couple other
major problems resolved by with new proposals by end of the year for sure,
in fact it might even happen a lot sooner.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net