Subject: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 16 Sep 2003 00:01:12 -0400

I am forwarding this message from the ASRG list. If you haven't heard it 
yet, Verisign has activated their "typos" DNS service for .COM and .NET.

-------- Original Message --------
Subject: [Asrg] Verisign: All Your Misspelling Are Belong To Us
Date: Tue, 16 Sep 2003 03:10:52 +0200
From: Brad Knowles <[email-masked]>
To: IRTF ASRG <[email-masked]>

Folks,

	This was just posted to the NANOG mailing list.  There are
already people who are working on hacking BIND to return NXDOMAIN for
wildcard records in TLD zones, or perhaps for any reference to the
specific IP address(es) they are using (so far, we only know about
64.94.110.11).  Meanwhile, many are already null-routing this IP
address.

	This affects us, because now anyone can send spam with an address
like "[email-masked]",
and yet still have that pass standard anti-spam checks like "Does
this domain really exist in the DNS"?

	Another one for the service provider BCP, I think.

	Anyway, the full message announcing this "enhancement" is:

>Date: Mon, 15 Sep 2003 19:24:29 -0400
>From: Matt Larson <[email-masked]>
>To: [email-masked]
>Subject: Change to .com/.net behavior
>
>
>Today VeriSign is adding a wildcard A record to the .com and .net
>zones.  The wildcard record in the .net zone was activated from
>10:45AM EDT to 13:30PM EDT.  The wildcard record in the .com zone is
>being added now.  We have prepared a white paper describing VeriSign's
>wildcard implementation, which is available here:
>
>http://www.verisign.com/resources/gd/sitefinder/implementation.pdf
>
>By way of background, over the course of last year, VeriSign has been
>engaged in various aspects of web navigation work and study.  These
>activities were prompted by analysis of the IAB's recommendations
>regarding IDN navigation and discussions within the Council of
>European National Top-Level Domain Registries (CENTR) prompted by DNS
>wildcard testing in the .biz and .us top-level domains.  Understanding
>that some registries have already implemented wildcards and that
>others may in the future, we believe that it would be helpful to have
>a set of guidelines for registries and would like to make them
>publicly available for that purpose.  Accordingly, we drafted a white
>paper describing guidelines for the use of DNS wildcards in top-level
>domain zones.  This document, which may be of interest to the NANOG
>community, is available here:
>
>http://www.verisign.com/resources/gd/sitefinder/bestpractices.pdf
>
>Matt
>--
>Matt Larson <[email-masked]>
>VeriSign Naming and Directory Services

---

From: Neal McBurnett <[email-masked]>
Date: Mon, 15 Sep 2003 22:36:16 -0600

This is outrageous, both in breaking DNS, and in abusing monopoly
power.

Other references:

 http://gnso.icann.org/mailing-lists/archives/ga/msg00311.html
 http://www.icann.org/correspondence/lynn-message-to-iab-06jan03.htm
 http://www.merit.edu/mail.archives/nanog/2003-01/msg00050.html
 
What can be done besides complaining to ICANN?
 [email-masked]

Neal McBurnett                 http://bcn.boulder.co.us/~neal/
Signed and/or sealed mail encouraged.  GPG/PGP Keyid: 2C9EBA60

---

From: Keith Moore <[email-masked]>
Date: Tue, 16 Sep 2003 00:43:35 -0400

so now verisign is deliberately misrepresenting DNS results.

why are these people allowed to live?

---

From: Tim Chown <[email-masked]>
Date: Tue, 16 Sep 2003 07:33:38 +0100

Because noone can stop them doing it, apparently...

---

From: Zefram <[email-masked]>
Date: Tue, 16 Sep 2003 11:02:59 +0100

>>zones.

This is, as already noted, very dangerous.  We in the IETF must work to
put a stop to this attempt to turn the DNS into a directory service,
and quickly.  I suggest the following courses of action, to be taken
in parallel and immediately:

0. Urgently publish an RFC ("Wildcards in GTLDs Considered Harmful", or
   "DNS Is Not A Directory") to provide a clear statement of the problem
   and to unambiguously prohibit the practice.

1. Via ICANN, instruct Verisign to remove the wildcard.

2. Some of us with sufficiently studly facilities should mirror the COM
   and NET zones, filtering out the wildcards.  Then the root zone can
   be modified to point at these filtered COM and NET nameservers.

3. Instruct ICANN to seek another organisation to permanently take over
   COM and NET registry services, in the event that Verisign do not
   comply with instructions to remove the wildcard.

I believe that the direct action I suggest in point 2 is necessary,
because we have previously seen the failure of the proper channels in
this matter, when Verisign added a wildcard for non-ASCII domain names.
Verisign have shown a disregard for the technical requirements of their
job, as well as displaying gross technical incompetence (particularly
in the wildcard SMTP server).  I believe Verisign have forfeit any moral
right to a grace period in which to rectify the situation.

-zefram
-- 
Andrew Main (Zefram) <[email-masked]>

---

From: Florian Weimer <[email-masked]>
Date: Tue, 16 Sep 2003 12:21:04 +0200

> 1. Via ICANN, instruct Verisign to remove the wildcard.

By the way, what about .museum?

---

From: Karl Auerbach <[email-masked]>
Date: Tue, 16 Sep 2003 03:25:12 -0700 (Pacific Daylight Time)

On Tue, 16 Sep 2003, Zefram wrote:

> ...  I suggest the following courses of action, to be taken

> 1. Via ICANN, instruct Verisign to remove the wildcard.

It isn't clear that this power is vested in ICANN.  There is a complicated
arrangement of Cooperative Agreements, MOUs, CRADAs, and Purchase Orders
that exist between various agencies of the US Department of Commerce
(including NTIA, NIST, and others) and ICANN and Verisign/NSI.

This web of agreements is sufficiently complicated that often really isn't
exactly clear who can compel Verisign/NSI on any particular point.  In
fact it may well be that the power may not exist.  Or it may take a lot of
legal dollars and time to press the issue.

To make the situation even less clear, there is, I believe, no statement
in the relevant Internet Standards docucuments that clearly rules out this
kind of wildcarding. (Yes, I think we can all agree that this particular
use of wildcarding *is* a bad thing, I'm simply pointing out that to those
who are not technically grounded in DNS matters, that without a clear
prohibition in the Internet Standards, the matter isn't so obvious.)

By-the-way, Neulevel (.us and .biz) did an "experiment" along these lines
back in May of this year.  It was short lived.  At the time I thought it
was a bad thing, and I still do.  And at the time I wrote and sent to the
ICANN board an evaluation of the risks of that "experiment."

		--karl--

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 16 Sep 2003 12:59:37 +0200

On dinsdag, sep 16, 2003, at 12:25 Europe/Amsterdam, Karl Auerbach 

> legal dollars and time to press the issue.

I think the ICANN has no choice and has to show its teeth here, or just 
roll over and die because there no longer is a reason for its existence.

On a related note: so far I have never bothered to move my domains to a 
competing registrar before, but now seems a good time to do it. Can 
anyone recommend a procedure for select a good quality registrar? 
(Off-list if this is more appropriate.)

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 16 Sep 2003 13:55:57 +0200

> ICANN board an evaluation of the risks of that "experiment."

.nu have been doing this for a long time AFAIK.

- kurtis -

---

From: Dean Anderson <[email-masked]>
Date: Tue, 16 Sep 2003 09:05:04 -0400 (EDT)

Is it any worse than IE taking you to msn search when a domain doesn't
resolve?  Or worse than Mozilla taking you to Netscape, duplicating a
Google search, and opening a sidebar (and a netscape search) you didn't
want?

I think it isn't.

And people shouldn't be using Reverse DNS for spam checks, either. This
has been hashed out on both DNSOP and Namedroppers.  People have known not
to do this for a long time, but some still insist on it. For that reason
alone, this is a good idea.

		--Dean

---

From: Zefram <[email-masked]>
Date: Tue, 16 Sep 2003 14:18:32 +0100

>Google search, and opening a sidebar (and a netscape search) you didn't

Yes, it is worse.  Much worse.  There is a fundamental difference between
this defaulting happening in the DNS and happening in a client program.
It is necessary that the wire protocols distinguish between existence and
non-existence of resources in a standard manner (NXDOMAIN in this case)
in order to give the client the choice of how to handle non-existence.
If IE wishes to default to doing a web search under those circumstances,
that is silly but harms no one else.  What Verisign has done pre-empts
that choice for everyone.

-zefram

---

From: Keith Moore <[email-masked]>
Date: Tue, 16 Sep 2003 09:24:27 -0400

> resolve? 

yes.  if an app that interfaces to humans masks the difference between an
invalid domain and a valid one, it only affects people who use that particluar
app.  however for other apps the difference between an invalid domain and a
valid one is significant.

verisign is masking the difference between a valid domain and NXDOMAIN for
all protocols, all users, and all software.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 16 Sep 2003 08:40:06 -0500

I agree with Zefram here, for at least a couple of reasons:

- there's a difference between doing this in infrastructure and
   doing this in a client program

- there's a difference between doing this in a scenario where
  there probably really IS a human in the loop (IE) and a
  scenario where there's no reason to think that a human is
  involved (trivially, an FTP running from cron on a Unix box)

- there's a difference between doing this in a component that
  can be replaced (IE) and one that is very difficult to replace
   in a meaningful way (DNS)

Not that I think IE's redirection is a GREAT example of the
Internet at its finest...

Spencer

----- Original Message ----- 
From: "Zefram" <[email-masked]>
To: "Dean Anderson" <[email-masked]>
Cc: "Keith Moore" <[email-masked]>; "Yakov Shafranovich"
<[email-masked]>; <[email-masked]>
Sent: Tuesday, September 16, 2003 8:18 AM
Subject: Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To
Us]

> _______________________________________________
> This message was passed through [email-masked],
which is a sublist of [email-masked]. Not all messages are passed.
Decisions on what to pass are made solely by Raffaele D'Albenzio.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 16 Sep 2003 10:06:45 -0400

>in order to give the client the choice of how to handle non-existence.

Here we go with DNS, wild card synthesis and existence again... ;)

I think there are a few separate issues here.  One is understanding 
the role of 'name errors' (the original name of NXDOMAIN) and wild 
card synthesis in DNS.  The other is understanding the difference 
between DNS and registry contents.  The operational issue is the 
conditions under which the change was made.

As someone whose spent a lot of time studying DNS and currently is 
editing a DNSEXT WG document on the topic of wild cards, what is 
going on here is well within the protocol design of DNS.  I can't see 
an operational issue here either.

Having experience as the co-chair of PROVREG WG, I'd like to make a 
case that the DNS isn't the best means to determine if an object 
(even if it is a domain name) is registered - it's a first order 
guess but not the last word.  There are names registered that may not 
have working servers (hence suspended from the DNS to prevent lame 
delegations) or are otherwise reserved or suspended.  There are 
plenty of network address objects in use - in routing tables - that 
are not in the reverse DNS map.  So, to those who were relying on DNS 
for "existence" or "legitimacy," perhaps they need to consider an 
alternate method.  (Namely something like whois or crisp.)

Operationally, at least the change was made on a Monday.  But given 
that there are other operational systems relying on the existing 
conditions, advance notice would have been a good idea.  In defense 
of not giving the advance notice, it's sometimes not clear who is 
impacted by a change because of the open nature of the Internet.

As someone who doesn't run spam tools (others do it for me), it 
wasn't obvious to me until reading the threads of the impact of the 
change on spam defenses.  I can understand how someone in the spam 
trenches would see the obvious impact, but be patient with others 
that are not in the trenches with you.

PS - With DNSSEC, you'll be able to distinguish between synthesized 
(wild card) answers and straight answers.  If you want to see DNSSEC 
because of this, get active in the the DNSEXT WG and help the effort 
along.

PPS - Maybe this will raise the need for the CRISP WG to develop a protocol.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Sponge Bob Square Pants?  I'm still trying to figure out the Macarena.

---

From: Gene Gaines <[email-masked]>
Date: Tue, 16 Sep 2003 10:07:26 -0400

Forwarded with Vittorio Bertola's permission.

I received a similar response from Izumi Aizu.

Gene Gaines
[email-masked]
Sterling, Virginia USA

This is a forwarded message
From:  Vittorio Bertola <[email-masked]>
To:    Gene Gaines <[email-masked]>
Date:  Tuesday, September 16, 2003, 9:17:46 AM
Subject: Verisign attempt to "take" all unpaid addresses
=================Original message text===============

Hello,

we've been working on this since the first rumours started to come up, see
http://forum.icann.org/mail-archive/alac/msg00385.html and following thread.
We will release a statement shortly.

Thanks for your support :-)

Regards,

On Tue, 16 Sep 2003 08:48:26 -0400, you wrote:

>To:
>ICANN Interim At-Large Advisory Committee:
>
>  Erick Iriarte Ahon, Peru, Computer Law Specialist, [email-masked]
>  Izumi Aizu, Asia Network Research Researcher, [email-masked]
>  Vittorio Bertola, Italy, Technical manager, [email-masked]
>  Pierre Dandjinou. BENIN, ICT Policy Advisor, SURF/UNDP [email-masked]
>  Esther Dyson, USA, publisher/writer/IT investor/small business owner, [email-masked]
>  Clement Dzidonu. GHANA, Dept Computer Science, Valley View Univ., [email-masked]
>  Xue Hong. Prof., Faculty of Law, U. Hong Kong, Prof., Foreign Affairs Coll., [email-masked]
>
>I have a request of you, and I politely request individual answers
>from each of you.
>
>There are many many emails denouncing the new move by VeriSign
>to hijack all unregistered addresses in the spaces they manage.
>
>All unregistered domains in .com and .net now resolve to
>64.94.110.11, a Verisign-operated web search engine on port 80
>which reports advertiser-paid results.
>
>If ICANN will not move immediately and aggressively here,
>then it is a clear sign that organization is of no value,
>and is in fact what ICANN is what Karl Auerbach has long
>suspected the organization to be.
>
>I ask that you immediately and publicly denounce this move
>by VeriSign.
>
>I ask that you issue statements both as an individual and as
>a member of ICANN.  If you do not issue such statements, I
>intend publicize widely your failure to do so.
>
>It is time for you to take a stand.  Either you support the
>Internet as it exists today, are you elect to be part of
>the interests that are moving to destroy it.
>
>I would like to know.
>
>Gene Gaines
>[email-masked]
>Sterling, Virginia USA
>+1 703-433-2081
>
>
>On Tuesday, September 16, 2003, 6:02:59 AM, Zefram wrote:
>

-- 
vb.               [Vittorio Bertola - v.bertola [a] bertola.eu.org]<------
--------> http://bertola.eu.org/ - Archivio FAQ e molto altro... <--------

==============End of original message text===========

-- 
Gene 
[email-masked]

---

From: grenville armitage <[email-masked]>
Date: Wed, 17 Sep 2003 00:10:09 +1000

> Is it any worse than IE taking you to msn search when a domain doesn't

Look on the bright side - everything now resolves.

cheers,
gja

---

From: James M Galvin <[email-masked]>
Date: Tue, 16 Sep 2003 10:18:13 -0400 (Eastern Daylight Time)

verisign is masking the difference between a valid domain and
    NXDOMAIN for all protocols, all users, and all software.

If you read the Verisign documentation (which is quite excellent by the
way) on what they did and what they recommend you will see that they
thought about this.

