- Test - lists.nanog.org

Re: AOL holes again.
by Shawn McMahon 22 Mar '01

22 Mar '01

On Wed, Mar 21, 2001 at 01:19:39PM -0800, David Schwartz wrote: > > Of course, the real questions are whether this law even applies to email > and whether contractual provisions trump it. As I've said many, many times, Well, as far as the question of whether it applies to email or not, that's been settled. See Steve Jackson Games v. Secret Service.

1 0

RE: AOL holes again.
by Roeland Meyer 21 Mar '01

21 Mar '01

> From: Shawn McMahon [mailto:smcmahon@eiv.com] > Sent: Wednesday, March 21, 2001 8:50 AM > To: nanog(a)merit.edu > Subject: Re: AOL holes again. > > > On Wed, Mar 21, 2001 at 07:55:05AM -0800, Roeland Meyer wrote: > > > > But, it would be trivial to claim exemption by contractual > agreement. Read > > the AOL TOS please. There are clauses in there that > specifically allow AOL > > to monitor, modify, or delete email messages at-will. Back > in the old days, > > AOL actually had volunteers going through their > message-base, regularly, > > monitoring and deleting content that didn't meet AOL criteria. > > You can't modify federal law with a contract. Tell that to the ICANN <g>. You can't sign away your civil-rights, but you can assign agents to perform specific tasks related to them. I have an MBE, in Colorado, that I pay to toss anything that is either "Bulk Rate" or to "Resident" (junk mail). They have no problems doing that, as my agent, even if it involves federal issues. They've been doing that job for years. I have similar arrangements here in California. Otherwise, I'd have to hire separate haulers to dump the junk-mail. Yes, that's US Postal Service delivered mail, under Feral regulation. Anyone signing the AOL agreement is making the same sort of arrangement. Again, I suggest a reading of the AOL TOS. The only way you are exempt from that TOS is to not use AOL (not a bad idea). Simply say "no".

2 1

Re: AOL holes again.
by Steven M. Bellovin 21 Mar '01

21 Mar '01

In message <20010320192341.A26277(a)eiv.com>, Shawn McMahon writes: > > >--liOOAslEiF7prFVr >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline >Content-Transfer-Encoding: quoted-printable > >On Tue, Mar 20, 2001 at 06:47:31PM -0500, Valdis.Kletnieks(a)vt.edu wrote: >>=20 >> > Especially those who've read the 1986 law requiring it. >>=20 >> Citation, please? > >Title 18, Chapter 119, sections 2510 through 2522. > >It forbids "interception" of electronic mail. > >Interception is defined as "acquiring the contents", but it's defined >broadly enough that if you get the message onto your hard drive and don't >deliver it, obviously you weren't acquiring it for the purpose of >delivering it, so you have intercepted it for reasons not related to >providing the service, and thus have committed a felony for EACH email >intercepted. That's a preposterous interpretation. 18 USC 2511(2)(a)(i) says: It shall not be unlawful under this chapter for an operator of a switchboard, or an officer, employee, or agent of a provider of wire or electronic communication service, whose facilities are used in the transmission of a wire or electronic communication, to intercept, disclose, or use that communication in the normal course of his employment while engaged in any activity which is a necessary incident to the rendition of his service or to the protection of the rights or property of the provider of that service, except that a provider of wire communication service to the public shall not utilize service observing or random monitoring except for mechanical or service quality control checks. See http://www4.law.cornell.edu/uscode/18/2511.html. In other words, reception of the mail is legal, since that's a necessary part of the service delivery, and given how much load spam places on ISPs rejecting it is permissible as protecting the property of the service provider. As for the last clause -- the law defines "provider of wire communication service" as (more or less) a phone company; ISPs are "electronic communication service" providers, and hence are not covered by that.

5 5

RE: AOL holes again.
by Roeland Meyer 21 Mar '01

21 Mar '01

> From: David Schwartz [mailto:davids@webmaster.com] > Sent: Wednesday, March 21, 2001 2:03 AM > > > That's a preposterous interpretation. 18 USC 2511(2)(a)(i) says: > > > > It shall not be unlawful under this chapter for an operator > > except that a provider of wire communication service to > > the public shall not utilize service observing or random > > monitoring except for mechanical or service quality control > > checks. > > You may have a very hard time convincing anyone that > rejecting significant > amounts of legitimate mail is necessary. Necessity is a > requirement for > exemption under this section. But, it would be trivial to claim exemption by contractual agreement. Read the AOL TOS please. There are clauses in there that specifically allow AOL to monitor, modify, or delete email messages at-will. Back in the old days, AOL actually had volunteers going through their message-base, regularly, monitoring and deleting content that didn't meet AOL criteria.

