Dean;
> When you get an NXDOMAIN DNS protocol reply, the DNS protocol (RFC 1034,
> etc) defines a specific meaning.
Neither rfc1034 nor rfc1035 define "NXDOMAIN DNS protocol reply.
> But when you don't get NXDOMAIN, there is
> no meaning to be implied. This is a fact due to the inclusion of wil
Dean;
> Specifically, you insist that DNS queries, via DNS _protocol_
> can be used to check if a domain exists.
No, I never.
Masataka Ohta
Sorry, this is actually WRONG.
Dean wrote:
>These people are upset because now the unregistered .com and .net domains
>don't return NXDOMAIN, but give the address of Verisign. The next step in
>their "test" will check the reverse address of Verisign, and find it to
>match.
--snip--
nslookup
>www
Ok, one last message. This removes some apparent confusion between
"reverse DNS abuse" and the current Verisign complaints.
The people who have "problems with Verisign" expect to do a forward lookup
on a domain name, and if they don't get NXDOMAIN, they want to do a
reverse lookup on the address,
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. A
Dean wrote:
>Specifically, you insist that DNS queries, via DNS _protocol_
>can be used to check if a domain exists.
You are pointedly ignoring the fact that there are two "planes of
existence". There is the "conceptual" plane - the registry records, saying
you have control over the name. Then the
On Tue, 23 Sep 2003 19:35:45 EDT, Dean Anderson <[EMAIL PROTECTED]> said:
> There has been no evidence that Verisign has collected any sender
> 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
Most of this is becoming tedious and circular. Different people are
posting the same canards. But I don't want people to go away with the
impression that I didn't use precise language to explain things. E.g
"domain names" in place of "domains", or "registry of domain names" in
place of "registry".
On Wed, 24 Sep 2003, Masataka Ohta wrote:
> > Wildcards are part of the DNS protocol.
>
> 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
James;
> Dean wrote:
> >The fact still remains that DNS entries do not necessarilly imply
> >registration, and that the DNS protocol cannot be used to make registry
> >queries.
>
> This is getting so far from the topic it's not funny.
>
> Do any of the systems broken by Verisign try and do REGIS
Dean;
> > Domain registry is a part of DNS system and is of no importance
> > as long as proper names are returned for DNS queries.
>
> 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.
> Wildc
Dean wrote:
>The fact still remains that DNS entries do not necessarilly imply
>registration, and that the DNS protocol cannot be used to make registry
>queries.
This is getting so far from the topic it's not funny.
Do any of the systems broken by Verisign try and do REGISTRY queries through
DNS?
> Domain registry is a part of DNS system and is of no importance
> 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;
> > > > > > 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
> > > >
> > > > Wrong.
> > > >
> > > > Whois protocol
On Tue, Sep 23, 2003 at 02:24:42PM -0400, Dean Anderson wrote:
> 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
On Tue, 23 Sep 2003, Doug Royer wrote:
> >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.
>
Dean Anderson wrote:
...
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.
You keep assuming things
On Mon, 22 Sep 2003, Doug Royer wrote:
> >>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'
On Tue, 23 Sep 2003, Bruce Campbell wrote:
> On Mon, 22 Sep 2003, Dean Anderson wrote in reply to Doug Royer:
>
> > > 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.
> >
> > You don't see
On Tue, 23 Sep 2003, Masataka Ohta wrote:
> > > > > 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
> > >
> > > Wrong.
> > >
On Mon, 22 Sep 2003, Larry Smith wrote:
> 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 r
Dean Anderson wrote:
On Mon, 22 Sep 2003, Doug Royer wrote:
You do not seem to be getting the message the MTA and MUA MAY be the same
program. So NOT true.
I do. Even in the same program, they are different functions. The MTA
should return a bounce. You should always get a bounce, in res
On 05:31 23/09/03, Larry Smith said:
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
On Mon, 22 Sep 2003, Dean Anderson wrote in reply to Doug Royer:
> > 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.
>
> You don't seem to understand how mail works. In both cases you get a
>
Dean;
> > > > 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
> >
> > Wrong.
> >
> > Whois protocol is a protocol for accessing the
On Monday 22 September 2003 20:35, Dean Anderson wrote:
> On Mon, 22 Sep 2003, Larry Smith wrote:
> > > 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 ma
On Mon, 22 Sep 2003, Doug Royer wrote:
>
> You do not seem to be getting the message the MTA and MUA MAY be the same
> program. So NOT true.
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 s
Dean Anderson wrote:
>Clearly, DNS doesn't indicate anything about whether a domain is
>registered, as you demonstrate.
DNS indicates whether there is a server serving that domain. Verisign broke
that quite effectively.
>However, we know that the registration will eventually be reflected in
>DNS.
Uhh, you might think about that.
Clearly, DNS doesn't indicate anything about whether a domain is
registered, as you demonstrate.
However, we know that the registration will eventually be reflected in
DNS. The reverse does not happen.
--Dean
On Tue, 23 Sep 2003, Laird, James wro
On Mon, 22 Sep 2003, Larry Smith wrote:
> > 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 se
> DNS !-> Registration
> Registration -> DNS
Wrong. I have a registered domain. I have no DNS entries.
DNS !-> Registration
Registration !-> DNS
--James
Disclaimer: Whilst every attempt has been made to ensure that material
contained in this email is free from computer viruses or other defe
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
>>>
>> No. On once case your get a "no such host" error and never send the
>>
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.
> >
> > No. On once case your get a "n
On Monday 22 September 2003 15:41, Dean Anderson wrote:
> On Sun, 21 Sep 2003, Larry Smith wrote:
> > > Both of these are perfectly valid responses. You get them at the same
> > > time, or you get the second one sooner.
> >
> > Not quite totally true. In the second case - it _will_ connect and
> >
> >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.
> >
> No. On once case your get a "no such host" error and never send the
> email in the first place
--On Monday, 22 September, 2003 15:57 -0600 Doug Royer
<[EMAIL PROTECTED]> wrote:
...
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 no
Dean Anderson wrote:
On Sun, 21 Sep 2003 [EMAIL PROTECTED] wrote:
On Sun, 21 Sep 2003 16:00:47 EDT, Dean Anderson <[EMAIL PROTECTED]> said:
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 wi
Dean Anderson <[EMAIL PROTECTED]> writes:
> 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.
Doesn't configuring browser behavior by making fundamental ch
On Mon, 22 Sep 2003, Masataka Ohta wrote:
> > > 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
>
> Wrong.
>
> Whois protocol is a protoc
On Sun, 21 Sep 2003, Larry Smith wrote:
> > Both of these are perfectly valid responses. You get them at the same
> > 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 _sendin
On Sun, 21 Sep 2003 [EMAIL PROTECTED] wrote:
> On Sun, 21 Sep 2003 16:00:47 EDT, Dean Anderson <[EMAIL PROTECTED]> said:
>
> > 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 c
Dean;
> > > > > The "set" is the set of *registered* names. The proper and only way to
> > > > > query this set is through whois.
> > > >
> > > > The only reason to have domain names registered is to use it
> > > > through DNS.
> > >
> > > The only reason we have DNS is to associate information s
On Sun, 21 Sep 2003 16:00:47 EDT, Dean Anderson <[EMAIL PROTECTED]> said:
> 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
On Sunday 21 September 2003 15:00, Dean Anderson wrote:
> 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
Yes, there always is someone who just doesn't understand what they are
talking about.
/usr/sbin/sendmail -t
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Lyndon can't figure out how sendmail works
Sendmail doesn't route messages in MUA mode.
.
Sendmail has completely different interna
On Sat, 20 Sep 2003, Doug Royer wrote:
> 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 dom
On Sun, 21 Sep 2003, Masataka Ohta wrote:
> Dean;
>
> > > > The "set" is the set of *registered* names. The proper and only way to
> > > > query this set is through whois.
> > >
> > > The only reason to have domain names registered is to use it
> > > through DNS.
> >
> > The only reason we have
Dean Anderson wrote:
On Sat, 20 Sep 2003, Doug Royer wrote:
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)
Your quote talks about conventions that may be used. It does not support
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
On Saturday 20 September 2003 18:13, Dean Anderson wrote:
> On Sat, 20 Sep 2003, Masataka Ohta wrote:
> > Dean;
> >
> > > The "set" is the set of *registered* names. The proper and only way to
> > > query this set is through whois.
> >
> > The only reason to have domain names registered is to use
Dean writes:
> However, there is a distinction between mail routing, an MTA
> function, and mail submission, an MUA function.
Not in the SMTP protocol.
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
> that.
$ sendmail -t
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Dean is *still* wrong
idiots abound
.
$
--lyndon
Never express your
Dean;
> > > The "set" is the set of *registered* names. The proper and only way to
> > > query this set is through whois.
> >
> > The only reason to have domain names registered is to use it
> > through DNS.
>
> The only reason we have DNS is to associate information such as IP
> addresses with
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
On Sat, 20 Sep 2003, Lyndon Nerenberg wrote:
> > The MUA in this case is performing (incorrectly) MTA functions. That is a
> > bug.
>
>
> The MUA in this case is performing (incorrectly) MTA functions. That is a
> bug.
$ sendmail -t
From: lyndon
To: lyndon
Subject: Dean is wrong
hi there
.
$
Say again?
--lyndon
The longest UNIX error code is ENAMETOOLONG.
On Sat, 20 Sep 2003, Doug Royer wrote:
> >
> >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)
> >
> Your quote talks about conventions that may be used. It does not support
> your view t
On Sat, 20 Sep 2003, Masataka Ohta wrote:
> Dean;
>
> > The "set" is the set of *registered* names. The proper and only way to
> > query this set is through whois.
>
> The only reason to have domain names registered is to use it
> through DNS.
The only reason we have DNS is to associate inform
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
--On Saturday, 20 September, 2003 11:02 -0600 Doug Royer
<[EMAIL PROTECTED]> wrote:
Dean Anderson wrote:
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)
Your quote talks about conventions t
Dean Anderson wrote:
On Thu, 18 Sep 2003, Doug Royer wrote:
No, its not valid for a mail client to make direct connections.
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 disagreem
Tim;
> 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.
Which .net/.com? Whois ones or DNS ones?
Whois ones may be updated by Verisign, forever. :-)
>
> Tim
>
> On Sat, Sep 20, 2003 at 03:04:52PM +0859, Masataka Ohta
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
On Sat, Sep 20, 2003 at 03:04:52PM +0859, Masataka Ohta wrote:
> > DNS has nothing to
> > do with registration
>
> If you are arguing that verisign registration has nothin
Dean;
> The "set" is the set of *registered* names. The proper and only way to
> 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, l
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".
As I pointed, this is incorrect behavior to begin with, on the part of
MUA. It is therefore, "not a big c
On Thu, 18 Sep 2003 [EMAIL PROTECTED] 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 ch
At 8:51 AM -0700 09/18/2003, Bill Manning wrote:
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.
Think it from a set theory perspective for a secon
move it - however it is not illegal. Go
figure
Bill
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean
Anderson
Sent: Thursday, September 18, 2003 8:45 AM
To: Keith Moore
Cc: [EMAIL PROTECTED]
Subject: Re: [Fwd: [Asrg] Verisign: All Your ...
On
On Thu, 18 Sep 2003, Doug Royer wrote:
> >No, its not valid for a mail client to make direct connections.
> >
> 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
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
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
On Thu, 18 Sep 2003 [EMAIL PROTECTED] wrote:
> At 6:17 PM -0400 09/18/2003, Dean Anderson wrote:
> >On Thu, 18 Sep 2003 [EMAIL PROTECTED] wrote:
> >
> >> At 8:51 AM -0700 09/18/2003, Bill Manning wrote:
> >> > ok, what about DoC & ICANN agreements w/ VSGN giving them
> >> > the authority to c
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.
Neal McBurnett
On Thu, 18 Sep 2003 15:49:15 EDT, Dean Anderson said:
> 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.
Oh.. so if you're not actually on port 80, but on any one of t
At 6:17 PM -0400 09/18/2003, Dean Anderson wrote:
On Thu, 18 Sep 2003 [EMAIL PROTECTED] wrote:
At 8:51 AM -0700 09/18/2003, Bill Manning wrote:
> ok, what about DoC & ICANN agreements w/ VSGN giving them
> the authority to continue to register in and publish
> the .COM and .NET domains?
On Thu, 18 Sep 2003 [EMAIL PROTECTED] wrote:
> At 8:51 AM -0700 09/18/2003, Bill Manning wrote:
> > 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.
ECTED]
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...
People are unhappy about VeriSign breaking the rules
On Thu, 18 Sep 2003 [EMAIL PROTECTED] wrote:
> On Thu, 18 Sep 2003 12:04:31 EDT, Dean Anderson said:
> > You have yet explain how is it misreporting anything. It in fact
> > reporting that the domain is available for purchase. How is that
> > misreporting?
>
> Well.. let's follow this line of rea
On Thu, 18 Sep 2003 14:32:33 EDT, Dean Anderson said:
> On Thu, 18 Sep 2003 [EMAIL PROTECTED] wrote:
>
> > On Thu, 18 Sep 2003 12:04:31 EDT, Dean Anderson said:
> > > You have yet explain how is it misreporting anything. It in fact
> > > reporting that the domain is available for purchase. How is
On Thu, 18 Sep 2003 15:35:25 EDT, Dean Anderson said:
> 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 se
Bill Manning wrote:
[..]
> 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.
"... publish the data in th
On Thu, 18 Sep 2003 [EMAIL PROTECTED] 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 avai
On Thu, 18 Sep 2003, Keith Moore wrote:
> this breaks anything that assumes (quite reasonably)
> that query to a a nonexistent domain will return NXDOMAIN.
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
Dean writes:
> I think you have pointed out that this is indeed the function of a mail
> server, not a mail client. It is a bug.
SMTP makes no distinction between servers and clients. It's not a bug.
Dean writes:
> No, its not valid for a mail client to make direct
> connections.
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.
No, its not valid for a mail client to make direct connections.
Can you site any RFC that says that?
There are
many ISPs that block this. Are they doing something wrong?
Orthogonal and unrelated.
Mail clients
are supposed to connect to their configured mail relays, which has the
responsibili
Dean Anderson wrote:
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 t
> No, its not valid for a mail client to make direct connections. There are
> many ISPs that block this. Are they doing something wrong?
IMHO yes, but that's between them and their customers.
> Mail clients
> are supposed to connect to their configured mail relays, which has the
> responsibil
On Thu, 18 Sep 2003 09:22:15 -0700
Paul Hoffman / IMC <[EMAIL PROTECTED]> wrote:
> 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...
>
> People are unhappy about VeriSign breaking the ru
> 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.
the very purpose of those agreements - hell, the primary purpose of ICANN, is
to constrain how NS
On Thu, 18 Sep 2003 12:04:31 EDT, Dean Anderson said:
> You have yet explain how is it misreporting anything. It in fact
> reporting that the domain is available for purchase. How is that
> misreporting?
Well.. let's follow this line of reasoning. If I mail to a domain, *and it gets
a pointer to
On Thu, 18 Sep 2003 11:45:14 EDT, Dean Anderson said:
> I think you have pointed out that this is indeed the function of a mail
> server, not a mail client. It is a bug.
OK Dean, let's go back and look at the original message.
On Wed, 17 Sep 2003, Doug Royer wrote:
> Before the change if I email
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...
People are unhappy about VeriSign breaking the rules. But here you
are proposing that they follow an *experimental* RFC whose rules were
not a
>
> 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.
Hm, to me publishing all registered entities of a domain
is not the same as publishing that th
On Wed, 17 Sep 2003, Keith Moore wrote:
> > People keep saying that something has been broken. But in fact, nothing
> > has been broken, except false assumptions that were false to begin with.
>
> You're simply wrong, and there have been numerous examples of this.
Sounds like a canard.
> > NXDOM
On Wed, 17 Sep 2003 [EMAIL PROTECTED] wrote:
>
> On Wed, 17 Sep 2003, Dean Anderson wrote:
>
> > 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 w
% > % 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 i
On Wed, 17 Sep 2003, Keith Moore wrote:
> > 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.
>
> No, you're making an incorrect assumption. It's perfectly valid for a
>
In your previous mail you wrote:
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.
=> IMHO it should reject SMTP connection from the beginning w
Bill;
> % 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 i
> % 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-
1 - 100 of 172 matches
Mail list logo