In fact, the purpose of the Stubby SMTP daemon is to return a 550 for
non-existent recipient domains.

It is left as an exercise to the reader as to which is more efficient:
DNS NXDOMAIN or SMTP 550.

Although taking note of the returned IP address and reacting accordingly
is roughly equivalent to DNS NXDOMAIN.  It just requires an extra step
and more importantly a patched application.  Would have been nice to get
some advance notice even if there are other TLDs that have been doing
this for some time.  By the way, they do mention the other TLDs in their
documentation.

It is worth noting that if we are to "pass judgement against" Verisign
there are at least half-dozen other TLDs that blazed the trail.  We just
overlooked them because of their size as compared to .NET and .COM.

Jim

---

From: Bruce Campbell <[email-masked]>
Date: Tue, 16 Sep 2003 16:26:13 +0200 (CEST)

> >in order to give the client the choice of how to handle non-existence.

[ on dns not the best choice for authoritative non-existence ]

> alternate method.  (Namely something like whois or crisp.)

I'm not sure whether thats a good idea.  The main fuss at the moment,
apart from Verisign acting without consultation, is that a lot of
automated software makes the assumption that 'NXDOMAIN' means 'Does Not
Exist'.  Adding the wildcard removes this assumption, and removes DNS as a
useful stateless low-overhead method of existence-verification.

For these items of software to change from using a stateless method of
existence-verification with low overhead, to using a semi-stateless method
of existence-verification with high overhead, is something akin to the Y2K
bug in scope, albeit without all the hype.

Operationally, having one's not-low-overhead whois server being hit by
automated queries solely for existence-verification is a terrible state of
affairs.

> PPS - Maybe this will raise the need for the CRISP WG to develop a protocol.

I can see a lot of people requesting a low-overhead stateless subset of
crisp/whois.

-- 
                             Bruce Campbell      I speak for myself.

---

From: Keith Moore <[email-masked]>
Date: Tue, 16 Sep 2003 10:29:55 -0400

> way) on what they did and what they recommend you will see that they

their mistake is in assuming that they can respond appropriately for
all ports - particularly when the association of applications with
known ports is only advisory, and many ports are open for arbitrary use.

in fact, a 550 response in SMTP is a different condition from NXDOMAIN,
and sometimes the difference is important - as the spam filter folks
have discovered.

> this for some time.  

"nice" is not a word that seems to apply to forcing the entire net to have to
patch its applications and libraries just because verisign decided to make
inappropriate assertions about unregistered domains.   that's like calling
a mugger "nice" because he talks to you politely while he takes your wallet
at gunpoint.

> overlooked them because of their size as compared to .NET and .COM.

not only their size, but their scope also.

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 16 Sep 2003 10:35:08 -0400

> way) on what they did and what they recommend you will see that they

I stopped reading the PDF when I saw the "Verisign Proprietary"
labels.

> DNS NXDOMAIN or SMTP 550.

Semantically they're not equivalent, particularly for the targets of
an MX. 

> Would have been nice to get
> some advance notice 

"would have been nice" doesn't even get close.

IMHO it was irresponsible of them to do this without several months
advance notice to allow authors of automated systems which depended on
NXDOMAIN queries to notice this and without a stable documented way to
reconstitute the NXDOMAIN they're suppressing.

						- Bill

---

From: [email-masked]
Date: Tue, 16 Sep 2003 10:49:55 -0400

> all protocols, all users, and all software.

Out of curiosity, where did Verisign get the right to have the advertising monopoly
for all the eyeballs they'll attract with this?

---

From: "Anthony Atkielski" <[email-masked]>
Date: Tue, 16 Sep 2003 17:01:23 +0200

Andrew writes:

> What Verisign has done pre-empts that choice for everyone.

There's a simple way to stop Verisign:  Type a domain name corresponding to
a registered trademark (or a near spelling of a registered trademark), for a
domain that isn't registered.  When Verisign comes up with its own page, sue
Verisign for misuse of the trademark.  In no time, Verisign will have
restored things back the way they were, since that would be cheaper than
trying to ensure that every single non-existent domain name typed is not a
registered trademark or something that resembles a registered trademark.

---

From: "Anthony Atkielski" <[email-masked]>
Date: Tue, 16 Sep 2003 17:05:13 +0200

Valdis writes:

> Out of curiosity, where did Verisign get the right
> to have the advertising monopoly for all the eyeballs
> they'll attract with this?

They didn't.

And there's even a way for individuals to stop it:  Type an incorrect
spelling for a famous trademark.  When Verisign puts up its own page for the
nonexistent domain, copy it and send it to the trademark owner, asking if he
intends to defend his trademark, or if he is releasing it to the public
domain.  In the former case, he'll have to take action against Verisign.
The latter case is unlikely unless he truly doesn't want the trademark,
because undefended trademarks are easily diluted and slip rapidly into the
public domain.  After Verisign has a few thousand lawsuits on its hands, it
will change its policy.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 16 Sep 2003 11:01:30 -0400 (EDT)

inline

> useful stateless low-overhead method of existence-verification.

Err, actually, its the opposite that they are assuming. They assume that
lack of an NXDOMAIN means the domain does exist. That is an invalid
assumption.

> bug in scope, albeit without all the hype.

The correct way to check for "domain existance" for email is to lookup an
MX record.

> automated queries solely for existence-verification is a terrible state of

One shouldn't be doing whois queries. One just wants to know if the domain
of the sender can receive email, back.

		--Dean

---

From: James M Galvin <[email-masked]>
Date: Tue, 16 Sep 2003 11:13:04 -0400 (Eastern Daylight Time)

their mistake is in assuming that they can respond appropriately for
    all ports - particularly when the association of applications with
    known ports is only advisory, and many ports are open for arbitrary
    use.

Agreed but this is overstating the issue since interoperability demands
we know which port is doing what and when.  What we needed was time to
either stop this before it happened or to deal with the implications.

Yes and this could be fixed with a new well-defined error code, which
brings us back to needing time to make an adjustment (or to have stopped
it from ever happening).

    > some advance notice even if there are other TLDs that have been doing

    "nice" is not a word that seems to apply to forcing the entire net
    to have to patch its applications and libraries just because
    verisign decided to make inappropriate assertions about unregistered
    domains.  that's like calling a mugger "nice" because he talks to
    you politely while he takes your wallet at gunpoint.

Agreed but let's be fair.  Verisign was not first.  In fact, they are
almost 10th in the process.  Someone earlier (just today, sorry for not
looking back for the name) asked about .museum, which I've seen
references elsewhere to suggest it has in its contract with ICANN to
have this wildcard.  I have not confirmed this but undoubtedly someone
out there will know and provide a reference.

And there is the matter of the other TLDs that are already doing this
and have been doing it for some time.

None of this makes it right but let's focus on the issue not Verisign.
And the issue is with ICANN and convincing it that this is bad behavior
for all registries.  Verisign just made us all notice.

What's the difference?  Their scope matters because of their size, or
vice versa.

Jim

---

From: James M Galvin <[email-masked]>
Date: Tue, 16 Sep 2003 11:17:29 -0400 (Eastern Daylight Time)

On Tue, 16 Sep 2003, Bill Sommerfeld wrote:

    IMHO it was irresponsible of them to do this without several months
    advance notice to allow authors of automated systems which depended
    on NXDOMAIN queries to notice this and without a stable documented
    way to reconstitute the NXDOMAIN they're suppressing.

Agreed although some might argue we had several months notice, albeit
quietly.  Verisign was far from being first at this.  It's just that
their size/scope made us all notice.

Jim

---

From: Bruce Campbell <[email-masked]>
Date: Tue, 16 Sep 2003 17:42:26 +0200 (CEST)

> The correct way to check for "domain existance" for email is to lookup an

That would be the correct method as defined in RFC2821 would it?  The one
which specifies:

	5. Address Resolution and Mail Handling

		If no MX records are found, but an A RR is found, the A RR
		is treated as if it was associated with an implicit MX RR,
		with a preference of 0, pointing to that host.

> of the sender can receive email, back.

Yes.  If I receive an SMTP connection purporting to be from
[email-masked]', and I follow the established standards for
seeing whether I can send mail back, I end up with 64.94.110.11 .  Ergo,
as far as that domain is concerned, it can receive mail back.

( This was covered at least 40 messages ago, do try to keep up ).

--==--
Bruce.

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 16 Sep 2003 12:09:24 -0400

> DNS NXDOMAIN or SMTP 550.

People, have you been reading the posts? The stubby SMTP daemon is not 
an SMTP server, it is simply a program that returns the following set of 
responses TO ANYTHING THAT IS PASSED TO IT.

----------snip---------
220 snubby2-wceast Snubby Mail Rejector Daemon v1.3 ready
blah
250 OK
blah
250 OK
blah
550 User domain does not exist.
blh
250 OK
blah
221 snubby2-wceast Snubby Mail Rejector Daemon v1.3 closing transmission 
channel
----------snip---------

That means that if the SMTP sender issues a RSET command after HELO, 
they will not get a 550 error code for the RCPT TO command, but rather 
for the MAIL FROM command as follows:

----------snip---------
220 snubby4-wceast Snubby Mail Rejector Daemon v1.3 ready
EHLO someone.com
250 OK
RSET
250 OK
MAIL FROM:<[email-masked]>
550 User domain does not exist.
RCPT TO:<[email-masked]>
250 OK
DATA
221 snubby4-wceast Snubby Mail Rejector Daemon v1.3 closing transmission 
channel
----------snip---------

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Sep 2003 12:25:59 -0400

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Dean" == Dean Anderson <[email-masked]> writes:
    Dean> Is it any worse than IE taking you to msn search when a domain
    Dean> doesn't 
    Dean> resolve?  Or worse than Mozilla taking you to Netscape, duplicating a
    Dean> Google search, and opening a sidebar (and a netscape search) you
    Dean> didn't 
    Dean> want?

    Dean> I think it isn't.

  I think that it is.
  I can:
    a) replace IE
    b) replace Netscape
    c) not run them on my mail server.

  This change is unilateral.

  Personally, I am considering not renewing any .com or .net that I have.

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [

---

From: Keith Moore <[email-masked]>
Date: Tue, 16 Sep 2003 12:27:40 -0400

> reconstitute the NXDOMAIN they're suppressing.

IMHO it would be irresponsible to do this under any circumstances.

---

From: Keith Moore <[email-masked]>
Date: Tue, 16 Sep 2003 12:34:36 -0400

>     their mistake is in assuming that they can respond appropriately
>     for all ports - particularly when the association of applications
>     with known ports is only advisory, and many ports are open for
>     arbitrary use.
> 
> Agreed but this is overstating the issue since interoperability
> demands we know which port is doing what and when. 

only the app (not the entire network) needs to know which port to use,
and this doesn't require that every port be assigned to a specific app.

> What we needed was time to

what we need is a way to punish people who abuse the Internet.
personally I think drawing and quartering would be appropriate...

>     in fact, a 550 response in SMTP is a different condition from
>     NXDOMAIN, and sometimes the difference is important - as the spam
>     filter folks have discovered.
> 
> Yes and this could be fixed with a new well-defined error code

NO Jim.  VERISIGN DOES NOT HAVE THE RIGHT TO IMPOSE DISRUPTIVE CHANGE
ON THE INTERNET, not even with advance notice. 

> None of this makes it right but let's focus on the issue not Verisign.

Yes, let's focus on the issue.  But let's not ignore who is doing it
either.

What's wrong for VeriSign is wrong for the other TLD operators also. 
But Verisign causes much more harm by screwing COM and NET than the
operators of ccTLDs do.

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 16 Sep 2003 12:37:48 -0400

Just to follow up on this - I just spoke to an engineer at Verisign and 
he informed me that the SMTP daemon is being replaced in a few hours 
with an RFC-compliant one. As for not giving a warning - this came from 
a higher policy level at Verisign and he is just an engineer.

Yakov

---

From: Keith Moore <[email-masked]>
Date: Tue, 16 Sep 2003 13:00:35 -0400

> > >It is necessary that the wire protocols distinguish between
> > >existence and non-existence of resources in a standard manner
> > >(NXDOMAIN in this case) in order to give the client the choice of
> > >how to handle non-existence.
> 

it's hard to imagine that there's a better oracle than DNS to ask about
the (non-) existence of a DNS name.

now to assume that the DNS name is bound to anything in particular,
like a host, or a particular business concern, that would be a stretch.

---

From: Keith Moore <[email-masked]>
Date: Tue, 16 Sep 2003 13:12:11 -0400

> guess but not the last word. 

I strongly disagree.  The DNS is the ultimate authority on whether a
domain exists, since the way you create a domain is by making an entry
in the DNS.    Making existence of a domain depend on a separate
registry makes no sense and is inconsistent with longstanding practice.

What's happening here is that the COM and NET zones were supposed to
reflect their respective registries, but Verisign is adding records to
the DNS that are not in the registry.  This is fraud.

> There are 
> are not in the reverse DNS map. 

that's not the same thing at all.  DNS is not the authority for whether
a device is connected to the net.  DNS is the authority on whether a DNS
name exists.

---

From: David Morris <[email-masked]>
Date: Tue, 16 Sep 2003 10:07:07 -0700 (PDT)

> automated queries solely for existence-verification is a terrible state of

Has anyone tried Verisign's whois server ... at least their 'web'
interface which is impractical to automate access to because of a
fuzzy image which a human or similar of visual discernment must
read?

---

From: Edward Lewis <[email-masked]>
Date: Tue, 16 Sep 2003 13:48:30 -0400

>lack of an NXDOMAIN means the domain does exist. That is an invalid

Using DNS to determine existence is a decent heuristic, but it isn't 
exact.  That's my point, in summary.  (IOW - we agree.)

>of the sender can receive email, back.

I was assuming that the check was done to see if the mail could be 
"traced" back - from "claimed source address" to domain name to 
registrant.  Of course, with spoofing, nothing can be trusted, but if 
it is legit, you should be able to check it out.

If the case is just to see if mail can go back, then yeah, there 
oughta be an MX.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: Edward Lewis <[email-masked]>
Date: Tue, 16 Sep 2003 14:19:14 -0400

>registry makes no sense and is inconsistent with longstanding practice.

DNS is the ultimate authority on whether there is an DNS answer to a 
DNS query, but that's about it.  What a DNS server answers is based 
on what is in the registry it represents.

To quote what I wrote on the provreg list in
    http://www.cafax.se/ietf-provreg/maillist/2001-09/msg00164.html:

"DNS names [...] are limited to 255 octets, which is about 2K bits, 
and 2^2k possibilities minus special cases.  Boom - all names exist."

The point is, before saying that DNS makes any statement about 
"existence" you need to define "exists for what purpose."  In the 
message above, it was "exists so that I can't register it."  In the 
wcard clarify draft in DNSEXT, it's "exists for the purposes of 
ruling out synthesis of the answer."

>a device is connected to the net.  DNS is the authority on whether a DNS

In engineering the DNS, "com." has been and still is a peculiar case 
and there has been the temptation to tailor the DNS protocol to 
accommodate it.  The community has said time and again not to do so - 
not to treat that zone (and the others growing like it) as special 
cases.  I think turnabout is fair play - that we not restrict "com." 
and the others from using what's in DNS protocol.

I'm neither endorsing nor criticizing what has been added to "com." 
and "net."  Let's just be fair, accurate, and on-topic (like, 
protocols) in the discussion.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

