- Test - lists.nanog.org

mail relay thread
by Larry Snyder 26 Nov '99

26 Nov '99

:0: * ^Subject: RE: ARIN whois /dev/null If for no other reason than to fix the S+N/N ratio, _please_ move this. my .02 -ls-

1 0

Re: ARIN whois
by Dean Anderson 26 Nov '99

26 Nov '99

I'm surprised to see such poorly considered statements from JD. Unless SMTP AUTH (just released in sendmail 3 weeks ago) works in every client, and is support in MS Exchange, then we (that is we as an operations community) don't have the technology to practically authenticate it yet. I too can write an authenticated SSL client & server to transfer mail between two computers. But its not useful unless its widely deployed. Statements to the contrary are just foolishness in an operational context such as a real business. We are running a _BUSINESS_, not a research lab, with one server and one specially developed client. We don't run relays out of laziness. We went out of our way to enable them. We go out of our way to monitor them for unauthorized use. We would certainly prefer an authenticated mail system. We have to live with what is currently deployed. What annoys me about the pressure from the junior antispammer league is they go from "gee, you know you can close those relays" We respond "Yes, we know. We operate them on purpose for business reasons". At times, I've explained these business reasons in detail. The technical conclusion is then that we have to operate relays. They then jump to "Thats unacceptable. You MUST CLOSE THEM". We say "No. Absolutely not." They say "Well, in that case we're going to start committing crimes against your service, posting to alt.2600, inciting attacks, and wasting your time, bandwidth, and computer resources until you agree to close them." We say, thats extortion. We say that crimes against our service are crimes. We report them, and they will get eventually get punished, and we will work hard to get paid for the services rendered and the damages done by criminals. We don't tolerate this sort of behavior. Most companies don't. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

6 5

Network Visualization (Oops)
by Tim Salo 25 Nov '99

25 Nov '99

> Date: Wed, 24 Nov 1999 13:09:08 -0600 (CST) > From: Tim Salo <salo(a)networkcs.com> > To: nanog(a)merit.edu > Subject: Network Visualization > > We are looking for networks on which to deploy our network visualization > tool. Our focus is on IP networks that operate over underlying > connection-oriented networks such as ATM. For more information, see: > > http://www.msci.magic.net/visualization/Visualization.html I just corrected the permissions so that you can now download the applet that does the animation on this page. Sorry for the inconvenience, -tjs (Geez, it worked when we tried it...)

1 0

Re: ARIN whois
by Dean Anderson 25 Nov '99

25 Nov '99

I have never heard them say anything of the sort. I do know that ORBS is uncommonly good at blocking relays. Much, much better than RBL. One admin I talked to recently told me about 8 of 10 relayed spams were identified by ORBS. Of course, is ORBS that good, or is ORBS actually the source of the relay attacks? I think the latter. I know our attacks increased (started actually) after ORBS people started inciting attacks. If it weren't for ORBS there wouldn't be so many relay attacks. I think it would be helpful to block all traffic to ORBS as an organization that promotes and incites criminal activity. I think port scanning from ORBS into the US can be blocked immediately by any ISP as an unauthorized security scan, and a security attack. We block them not only from our servers, but all of our customers as well. Of course, they still advertise our servers to spammer and antispammer attackers. All I can do is keep listing them in our complaints to the FBI. But more complaints will help. --Dean At 03:19 AM 11/25/1999 +0300, Alex P. Rudnev supposedly said: >Btw. > >They, antispammers, have one usefull policy. Yes, you can keep OPEN RELAY, if >you agree to restrict RELAYING FROM the wrong (existing in the ORBS or other) >sources. > >It's just enougph for the business. > >Alex R. > > > >On Wed, 24 Nov 1999, Dean Anderson wrote: > >> Date: Wed, 24 Nov 1999 17:13:59 -0500 >> From: Dean Anderson <dean(a)av8.com> >> To: J.D. Falk <jdfalk(a)cybernothing.org>, nanog(a)merit.edu >> Subject: Re: ARIN whois >> >> >> I'm surprised to see such poorly considered statements from JD. >> >> Unless SMTP AUTH (just released in sendmail 3 weeks ago) works in every client, and is support in MS Exchange, then we (that is we as an operations community) don't have the technology to practically authenticate it yet. I too can write an authenticated SSL client & server to transfer mail between two computers. But its not useful unless its widely deployed. Statements to the contrary are just foolishness in an operational context such as a real business. We are running a _BUSINESS_, not a research lab, with one server and one specially developed client. >> >> We don't run relays out of laziness. We went out of our way to enable them. We go out of our way to monitor them for unauthorized use. We would certainly prefer an authenticated mail system. We have to live with what is currently deployed. >> >> What annoys me about the pressure from the junior antispammer league is they go from "gee, you know you can close those relays" >> >> We respond "Yes, we know. We operate them on purpose for business reasons". At times, I've explained these business reasons in detail. The technical conclusion is then that we have to operate relays. >> >> They then jump to "Thats unacceptable. You MUST CLOSE THEM". >> >> We say "No. Absolutely not." >> >> They say "Well, in that case we're going to start committing crimes against your service, posting to alt.2600, inciting attacks, and wasting your time, bandwidth, and computer resources until you agree to close them." >> >> We say, thats extortion. We say that crimes against our service are crimes. We report them, and they will get eventually get punished, and we will work hard to get paid for the services rendered and the damages done by criminals. We don't tolerate this sort of behavior. Most companies don't. >> >> --Dean >> >> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> Plain Aviation, Inc dean(a)av8.com >> LAN/WAN/UNIX/NT/TCPIP http://www.av8.com >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >> >> > >Aleksei Roudnev, >(+1 415) 585-3489 /San Francisco CA/ > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2 1

