Re: [Fwd: [Asrg] Verisign: All Your ...

[Doug Royer]

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
responsibility to route mail.
Says who?

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.
   

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.
--

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

   We Do Standards - You Need Standards



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Fwd: [Asrg] Verisign: All Your ...

[Doug Royer]

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 the relay. 

There is no rule  that says that my smart MUA can not deliver email 
itself.  Not a bug.

--

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

   We Do Standards - You Need Standards



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [Fwd: [Asrg] Verisign: All Your ...

[Keith Moore]

> 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
> responsibility to route mail.

this is a figment of your imagination.

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

[Keith Moore]

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 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?

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)

Hurricane Isabel and ietf.org

[sweilnau]

The machines that serve the IETF are located in the track of Hurricane 
Isabel, which is expected to impact the East Coast of the United States on 
Thursday.  There are currently two servers:

www1.ietf.org (in Reston, Virginia)
www2.ietf.org (in Natick, Massachusetts)

The Reston site hosts the mail server, all of the Web pages, and the Web 
site search engine.  The Natick Web server is a mirror of the Reston Web 
server, except for the Web archives of the mail.  The address www.ietf.org 
points to both servers.

As a protective measure, many servers in the Reston office will be powered
off starting as of 1400 EDT.  Mail to ietf.org will not be processed until
the servers are brought back on-line.  If the Reston office has a
powerfailure, the Web archives of the mail, and the Web search engine will
not be available.  If the Web server you are pointing to is not
responding, then please attempt to use the direct addresses of both
servers to access the pages.

Please be sure that the technical team will be working to restore these 
services as quickly as possible.

Thank you in advance for your understanding in this matter.

The IETF Secretariat

Re: [Fwd: [Asrg] Verisign: All Your ...

[Keith Moore]

>   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 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
>   .COM and .NET, then you should make your concerns known to 
>   your legal advisors, DoC, and Verisign.

the NET owns .COM and .NET.  

Re: [Fwd: [Asrg] Verisign: All Your ...

[Valdis . Kletnieks]

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 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.


pgp0.pgp
Description: PGP signature

Re: [Fwd: [Asrg] Verisign: All Your ...

[Valdis . Kletnieks]

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 [EMAIL PROTECTED], the email tool would
> tell me immedatally
> 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:[EMAIL PROTECTED] [10.1.1.13]

   - Transcript of session follows -
<[EMAIL PROTECTED]>... 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.


pgp0.pgp
Description: PGP signature

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

[Paul Hoffman / IMC]

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 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

Re: [Fwd: [Asrg] Verisign: All Your ...

[Peter Sylvester]

> 
>   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 the domain contains everything.


 

Re: [Fwd: [Asrg] Verisign: All Your ...

[Dean Anderson]

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.

> > NXDOMAIN means the domain isn't in the DNS distributed databse.  It
> > 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.

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.

> > However, NXDOMAIN hasn't been
> > wrongly sent.  It is not the case that NXDOMAIN _MUST_ be sent. That would
> > preclude wildcard records.
>
> 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.

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?

> > 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.
>
> 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.

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

> > > 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.
> >
> > It is not _mis-reporting_ anything.
>
> 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

Hurricane Isabel and ietf.org

[sweilnau]

The machines that serve the IETF are located in the track of Hurricane 
Isabel, which is expected to impact the East Coast of the United States on 
Thursday.  There are currently two servers:

www1.ietf.org (in Reston, Virginia)
www2.ietf.org (in Natick, Massachusetts)

The Reston site hosts the mail server, all of the Web pages, and the Web 
site search engine.  The Natick Web server is a mirror of the Reston Web 
server, except for the Web archives of the mail.  The address www.ietf.org 
points to both servers.

As a protective measure several servers in the Reston office will be
powered off between 1400 and 1430 EDT.  Mail to ietf.org will not be
processed until the servers are brought back on-line.  If the Reston
office has a powerfailure, the Web archives of the mail, and the Web
search engine will not be available.  If the Web server you are pointing
to is not responding, then please attempt to use the direct addresses of
both servers to access the pages.

Please be sure that the technical team will be working to restore these 
services as quickly as possible.

Thank you in advance for your understanding in this matter.

The IETF Secretariat

Re: [Fwd: [Asrg] Verisign: All Your ...

[Dean Anderson]

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 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.
  ^^
> 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.


> 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.
>

Re: [Fwd: [Asrg] Verisign: All Your ...

[Bill Manning]

% > % 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

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).

Re: [Fwd: [Asrg] Verisign: All Your ...

[Dean Anderson]

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
> 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.

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.

> 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.

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

--Dean

E-Commerce implications [Re: Verisign: All Your Misspelling Are Belong To US]

[Steve Neruda]

*This message was transferred with a trial version of CommuniGate(tm) Pro*
I've was uncomfortable when Verisign got into the register business 
since having your Certificate from someone who can also mess with your 
registration is liking having the same person do your accounting and 
auditing...

Do you suppose next they will print up a wildcard X.509 for their new 
address :-P

Re: typo wildcard I-D

[Zefram]

I've had one person email me concerning my I-D.  Am I to understand that
everyone else sees no way to improve it?  Plenty of you are reading it.

Version -01 is now at , and
will be in the internet-drafts directory shortly.

-zefram

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

[Francis Dupont]

 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 with
the 521 greeting described in RFC 1846...

Regards

[EMAIL PROTECTED]