---

From: James M Galvin <[email-masked]>
Date: Tue, 16 Sep 2003 15:19:47 -0400 (Eastern Daylight Time)

only the app (not the entire network) needs to know which port to use,
    and this doesn't require that every port be assigned to a specific
    app.

You can't have it both ways.  Either the app is so widespread that the
port in use is at least a de facto standard or it is a "de jure"
standard.  Either way it is possible to respond appropriately.  And
there aren't that many apps that fall into this category.

But I do agree that in the general case there are a lot of ports to
worry about.  I just don't think the general case is a practical
concern.  So perhaps we just disagree?

I'm not so sure.  Others on this list and other lists, some more
qualified than I, have been asserting there are no rules -- technical or
otherwise -- to prevent Verisign and others from doing what they've
done.  Oh we can certainly debate philosophical positions like "do not
harm,"  but what exactly is the disruption here?

Correct me if I'm wrong, the principle disruption -- and I want to
emphasize disruption here -- I've seen is that a particular spam
indicator no longer works as expected.  Is there more to this than that?
Okay, yes, there may be technical DNS issues but it is still not
disruptive to the Internet infrastructure in general as far as I can
tell.

There seems to be no shortage of reasons to dislike the behavior but
what exactly has been disrupted?

Ignore, no.  But let's not start Verisign bashing either.

But what exactly is the "screw" here?

Jim

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 16 Sep 2003 13:39:26 -0600 (MDT)

> From: James M Galvin <[email-masked]>

> ...
> ...

The list I've seen is:

 - failing to reject spam based on NXDOMAIN for the envelope sender.
     (What you term "the principle disruption")

 - rejecting legitimate mail because some long dead DNS-based
     blacklists are suddenly resolving  

 - HTTP spiders will fetch Verisign's robots.txt a lot as they
    find bogus domains (e.g. typos in HREFs) resolving.

 - HTTP users see a stalled screen instead of an error message as
    their browsers wait for Verisign's overloaded HTTP server to
    deliver its advertising.

Vernon Schryver    [email-masked]

---

From: [email-masked]
Date: Tue, 16 Sep 2003 15:46:14 -0400

> But what exactly is the "screw" here?

Verisign was (as far as I knew) given *stewardship* of the .com and .net zones
as a public trust.  I don't see anywhere they were given the right to use their
stewardship to try to make money selling typo eyeballs.  (And note that unless
you do something *really* ugly like round-robin the wildcards, only one
organization can do this per TLD - so they're essentially abusing their
monopoly).

So the question boils down to:  Are they owners of .com, or merely caretakers?

---

From: James M Galvin <[email-masked]>
Date: Tue, 16 Sep 2003 15:19:47 -0400 (Eastern Daylight Time)

Jim

---

From: "Anthony Atkielski" <[email-masked]>
Date: Tue, 16 Sep 2003 22:08:09 +0200

> indicator no longer works as expected.  Is there more to this than that?

You could make many random DNS requests of a DNS server and flush the cache,
producing a partial denial of service (or at least a drop in performance).
If every single request for a domain produces an address, existent or not,
it takes up more continuing resources than a request that produces an error.
No?

---

From: Keith Moore <[email-masked]>
Date: Tue, 16 Sep 2003 16:13:16 -0400

>     only the app (not the entire network) needs to know which port to
>     use, and this doesn't require that every port be assigned to a
>     specific app.
> 
> standard. 

False.  Many ports have neither a de factor nor a de jure assignment.

> Either way it is possible to respond appropriately. 

False.  As I pointed out earlier, there is no SMTP respose which is
equivalent to "this domain does not exist".  Furthermore there are
failure modes associated with the wildcard MX record that do not
exist if the server returns NXDOMAIN.  For instance, if their SMTP
server is down or unreachable (as it might be from time to time), the
sender will keep retrying to send the message when it should have failed
immediately with NXDOMAIN.

Frankly, your apologies for Verisign's abuse aren't very credible.
The only appropriate response to this situation is to punish Verisign.

> concern.  So perhaps we just disagree?

Perhaps.   I actually care about preserving the Internet's ability to
support a wide variety of applications.  So arguments of the form
"it works for the web and email, therefore the practical concerns
are taken care of" don't wash.  Particularly when it doesn't even 
do the right thing for either the web or email.  Hint: just because
the protocol is HTTP doesn't mean that the client has a human 
typing URLs in and looking at the output.

> 
>     >     in fact, a 550 response in SMTP is a different condition
>     >     from NXDOMAIN, and sometimes the difference is important -
>     >     as the spam filter folks have discovered.
>     >
>     NO Jim.  VERISIGN DOES NOT HAVE THE RIGHT TO IMPOSE DISRUPTIVE
>     CHANGE ON THE INTERNET, not even with advance notice.
> 
> qualified than I, have been asserting there are no rules -- technical
> or otherwise -- to prevent Verisign and others from doing what they've
> done.  

Nothing gives VeriSign the right to misrepresent the contents of the
registry.  If it's wrong for businesses to register individual
misspelled domain names in the hopes of getting misspelled queries
redirected to their sites, it is surely wrong for VeriSign to do the
same thing for ALL unregistered domains within COM and NET.

> Oh we can certainly debate philosophical positions like "do not

Have you not been paying attention?  When you try to download a web page
that doesn't exist, you don't get a "host does not exist" error, you get
a redirect to a web page.  That's fraud.   When you try to verify that a
domain is valid, you don't get NXDOMAIN, you get an A record.  That's
also fraud.  When you try to talk to another port, you get connection
refused, so instead of getting the error that corresponds to "no such
host" you'll probably think it is a temporary error (say, the server is
down) and try again later.

It is a gross protocol violation to take an explicit error indication
that has a very specific meaning and instead map it to what in some
cases looks like valid output, and in other cases looks like a very
different kind of error.

> indicator no longer works as expected. 

You are wrong.  

> disruptive to the Internet infrastructure in general as far as I can

It's broken the ability to detect misspelled domains for every
application and every protocol, for every name under .COM or .NET.  

>     Yes, let's focus on the issue.  But let's not ignore who is doing
>     it either.
> 

It's not bashing them to speak the truth about what they are doing.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 16 Sep 2003 16:26:58 -0400

> >domain exists, since the way you create a domain is by making an
> >entry in the DNS.    Making existence of a domain depend on a
> >separate registry makes no sense and is inconsistent with
> >longstanding practice.
> 

What a DNS server answers is based on what is in the zone it represents.
Not all zones have registries.

> and 2^2k possibilities minus special cases.  Boom - all names exist."

You didn't actually cite any support for your statement.  And the
existence of the NXDOMAIN response code contradicts that statement.

> "existence" you need to define "exists for what purpose."

That's beside the point.  NXDOMAIN is still a meaningful condition even
though you can't tell what a domain means if it does exist.

> >that's not the same thing at all.  DNS is not the authority for
> >whether a device is connected to the net.  DNS is the authority on
> >whether a DNS name exists.
> 

It is never appropriate to make wildcard assertions about names within a
zone if those assertions are not true.  If all of the names in
foo.example.com zone will always be associated with address a.b.c.d,
it's reasonable to set up a wildcard A record for that zone.  Otherwise
it is not reasonable. This is no less true for com or net than for
foo.example.com 

COM and NET are supposed to reflect their respective registries - this
isn't itself a DNS protocol issue but part of the arrangement for
managing those zones.  VeriSign is making assertions about names that
don't exist in the registries.  (It also happens that those assertions
are disruptive to the operation of protocols when those protocols use
names in those zones, and that *is* a protocol issue)

Keith

---

From: Paul Vixie <[email-masked]>
Date: 16 Sep 2003 20:41:41 +0000

> By the way, what about .museum?

.museum does not delegate all of its subdomains.

not all tld's are delegation-only.
-- 
Paul Vixie

---

From: James M Galvin <[email-masked]>
Date: Tue, 16 Sep 2003 16:43:04 -0400 (Eastern Daylight Time)

> But what exactly is the "screw" here?

    Verisign was (as far as I knew) given *stewardship* of the .com and
    .net zones as a public trust.  I don't see anywhere they were given
    the right to use their stewardship to try to make money selling typo
    eyeballs.  (And note that unless you do something *really* ugly like
    round-robin the wildcards, only one organization can do this per TLD
    - so they're essentially abusing their monopoly).

    So the question boils down to: Are they owners of .com, or merely
    caretakers?

An excellent question!  But that is a discussion that belongs with
ICANN, not the IETF.

Jim

---

From: David Morris <[email-masked]>
Date: Tue, 16 Sep 2003 13:54:42 -0700 (PDT)

> > indicator no longer works as expected.  Is there more to this than that?

One more I've seen mentioned today ... an incorrect MX record which refers
to a non-existant domain will/may no longer properly fail over to an
alternate lower priority MX entry.

---

From: Gene Gaines <[email-masked]>
Date: Tue, 16 Sep 2003 17:16:22 -0400

Date:  Tuesday, September 16, 2003, 2:06:02 PM

=====
The At-Large Advisory Committee would like to bring to ICANN's
attention concerns about Verisign's surprising roll-out of the
"SiteFinder" service for .com and .net.  

SiteFinder works by re-directing queries for non-existing domain
names to the IP address of a search service that is being run by
Verisign.

This practice raises grave technical concerns, as it de facto
removes error diagnostics from the DNS protocol, and replaces them
by an error handling method that is tailored for HTTP, which is just
one of the many Internet protocols that make use of the DNS. We will
leave it for others to explain the details of these concerns, but
note that returning resource records in a way which is countrary to
the very design of the DNS certainly does not promote the stability
of the Internet.

These concerns are not mitigated by Verisign's efforts to work
around the consequences of breaking the Internet's design on a
service-by-service basis: These workarounds make specific
assumptions on the conclusions that Internet software would be
drawing from nonexisting domain names; these assumptions are not
always appropriate.

When working as intended, the service centralizes error handling
decisions at the registry that are rightly made in application
software run on users' computers.  Users are deprived of the
opportunity to chose those error handling strategies best suited for
their needs, by chosing appropriate products available on a
competitive marketplace. Software makers are deprived of the
opportunity to compete by developing innovative tools that best
match the user's needs.

We urge ICANN to take whatever steps are necessary to stop this
"service."
-- 
vb.                  [Vittorio Bertola - vb [at] bertola.eu.org]<---
-------------------> http://bertola.eu.org/ <-----------------------

--

---

From: Rick Wesson <[email-masked]>
Date: Tue, 16 Sep 2003 14:28:52 -0700 (PDT)

> An excellent question!  But that is a discussion that belongs with

Jim,

that would be true if the ICANN were functioning and this event is just
proof that the ICANN does not function.

the mission of ICANN (my paraphrase) is "Technical Administration of
Internet ?N?ames and Numbers"

It is ovious to anyone today, that there is no technical oversite of the
DNS today.

-rick

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 16 Sep 2003 23:39:55 +0200

Nearly my reaction as well. Note, using the concept of "ownership"
has/will get quite some lawyers debating.

Some (rhetoric) questions:
	If there is a caretaker, who is the owner of what is taken
	care of?  Under which law system?

	jaap

---

From: Paul Vixie <[email-masked]>
Date: 17 Sep 2003 02:32:42 +0000

> overlooked them because of their size as compared to .NET and .COM.

when people started beating on my phone ringer about wildcards yesterday
evening, and screaming for patches to bind to somehow make it all better,
i asked "but other tld's do this, what's the big deal?"  as near as i can
figure it, the problem is one of expectation.  if someone signs up for .nu
they know there'll be a wildcard there before they sign, and they can take
appropriate precautions (like only using it for web or e-mail, and not
naming hosts under that tld).  the expectations for .com and .net to not
have wildcards were all set many years ago, and it's the violation of those
expectations that's got people angry enough to publish patchware about it.
-- 
Paul Vixie

---

From: Keith Moore <[email-masked]>
Date: Wed, 17 Sep 2003 00:00:14 -0400

interesting point.  if we created a new gTLD and announced that it would be
wildcarded from day one, it wouldn't be used in the same way as the other
gTLDs.

then again, do we really want different ways of reporting errors for 
different zones in the DNS?  would apps then want to special-case 
certain zones to interpret their results differently than the others?

Keith

---

From: [email-masked]
Date: Wed, 17 Sep 2003 00:23:41 -0400

> certain zones to interpret their results differently than the others?

Blech.

If it's Tuesday, this must be .belgium?

A non-starter.  *MAYBE* if it were a different RR with different semantics.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 17 Sep 2003 05:15:28 +0000

> % Blech.
> % 
> % If it's Tuesday, this must be .belgium?
> % 
> % A non-starter.  *MAYBE* if it were a different RR with different semantics.
> 
> 	This may be exactly what we get w/ a patch from ISC.
> 	If BIND is offically tweeked so that some zone cuts are 
> 	allowed to exercise legal protocol options while others 
> 	are not...  changes based on "mob" rule... not good.

as bill must surely know, we would never do that.

> 	BIND begins to lose its reputation as a reference 
> 	implementation of open standards.

i certainly hope not.

---

From: Bill Manning <[email-masked]>
Date: Tue, 16 Sep 2003 22:12:13 -0700 (PDT)

% On Wed, 17 Sep 2003 00:00:14 EDT, Keith Moore said:
% 
% > then again, do we really want different ways of reporting errors for 
% > different zones in the DNS?  would apps then want to special-case 
% > certain zones to interpret their results differently than the others?
% 
% Blech.
% 
% If it's Tuesday, this must be .belgium?
% 
% A non-starter.  *MAYBE* if it were a different RR with different semantics.
% 

	
	Ick.

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: "bill" <[email-masked]>
Date: Wed, 17 Sep 2003 12:58:38 -0700

I've just got to ask... I am seeing news that BIND  WILL BE patched with
this kind of support in it. 

Is this a sponsored patch, or is it just a random person posting a patch
- that if applied would have this functionality

Bill

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Vixie
Sent: Tuesday, September 16, 2003 7:33 PM
To: [email-masked]
Subject: Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To
Us]

> there are at least half-dozen other TLDs that blazed the trail.  We 
> just overlooked them because of their size as compared to .NET and 
> .COM.

when people started beating on my phone ringer about wildcards yesterday
evening, and screaming for patches to bind to somehow make it all
better, i asked "but other tld's do this, what's the big deal?"  as near
as i can figure it, the problem is one of expectation.  if someone signs
up for .nu they know there'll be a wildcard there before they sign, and
they can take appropriate precautions (like only using it for web or
e-mail, and not naming hosts under that tld).  the expectations for .com
and .net to not have wildcards were all set many years ago, and it's the
violation of those expectations that's got people angry enough to
publish patchware about it.
-- 
Paul Vixie

---

From: Dean Anderson <[email-masked]>
Date: Wed, 17 Sep 2003 16:35:19 -0400 (EDT)

> registry makes no sense and is inconsistent with longstanding practice.

No, the ultimate authority of whether a domain exists is the registry of
domain names. DNS is just a protocol to distribute that information.
What you are saying about DNS is like saying BGP is the ultimate authority
of IP address assignment.  Obviously, it is the records of assignment that
are the ultimate authority.

We are not just now making a separate registry. There has always been a
separate registry, with records apart from DNS.  DNS is a protocol for
distributing DNS records from hierarchically delegated subregistries.
The existance of the TLDs is managed by one registry. The existance of
.net and .com is managed by another.