Re: Fwd: Bell Atlantic - Just a little congestion (corrected URL)
by Sean Donelan 25 Nov '99

25 Nov '99

>Is there a FCC URL where the required "oops" report will >appear? Well, there may not be any report filed. The FCC reporting criteria are designed for POTS failures, i.e. lots of analog phone lines. Although thousands of T3s were affected by this, its not clear if 30,000 customers were affected. Remember, resellers like Northpoint or an ISP only count as a single BA customer. Other carriers do the same thing. For example, as far as I can tell MCI Worldcom never filed an outage report for their frame-relay outage this summer, I suppose because only 3,000 customers were affected. And remember, it was just some "congestion," not an outage. If one is filed, it will show up at the following URL in 1-2 months. http://www.fcc.gov/Bureaus/Engineering_Technology/Filings/Network_Outage/

2 2

Bell Atlantic FCC outage report available now
by Sean Donelan 24 Nov '99

24 Nov '99

Ah, I see my friends at the FCC are reading this list. The Bell Atlantic FCC outage report for the Nov 23 New Jersey outage has been scanned, and is online at the FCC web site. http://www.fcc.gov/Bureaus/Engineering_Technology/Filings/Network_Outage/19…

1 0

Well Time A Holiday
by Henry R. Linneweh 24 Nov '99

24 Nov '99

Happy Thanksgiving to all -- Thank you; |--------------------------------------------| | Thinking is a learned process so is UNIX | |--------------------------------------------| Henry R. Linneweh

1 0

Re: Fwd: Bell Atlantic - Just a little congestion (corrected URL)
by Sean Donelan 24 Nov '99

24 Nov '99

On Wed, 24 November 1999, David Lesher wrote: > What about the 911 failures? FAA, 911 and NCS circuits have seperate reporting criteria. Bell Atlantic rerouted most of the 911 lines to local answering points quickly, and didn't require the DACS rebuild to complete. I don't know if enough 9-1-1 calls were blocked for a long enough time to require filing a report. The reporting criteria are written regulations. Just like accountants look for loopholes in the tax regulations, carriers seem to look for loopholes in the FCC regulations to minimize what their reports. As Bob Cannon pointed out, the FCC is starting a "voluntary" project where ISPs would also file outage reports. So expect ISPs to start redefining things to avoid filing an outage report. I suspect that was also the reason why AT&T Wireless didn't initially file a report after Rochelle Park, although Bell Atlantic did. Wireless, cable, pager, satellite are treated seperately in the FCC regulations. The ISP reporting regulations were supposed to be posted on the FCC web site today, but I haven't found them yet. As always, I speak only for myself.

1 0

My mistake, Worldcom was filed under the wrong date
by Sean Donelan 24 Nov '99

24 Nov '99

My mistake, Worldcom did file a report with the FCC on September 14, 1999. It was filed with the FCC under MCI on August 8, 1999. I wasn't looking backwards through the files, only at the additions.

1 0

IP packet size distribution
by Niels Chr. Bank-Pedersen 24 Nov '99

24 Nov '99

Hi, We are in the process of evaluating different means of providing QoS (and whether this is sane or not is not the topic of this mail :) . The performance indications we have from our vendors are based on different packet size distributions, so we'd like to see how the distribution is on the Net in general. Our own statistics show: Router#sh ip cache flow IP packet size distribution (93363M total packets): 1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480 .002 .433 .054 .022 .014 .012 .008 .010 .008 .008 .008 .009 .007 .006 .005 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 .004 .004 .148 .035 .194 .000 .000 .000 .000 .000 .000 But we may have a few "nonstandard" applications within our network that could push the distribution towards smaller packets. Anyway, if anyone could provide me with their view of packetsizes I'd appreciate it (private mail would probably be appreciated by the list ;) . /Niels Chr. -- Niels Christian Bank-Pedersen, NCB1-RIPE. Network Manager, Tele Danmark NET, IP-section. "Hey, are any of you guys out there actually *using* RFC 2549?"

3 2