- Test - lists.nanog.org

Re: Splitting a block of Class C's
by Albert Meyer 25 May '01

25 May '01

At 04:23 AM 5/25/01 -0400, John Fraizer wrote: >Huh? You mean they're not running their own DNS servers? If they're not >running their own DNS servers but are doing hosting, they deserve what >they get. If they are, they need to simply update their host object in >whois for their DNS servers. (This may or may not work with "alternate >registries".) Then, they can write a simple script to go through the zone >files they have and change the first three octets to the new address >space. I mentioned that, and it turns out they meant s/domains/servers/ but they really really don't want to re-IP, which I can understand. I had to re-IP 10 servers when my former employer moved offices, and it wasn't much fun. They have 50+ boxes in their space, and about half are client colos. In light of the advice I've heard here and elsewhere, I'm a bit nervous about what will happen, but I did tell them I would do it if Sprint agreed. I expected that Sprint would say no, but they claim that Sprint has agreed.

1 0

NANOG T-shirt gallery
by Sean Donelan 25 May '01

25 May '01

Has anyone created a gallery of all the NANOG T-shirt designs and put it on-line anywhere?

2 1

Re: Stealth Blocking
by dlr＠bungi.com 25 May '01

25 May '01

[In the message entitled "RE: Stealth Blocking" on May 24, Roeland Meyer <rmeyer(a)mhsc.com> writes:] > > I'm getting seriously confused here. I thought that the open-relay issue was > irelevent to MAPS. That MAPS only black-holed confirmed SPAM sites (a little > tougher, but more granular, charter). Further, that it was ORBS that listed > open-relay sites specifically, whether they were involved in a spam or not > (unacceptable due to punishing potential anti-spammers for proliferating > spam that never saw their systems). To me, these are two entirely different > charters. If MAPS starts to look like ORBS then I will stop using MAPS. > > Can someone please clarify? Sure. MAPS has four real-time lists. The MAPS RBL(sm) is a list of sites and networks which are known to be friendly, or neutral to spam. They include sites which harbour known spam origin points, multi-hop open relays which refuse to close (and have transmitted spam), spamware sites, and other persistant spam sources. Hosts and networks can use this list via DNS (rejecting mail, and other traffic as they see fit), or BGP (usually blackholing all traffic bound for those sites). It's very hard to get a site listed. It's quite easy to get off the RBL, assuming that the issue that caused the listing has been corrected. The MAPS RSS(sm) is a list of open relays *which have been abused*. These are sites which have been reported to MAPS as open relays, and have spam samples. Once the spam has been verified, a test is performed to verify that the site is, indeed, an open relay. If a sample message is accepted, and then returned by the site as a relay, the host is listed. Removal from the RSS requires that the host no longer relays. Automated probes are never done - a human must request the test, and spam must be available. Because of the very large number of hosts listed (around 100,000 as I write this), it's generally used in DNS mode only. It's pretty easy to get a host which is an open relay that has transmitted spam onto the list. Between 100 and 1,500 hosts per day are added, and hundreds per day are taken off (as soon as they let MAPS know that the relay has been closed). The MAPS DUL(sm) is a list of dialup ports. These are dialups which have been reported to MAPS by the ISP running them, or by users which have received spam from the dialup. An investigator verifies that the address range does contain dialup ports before they are listed. Hosts and networks typically use this list in DNS mode to reject direct-from-dialup spam. It's time-consuming to get an address listed, and also time-consuming to get an address removed from this list. The MAPS RBL+(sm) is a combined list, which allows a single lookup to search all lists. It's possible to use this in BGP mode, but it's unlikely that anyone would want to do so. So, does MAPS look like ORBS? ORBS probes systems no matter if spam has emitted or not. Does this catch more open relays? You bet. Is it network abuse to scan for open relays? I think so. Do spammers use the same techniques? You bet. MAPS probes systems only after they have been abused by spammers. Does this allow spammers to use the relays for at least one spam run? You bet. Is it network abuse to confirm an open relay that has transmitted spam? I don't think so. Do spammers use the same techniques? I don't think so. ORBS probes systems periodically after they are listed to see if they have been closed. Does this ensure that relays are removed after they are secured? Sort of. But this requires that the hosts listed be probed frequently, and still doesn't ensure that they are removed "as soon as they are secured". MAPS depends on the system administrator contacting MAPS to get a host de-listed. Does this ensure that they are removed once they are secured? Sort of. It does require that the admin be willing to contact MAPS. So, does MAPS look like ORBS? You decide. I'm certain that all of the network owners on this list want spam to stop. MAPS is one tool that can help. ORBS is another. Where you draw the line, or how you protect your networks is your choice. One thing that I think *will* help, particularly in the short term, is port 25 blocking of dialup ports. It's my personal opinion that this will have the greatest impact on spammers who abuse open relays. I've watched this happen over the last few months, as various large networks have secured their dialup ports. It's impressive. --