2 1

RE: Statements against new.net?
by Roeland Meyer 21 Mar '01

21 Mar '01

> From: Miles Fidelman [mailto:mfidelman@civicnet.org] > Sent: Friday, March 16, 2001 5:38 AM > > On Thu, 15 Mar 2001, Patrick Greenwell wrote: > > > On Thu, 15 Mar 2001, Miles Fidelman wrote: > > > > At some point cooperation has to yield to due process - > at least that's > > > the history of society to date. Unless there's a major > change to the > > > Internet infrastructure, we need DNS to function > reliably, and that > > > requires that the root nameservers behave the way they're > supposed to. > > > > I don't see any problem with anything you have said. I think the > > difficulty comes when I tell you that the root servers I > choose to use are > > operating fine, and you attempt to tell me that I have to > use yours. > > For the Internet to work, at least with currently accepted > DNS standards, > everyone has to use the same root servers. Otherwise things > can rapidly > degenerate into chaos. The whole point of law and due process is that > a duly authorized somebody has to have the authority to insist that > everyone use the same root servers. Two problems; Who does the authorization? ... and US Constitution. There is also the not-so-small problem of global enforcement, of such a draconian measure. I'm not unsympathetic to folks paying for heldesks. But, you're gonna get those calls anyway. You may even be getting them now. Is this any different than lusers asking why their machine doesn't work ... during a blackout? You've been living in the regulated side of the telco business far too long.

13 14

The Cidr Report
by Tony Bates 21 Mar '01

21 Mar '01

This is an auto-generated mail on Fri Mar 16 23:00:00 PST 2001 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 16Mar01 0) General Status Table History ------------- Date Prefixes 090301 98107 100301 97522 110301 97508 120301 97530 130301 97798 140301 98013 150301 98259 160301 97900 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 91.16.23.0/24 from AS11770 AS Summary ---------- Number of ASes in routing system: 10240 Number of ASes announcing only one prefix: 6004 (3405 cidr, 2599 classful) Largest number of cidr routes: 957 announced by AS701 Largest number of classful routes: 1594 announced by AS1221 1) Gains by aggregating at the origin AS level --- 16Mar01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1594 1194 400 25.1% Telstra Pty Ltd AS701 1417 1256 161 11.4% UUNET Technologies, Inc. AS6499 170 60 110 64.7% Brooks Fiber Properties, Inc. AS9269 162 53 109 67.3% Internet service Provider in Hong AS6429 212 107 105 49.5% RdC Internet AS6595 161 62 99 61.5% DoD Education Activity Network As AS7545 169 76 93 55.0% TPG Internet Pty Ltd AS705 329 237 92 28.0% UUNET Technologies, Inc. AS4293 376 285 91 24.2% Cable & Wireless USA AS13999 102 11 91 89.2% Mega Cable S.A. de C.V. AS8013 326 242 84 25.8% PSINet Ltd. Canada AS7018 654 575 79 12.1% AT&T AS4151 226 148 78 34.5% USDA AS4755 207 133 74 35.7% Videsh Sanchar Nigam Ltd. Autonom AS577 239 169 70 29.3% Bell Advanced Communications Inc. AS724 222 155 67 30.2% DLA Systems Automation Center AS174 495 428 67 13.5% PSINet Inc. AS9498 83 18 65 78.3% BHARTI BT INTERNET LTD. AS5106 101 37 64 63.4% Ameritech Advanced Data Services, AS11170 64 1 63 98.4% Bewell Net AS3749 120 59 61 50.8% Tennessee Board of Regents AS3464 153 92 61 39.9% Alabama SuperComputer Network AS7657 163 103 60 36.8% The Internet Group Limited AS16758 63 6 57 90.5% IKON Office Solutions AS6413 67 11 56 83.6% Southern Online Systems, Inc. AS4323 233 177 56 24.0% Time Warner Communications, Inc. AS376 133 77 56 42.1% Reseau Interordinateurs Scientiqu AS226 149 93 56 37.6% Los Nettos AS1 605 550 55 9.1% BBN Planet AS6471 99 46 53 53.5% ENTEL CHILE S.A. For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

3 2

