- NANOG - lists.nanog.org

Re: Digex and Akamai are raping the ARIN whois database
by Adam Herscher 05 Sep '01

05 Sep '01

Hah. This comes from UltraDNS, the company that makes cold calls beginning with "my wife couldn't access your web page the other night". See: http://ignite.blackened.net/misc/salespitch.wav > > -----Original Message----- > From: Rachel Luxemburg [mailto:rslux@link-net.com] > Sent: Tuesday, September 04, 2001 5:04 PM > To: nanog(a)merit.edu > Subject: Re: Digex and Akamai are raping the ARIN whois database > > > At 07:52 PM 9/4/2001 -0400, Steven J. Sobol wrote: > > > > You can't purchase an opt-in list. Period. > > > > That would depend on how the list was built. If the list subscribers signed > up knowing that the list would be sold to 3rd party companies then AFAIK it > would not be spamming. > > > > Regards, > > Rachel > > > ----------------------------- > Rachel Luxemburg > Sr. Product Manager, UltraDNS > http://www.ultradns.com <http://www.ultradns.com/> > Voice: (650) 227-2684 > > >

1 0

Re: Digex and Akamai are raping the ARIN whois database
by Rachel Luxemburg 05 Sep '01

05 Sep '01

At 07:52 PM 9/4/2001 -0400, Steven J. Sobol wrote: >You can't purchase an opt-in list. Period. That would depend on how the list was built. If the list subscribers signed up knowing that the list would be sold to 3rd party companies then AFAIK it would not be spamming. Regards, Rachel ----------------------------- Rachel Luxemburg Sr. Product Manager, UltraDNS http://www.ultradns.com Voice: (650) 227-2684

1 0

Re: Digex and Akamai are raping the ARIN whois database
by Dave Israel 04 Sep '01

04 Sep '01

Ah, I knew this was coming. For the record: Digex.net does not do any sort of web hosting. Digex.com does not do any sort of leased line sales. They're vastly different companies these days. You did, however, send your complaint to the correct address (digex.com) Folks, please follow Kai's example, and let abuse(a)digex.com (and your digex.com salesperson, if you have one) know exactly what you think of this. I'm sure I'm going to hear a lot about this over the next few days, and I'm hoping that everybody realizes that the digex.net/icix.net folks have nothing to do with this whatsoever. I have no idea if digex.com knew what they were getting into with this. I hope they did not. Please, though, don't harrass/mailbomb us IBI/digex.net folks. We're innocent. I swear. And Kai, I'm sorry our sales force let you down. I'm more ashamed to admit you're not the only one. -Dave On 9/4/2001 at 15:38:30 -0400, Kai Schlichting said: > > Nothing like the smell of spam in the morning - coming to you through the > "benevolent" acts of Akamai and Digex - sent to POC handles blatantly stolen > from ARIN's whois database. > > Yo, Digex: this just reminds me how much your "sales team" sucked the last > time around, when there was a DS3 contract up for grabs on an RFP. > This spam certainly cuts you out of any future consideration for a while: > You'll find yourself in good company with Savvis, I am sure. > > Sep 4 11:4x:xx host sendmail[14500]: LAA14500: from=<bounces(a)bounce.innovyx.com>, size=10198, class=0, pri=40198, nrcpts=1, msgid=<200109041542.LAA14183@host>, bodytype=8BITMIME, proto=ESMTP, relay=shiner.innovyx.com [63.143.186.194] (may be forged) > Sep 4 11:4x:xx host sendmail[14500]: LAA14500: to=<CENSORED@TLD>, delay=00:00:00, xdelay=00:00:00, mailer=local, stat=Sent > > > > [censored] > > Received-Date: Tue, 4 Sep 2001 11:4x:xx -0400 (EDT) > > Received: from shiner.innovyx.com (shiner.innovyx.com [63.143.186.194] (may be forged)) > > by [censored].com (8.9.3/8.9.3) with ESMTP id LAA14500 > > for <ADDRESS-STOLEN-FROM-ARIN-WHOIS-DB@TLD>; Tue, 4 Sep 2001 11:4x:xx -0400 (EDT) > > Received: by shiner.innovyx.com (PowerMTA(TM) v1.0); Tue, 4 Sep 2001 08:4x:xx -0700 (envelope-from <bounces(a)bounce.innovyx.com>) > > Date: Tue, 4 Sep 2001 08:41 -0700 > > From: digexakamai <digexakamai-[censored](a)m2.innovyx.com> > > Reply-to: digexakamai <digexakamai-[censored](a)m2.innovyx.com> > > Subject: You're Invited > > To: ADDRESS-STOLEN-FROM-ARIN-WHOIS-DB@TLD > > MIME-Version: 1.0 > > Content-Type: multipart/alternative; boundary="-------=_8418644195" > > > We're sending you this invitation because we received your e-mail > > address from one of our marketing partners. If you'd like to receive > > future emails, please click here: > > http://edge.akamai.com/redir.asp?[censored]&SubscriberID=[censored] > > Not confirming your interest automatically leaves you unsubscribed and > > we will not send you future emails. Additionally, each issue you receive > > as a subscriber will contain unsubscription instructions. > > > > Digex and Akamai Present: Performance!...a Free seminar on enhancing > > your Web site performance. > > > As the strategic value of Web sites has become a critical factor in > > the success of many companies, managing performance has become an > > ongoing challenge. Fast response time is not just a feature, it is > > a requirement for today's transaction oriented Web sites where real > > business is conducted online. > > > Join two industry leaders for a discussion about: > > > * Architecting your site for maximum performance > > * Enhancing your e-business reach > > * Speeding content and application delivery > > * Eliminating costly and excessive bandwidth > > * Maximizing the return on your investment > > > > > When & Where > > [blah cut] > > > Digex, the proven leader in managed Web and application hosting > > since 1996, offers the most comprehensive portfolio of hosting > > products and services designed to enhance the performance of your > > mission-critical Web operations. Akamai, the leading provider > > of distributed application and content delivery services, gives > > businesses a distinct competitive advantage by providing the > > technology to optimize your customers' Web experience. > > > > If you'd like to receive future Akamai emails, please click here: > > http://edge.akamai.com/redir.asp?[censored]&SubscriberID=[censored] -- Dave Israel Senior Manager, IP Backbone Intermedia Business Internet