It is quite reasonable to have all unassigned delegations come back to the
appropriate registry.  This is the purpose of a wildcard record. There is
no reason that a registry isn't allowed to have all unassigned delegations
point to it.

		--Dean

---

From: Keith Moore <[email-masked]>
Date: Wed, 17 Sep 2003 17:16:03 -0400

> No, the ultimate authority of whether a domain exists is the registry
> of domain names. 

There is no registry of domain names; there are only registries for a
few zones.   You could claim that the registry for the other zones is
in a zone file somewhere, and that's the ultimate authority for that
zone, but that would be a stretch.  If a domain isn't listed in DNS then
practically speaking it does not exist. (LLMNR might change that if they
ever make it reasonable enough to use - I will reserve judgement on the
lastest draft until I have read it).

Even if the domain might not be in DNS but still be in the registry for
that zone, and there were a way to query that registry, would you expect
apps to special-case handling of the zones that were defined by
registries?  Given that they couldn't get the RRs for that domain
anyway, what would be the point of their doing so?

We've got ~16 years of history that says that NXDOMAIN means that the
domain does not exist, that is fully consistent with the protocol
specifications and which is built into apps.  Changing this behavior
would be incompatible with all that code, and VeriSign's attempt to
subvert the COM and NET zones is not a compelling reason to do so.  

Keith

p.s. Now, with something like LLMNR we might someday have a way of
distributing domain names and their RRsets that is separate from DNS,
and it could be very useful for it to do so.  But in order to be viable
it needs to produce results that are consistent with DNS.  We can't have
two different lookup services for the same names producing mutually
inconsistent results.  

Note that this is not the same problem that VeriSign is causing -
VeriSign is uniformly mis-representing the COM and NET registries and
mis-reporting NXDOMAIN error conditions for these zones as successful
queries, which is not the same thing as producing inconsistent results
depending on who is asking.  But it does relate to the question of
whether the DNS is the authority for DNS name information or just a way
of obtaining the information.

---

From: Doug Royer <[email-masked]>
Date: Wed, 17 Sep 2003 15:26:06 -0600

Before the change if I email [email-masked], the email tool would 
tell me immedatally
that no such host exists.

Now, it unconditionally sends the email, then later bounces. This is a 
HUGE difference
in behaviour.

-- 

 Doug Royer                     |   http://INET-Consulting.com 
 -------------------------------|-----------------------------
 [email-masked]                 | Office: (208)612-INET
 http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                |   Cell: (208)520-4044

                We Do Standards - You Need Standards

---

From: Carl Malamud <[email-masked]>
Date: Wed, 17 Sep 2003 14:30:27 -0700 (PDT)

Hi -

http://www.isc.org/products/BIND/delegation-only.html

Carl

---

From: Dean Anderson <[email-masked]>
Date: Wed, 17 Sep 2003 18:28:50 -0400 (EDT)

It did that if you sent to any other toplevel domain that had wildcards,
and others do.

The behavior hasn't changed.

Your mail client was making a false assumption. That is a bug in the
software.  The mail client shouldn't be looking up domains. It should be
sending it to the relay. The relay then decides where to send the message.
The relay may be configured to route non-DNS domains, or do translations
to other systems. Your mail client can't know about that. If the relay
can't send the message somewhere, then it is supposed to bounce the
message.  This decision is made by the relay, not the mail client.

Your mail client has had a bug, for a long time.

		--Dean

---

From: [email-masked]
Date: Wed, 17 Sep 2003 13:20:40 -0700 (PDT)

> Your mail client has had a bug, for a long time.
Its not a bug. As many pointed out RFCs specify that mail servers should 
attempt to get MX record for domain first but if it fails should use "A" 
record if it exists. This behavior has existed for long time, but I think 
it came from way early on the internet when MXs were not used by everybody
and mail was still being routed directly to the machine specified.

Its possible that this is also used (dont know how much) for internal mail
routing (i.e. when [email-masked] is received by public mail
gateway it is then rerouted to [email-masked] 
and mail administrator is too lazy to enter MX for corporate.mailserver 
possibly because they are not even using DNS internally and are using 
WINS or domain is directly in the mail routing gateway, like in /etc/hosts)

What would be interesting is too try to get some statistics on how much 
the direct A DNS records (as opposed to MXs) are really used nowdays and 
if the number if sufficiently small (on the public internet, i.e. if its
done on company net as described above, then mail routing software may handle 
case as it wants anyway), it maybe good idea for IETF to release update 
BCP to specify that mail should ALWAYS be routed to MX record and failure 
maybe issued if it does not exist.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Dean Anderson <[email-masked]>
Date: Wed, 17 Sep 2003 18:22:49 -0400 (EDT)

On Wed, 17 Sep 2003, Keith Moore wrote:

> few zones.

Well, ICANN registers the Top level domains for something like 80+ top
level zones including country code zones. You can't have a TLD unless you
register with ICANN, first, and meet the requirements for a TLD.  These
TLD sub-registries then have their own rules. ".com" and ".net" are two
that are (partially) handled by NetSol.

I know that there used to be a database of files which contained the
registration info.  The DNS Zone files for .com, .net, .org etc were
generated by scripts that read these files.  That database is accessed by
whois, which also accessed the files. I suspect this flat file database
has been converted to a relational database, but I can't be sure.  When
Network solutions was created, the flat files were transfered to them,
from SRI, I think.  I think there were paper records that were kept, too.

When you sent in registation email, scripts would process registration
templates into the flat files.  Network solutions first added fees to this
process.  Later, other registries were created.

>  You could claim that the registry for the other zones is
> practically speaking it does not exist.

No, this isn't the case. A domain may not be in DNS in the case that it
exists but is suspended for some reason.  There may be other reasons, such
as the DNS zones have been updated since the domain was created.

> anyway, what would be the point of their doing so?

I wouldn't expect that, unless of course, they are other registries trying
to register the domain.

People keep saying that something has been broken. But in fact, nothing
has been broken, except false assumptions that were false to begin with.
People have been told these assumptions are false by people on the various
DNS lists.  They were well aware of the falseness of their assumptions, or
they ought to have been. This is not something that is surprising to any
reasonable person in any way whatsoever. These people just assumed that if
they kept using reverse DNS this way, that they would be able to keep
doing it. Well, that isn't how it works, is it?

> subvert the COM and NET zones is not a compelling reason to do so.

NXDOMAIN means the domain isn't in the DNS distributed databse.  It
doesn't mean that it isn't registered.  However, NXDOMAIN hasn't been
wrongly sent.  It is not the case that NXDOMAIN _MUST_ be sent. That would
preclude wildcard records.

Further, lack of NXDOMAIN does't mean the record exists.  Only NXDOMAIN
has meaning.  No NXDOMAIN response means nothing.  That is the case we
have.  There is nothing that says a registry has to return NXDOMAIN
instead of a wildcard match.

> of obtaining the information.

It is not _mis-reporting_ anything. Just the opposite in fact.  The
purpose of a wildcard is to match queries that aren't matched by other
records.  This is legal report and response for any zone.

		--Dean

---

From: "bill" <[email-masked]>
Date: Wed, 17 Sep 2003 16:41:59 -0700

Depends on if you have wildcarded MX records as well too.  

The mail might never bounce.  Who is to say a clever spammer wouldn't
setup a wildcarded series of MX records to point to their own SMTP
servers, and harvest the FROM/REPLY TO addresses and place them in to
their spam lists. (obviously the TO field is wrong, since it's domain
bounced - however I wonder if you could take the @part.com and look for
valid domains that come close to matching and add THOSE TO: fields to
the spam directory)

An even WORSE difference in behavior (plus you aren't notified that your
mail didn't make it to where you thought it was going)

Bill

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Doug
Royer
Sent: Wednesday, September 17, 2003 2:26 PM
To: [email-masked]
Subject: Re: [Fwd: [Asrg] Verisign: All Your ...

--

---

From: Florian Weimer <[email-masked]>
Date: Thu, 18 Sep 2003 01:51:49 +0200

> not all tld's are delegation-only.

I know.  I have to admit that (as someone who grew up under .de) I
would never have thought of the delegation-only approach. 8-)

---

From: Tom Lord <[email-masked]>
Date: Wed, 17 Sep 2003 17:52:44 -0700 (PDT)

Given the importance of TLDs, perhaps the right thing to do here, for
ietf, is to assume the worst-relevant-case scenario:

* worst:

  Presume that a malevolent entity gains control of a TLD.

* relevant:

  Assume that through litigious or regulatory or (gasp) voluntary
  mechanisms, the malevolent parties are subject to standards.  They
  must operate the TLD according to approved standards (which
  apparently do not currently prohibit or even explicitly discourage
  Verisign's behavior).

In other words: write RFCs with the presumption that they will have
force and with the goal that they would prevent objectionable behavior
(which in this case, from what I've seen on the list, is more
ambiguous than one might wish).  And then leave the implementation of
"force" up to other entities.  This is an alternative to the emerging
game of "core wars" exemplified by the recent patch to BIND.

For the case at hand, the ex-post-facto nature of the new standard is
problematic and RFCs should explain how and why that should be taken
into account.

In the best case, no force is actually necessary, and entities such as
Verisign will simply choose to comply voluntarily because so many
people have agreed that they should.

In other words: express the sin negatively as an RFC.  That it is the
case, list traffic suggests, other TLD custodians have performed
similar acts without objection, complicates the issue, of course.

-t

---

From: Keith Moore <[email-masked]>
Date: Wed, 17 Sep 2003 21:50:31 -0400

> has been broken, except false assumptions that were false to begin with.

You're simply wrong, and there have been numerous examples of this.

> doesn't mean that it isn't registered. 

The app doesn't care whether the domain is registered.  The app cares whether
the domain exists in DNS, because using DNS to look up the address is the way
the app is designed to work.  Putting the domain in DNS is (either implicitly
or explicitly) part of the application protocol.

> However, NXDOMAIN hasn't been

Wildcard records make a global assertion for an entire zone.  This is not
an assertion that VeriSign is entitled to make.  VeriSign does not have the
right to make assertions about all unregistered domains in NET or COM.

> have.  

No the case we have is not the lack of a response.  It is a response
containing an A record.  That A record is a lie.

> It is not _mis-reporting_ anything. 

That is precisely what it is doing. 

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 17 Sep 2003 22:36:31 -0400

> sending it to the relay. 

No, you're making an incorrect assumption.  It's perfectly valid for a
mail client to send mail directly to the MX for the recipient domain
(or A record if there is no MX)  That's how mail was intended to work,
having a local relay is just a popular optimization.  So it's perfectly valid
for a mail client to look up domain names, and it's perfectly valid for a mail
client to assume that NXDOMAIN means that the domain does not exist.  again,
that is how the mail protocol is defined to work.

Your attempt to reinterpret the mail specs in order to apologize for
VeriSign's fraud and unfair business practice is not in the least bit
persuasive.

---

From: [email-masked]
Date: Wed, 17 Sep 2003 23:22:31 -0400

> sending it to the relay. The relay then decides where to send the message.

OK. Now repeat your entire thing, this time from the point of view of the MTA
that's just been handed a piece of mail by the MSA.  Hey.. the MTA *should*
be looking up domains, and deciding where to route them.  And most MTAs
really appreciate it if the DNS gives them *useful* information like an NXDOMAIN
return if it doesn't exist, so it can bounce the mail *RIGHT NOW* rather than
having it sit in a queue for hours or days waiting for Verisign's Snubby BMTP
(Broken Mail Transport Program) to become available so it can do something
silly like harvest the From: line and then reject the mail.

For bonus points, work out what happens to your mail if you happen to get
more than one RCPT TO (possibly by sending to 2 or 4 people at the same now-defunct
site).  Wow, that 221 shows up at an inconvenient time, doesn't it?

---

From: Bill Manning <[email-masked]>
Date: Wed, 17 Sep 2003 21:27:07 -0700 (PDT)

% Wildcard records make a global assertion for an entire zone.  This is not
% an assertion that VeriSign is entitled to make.  VeriSign does not have the
% right to make assertions about all unregistered domains in NET or COM.
% 
	Can you back up your assertion that Verisign is -NOT- entitled? 
	A number of us think that they do, in fact, have the right to 
	assert information about COM and NET, registered or not.  I have 
	reason to beleive this, since they assert their rights to do so 
	at least twice a day.

% Keith

--bill

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 18 Sep 2003 13:31:19 +0859 ()

Carl;

> http://www.isc.org/products/BIND/delegation-only.html

As I just post to DNSOP WG ML (detailed discussion should be done
there), it is not an effective protection against synthesised (from
wildcared NS, in this case) NS and synthesised (from scratch) child
zone contents.

A protection is to reject NS answers, if it is identical to wildcarded
one, though it has several side effects.

							Masataka Ohta

---

From: Keith Moore <[email-masked]>
Date: Thu, 18 Sep 2003 00:41:50 -0400

> % an assertion that VeriSign is entitled to make.  VeriSign does not have
> the% right to make assertions about all unregistered domains in NET or COM.
> % 

I've already done so, from numerous angles.

> 	reason to beleive this, since they assert their rights to do so 

Just like a thief asserts his rights to your property.  Neither one is right.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 18 Sep 2003 14:09:47 +0859 ()

Bill;

> 	reason to beleive this, since they assert their rights to do so 

Right.

Because of the freedom of speech, anyone has the basic right to
assert anything, of course.

Others have right to ignore it.

And, if a false assertion causes damage to others, then...

							Masataka Ohta

---

From: Francis Dupont <[email-masked]>
Date: Thu, 18 Sep 2003 14:14:04 +0200

In your previous mail you wrote:

=> IMHO it should reject SMTP connection from the beginning with
the 521 greeting described in RFC 1846...

Regards

[email-masked]

---

From: Dean Anderson <[email-masked]>
Date: Thu, 18 Sep 2003 11:45:06 -0400 (EDT)

> that is how the mail protocol is defined to work.

No, its not valid for a mail client to make direct connections. There are
many ISPs that block this. Are they doing something wrong?  Mail clients
are supposed to connect to their configured mail relays, which has the
responsibility to route mail.

> VeriSign's fraud and unfair business practice is not in the least bit

What is not persuasive is the attempts to claim they did anything wrong.

		--Dean

---

From: Bill Manning <[email-masked]>
Date: Thu, 18 Sep 2003 08:51:31 -0700 (PDT)

% > % Wildcard records make a global assertion for an entire zone.  This is not
% > % an assertion that VeriSign is entitled to make.  VeriSign does not have
% > the% right to make assertions about all unregistered domains in NET or COM.
% > % 
% > 	Can you back up your assertion that Verisign is -NOT- entitled? 
% 
% I've already done so, from numerous angles.

	ok, what about DoC & ICANN agreements w/ VSGN giving them
	the authority to continue to register in and publish
	the .COM and .NET domains?  That looks like an entitlment to me.

% > 	A number of us think that they do, in fact, have the right to 
% > 	assert information about COM and NET, registered or not.  I have 
% > 	reason to beleive this, since they assert their rights to do so 
% > 	at least twice a day.
% 
% Just like a thief asserts his rights to your property.  Neither one is right.

	Are you insinuating that COM and NET are "your" property?
	Verisign has and continues to publish .COM and .NET zone data
	twice each day that is marked with records that indicate 
	they, Verisign are asserting their rights to publish the
	data in those zones.  If you think that Verisign has stolen
	.COM and .NET, then you should make your concerns known to 
	your legal advisors, DoC, and Verisign.

--bill

---

From: Dean Anderson <[email-masked]>
Date: Thu, 18 Sep 2003 11:45:14 -0400 (EDT)

> > Your mail client has had a bug, for a long time.
              ^^^^^^
> Its not a bug. As many pointed out RFCs specify that mail servers should
                                                            ^^^^^^^
I think you have pointed out that this is indeed the function of a mail
server, not a mail client.  It is a bug.

---

From: Dean Anderson <[email-masked]>
Date: Thu, 18 Sep 2003 12:04:31 -0400 (EDT)

> You're simply wrong, and there have been numerous examples of this.

Sounds like a canard.

> or explicitly) part of the application protocol.

The app is designed incorrectly. Only mail relays are expected to be able
to route mail.

As Valdis points out, the mail server should look up the address, and upon
connecting to port 25, it finds the mail rejected. A bounce is returned,
as it should be.  A bounce would also be returned if there was nothing
listening on port 25. As it should be.  There is nothing broken by having
a wildcard, that wasn't broken before by false assumptions.

> right to make assertions about all unregistered domains in NET or COM.

I think they do.  They think they do. Other TLDs think they do.  They have
the right to insert records into .net and .com. And they have the
privilege of selling entries in those zones.  So, upon what is your
assertion based on?

> containing an A record.  That A record is a lie.

No, it is a wildcard. It is no more or less a lie than any other wildcard.

> That is precisely what it is doing.

You have yet explain how is it misreporting anything.  It in fact
reporting that the domain is available for purchase. How is that
misreporting?

Other TLDs have been doing this for a long time. What are they
misreporting?

		--Dean

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Thu, 18 Sep 2003 09:22:15 -0700

>the 521 greeting described in RFC 1846...

People are unhappy about VeriSign breaking the rules. But here you 
are proposing that they follow an *experimental* RFC whose rules were 
not accepted into the later revision of SMTP in RFC 2821. How will 
them breaking the rules twice make it better?

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: [email-masked]
Date: Thu, 18 Sep 2003 12:25:19 -0400

> server, not a mail client.  It is a bug.

OK Dean, let's go back and look at the original message.

> that no such host exists.

Well you know what Dean?  When I mail to a duff address, my MUA (exmh)
hands it off to a proper MTA, and the MTA gets an error.  And it hands a bounce
message back to my MUA, which tells me about it.

Hey - look what my mail tool is telling me:

----
	(multipart/report)
Human-readable report  		(text/plain)
    **********************************************
    **      THIS IS A WARNING MESSAGE ONLY      **
    **  YOU DO NOT NEED TO RESEND YOUR MESSAGE  **
    **********************************************

The original message was received at Tue, 16 Sep 2003 15:42:05 -0400 (EDT)
from IDENT:mirapoint@evil-zidane [10.1.1.13]

   ----- Transcript of session follows -----
<[email-masked]>... Deferred: Connection timed out with vsu.vsu.edu.
Warning: message still undelivered after 1 day
Will keep trying until message is 3 days old
----

The DSN was generated on a Alphaserver running Sendmail some 8 miles
from where I'm typing. My laptop never even tried to resolve vsu.edu in connection
with this transaction.  But I'm getting the notification from my MUA.

And neither is there any actual justification for your claim that the original poster's
mail client tried to do the lookup.

So all your sophistry about "the client shouldn't be doing it" is just that. Sophistry.

---

From: [email-masked]
Date: Thu, 18 Sep 2003 12:30:35 -0400

> reporting that the domain is available for purchase. How is that

Well.. let's follow this line of reasoning.  If I mail to a domain, *and it gets
a pointer to a mail server* then we can conclude one of the following:

1) The domain is *NOT* available for purchase, because it is *IN USE* by
at  least that mail server.