Secure multi-homing Internet Access
by Martin Picard 21 Mar '01

21 Mar '01

Hi all, Due to may different factors, including different filtering policies, mutli-homing to different providers might not provide the same Internet view, or even reachability. Default-routing to the upstream ISPs therefore seems not to be the way to go. Instead full BGP tables can be kept on the enterprise border routers and default routes can be originated on these border routers and injected in the enterprise IGP. iBGP is used between the enterprise border routers. From any router in the enterprise network, the IGP metric is used to get to the nearest border router, and then, the best BGP route is selected, which could very well be on one of its iBGP peers. Therefore traffic can flow from any router to Border1, then Border2, then the upstream ISP router. (Assuming there is a direct path between Border1 and Border2 (tunnels, MPLS-LSP, etc)). Everything's fine (at least I think so) until we throw in some Firewalls !!! They either ought to be on the eBGP path or on the iBGP path. That is between the enterprise border router and the upstream ISP router or between the enterprise border router and the enterprise network. Putting the firewall on the iBGP path can lead to routing loops since the firewall will only have a default route to the local border router. When putting the firewall on the eBGP path, it defaults to its outside interface toward the upstream ISP router and has the enterprise address block on its inside interface. So far so good, but that means that the upstream ISP media type has to be supported by the firewall: oc3, oc12 !!!! ;-( And in any case the firewall has to provide proper throughput !!! ;-( How are large enterprise implementing secure multi-home internet access ? And to what type of bandwidth does this scale ? tx martin

1 0

RE: AOL holes again.
by Roeland Meyer 21 Mar '01

21 Mar '01

How many businesses use AOL? Most AOLers are consumers and their kids. They don't have the same service expectations. > -----Original Message----- > From: M. David Leonard [mailto:mdl@equinox.shaysnet.com] > Sent: Tuesday, March 20, 2001 1:42 PM > > Peter- > > This is nothing new - AOL was silently discarding e-mail a year > ago. What's worse, when I contacted them I was told that > they have an > automated system *which does NOT generate reports for the human > postmasters* so the staff does not know what domains are > being blackholed > without grepping through the logs on scores of SMTP servers. > I find it > difficult to believe that anyone could run a business like > that but, hey, > they seem to have a lot of customers who either don't care if > e-mail gets > through or don't know how much AOL loses for them. > > > David Leonard > ShaysNet > > > On Tue, 20 Mar 2001, Peter van Dijk wrote: > > > > > On Tue, Mar 20, 2001 at 01:36:02PM -0500, ken harris. wrote: > > > >If the MSNBC article is anywhere near correct (yeah, a > big assumption) then > > > >what AOL was doing was black-holing any "high-volume" > source. While that > > > >is a noble goal, the fact that any mailing list would > fall into that > > > >category is pretty lame. > > > > > > http://members.aol.com/adamkb/aol/mailfaq/dropped-mail.html#lists > > > > This basically means AOL is violating the very spirit of SMTP - you > > say '250 message accepted', and you deliver it to all recipients you > > specified acceptance for, or produce bounces. > > > > Greetz, Peter. > > > > >

9 10

AOL holes again.
by Alan Clegg 20 Mar '01

20 Mar '01

I run mailinglists.org a non-profitable mailing list server. Several people have complained to me over the last few days about people on various lists not getting mail. The only common thread was that the users were on AOL. Contacting AOL did no good, as it was always a "problem with the list server". Well, it turns out that it is a problem with AOL that NANOG folks might be interested in: http://www.msnbc.com/news/546689.asp?0nm=C14R&cp1=1 Now, since AOL told everyone that *MY* service was faulty, what can I do? *SIGH* AlanC -- perl -le '$_="6110>374086;2064208213:90<307;55";tr[0->][ LEOR\!AUBGNSTY];print' abc(a)bsdi.com

8 8

RE: AOL holes again.
by Richard Welty 20 Mar '01

20 Mar '01

> That may be the case, but the fix is not to put any server > that generates > "lots of mail" into the bitbucket. I've been getting > complaints from a > number of list members (no spam or relaying from mailinglists.org, I > promise) that folks on AOL suddenly stopped getting the > majority of their > list mail. i suggest not jumping to any conclusions here. i run digest.net, a smallish not-very-profitable electronic mailing list host, and i observed similar dropouts, but discovered that my reverse DNS lookups were broken, and AOL's current policy is to reject email from hosts for which reverse DNS isn't working properly. richard

1 0