12 18

Re: PacBell Frame Relay Outage?
by Richard A. Steenbergen 25 May '01

25 May '01

On Fri, May 25, 2001 at 12:48:40PM -0700, Sean Donelan wrote: > > Pacbell statement at 11:04am PDT: > > Some customers in California and Reno may be unable to access the > Internet at this time do to an equipment problem. Our Engineering > Team is working to resolve this issue. We apologize for any > inconvenience this may cause and thank you for your patience. How delightfully non-descriptive. I hope it was at least "due" to an equipment problem. Wouldn't it be easier if they just issued a magic 8ball instead of a statement? "When will my internet be up?" "Reply hazy, try again" -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

Re: PacBell Frame Relay Outage?
by Roy 25 May '01

25 May '01

> Thanks to everyone for their info and help. According to my source, the problem was in the Newbrodge switches. Tonight's outage is for maintenance on the Lucent gear. My frame circuits returned a few minutes ago but DSL still seems affected. Roy Engehausen PS.. Sorry to have pestered everyone for the operational issues :-)

1 0

RE: Stealth Blocking
by Raul Hixie 25 May '01

25 May '01

NANOG, I don't like Outlook, nor do I like SPAM! I do, however like cupcakes! Can we please talk about cupcakes now? And perhaps domain-policy? I'd like a .cupcake TLD, can you please help me in setting this up!? Thank You NANOG! This is where I go for the best information on making my network and writing my policies. Most important it is the best place for hot intellectual discussion! I used to lurk, but this SPAM and EMAIL/FTP is good information and lots of STRONG OPINIONS! Good day NANOG, good NANOG, NANOG! Haul -- Sanrio Town is proud to announce that Hello Kitty's "World of Fairy Tales" Single Pack Stamps and First Day Cover series are available for purchase NOW! http://www.sanriotown.com Powered by Outblaze

1 0

PacBell Frame Relay Outage?
by Roy 25 May '01

25 May '01

Is anyone else experiencing an outage in the PacBell Frame Relay cloud in the SF Bay area.? 75% of my PVCs are down and the trouble number is busy or you go into "hold" forever. Roy Engehausen

4 4

RE: EMAIL != FTP
by Roeland Meyer 25 May '01

25 May '01

> From: Rowland, Alan D [mailto:alan_r1@corp.earthlink.net] > Sent: Friday, May 25, 2001 12:21 PM > > <snip> > At $99 per 40GB HDD, there is no excuse for lack of space. > <snip> > > And the source for this price point for a SPARC server would be? http://208.56.182.73/Products___Solutions/Appliances_Overview/R-Series_Main/ r-series_main.html That's at $20K per TB and quad PIII-1GHz are faster than quad SPARCs, for the money. > 40GB also doesn't scale well to 5,000,000 users. Do you have 5M users? > So let's say we double our user's boxes from 10MB to 20MB. > > 10MB X 5,000,000 = 50TB (assuming only one mail box per > customer, more like > two plus in the real world so you might consider trebling the > following > figures in the real world) > > 50TB/40GB = 1,250 HDD X $99 = $123,750 (at your PC price) plus the not > inconsiderable cost of the servers/raids to hold them and staff to > administer/maintain them. My WAG (wild ass guess) would place the true > multiple E-mail box/user cost at about $1/customer/month; > close to, if not > more than, most ISP's profit margin. (Profit, what profit?) Let's take your user figures and the RAIDZONE prices; 50TB x $20K = $1M $1M / 5M = $0.20 (20 cents per user, or 2 cents per MB) If you can't make "keystone" then that's a clear indication that your market will not support the service. > Now if we can just get the marketing folk to do a study to see if our > customers would be willing to pay that additional $1/month to > fund this in a market where more and more providers are offer additional "free" mail > boxes... Many of those "free" email boxen are underwritten by advertising revenue. In case you hadn't noticed, that market is collapsing. Others are bundeling that service with other services. Incremental cost factors still contribute to COGs and COGs should be no mkore than 60% of retail price, or you shouldn't be offering the service. No wonder many ISPs are going under.

1 0

RE: EMAIL != FTP
by Rowland, Alan D 25 May '01

25 May '01