2) The domain is available, but is in the DNS.  This would by all reasonable
people be judged a miscommunication between the registrar of record and the DNS
server, as there is data in the DNS that is not in any registrar.

If their bogus mailserver answered with an RFC1846 style reply:

521 mailserver.this-never-existed.com Domain Not In Use, contact <...> to purchase

you would *ALMOST* have a leg to stand on.

---

From: Keith Moore <[email-masked]>
Date: Thu, 18 Sep 2003 12:28:34 -0400

> 	the .COM and .NET domains?  That looks like an entitlment to me.

the very purpose of those agreements - hell, the primary purpose of ICANN, is
to constrain how NSI/VeriSign  maintains those zones.  how in the world you can
interpret this as an entitlement to VeriSign to make arbitrary and disruptive
changes to the zone is beyond me.

of course there are some people who feel that anything that you can get
away with becomes an entitlement.   I don't happen to share that belief, but 
if you are one of those who do, there's no point in our discussing it 
further.  but you might want to think about the implications of a world where
the only to solve problems like this is by force.

> If you think that Verisign has stolen

the NET owns .COM and .NET.

---

From: Keith Moore <[email-masked]>
Date: Thu, 18 Sep 2003 12:34:48 -0400

On Thu, 18 Sep 2003 09:22:15 -0700

> them breaking the rules twice make it better?

it's sort of missing the point anyway.  mail and web aren't the only apps 
affected by this.  this breaks anything that assumes (quite reasonably)
that query to a a nonexistent domain will return NXDOMAIN.

this does point out something about our standards - they're written assuming
that people want to interoperate and that they're acting in good faith.
while they might try to prohibit harmful behavior that might occur by
accident, they weren't written to dictate the actions of potentially hostile
parties (and I do regard VeriSign as hostile)

---

From: Keith Moore <[email-masked]>
Date: Thu, 18 Sep 2003 12:37:01 -0400

> many ISPs that block this. Are they doing something wrong?  

IMHO yes, but that's between them and their customers.  

> Mail clients

this is a figment of your imagination.

---

From: Doug Royer <[email-masked]>
Date: Thu, 18 Sep 2003 11:20:56 -0600

>software.  The mail client shouldn't be looking up domains. It should be
There is no rule  that says that my smart MUA can not deliver email 
itself.  Not a bug.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 18 Sep 2003 11:30:54 -0600

>No, its not valid for a mail client to make direct connections.
>
Can you site any RFC that says that?

>many ISPs that block this. Are they doing something wrong?
Orthogonal and unrelated.

>responsibility to route mail.
Says who?

>What is not persuasive is the attempts to claim they did anything wrong.
Breaking existing applications like MUA's (and your ISP's relays)
is wrong.

--

---

From: Dean Anderson <[email-masked]>
Date: Thu, 18 Sep 2003 15:35:25 -0400 (EDT)

On Thu, 18 Sep 2003 [email-masked] wrote:

> On Thu, 18 Sep 2003 14:27:47 EDT, Dean Anderson said:
> > What Doug Royer is complaining about is that his mail client previously
> > told him right away. He didn't have to wait for a bounce.  Now he has to
> > wait for a bounce, and that is a "big change".
>
> Oh?  Do you have proof that "right away" means "immediate in-line checking"?

You'll have to ask Doug. That was the way I took his message.  "Immediate
in-line checking" (by the MUA) is the only thing that is "broken", so I
think that tends to suggest this was what he meant.

> My laptop is currently a 100BaseT and a gigabit hop from the mail server -
> a proper bounce done the way you want can arrive in under 2-3 seconds.
> If you count in the fact that my laptop has a perfectly good MTA of its own,
> a bounce can come back before I've gotten the mouse cursor off the 'send'
> button.

Good for you. I don't know what you are complaining about.

> Contrast that to a possibly multiple-hour wait if you're sending it off
> to wherever Verisign is sucking your mail.  And *MAYBE* a bounce. (Work
> out what happens if you send to more than one bad recipient).

Nothing different happens. If your laptop MTA can return a bounce in 2
seconds, so can other MTAs.  If the MTA takes too long, that might be a
reason to distribute users to more MTAs.

If you send to more than one recipient, you still only transfer one
message. You've been listening to too many open relay crackpots, instead
of checking into how SMTP works.

From RFC 821 section 2:

   When the same message is sent to multiple recipients the SMTP
   encourages the transmission of only one copy of the data for all the
   recipients at the same destination host.

I don't know of any MTA that doesn't do this.

		--Dean

---

From: "bill" <[email-masked]>
Date: Thu, 18 Sep 2003 13:02:49 -0700

I have to agree, I don't think Verisign did anything "Wrong".

I have often drawn a line between corporate behavior that is immoral,
and that behavior that is illegal.  There is a huge difference between
them.

Verisign has not broken any laws, therefor what they did isn't "Wrong"
(if someone can point to a law that Verisign is in the juristiction of
that adding a wildcard domain in .com/.net please inform me of the
statute and I will say I am incorrect)

Now we can talk about immoral behavior of adding the wildcard.  I don't
like it, I think they should remove it - however it is not illegal.  Go
figure

Bill

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
Anderson
Sent: Thursday, September 18, 2003 8:45 AM
To: Keith Moore
Cc: [email-masked]
Subject: Re: [Fwd: [Asrg] Verisign: All Your ...

> > software.  The mail client shouldn't be looking up domains. It 
> > should be sending it to the relay.
>

> having a local relay is just a popular optimization.  So it's 
> perfectly valid for a mail client to look up domain names, and it's 
> perfectly valid for a mail client to assume that NXDOMAIN means that 
> the domain does not exist.  again, that is how the mail protocol is 
> defined to work.

No, its not valid for a mail client to make direct connections. There
are many ISPs that block this. Are they doing something wrong?  Mail
clients are supposed to connect to their configured mail relays, which
has the responsibility to route mail.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Thu, 18 Sep 2003 14:27:47 -0400 (EDT)

As I pointed, this is incorrect behavior to begin with, on the part of
MUA.  It is therefore, "not a big change".  Proper MUA's previously handed
the message to a relay, and got a bounce. Proper MUA's still get a bounce.
You still get a bounce, and you still find out that the domain is
incorrect. Nothing has changed.

Your assertions below are irrelevant to the original message. As such,
they are in fact sophistry.

		--Dean

---

From: "Anthony Atkielski" <[email-masked]>
Date: Fri, 19 Sep 2003 10:08:25 +0200

> No, its not valid for a mail client to make direct

There is no distinction between a mail client and a mail server in SMTP.  It
is perfectly valid for either to deliver mail directly to another SMTP
server.

---

From: "Anthony Atkielski" <[email-masked]>
Date: Fri, 19 Sep 2003 10:09:23 +0200

> server, not a mail client.  It is a bug.

SMTP makes no distinction between servers and clients.  It's not a bug.

---

From: Dean Anderson <[email-masked]>
Date: Thu, 18 Sep 2003 14:46:02 -0400 (EDT)

On Thu, 18 Sep 2003, Keith Moore wrote:

> this breaks anything that assumes (quite reasonably)

That an invalid assumption to make. It was not made "quite reasonably",
but rather was made quite irrationally. In many or most cases, it was made
willfully, knowing and having been warned that such assumptions were
invalid.

I have little sympathy for the claims that this was somehow disruptive.
The people making these assumptions have known about and had been told of
the invalidity of those assumptions for many years. They didn't just learn
of this on Monday.  They were warned well in advance. All that happened on
Monday was that the hammer finally fell making those assumptions
operationally untenable.

> this does point out something about our standards - they're written
> assuming that people want to interoperate and that they're acting in
> good faith. while they might try to prohibit harmful behavior that might
> occur by accident, they weren't written to dictate the actions of
> potentially hostile parties (and I do regard VeriSign as hostile)

This is also unreasonable. Verisign is not hostile.

		--Dean

---

From: grenville armitage <[email-masked]>
Date: Fri, 19 Sep 2003 09:36:07 +1000

Bill Manning wrote:
	[..]
>         data in those zones.

"... publish the data in those zones."

if Verisign were not now also (effectively) _adding_ unlimited data to
those zones, i suspect we'd have less of a debate right now.

cheers,
gja

---

From: Dean Anderson <[email-masked]>
Date: Thu, 18 Sep 2003 15:49:15 -0400 (EDT)

On Thu, 18 Sep 2003 [email-masked] wrote:

> On Thu, 18 Sep 2003 14:32:33 EDT, Dean Anderson said:
> > No, that isn't correct. If you want to purchase a domain, you have to
> > check the registry database via whois.
>
> Why?  As you yourself said: "It is in fact reporting that the domain is available
> for purchase".

Yes, by pointing you to a netsol server that says so. It is the servers'
web content that says this, not the fact that the wildcard exists.  You
cannot use DNS to perform this check.

> If there's a nameserver for the domain, and there's an active
> mail host for the domain, that indicates an *IN USE* domain, as far as anybody
> can tell *ON THE SMTP PORT*.

But you don't look at the SMTP port to find out of the domain is
available.  No one has ever used DNS or SMTP to check on whether a domain
is purchasable.  This is sophistry.

The people most "disrupted" are those that were misusing reverse DNS.
Now that reverse DNS matches on unused domains, their invalid assumptions
have lost completely whatever operational usefulness they were wrongly
perceived to have once had.  But they were invalid previously.  So nothing
has been broken.

		--Dean

---

From: [email-masked]
Date: Thu, 18 Sep 2003 14:46:50 -0400

Why?  As you yourself said: "It is in fact reporting that the domain is available
for purchase".   If there's a nameserver for the domain, and there's an active
mail host for the domain, that indicates an *IN USE* domain, as far as anybody
can tell *ON THE SMTP PORT*.

---

From: [email-masked]
Date: Thu, 18 Sep 2003 16:10:35 -0400

> I don't know of any MTA that doesn't do this.

Right. The point is that the Verisign SMTP responds with a fixed series of
reply codes (220, 250, 250, 550, 221).  So let's run that with 3 recipients:

220 snubby4-wceast Snubby Mail Rejector Daemon v1.3 ready
MAIL FROM..
250 OK
RCPT TO...
250 OK
RCPT TO...
550  User domain does not exist.
RCPT TO...
250 OK
DATA
221 snubby4-wceast Snubby Mail Rejector Daemon v1.3 closing transmission channel
<Connection closed by foreign host.>

Now what do you do, absent a 3xx reply to your DATA command?

---

From: Dean Anderson <[email-masked]>
Date: Thu, 18 Sep 2003 14:32:33 -0400 (EDT)

> 2) The domain is available, but is in the DNS.  This would by all
> reasonable people be judged a miscommunication between the registrar of
> record and the DNS server, as there is data in the DNS that is not in
> any registrar.

Again, the method you describe is not a valid or method for determining if
domains are available. Nor is it one that any reasonable person would use
to determine if a domain was available for purchase.  So it has no value
as a rationale to justify the claim that something has been misreported.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Thu, 18 Sep 2003 18:17:21 -0400 (EDT)

On Thu, 18 Sep 2003 [email-masked] wrote:

> At 8:51 AM -0700 09/18/2003, Bill Manning wrote:
> Think it from a set theory perspective for a second.  They have been
> given the contract to populate a set (*registered* domains in COM. and
> NET.) and publish that set (through DNS, ftp-able zone files, whois,
> phone calls and so on). For this publication method, this behavior
> eliminates the ability to determine whether the item is in or out of the
> set.  This has a couple of consequences:

DNS, Zone files, etc, are not acceptable means to query the set.

> 1)  The different publication methods are out of synch.