2 1

e-mail list use at Akamai, followup
by Avi Freedman 04 Sep '01

04 Sep '01

In article <10184.163350.27021(a)avi.netaxs.com> you wrote: : Very sorry this happened. Marketing purchased a 'trial version' of : a list that apparently had ARIN-gleanings. Follow-up: 1) Akamai won't be using any lists in the future to do e-mail marketing. That's a firm commitment that we're prepared to make. Anyone doing so will be terminated. 2) Akamai's policy has been and remains that no Akamai salespeople are to e-mail potential customers unless they've been given permission to do so by a human. Violations have led, and will lead, to termination. If there are any issues relating to spam or suspected spam, ccare(a)akamai.com will follow them through. Any issues with the Akamai customer care group's followup (they also deal with network portscanning etc complaints), feel free to escalate to me or anyone in networking at Akamai and we'll follow through. Thanks, Avi

3 2

Re: Digex and Akamai are raping the ARIN whois database
by brandon＠rd.bbc.co.uk 04 Sep '01

04 Sep '01

> If anyone has any heuristics for ensuring that lists don't have automated > new-domain or SWIP gleanings, I'd appreciate them Apparently not mailing people unless they gave you their address and said you could is effective. brandon

1 0

RE: Digex and Akamai are raping the ARIN whois database
by Smith, Rick 04 Sep '01

04 Sep '01

Did they leave an 800 # ? :) Nothing like autodial & coffee... -----Original Message----- From: Kai Schlichting [mailto:kai@pac-rim.net] Sent: Tuesday, September 04, 2001 3:39 PM To: nanog(a)merit.edu Cc: abuse(a)digex.com; abuse(a)innovyx.com; postmaster(a)innovyx.com; abuse(a)winstar.net; abuse(a)akamai.net; abuse(a)arin.net; hostmaster(a)arin.net Subject: Digex and Akamai are raping the ARIN whois database Nothing like the smell of spam in the morning - coming to you through the "benevolent" acts of Akamai and Digex - sent to POC handles blatantly stolen from ARIN's whois database. Yo, Digex: this just reminds me how much your "sales team" sucked the last time around, when there was a DS3 contract up for grabs on an RFP. This spam certainly cuts you out of any future consideration for a while: You'll find yourself in good company with Savvis, I am sure.

1 0

Digex and Akamai are raping the ARIN whois database
by Kai Schlichting 04 Sep '01

04 Sep '01