<snip> At $99 per 40GB HDD, there is no excuse for lack of space. <snip> And the source for this price point for a SPARC server would be? 40GB also doesn't scale well to 5,000,000 users. So let's say we double our user's boxes from 10MB to 20MB. 10MB X 5,000,000 = 50TB (assuming only one mail box per customer, more like two plus in the real world so you might consider trebling the following figures in the real world) 50TB/40GB = 1,250 HDD X $99 = $123,750 (at your PC price) plus the not inconsiderable cost of the servers/raids to hold them and staff to administer/maintain them. My WAG (wild ass guess) would place the true multiple E-mail box/user cost at about $1/customer/month; close to, if not more than, most ISP's profit margin. (Profit, what profit?) Now if we can just get the marketing folk to do a study to see if our customers would be willing to pay that additional $1/month to fund this in a market where more and more providers are offer additional "free" mail boxes... ___________________________________ Alan Rowland "Get Linked" -----Original Message----- From: Roeland Meyer [mailto:rmeyer@mhsc.com] Sent: Friday, May 25, 2001 9:05 AM To: 'Jim Mercer'; Mitch Halmu Cc: John Fraizer; Roeland Meyer; 'Steve Sobol'; Shawn McMahon; nanog(a)nanog.org Subject: RE: EMAIL != FTP > From: Jim Mercer [mailto:jim@reptiles.org] > Sent: Friday, May 25, 2001 4:03 AM > > On Fri, May 25, 2001 at 06:32:48AM -0400, Mitch Halmu wrote: > > So what's a regular user to do? Email it! Hence the > legitimate use of > > email for transmission of large files. Most ISPs know that > if they start > > limiting this privilege, users will migrate to someone that > allows it. > > i regularly configure ISP's with a limit on the size of email > messages. > (generally 10meg, although i think 100k is probably better). That's why most corps use their own MTA's. Sometimes, I run into a client that has such bigots running their systems. A few "failures to communicate" usually result in executive management applying the clue-by-four. Business rules drive technology, not the other way around. One clueless company even blocks attachments with more than one dot in the name. They are steadily losing business. One does not give access to passworded sites without an NDA. After the initial deal is set, one does NOT strike clients in the face with security. Security need to be transparent. > when they get a complaint, i then point them to the fact that > many of the > large email messages get stuck in the queue because the receiving side > is too slow or doesn't have enough disk, or the users quota is full. At $99 per 40GB HDD, there is no excuse for lack of space. MTAs should delete all messages once they are sent, or soon thereafter. My laptop is considered small ... at 12GB. BTW, end users DO know how to delete files and manage space. The file cabinet metaphor works well. > and of course, the sending user hears that it wasn't > received, and then assumes it was lost and resends it. ... and the system should accomodate them. > file transfer by email is evil. That's your unsupported opinion. > i've been saying that for literally 10 years now: ... and you never wondered why no one listened?

1 0

RE: EMAIL != FTP
by Roeland Meyer 25 May '01

25 May '01

> From: Jim Mercer [mailto:jim@reptiles.org] > Sent: Friday, May 25, 2001 4:03 AM > > On Fri, May 25, 2001 at 06:32:48AM -0400, Mitch Halmu wrote: > > So what's a regular user to do? Email it! Hence the > legitimate use of > > email for transmission of large files. Most ISPs know that > if they start > > limiting this privilege, users will migrate to someone that > allows it. > > i regularly configure ISP's with a limit on the size of email > messages. > (generally 10meg, although i think 100k is probably better). That's why most corps use their own MTA's. Sometimes, I run into a client that has such bigots running their systems. A few "failures to communicate" usually result in executive management applying the clue-by-four. Business rules drive technology, not the other way around. One clueless company even blocks attachments with more than one dot in the name. They are steadily losing business. One does not give access to passworded sites without an NDA. After the initial deal is set, one does NOT strike clients in the face with security. Security need to be transparent. > when they get a complaint, i then point them to the fact that > many of the > large email messages get stuck in the queue because the receiving side > is too slow or doesn't have enough disk, or the users quota is full. At $99 per 40GB HDD, there is no excuse for lack of space. MTAs should delete all messages once they are sent, or soon thereafter. My laptop is considered small ... at 12GB. BTW, end users DO know how to delete files and manage space. The file cabinet metaphor works well. > and of course, the sending user hears that it wasn't > received, and then assumes it was lost and resends it. ... and the system should accomodate them. > file transfer by email is evil. That's your unsupported opinion. > i've been saying that for literally 10 years now: ... and you never wondered why no one listened?

2 1