DNS is always out of sync with the set. It comes close twice per day. But
even then it is out of sync probably before the zone transfers are
complete.  This is why there is only one method (whois) that is acceptable
to query the set.

> 2)  Those parts of the application infrastructure of the Internet which
> have protocol processing choices depending on that set membership
> response will get the protocol processing wrong.

They were wrong to begin with.  They shouldn't be depending on this
behavior. We've told those people that for a long time. We even discussed
removing reverse DNS from IPv6, just because of the substantial damages
caused by this incorrect use.

		--Dean

---

From: "bill" <[email-masked]>
Date: Thu, 18 Sep 2003 21:38:09 -0700

After all two wrongs don't make a right,
But two Wrights make an airplane

In honour of the 100 year aniversary

Bill

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Hoffman / IMC
Sent: Thursday, September 18, 2003 9:22 AM
To: [email-masked]
Subject: Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To
Us]

At 2:14 PM +0200 9/18/03, Francis Dupont wrote:
>=> IMHO it should reject SMTP connection from the beginning with the 
>521 greeting described in RFC 1846...

--Paul Hoffman, Director

---

From: [email-masked]
Date: Thu, 18 Sep 2003 15:40:14 -0700

>DNS, Zone files, etc, are not acceptable means to query the set.

If you believe this, we are starting from such different views of the world
that there isn't much point in us trying to convince each other.   Indeed,
I find it hard to understand what you think the set is for.
				Ted

---

From: [email-masked]
Date: Thu, 18 Sep 2003 16:09:45 -0400

> is purchasable.  This is sophistry.

Oh.. so if you're not actually on port 80, but on any one of the OTHER 65,364
legal ports, this doesn't apply:

> reporting that the domain is available for purchase. How is that

It's reporting it's available on port 80, and EVERY OTHER SERVICE can
go take a flying leap.

Internet != HTTP.

---

From: Neal McBurnett <[email-masked]>
Date: Thu, 18 Sep 2003 16:11:41 -0600

I've put up a web page about this at:

 http://bcn.boulder.co.us/~neal/ietf/verisign-abuse.html

with technical issues, pointers to relevant discussions, ICANN
agreements, contact info, etc.

I'd appreciate any pointers to similar efforts, or
suggestions for updates.

---

From: Dean Anderson <[email-masked]>
Date: Thu, 18 Sep 2003 22:12:06 -0400 (EDT)

> I find it hard to understand what you think the set is for.

The "set" is the set of *registered* names.  The proper and only way to
query this set is through whois.

DNS is a distributed database for the translation of domain names into
records that are useful for their respective purposes.  DNS has nothing to
do with registration (getting registering, being registered, other
registration information and contacts, etc).  Verisign generates zone
files from their registry information:

   Registry -> DNS zone

But the following is invalid:

   DNS zone -> Registration.

This is precisely the assumption that reverse DNS tries to make.

As I recall, the correct set-theory terms for this is "one-to-one but not
onto".

Does that make more sense?

		--Dean

---

From: Simon Leinen <[email-masked]>
Date: Fri, 19 Sep 2003 10:27:56 +0200

Yakov Shafranovich writes:
> Just to follow up on this - I just spoke to an engineer at Verisign
> and he informed me that the SMTP daemon is being replaced in a few
> hours with an RFC-compliant one. As for not giving a warning - this
> came from a higher policy level at Verisign and he is just an
> engineer.

They finally did, and the new version (1.5) of the "Snubby Mail
Rejector" does work better.  It handles multiple "RCPT TO:" commands
better - the previous version 1.3 would always reply 550 to the first,
but 250 to the next.  And the new version even does ESMTP with the
PIPELINING extension - this will save quite a few packets globally.

<[email-masked]>,<[email-masked]>... Connecting to dafladshflhfldkshflaasdf.com. via esmtp...
220 Snubby Mail Rejector Daemon v1.5 ready
>>> EHLO babar.switch.ch
250-snubby
250-PIPELINING
250-SIZE 10240000
250-ETRN
250-XVERP
250 8BITMIME
>>> MAIL From:<[email-masked]> SIZE=570
250 Ok
>>> RCPT To:<[email-masked]>
>>> RCPT To:<[email-masked]>
>>> DATA
550 <unknown[130.59.4.85]>: Client host rejected: The domain you are trying to send mail to does not exist.
550 <unknown[130.59.4.85]>: Client host rejected: The domain you are trying to send mail to does not exist.
554 Error: no valid recipients
>>> RSET
421 Error: too many errors
>>> QUIT
-- 
Simon.

---

From: [email-masked]
Date: Thu, 18 Sep 2003 14:46:56 -0400

Contrast that to a possibly multiple-hour wait if you're sending it off to wherever
Verisign is sucking your mail.  And *MAYBE* a bounce. (Work out what happens
if you send to more than one bad recipient).

---

From: [email-masked]
Date: Thu, 18 Sep 2003 14:09:46 -0700

Think it from a set theory perspective for a second.  They have been
given the contract to populate a set (*registered* domains in COM. and NET.)
and publish that set (through DNS, ftp-able zone files, whois, phone 
calls and so on).
For this publication method, this behavior eliminates the ability to 
determine whether
the item is in or out of the set.   This has a couple of consequences:

	a) In other contexts, the presence of a wildcard does not 
necessarily generate
incorrect protocol processing, _because the zone maintainer has the ability
and the right to make the other adjustments necessary to keep 
protocol processing
correct_.

	b) In this context, Verisign does not have the information 
and may not have
the right to collect the information which could possibly be used to 
keep protocol
processing correct.

My personal guess is that Verisign read:
http://www.iab.org/documents/docs/icann-vgrs-response.html
which makes a strong statement about the difference between the IDN
system they attempted and wildcards and drew the wrong conclusion.  Instead
of concluding "our job is to correctly populate and publish a set, 
and this system
does not do that" it concluded "ah, they want us to accomplish this task using
wildcards instead of the tools we used".  Since I contributed to that doc, I'll
take some blame for any lack of clarity--I, at least, was not trying 
to say "wrong tool",
I was trying to say "wrong task".  They have still got the wrong task.

To take something Steve Bellovin said on Nanog and elaborate it--this can be
seen as a monkey-in-the-middle attack, and the standard response to that
is to use cryptographic methods to ensure the trustworthiness of the response.
In this case, the monkey in the middle is in the business of ensuring trust,
and this means one of two things:

1) We must invent some new method of ensuring against this attack.

2) We must cease to trust assurances by this business.

I think, frankly, Versigin would be better off in the trust business than the
typo-advertising business, but this is obviously their choice.

For those who need reassurance, I am not speaking for my company, as an
Area Director, or on behalf of last year's IAB.  I am speaking for myself
and only myself.
				regards,
					Ted Hardie

---

From: Dean Anderson <[email-masked]>
Date: Thu, 18 Sep 2003 15:24:55 -0400 (EDT)

> Can you site any RFC that says that?

RFC 2821 (proposed standard) sheds some light on that: (This isn't a
replacement to STD0010, but reveals the disagreement on the roles of MTAs
and MUAs)

2.3.3 Mail Agents and Message Stores

   Additional mail system terminology became common after RFC 821 was
   published and, where convenient, is used in this specification.  In
   particular, SMTP servers and clients provide a mail transport service
   and therefore act as "Mail Transfer Agents" (MTAs).  "Mail User
   Agents" (MUAs or UAs) are normally thought of as the sources and
   targets of mail.  At the source, an MUA might collect mail to be
   transmitted from a user and hand it off to an MTA; the final
   ("delivery") MTA would be thought of as handing the mail off to an
   MUA (or at least transferring responsibility to it, e.g., by
   depositing the message in a "message store").  However, while these
   terms are used with at least the appearance of great precision in
   other environments, the implied boundaries between MUAs and MTAs
   often do not accurately match common, and conforming, practices with
   Internet mail.  Hence, the reader should be cautious about inferring
   the strong relationships and responsibilities that might be implied
   if these terms were used elsewhere.

Note the last sentence, which tends to refute the notion that there are
implied boundaries between MTAs and MUAs. This reflects your idea. But of
course, this is a proposed standard, and not a full standard. And there
are good reasons to reject this.

Most people, and the market for mail software, tend to support the notion
that there is a distinction and a boundary between MUA and MTA.

RFC 821 (STD0010) Section 2:

   The argument to the MAIL command is a reverse-path, which specifies
   who the mail is from.  The argument to the RCPT command is a
   forward-path, which specifies who the mail is to.  The forward-path
   is a source route, while the reverse-path is a return route (which
   may be used to return a message to the sender when an error occurs
   with a relayed message).

MTAs route mail.  MUAs do not.

> > There are many ISPs that block this. Are they doing something wrong?
> >

Certainly not. If it is valid for the MUA to connect directly, then it is
invalid to block this, assuming such mail privileges were given.  Such
ISPs give MUA privileges, not MTA privileges. So this distinction is
useful technically and contractually.

> >Mail clients are supposed to connect to their configured mail relays,
> >which has the responsibility to route mail.
> >
> Says who?

At the very least, the market of system administrators who purchase mail
software; most mail clients that are configured to use a specific relay.
Most mail clients do not connect directly.  And the market that wants to
unbundle MUA services from MTA services.

> Breaking existing applications like MUA's (and your ISP's relays)

Those have not been broken. Mine work just fine.

IF some were misconfigured previously, then it is the administrators who
misconfigured them who are at fault, not Verisign.

		--Dean

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 20 Sep 2003 15:04:52 +0859 ()

Dean;

> query this set is through whois.

The only reason to have domain names registered is to use it
through DNS.

Whois may be a useful tool for registration convenience but is of
secondary importance.

If you disagree, let me control DNS reply of your domain "av8.com",
while keeping whois response to "av8.com" as is.

> DNS has nothing to
> do with registration

If you are arguing that verisign registration has nothing to do
with DNS, I have no reason to disagree.

Then, for DNS use, we need another registration which has much
to do with DNS.

Verisign can still continue to operate their current registry
for "com" and "net" for their whois query, though it has nothing
to do with "com" and "net" TLDs in DNS reply.

							Masataka Ohta

---

From: Tim Chown <[email-masked]>
Date: Sat, 20 Sep 2003 10:25:56 +0100

So when are Verisign's rights to handle .net/.com up for renewal?

It seems we should see that they don't get a renewal.

Tim

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 20 Sep 2003 20:54:43 +0859 ()

Tim;

> It seems we should see that they don't get a renewal.

Which .net/.com? Whois ones or DNS ones?

Whois ones may be updated by Verisign, forever. :-)

---

From: Doug Royer <[email-masked]>
Date: Sat, 20 Sep 2003 11:02:25 -0600

>replacement to STD0010, but reveals the disagreement on the roles of MTAs
Your quote talks about conventions that may be used. It does not support 
your view
that the MUA and MTA have to be separate pieces of code. And what your 
ISP does
for your does not have to be what other ISPs do for their customers.

>   published and, where convenient, is used in this specification. ....
>

--

---

From: Dean Anderson <[email-masked]>
Date: Sat, 20 Sep 2003 19:01:36 -0400 (EDT)

You are correct that SMTP is a peer to peer protocol, not a client server
protocol.  However, there is a distinction between mail routing, an MTA
function, and mail submission, an MUA function.

The MUA in this case is performing (incorrectly) MTA functions.  That is a
bug.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Sat, 20 Sep 2003 19:13:24 -0400 (EDT)

> The only reason to have domain names registered is to use it

The only reason we have DNS is to associate information such as IP
addresses with names.  Registration is far more important than the
protocol.

> Whois may be a useful tool for registration convenience but is of

This is the tail wagging the dog.

> while keeping whois response to "av8.com" as is.

I also say that power is of secondary importance to computing.  What we
are interested in is the result of computing.  We do not care about power,
unless I give you control over the power switch.

> with DNS, I have no reason to disagree.

I think you missed this:

   Registration -> DNS

   DNS !-> Registration

The symbol '->' is read to mean "implies something about".

You are correct that Registration has a lot to do with DNS. But DNS has
nothing to do with Registration, as I said. You cannot check a
registration via DNS.  This is what abusers of reverse DNS are doing, or
rather, were attempting to do.

---

From: Dean Anderson <[email-masked]>
Date: Sat, 20 Sep 2003 19:18:59 -0400 (EDT)

On Sat, 20 Sep 2003, Doug Royer wrote:
> your view that the MUA and MTA have to be separate pieces of code.

If they aren't separate peices of code, how is it that their functions
will be separated?  But assuming an MTA is bundled together with an MUA,
the MUA function must hand the message to the MTA function for routing.
The function of an MTA is still to return a bounce.  The MUA functions may
not attempt to perform routing.  So they cannot determine immediately if
the "domain exists".

> And what your ISP does for your does not have to be what other ISPs do
> for their customers.

I agree.

		--Dean

---

From: Lyndon Nerenberg <[email-masked]>
Date: Sat, 20 Sep 2003 17:29:35 -0600 (MDT)

> The MUA in this case is performing (incorrectly) MTA functions.  That is a

$ sendmail -t
From: lyndon
To: lyndon
Subject: Dean is wrong

hi there
.
$

Say again?

--lyndon

The longest UNIX error code is  ENAMETOOLONG.

---

From: Dean Anderson <[email-masked]>
Date: Sat, 20 Sep 2003 19:46:08 -0400 (EDT)

I notice that it didn't try to route the message immediately when you did
that.

Sendmail, works just like I describe.  You are wrong.

		--Dean

---

From: Masataka Ohta <[email-masked]>
Date: Sun, 21 Sep 2003 08:47:29 +0859 ()

Dean;

> addresses with names.

I think you should clarify your terminology.

You say "names". But, is it "whois names" or "domain names"?

I think you know what D and N of DNS stand for.

> Registration is far more important than the
> protocol.

In this context, yes.

I'm talking about not protocols, but names retrieved through the
protocol, domain names retrieved through DNS.

> are interested in is the result of computing.

As the computing use DNS, not whois, the result of computing is
controlled by DNS.

> We do not care about power,

You are saying we should care about power, if we give someone
control over the power switch.

In this case, "someone" was verisign.

> > > do with registration

It mathematically means:

   Registration !-> DNS

   DNS !-> Registration

>    DNS !-> Registration

Study mathematics.

							Masataka Ohta

---

From: Lyndon Nerenberg <[email-masked]>
Date: Sat, 20 Sep 2003 18:25:12 -0600 (MDT)

On Sat, 20 Sep 2003, Dean Anderson wrote:

There's one in every crowd ...

> I notice that it didn't try to route the message immediately when you did

$ sendmail -t
From: [email-masked]
To: [email-masked]
Subject: Dean is *still* wrong

idiots abound
.
$

--lyndon

Never express yourself more clearly than you think.
			-- Neils Bohr

---

From: "Anthony Atkielski" <[email-masked]>
Date: Sun, 21 Sep 2003 02:42:01 +0200

Dean writes:

> However, there is a distinction between mail routing, an MTA

Not in the SMTP protocol.

---

From: Larry Smith <[email-masked]>
Date: Sat, 20 Sep 2003 20:18:46 -0500

> addresses with names.  Registration is far more important than the

 Actually registration tells "who" (as in what servers) to query _for_ DNS.

> > to do with "com" and "net" TLDs in DNS reply.

 My psyc professor always said - "The norm _is_" - meaning that what people 