Nothing like the smell of spam in the morning - coming to you through the "benevolent" acts of Akamai and Digex - sent to POC handles blatantly stolen from ARIN's whois database. Yo, Digex: this just reminds me how much your "sales team" sucked the last time around, when there was a DS3 contract up for grabs on an RFP. This spam certainly cuts you out of any future consideration for a while: You'll find yourself in good company with Savvis, I am sure. Sep 4 11:4x:xx host sendmail[14500]: LAA14500: from=<bounces(a)bounce.innovyx.com>, size=10198, class=0, pri=40198, nrcpts=1, msgid=<200109041542.LAA14183@host>, bodytype=8BITMIME, proto=ESMTP, relay=shiner.innovyx.com [63.143.186.194] (may be forged) Sep 4 11:4x:xx host sendmail[14500]: LAA14500: to=<CENSORED@TLD>, delay=00:00:00, xdelay=00:00:00, mailer=local, stat=Sent > [censored] > Received-Date: Tue, 4 Sep 2001 11:4x:xx -0400 (EDT) > Received: from shiner.innovyx.com (shiner.innovyx.com [63.143.186.194] (may be forged)) > by [censored].com (8.9.3/8.9.3) with ESMTP id LAA14500 > for <ADDRESS-STOLEN-FROM-ARIN-WHOIS-DB@TLD>; Tue, 4 Sep 2001 11:4x:xx -0400 (EDT) > Received: by shiner.innovyx.com (PowerMTA(TM) v1.0); Tue, 4 Sep 2001 08:4x:xx -0700 (envelope-from <bounces(a)bounce.innovyx.com>) > Date: Tue, 4 Sep 2001 08:41 -0700 > From: digexakamai <digexakamai-[censored](a)m2.innovyx.com> > Reply-to: digexakamai <digexakamai-[censored](a)m2.innovyx.com> > Subject: You're Invited > To: ADDRESS-STOLEN-FROM-ARIN-WHOIS-DB@TLD > MIME-Version: 1.0 > Content-Type: multipart/alternative; boundary="-------=_8418644195" > We're sending you this invitation because we received your e-mail > address from one of our marketing partners. If you'd like to receive > future emails, please click here: > http://edge.akamai.com/redir.asp?[censored]&SubscriberID=[censored] > Not confirming your interest automatically leaves you unsubscribed and > we will not send you future emails. Additionally, each issue you receive > as a subscriber will contain unsubscription instructions. > Digex and Akamai Present: Performance!...a Free seminar on enhancing > your Web site performance. > As the strategic value of Web sites has become a critical factor in > the success of many companies, managing performance has become an > ongoing challenge. Fast response time is not just a feature, it is > a requirement for today's transaction oriented Web sites where real > business is conducted online. > Join two industry leaders for a discussion about: > * Architecting your site for maximum performance > * Enhancing your e-business reach > * Speeding content and application delivery > * Eliminating costly and excessive bandwidth > * Maximizing the return on your investment > When & Where [blah cut] > Digex, the proven leader in managed Web and application hosting > since 1996, offers the most comprehensive portfolio of hosting > products and services designed to enhance the performance of your > mission-critical Web operations. Akamai, the leading provider > of distributed application and content delivery services, gives > businesses a distinct competitive advantage by providing the > technology to optimize your customers' Web experience. > If you'd like to receive future Akamai emails, please click here: > http://edge.akamai.com/redir.asp?[censored]&SubscriberID=[censored]

1 0

Standard naming scheme, or lookup system
by Roy Hockett 04 Sep '01

04 Sep '01

Is there a standard naming convention for troubleshooting tools like looking glass servers? Thanks, -Roy -- /********************************************************************/ /* Roy Hockett * Telephone: (734) 763-7325 */ /* Network Engineer, * FAX: (734) 763-2180 */ /* ITD, * Internet: royboy(a)umich.edu */ /* University of Michigan * */ /********************************************************************/

2 1

RE: Is anyone using GILAT's "Spacenet" service
by Dennis Hartmann 03 Sep '01

03 Sep '01

Oops! The link is as follows: http://www.starbandusers.com/performance.htm Keep in mind that this information is based on the 180 system. The 360 system is out and some of this information may have changed (web caching, etc.). The new 360 system has an Ethernet port which is a great improvement over the USB port that the 180 system came with. The beta systems started out as 2 PCI cards. Sincerely, Dennis J. Hartmann White Pine Consulting Global Knowledge-MPLS Course Director http://www.globalknowledge.com/training/course.asp?PageID=9&courseid=1571 dennisjhartmann(a)hotmail.com AOL IM: dennisjhartmann -----Original Message----- From: Simon Lyall [mailto:simon.lyall@ihug.co.nz] Sent: Saturday, September 01, 2001 12:40 AM To: Dennis Hartmann Subject: RE: Is anyone using GILAT's "Spacenet" service On Fri, 31 Aug 2001, Dennis Hartmann wrote: > Is Spacenet one of their business satellite services? I'm a user of the > Starband service and I get pretty good speeds and feeds on the satellite, > although telnet is a drag. Starband uses a page accelerator technology that > greatly increases performance. The following link has a good technical > explanation of the HPA host page acceleration and the RPA remote page > acceleration. What link? The one in you signature is a MPLS course. Simon. -- Simon Lyall. | Newsmaster | Work: simon.lyall(a)ihug.co.nz Senior Network/System Admin | Postmaster | Home: simon(a)darkmere.gen.nz ihug, Auckland, NZ | Asst Doorman | Web: http://www.darkmere.gen.nz

2 1

Re: multi-homing fixes
by Paul A Vixie 02 Sep '01

02 Sep '01

> Understand [1] well, but not [2]. Care to elaborate? > > I'd have thought there were trivial counterexamples (i.e. when > it 'is so'), f'rinstance when one path has both huge delay and > large packet loss. sorry. yes, it's possible to construct a scenario which makes udp seem like a fine predictor of tcp performance. necessary constraints for the experiment include the number of simultaneous tcp sessions going over the probed path, and also the average and maximum size of the sessions, and so on. but for observed traffic over observed paths, neither measured DNS RTT nor anycast DV show any similarity to the "time to last byte" of any known TCP implementation, especially not the bad (and dominant) ones. the example we used back at vayu was to compare a 56K serial link to a 1Gb/s satellite link. anycast DNS says that one of them is better. TCP says that the other is better, but only if the file is larger than 16KB. "you pick." (i'm trying to decide whether vayu is dead enough that it would be safe to publish any of the whitepapers we did on this general topic.)

1 0