do, regardless of how logical, correct, or whatever, at some point "becomes" 
the normal accepted behavior.  As in the statement "When in Rome...".  Such 
is the situation here, in that the norm has become to "accept" that no dns 
(eg nxdomain) has meant no registration or a suspended registration.  
Regardless of the semantics and word dicing - the "norm" has been changed by 
Versign's actions.

-- 
Larry Smith
SysAd ECSIS.NET
[email-masked]

---

From: "Eric A. Hall" <[email-masked]>
Date: Sat, 20 Sep 2003 20:30:46 -0500

on 9/20/2003 6:01 PM Dean Anderson wrote:

> You are correct that SMTP is a peer to peer protocol, not a client
> server protocol.  However, there is a distinction between mail routing,
> an MTA function, and mail submission, an MUA function.

The functions constitute the service, not the protocol. The protocol is
just one part of the service (mostly the transfer function), while things
like routing and submission are separate. Filesystem submission, nis/ldap
routing, ..., are also valid for the service at-large, while outside the
scope of the SMTP protocol.

Whenr the protocol is used for these functions, the functions are usually
folded to fit the demands of the protocol. If an implementation folds the
protocol to fit the function, then it's not the same protocol anymore.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: Doug Royer <[email-masked]>
Date: Sat, 20 Sep 2003 19:37:36 -0600

Dean Anderson wrote:

>If they aren't separate pieces of code, how is it that their functions
>will be separated?
>

The RFC does not say they must be separate programs. It talks about 
separate functions at the
conceptual level.

>  But assuming an MTA is bundled together with an MUA,
>The function of an MTA is still to return a bounce.
>

So even if you were right, it busts the MTA:

Prior to the change, the MTA would say "NO SUCH HOST" and never send the 
email (and
my  MTA was built into my MUA).

Now the MTA gets the 64.94.110.11 address and sends the email to the non 
existent domain.
Only for the same MTA to later get a bounced email that it has to make 
available to the MUA.

And I hope this will be my last email on this subject as this is not the 
list for this debate.

--

---

From: Dean Anderson <[email-masked]>
Date: Sun, 21 Sep 2003 16:00:47 -0400 (EDT)

On Sat, 20 Sep 2003, Doug Royer wrote:

> email (and my MTA was built into my MUA).
>
> existent domain. Only for the same MTA to later get a bounced email that
> it has to make available to the MUA.

It never sends the email in either case. In the first case, it will say no
such host, and return an error to the user.  In the second case, it will
attempt to connect to 64.94.110.11 and will get an error, which will be
returned to the MUA.

In both cases, it is permissible for the MTA to try again later in the
first case.

Both of these are perfectly valid responses. You get them at the same
time, or you get the second one sooner.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Sun, 21 Sep 2003 15:50:41 -0400 (EDT)

> You say "names". But, is it "whois names" or "domain names"?

I mean "people useful" names. Whois is a protocol for accessing the
registration of names. DNS is a a protocol for distributing Records
associated with names.  Registries of names are found all over
civilization. At the Department of Motor Vehicles, at the Patent and
Trademark Office, at the Department of State Division of Corporations,
etc.

> protocol, domain names retrieved through DNS.

So am I, above.

> In this case, "someone" was verisign.

Verisign was given that control, and there is no evidence that they have
somehow abused that control.

> > > > DNS has nothing to do with registration
>
> It mathematically means:
>    Registration !-> DNS
>    DNS !-> Registration

No, that isn't what it means, mathematically. But perhaps this is what it
means to you. If so, this is the source of our difficulties.

> Study mathematics.

I have.  I think you need to go back and check out your logical
connectives.  The following is a perfectly valid construction:

  Registration -> DNS
  DNS !-> Registration

It represents the relationship between domain names services, and
registration services.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Sun, 21 Sep 2003 15:55:10 -0400 (EDT)

Yes, there always is someone who just doesn't understand what they are
talking about.

/usr/sbin/sendmail -t
From: [email-masked]
To: [email-masked]
Subject: Lyndon can't figure out how sendmail works

Sendmail doesn't route messages in MUA mode.

.

Sendmail has completely different internal procedures to handle -t

		--Dean

---

From: Larry Smith <[email-masked]>
Date: Sun, 21 Sep 2003 16:06:00 -0500

> time, or you get the second one sooner.

Not quite totally true.  In the second case - it _will_ connect and initiate 
the transfer (helo, mail from, rcpt to) phase of _sending_ the message.  It 
will fail, but it will make the attempt.  Whereas with the first case it will 
never try.  The second is much, much slower from the perspective of a mail 
server.

-- 
Larry Smith
SysAd ECSIS.NET
[email-masked]

---

From: [email-masked]
Date: Sun, 21 Sep 2003 18:04:17 -0400

> attempt to connect to 64.94.110.11 and will get an error, which will be

So if a domain gets shelved by accident, as happened to one NANOG poster
this weekend, all their mail gets sucked up and handed a 5xx error by the
Verisign server and bounced, rather than getting hit with a 4xx and retried
for a few days.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 22 Sep 2003 08:52:32 +0859 ()

Dean;

> registration of names. DNS is a a protocol for distributing Records

Wrong.

Whois protocol is a protocol for accessing the registration of
names, not specifically domain names.

DNS, domain name system, is not a protocol but the system to manage
domain names.

DNS protocol is the protocol to access domain names.

The system, of course, includes registries, which may use any
additional protocol.

> Registries of names are found all over

That's why clarification that we are discussing on domain names of
DNS essentially important.

As you are talking about not domain names of DNS system but
other names, your statement has nothing to do with domain names.

The remaining problem is that you don't understand "has nothing to do
with". But you can understand, I hope, that verisign is not the
trademark registry. Or, you may be able to consult with dictionaries.

							Masataka Ohta

---

From: Dean Anderson <[email-masked]>
Date: Mon, 22 Sep 2003 16:43:43 -0400 (EDT)

> Verisign server and bounced, rather than getting hit with a 4xx and retried

As was pointed out, some servers will give up right away.  In either case,
the user should get a bounce, and can follow the instructions as to
whether the delivery will be retried or not.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Mon, 22 Sep 2003 16:41:33 -0400 (EDT)

> never try.  The second is much, much slower from the perspective of a mail

Some may never try. Sendmail won't try in that case. But it is perfectly
valid to wait and try again. In such a case, the wait time is typical 3 to
5 days.

In the second case, it takes usually about 300ms to setup a tcp
connection, and fail. This 300ms isn't too long to wait.  I doubt that
most people would notice.  Quite a lot of fuss over 300ms, I think.

And I am just thrilled to see IE not go to MSN when I type in a wrong
name. I've been showing this to everyone. Most people like the
demonstration, and trust Verisign more than Microsoft.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Mon, 22 Sep 2003 17:19:42 -0400 (EDT)

> DNS, domain name system, is not a protocol but the system to manage

I've never heard of such a system. I manage zone files with Vi or Emacs,
and RCS. I've heard there are some php scripts that do this quite nicely,
too. Microsoft has a nice application to do this, but I don't use the
Microsoft server. These are applications that are not the concern of the
IETF, nor of ICANN.

> DNS protocol is the protocol to access domain names.

Yes, that is what I mean when I say "DNS".

> other names, your statement has nothing to do with domain names.

Uhh, no. You don't seem to understand that names are abstract concepts,
and that the DNS is a communication protocol to associate the abstract
concept of a name designation with a concrete concept of a data like an IP
address.

A registry associates the abstract concept of a name with a concrete
concept of an organization or owner, and other adminstrative information.
Some of that information is helpful to the operation of DNS.  However,
even without DNS, we would still need to have a registry to associate this
information, and to help construct LDAP directories, or X.500 directories.

The construction of these directories does not place any restrictions on
the registry.  One cannot show up, and claim "I saw this via DNS, so
therefore it must be registered", or "I didn't see this in DNS, so
therefore it must not be registered"  anymore than one can show up at the
corporations office with a coffee cup and a logo and say "I have a cup,
where is my certificate of incorporation?".

> trademark registry. Or, you may be able to consult with dictionaries.

I think you don't understand the difference between "one to one" and
"onto". I've specified exactly what the translation of the statements
  "DNS has nothing to do with Registration.
   Registration has something to do with DNS"

into mathematical language.  Equivalently, one can say

  "DNS implies nothing about registration.
   Registration implies something about DNS"

This is equivalent to:

   DNS !-> Registration
   Registration -> DNS

As before.

It seems you don't understand this.  The problem, it seems, is that you
can't understand something about logical connectives.  Specifically, you
don't seem to understand the truth tables of statements of logic. Until we
resolve that, we can't communicate.  I can recommend some textbooks for
you, if you like.  Then we can communicate.

However, this failure to properly understand the relationship between DNS
and Registration is shared by a sizeable minority of people, who insist on
trying to use DNS to imply things about registration.  This results in
much harm, as has been documented and explained on DNSOP and Namedroppers.
Numerous security vulnerabilties have been introduced as a result, and
continue to be introduced, as a result of this. We have considered
dropping Reverse DNS altogether from IPv6, and have implemented alternate
methods to replace Reverse DNS in applications such as traceroute.  The
harms are serious, significant, and well documented.

Everything "broken" as a result of the Verisign wildcard fall into the
category of "misuse of the DNS system".  All of these things have been
broken for sometime.

		--Dean

---

From: Russ Allbery <[email-masked]>
Date: Mon, 22 Sep 2003 14:36:27 -0700

> demonstration, and trust Verisign more than Microsoft.

Doesn't configuring browser behavior by making fundamental changes to the
nature of the .com and .net zones strike you as overkill?

In my browser, I can go into the configuration menu and specify whatever
behavior I want for handling of unknown hosts (or at least I could, until
Verisign broke that behavior).  This seems to me to be a more natural way
of configuring the behavior of my software than imposing on the entire
rest of the world a configuration that's slightly more convenient for me.

Besides, I want unknown hosts to go to Google instead.  How do I get
Verisign to do that?

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Doug Royer <[email-masked]>
Date: Mon, 22 Sep 2003 15:57:23 -0600

>whether the delivery will be retried or not.
No. On once case your get a "no such host" error and never send the 
email in the first place
and the other case gets a bounce. Not the same thing.

I manage a site that sends mortgage documents. It NEEDS to be sure that 
the destination
is valid before sending confidential information. So the first time a 
new e-mail address
is allowed to send the very sensitive information to a new email address 
it looks up the
host and submits the initial message itself.  So unless I want to parse 
every possible
error text the bogus verisign SMTP server may say, I had to hack the 
code so that it knows
that the IP address provided by Verisign means no such host and never 
sends the confidential
information to a site that may be using the information in a way that is 
in conflict with the
senders confidentially requirements.

Same with health / HIPPA issues. Saying I'll take your email and bounce 
it back is not
the same as saying "hey bozo, you are trying to send to a bogus host name".

The email may be encrypted, however that is not sufficient for some usage's.

--

---

From: John C Klensin <[email-masked]>
Date: Mon, 22 Sep 2003 19:57:33 -0400

--On Monday, 22 September, 2003 15:57 -0600 Doug Royer 
<[email-masked]> wrote:

>...
> Same with health / HIPPA issues. Saying I'll take your email
> and bounce it back is not

In particular, encryption doesn't protect the information that a 
particular sender was trying to send information to a particular 
recipient.  For some applications and transactions, having that 
information in the wrong hands --e.g., knowing who is trying to 
communicate with a competitor-- can, itself, be a significant 
security and/or privacy problem.

   john

---

From: Larry Smith <[email-masked]>
Date: Mon, 22 Sep 2003 19:37:48 -0500

On Monday 22 September 2003 15:41, Dean Anderson wrote:
> > Not quite totally true.  In the second case - it _will_ connect and
> > initiate the transfer (helo, mail from, rcpt to) phase of _sending_ the
> > message.  It will fail, but it will make the attempt.  Whereas with the
> > first case it will never try.  The second is much, much slower from the
> > perspective of a mail server.
>

Hmmm, maybe 300ms is not a long time for a "person" - but when one has say 
several thousand messages in queue on a server, it starts to add up quickly 
and this was the original context of the thread I believe - them "impact" on 
mail servers trying to deliver mail.

-- 
Larry Smith
SysAd ECSIS.NET
[email-masked]

---

From: Larry Smith <[email-masked]>
Date: Mon, 22 Sep 2003 19:42:53 -0500

On Monday 22 September 2003 19:04, Dean Anderson wrote:
> > >As was pointed out, some servers will give up right away.  In either
> > > case, the user should get a bounce, and can follow the instructions as
> > > to whether the delivery will be retried or not.
> >
> > email in the first place and the other case gets a bounce. Not the same
> > thing.
>
> You don't seem to understand how mail works. In both cases you get a
> bounce. In neither case is a message sent.

Hmmm, again not totally true.  In the first case (pre-Versign) the mail 
"client" (user end of the equation - at least on all my servers) would get an 
"invalid address" type error (whatever Microsoft dreams up) and hence the 
message would never "leave" their machine.  In the second case 
(post-Verisign) the message is accepted by my server (since it cannot tell at 
that stage) and it (my server) will then try to deliver.  Depending upon the 
error code, the server might bounce immediately, or it might try for "x" 
amount of time before it bounces.  

  Significant difference between the email never leaving the client/customer 
machine and going to a "host" server and then being bounced....

-- 
Larry Smith
SysAd ECSIS.NET
[email-masked]

---

From: Dean Anderson <[email-masked]>
Date: Mon, 22 Sep 2003 20:04:41 -0400 (EDT)

> the destination is valid before sending confidential information.

This isn't broken.  You won't send any messages because you won't get to
the "data" command. You will get an SMTP error code. The message is never
delivered to Verisign.

Those claiming otherwise are simply lying, and using fear mongering
techniques, as you are below.

> So the first time a new e-mail address is allowed to send the very
> sensitive information to a new email address it looks up the host and
> submits the initial message itself.  So unless I want to parse every
> possible error text the bogus verisign SMTP server may say, I had to
> hack the code so that it knows that the IP address provided by Verisign
> means no such host and never sends the confidential information to a
> site that may be using the information in a way that is in conflict with
> the senders confidentially requirements.
>
> it back is not the same as saying "hey bozo, you are trying to send to a
> bogus host name".
>

---

From: Doug Royer <[email-masked]>
Date: Mon, 22 Sep 2003 19:04:08 -0600

Dean Anderson wrote

 >>> As was pointed out, some servers will give up right away. In either 
case,
 >>> whether the delivery will be retried or not
 >>>
 >> thing.You don't seem to understand how mail works. In both cases you 
get a
 >> bounce. In neither case is a message sent.

You do not seem to be getting the message the MTA and MUA MAY be the same
program. So NOT true.

> the "data" command. You will get an SMTP error code. The message is never

The fact that a 3rd party knows (or can tell) that user X tried
to send email to user Y can be a violation of HIPPA security.

--

---

From: Dean Anderson <[email-masked]>
Date: Mon, 22 Sep 2003 21:35:30 -0400 (EDT)

> amount of time before it bounces.

You missed the start of this discussion, I think. This is what Doug Boyer
said. However, the MUA should always hand the message to the MTA portion,
and the MTA should always return a bounce.  We just went through why the
MUA shouldn't be performing these checks. You might want to go back
through the recent archives and look at this discussion.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Mon, 22 Sep 2003 22:01:49 -0400 (EDT)

> You do not seem to be getting the message the MTA and MUA MAY be the same

I do. Even in the same program, they are different functions. The MTA
should return a bounce. You should always get a bounce, in response to an
error. You should never get "no such domain" in response to typing in an
email address to an MUA.

> to send email to user Y can be a violation of HIPPA security.

No. Because the 3rd party didn't know that X tried to send mail to Y. The
domain doesn't exist, so Y's identity has not been revealed.  Only
non-registered domains go to Verisign.

The HIPPA argument doesn't fly at all. However, Verisign is also subject
to the ECPA, and may not disclose the contents email, any more than any
other communications providers can. No confidentiality (HIPPA or
otherwise) is broken.

I'm not sure if you are ignorant of HIPPA, the ECPA, or just
fear-mongering.  I guess all those people who used to say there were no
laws on the internet must now be thinking "well, there ought to be". Well,
they're in luck. It just happens there are laws already.

		--Dean

---

From: Larry Smith <[email-masked]>
Date: Mon, 22 Sep 2003 22:31:09 -0500

On Monday 22 September 2003 20:35, Dean Anderson wrote:
> > "client" (user end of the equation - at least on all my servers) would
> > get an "invalid address" type error (whatever Microsoft dreams up) and
> > hence the message would never "leave" their machine.  In the second case
> > (post-Verisign) the message is accepted by my server (since it cannot
> > tell at that stage) and it (my server) will then try to deliver. 
> > Depending upon the error code, the server might bounce immediately, or it
> > might try for "x" amount of time before it bounces.
>

Have followed the thread and am aware of what has been said.  Point still 
remains, your comment is that in "neither" case will the message get 
delivered - and my comment was "not totally true".  I am not referring to the 
MUA doing the check, I am referring to it being done at the MTA upon hand-off 
from the MUA.  Pre-Verisign "many" mail servers (mine included) would 
"reject" a bogus or non-existant address _before_ receipt of the message from 
the MUA therefore leaving the message on the client/customer machine (at the 
MUA).  Post-Verisign there is no such thing as a "non-existant" com or net 
domain from the MTA point of view (eg: it will get an "answer" to any and all 
queries for MX - the "A" record for verisign) hence the message is accepted 
by the MTA [ this constitues first "delivery"], then it (the MTA) attempts to 
deliver - and _then_ fails and is presumably returned to the originator.

If I am technically incorrect please let me know, but your comment was  - and 
I quote 

>>> In both cases you get a

which is at least "partly" incorrect.  The acceptance of a message by an MTA 
for delivery constitutes a "send" condition to the MUA.  Check any mail 
software you wish.  If you/your mail software hand a message off to the 
"next" machine/system/server in your particular mail chain - then to your 
mail software the message _has_ been sent.  Any Outlook user can prove this 
by simply checking their "sent" message folder.  The fact that it is 
immediately or subsequently returned does not mean it was not "sent".

This is what verisign has "changed"...
-- 
Larry Smith
SysAd ECSIS.NET
[email-masked]

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 23 Sep 3 14:12:34 JST

Dean;

> I've never heard of such a system.

DNS is an acronym of Domain Name System.

> Uhh, no. You don't seem to understand that names are abstract concepts,

And the names are called domain names.

PERIOD.

							Masataka Ohta

---

From: Bruce Campbell <[email-masked]>
Date: Tue, 23 Sep 2003 13:33:42 +0200 (CEST)

> bounce. In neither case is a message sent.

To correct you on matters emailish once again; a SMTP transaction can be
rejected _after_ the DATA (the complete message) has been completed.

The fact that Entity Foo _currently_ rejects the SMTP transaction before
the data statement is not a guarantee that Entity Foo will _always_ reject
the SMTP transaction before the data statement.

( See 4.2.5 of RFC2821 and 4.1.1 (&4.3) of RFC821 )

This is what some people are afraid of; that Entity Foo _does_ have the
_ability_ to intercept the complete email message, even though Entity Foo
does not appear to use it.  For Doug's application, the fact that Entity
Foo (being a 3rd party) does have this ability is enough to dictate
careful reconsideration of its methodology.

> the "data" command. You will get an SMTP error code. The message is never

s/never/currently not/ .

> techniques, as you are below.

Actually, those claiming otherwise seem to have read and understood
various references on how email works.

---

From: jfcm <[email-masked]>
Date: Tue, 23 Sep 2003 14:31:18 +0200

>This is what verisign has "changed"...

I am afraid this is not what they have changed, this is what IETF has not 
addressed in 20 years.
Let not blame the need. Let blame the lack of solutions.
jfc

---

From: Doug Royer <[email-masked]>
Date: Mon, 22 Sep 2003 21:16:45 -0600

>error. You should never get "no such domain" in response to typing in an

No bounce - it was never sent becuse the MUA checked first to see if
the target domain even existed priror to sending the email.

>>to send email to user Y can be a violation of HIPPA security.

The 3rd pary *is* verisign.  And it is free to change its policy at any 
time and
harvist those addresses.

>>they're in luck. It just happens there are laws already.

You reall do not have a clue about HIPPA regulations.

--

---

From: Dean Anderson <[email-masked]>
Date: Tue, 23 Sep 2003 14:15:51 -0400 (EDT)

On Mon, 22 Sep 2003, Larry Smith wrote:

> MUA).

Sure, but when the MTA rejects something in this case, a bounce is
returned to the user. As I said, in all cases a bounce should be returned.

In this case, as bounce is still returned. The only (trivial) difference
is that the MTA must make a connection to the verisign server to get its
rejection.

All that has been changed (at most), is the error message in the bounce
message.

However, the configuration you describe has been shown to be less than
ideal.  High speed systems first queue all the messages, then filter spam,
then route those that are not spam.  Attempting to reject messages "early"
results in poorer performance.  So I think we need not be too concerned
with the nominal effect on such systems.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 23 Sep 2003 14:24:42 -0400 (EDT)

> DNS is an acronym of Domain Name System.

This acronym, used in RFC 1034 and elsewere refers to a protocol. RFC 1034
and subsequent RFCs describe the protocol.  You seem to think that
Verisign operations are restricted by this protocol.  This is incorrect.
You have offered no relevant facts to support your claims.

> And the names are called domain names.

That is irrelevant to the discussion.

The fact still remains that DNS entries do not necessarilly imply
registration, and that the DNS protocol cannot be used to make registry
queries.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 23 Sep 2003 14:43:31 -0400 (EDT)

> rejected _after_ the DATA (the complete message) has been completed.

This is not a correction. I have never said it can't be rejected after the
DATA transaction.

> the SMTP transaction before the data statement.

Well, this is the purpose of the SMTP mail rejector that Verisign
operates.  The Electronic Communications Privacy Act ensures that they
will not ever divulge the contents of such mail.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 23 Sep 2003 14:52:06 -0400 (EDT)

> You reall do not have a clue about HIPPA regulations.

Actually, I have customers who are hospitals and health care providers and
pharmaceutical companies.  I have a copy of the HIPPA regulations. I have
a clue about HIPPA regulations.

HIPPA covers _medical_ information. Email addresses are not medical
information. The email address in an email message is not a medical record
protected by HIPPA.  Third, the email address is already being disclosed
to the ISP running the relay.

The relevant privacy law involving email is the ECPA, not HIPPA.  Verisign
is prevented from disclosing the contents of any email, as is the ISP.
Quite obviously, Verisign is not improperly disclosing any information.
Contrary assertions are FUD.

		--Dean

---

From: Doug Royer <[email-masked]>
Date: Tue, 23 Sep 2003 15:02:23 -0600

>to the ISP running the relay.
You keep assuming things and then declaring them as reasons for it to be 
a non-issue.
Your assumptions about my implementation, my customer requirements,
regulatory rulings relatedto HIPPA as it effects the customers license 
to practice, and my
email routing are not true.

>Contrary assertions are FUD
>
Name one good reason to run a bogus SMTP server that always rejects
email if it is not their intention to use the data? Why would
anyone accept connections on the SMTP port at all if not to use
the data? There are only two reasons that I can think of; (1)
when they experimented they found that they caused email to back
up one sending systems when sent to bogus hosts and/or (2) they
want the sender email address.

Item (1) means they did find that what they were doing broke
things and they attempted to fix it.

And (2) may be FUD, but there is NO law that keeps them from
collecting the sender email address.

--

---

From: Dean Anderson <[email-masked]>
Date: Tue, 23 Sep 2003 19:35:45 -0400 (EDT)

> a non-issue. Your assumptions about my implementation, my customer
> requirements, regulatory rulings relatedto HIPPA as it effects the
> customers license to practice, and my email routing are not true.

I'm not assuming anything about your customer requirements, other than
they are obviously sending email over the internet, and that on occassion,
they might have a invalid domain name in an email address.

This is just an officious sounding FUD phrase:
     "regulatory rulings related to HIPPA as it effects the customers
license to practice" is simply meant to scare users and care providers.
Nothing here is affected by HIPPA regulatory rulings or care providers'
license to practice.  But of course, your whole claim about HIPPA is
nothing but FUD.

> email if it is not their intention to use the data?  Why would anyone
> accept connections on the SMTP port at all if not to use the data?

Other TLD's that have wildcard entries do it.  Verisign's research
probably included the practices of other TLDs that use wildcard entries.

Having a rejector allows the mail to be rejected faster and ultimately
reduces network traffic. Not having a rejector would cause relays to
continue trying to connect for up to several days.  The TCP syn packet,
along with the ICMP message is about the same as accepting the connection
and rejecting the message.

There has been no evidence that Verisign has collected any sender
addresses, nor would there be any reason for them to want to.

Your two reasons, the 'only reasons you can think of', like the rest of
this, are nothing but FUD.

		--Dean

---

From: Tim Chown <[email-masked]>
Date: Wed, 24 Sep 2003 01:02:23 +0100

> That is irrelevant to the discussion.

What is relevant to this discussion?

It goes on endlessly (although I'm only seeing 50% of the posts without
looking in my "special" folder :)

Tim

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Sep 2003 09:12:25 +0859 ()

Dean;

> This acronym, used in RFC 1034 and elsewere refers to a protocol.

As is clearly stated in the second paragraph of rfc1034,

	A subset of DNS functions and data types constitute an official
	protocol.

DNS system includes DNS protocol but is not DNS protocol.

> RFC 1034
> and subsequent RFCs describe the protocol.

Yes, rfc1034 does describe the protocol and other things. So what?

> You seem to think that
> Verisign operations are restricted by this protocol.

No. DNS is a system, not a protocol.

Verisign operations directly related to the protocol, is, of course,
restricted by the protocol, though, which is irrelevent.

> registration, and that the DNS protocol cannot be used to make registry

Domain registry is a part of DNS system and is of no importance
as long as proper names are returned for DNS queries.

							Masataka Ohta

---

From: Dean Anderson <[email-masked]>
Date: Tue, 23 Sep 2003 20:49:30 -0400 (EDT)

> as long as proper names are returned for DNS queries.

Good, Then we agree: Verisign is not doing anything wrong.  Wildcards are
part of the DNS protocol.  A wildcard is a "proper name .. returned for
DNS queries".

		--Dean

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Sep 2003 10:08:50 +0859 ()

Dean;

> Good, Then we agree: Verisign is not doing anything wrong.

As long as Verisign's registry has nothing to do with the result for
com/net TLD query, yes.

> Wildcards are part of the DNS protocol.

You are still trying to confuse the system and a protocol in vain.

Our concern is not merely on a protocol but on the DNS system as a whole.

							Masataka Ohta

---

From: Dean Anderson <[email-masked]>
Date: Tue, 23 Sep 2003 23:53:35 -0400 (EDT)

> You are still trying to confuse the system and a protocol in vain.

It is you who is struggling in vain. You and the rest of the reverse DNS
abusers are confused. They and you, have been proven wrong on this subject
on DNSOP and Namedroppers.  They and you insist on making assumptions that
aren't true; Specifically, you insist that DNS queries, via DNS _protocol_
can be used to check if a domain exists. But such checks are based on
false assumptions.  Nothing you can do or say can make this true, because
it is indisputably false.  Even eliminating wildcards from the protocol
will not make this true.  Your belief in this has the character of
religious zealotry, as you will not believe anything anyone says on the
subject, despite having had your assumptions so obviously and publicly
proven to be false.  Even reducing the statements to the abstract logic
statements

  	DNS !-> Registration
	Registration -> DNS

which are true, and consistent with actual and standardized behavior, you
can't accept the truth of these statements.  But neither have you shown
them to be false. That is simple obstinancy.  I cannot overcome that. No
one can. So there is little point to continuing this discussion.

> Our concern is not merely on a protocol but on the DNS system as a whole.

Indeed. Then why do you insist on abusing reverse DNS to the point that
security vulnerabilities have been introduced, abuses have been well
documented and are severe problems, and the DNS working groups have
discussed removing Reverse DNS altogether to combat these problems and
abuses?

		--Dean

---

From: [email-masked]
Date: Wed, 24 Sep 2003 00:50:47 -0400

> addresses, nor would there be any reason for them to want to.

*plonk* Sorry Dean, you've finally managed to push over the edge from "possibly
just dense" into "obviously being intentionally dense".

"nor would there be any reason"?  Take the number of mis-addressed pieces of
mail per day (which was sufficient to even DDoS their Snubby server, which was
hopefully not a very heavy-weight MTA), and multiply by the going rate for
pre-washed e-mail addresses.

Or phrased differently - given that it's all about the benjamins, is there any
reason to expect them to *NOT* use the data they're being given to compile
lists for spammers?

---

From: Dean Anderson <[email-masked]>
Date: Wed, 24 Sep 2003 02:19:03 -0400 (EDT)

More FUD.

Real spammers use opt-in addresses, collected by the companies they are
spamming for. This costs the company no more than collecting snail mail
addresses.  Most companies collect these opt-in addresses.

Only radical antispammers collect and abuse addresses via things like
webscanning. And then they tell people that spammers do this. Clue: There
are no real companies selling fake viagra via spam.  These, and many other
"spams" are sent to you by anti-spammer script kiddies to try to get
people to pass anti-spam legislation.

Of course, real spammers aren't violating the anti-spam legislation. They
weren't before, and aren't now.  When blacklists like MAPS block them,
they sue in court, and win.  Real spammers are now on fixed IP addresses
with T3 connections.  They are easy to pick out of the "noise". I haven't
seen a single unsolicited spam from them.

In fact, haven't seen a spam that is both _unsolicited_ and _genuine_ in
over a year.  Yet I am getting 500+ a day. It was steady at around 300+ a
day all summer, but jumped up to 500+ about a week ago. It has been steady
at 500+ a day.  Funny, that.  Yet almost none of it is genuine, and what
is genuine, is opt-in.

So there is no reason whatsoever for Verisign to collect "verified"
addresses to spam people. This is completely ludicrous FUD that
anti-spammers have been promoting for a long time.  While there once were
unsolicited spammers. They've all changed their operations, now.  But back
then, they already had your address. They didn't need to "verify it".
Advertisers are interested in response rate, not "verified addresses".
Radical antispammer script kiddies just didn't know this, because they are
kiddies with no business or marketing education.

FUD doesn't stand the test of time.

But Goodwins law has been called, so this will have to wait a little
longer.

		--Dean

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 24 Sep 2003 18:16:24 +0859 ()

Dean;

> Specifically, you insist that DNS queries, via DNS _protocol_
> can be used to check if a domain exists.

No, I never.

						Masataka Ohta