- Test - lists.nanog.org

Re: Email Parcel Post is Good!
by owen＠dixon.delong.sj.ca.us 25 May '01

25 May '01

True. However, it's not arbitrary if the ISP says I'm not going to provide store and forward services for email over 100k (although I usually use 1Meg as the cutoff). If you want to do something different in your office or pay for the resources to host some sort of multi-terrabyte mailserver and the bandwidth to handle all the retries, latent failures, etc., go for it. Personally, I choose not to accept the headaches for users that don't know how to use computers. While "Parcel Post" is arguably valid, there are better methods of achieving the desired result that are much more net-friendly, user-polite, and efficient. To further your analogy, parcel post generally accepts packages up to 50#, nothing more. This is approximately 800 times the weight of a standard letter. (50 pounds == 800 ounces, and first class letter pricing is based on one ounce increments). A standard email message is usually less than 32k. 800 times 32k is 25600k, or about 25 Megabytes. Therefore, using your analogy, it is reasonable to limit parcel post to 25 Megs. This is giving you substantial bennefit of the doubt here, as the largest non-attachment email I could find in my inbox was about 10k (making the parallel limit more like 8 Megs). Denying other users resources on a store-and-forward system you don't own by sending large attachments is, in and of itself, arguably a denial of service attack. Owen > Arbitrarily denying the use of email for file transfer is, in and of itself, > tortuous interference with legitimate business of others. > - > James R. Cutler - EDS > 800 Tower Drive, Troy, MI 48098 > 1 248 265 7514 > james.cutler(a)eds.com > > > > > > > > >

3 2

Re: Stealth Blocking
by Mitch Halmu 25 May '01

25 May '01

The material mentioned was first referenced in the following article: <A HREF="http://slashdot.org/yro/01/05/21/1944247.shtml">http://slashdot.org/yro/01/05/21/1944247.shtml</A> which refers to MAPS and Abovenet blackholing Macromedia. It appears as a slashdot sequel to 'MAPS RBL is now Censorware' (Dec 2000) by Jamie McCarthy. Notice the ACLU signature. You will find details on how they squeezed my company and our stand at <A HREF="http://www.dotcomeon.com">http://www.dotcomeon.com</A> Mitch NetSide

27 50

Punch and Pie
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

Strange IPSEC activity over UUNet..
by Craig Holland 25 May '01

25 May '01

-Typed after no sleep...bear with me please- We use an IPSEC client for remote access to certain resources. I typically use a Ricochet modem at home, but a lot us use IPASS for general ISP dialup. Over the last week, I've been getting a lot of calls from people saying they had problems connecting to the remote access server, but I didn't seem to have any problems. Then a couple of days ago, my Ricochet connection stopped working. The only common denominator is any connection that passes through UUNet/AlterNet doesn't work. Crazy? I dialup to a Telia pop, no problem. I dial up to a WorldCom POP, no problem. I connect with a Ricochet (which goes through UUNet in this case)...broken. I dialup to a UUNet pop...broken. I don't get it. The client reports that it is receiving fragmented packets, and that it doesn't have the other fragment in its cache. Its almost like the packets are getting fragmented, and then some of those fragments are getting lost. Because of how the client works, this breaks its ability to connect. I've checked all my MTUs and circuits. I've reduced my MTU on the client to attempt to stop this from happening. I'm running clean as far as I can tell, and the good connections through other ISPs tells me my system is working OK. I've pinged my host from the destination network with large packets and don't lose any. Does anyone have any idea what this might be about? If this is rediculous...Great! Just want to get a fix for this or find out what is causing this. Can someone from UUNet say if you are doing some maint. that would cause this kind of activity? Thanks! Craig Holland Network Engineer Y!Messenger: cholland Ph: (408)349-3572 Fx: (408)349-3707

1 0

network policy (was Re: Stealth Blocking)
by Paul Vixie 25 May '01

25 May '01

> > What's so bad about pre-emptive open-relay scanning is that if you feel > > that is justified, you pretty much have accepted that anybody who pleases > > may scan anybody else's network for any weakness he or she would like to > > probe for. > > Whether you like / agree with it or not, this is happening and you can't > stop it. That depends on the definition of "stop." If you mean, I can't stop it in all places for all time, that's true. If you mean, I can't stop it FROM all places at ANY time, that's also true. But if you mean, I can't stop it FROM a specific place AFTER a particular time, then it's false. Any network owner has the right to accept or reject traffic based on any criteria they select. If that criteria includes "reject all IP addresses ending in .42" then it will be inconvenient to be a customer of such a network but the owner is still within his or her rights to reject that traffic. (Such a network owner would soon have no customers, most likely.) But if a network owner gets port-scanned, or spammed, or relayspammed, or otherwise abused by some host or hosts, then she can absolutely complain to the owner of the network where those hosts are connected, and if she doesn't like their response to her complaint she can absolutely decide to reject all traffic from them. Perhaps her own customers will complain, and perhaps she will lose business. That's between her and her customers. A private matter. If the contract between the network owner and her customers does not allow this type of policy-level traffic rejection, then she may have to stop. At best this would be a matter for an arbitrator or civil court to determine. It's certainly not something that third parties, including third parties whose traffic is being rejected, to have any say in. Many restaurants have a "No shirt, no shoes, no service" sign out front. Perhaps they lose the business of shirtless and/or shoeless persons. But it's their business to lose. Outsider busybodies have no right to override the expressed wishes of business owners.

1 0

New in-addr.arpa release
by ARIN IN-ADDR Role 25 May '01

25 May '01

On May 17, ARIN announced that it would be making changes to the way it produces the in-addr.arpa zone file. Comments on these changes have been minimual. Most were questions addressing specific networks, or were statements of approval. Therefore, ARIN will proceed with implementation on June 1. If you are concerned about possible impact on your networks, please review examples of the changes to occur at: http://www.arin.net/inaddr/ If you still have concerns after reviewing these examples, please direct specific questions about your networks to inaddr(a)arin.net. Regards, Ginny Listman Director of Engineering ARIN

1 0

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

25 May '01

> From: Greg Maxwell [mailto:gmaxwell@martin.fl.us] > Sent: Friday, May 25, 2001 6:25 AM > Web browsers will only display 'funny characters' for .zip > files if they > don't have their mime-types sufficently configured. Right ... and you're going to go out an reconfigure every one of them for me .. right?

1 0

RE: Stealth Blocking
by Roeland Meyer 25 May '01

25 May '01

The original message never made that distinction. > -----Original Message----- > From: Shawn McMahon [mailto:smcmahon@eiv.com] > Sent: Friday, May 25, 2001 4:30 AM > To: nanog(a)merit.edu > Subject: Re: Stealth Blocking > > > On Thu, May 24, 2001 at 08:04:34PM -0400, Jason Slagle wrote: > > > > And, as a business we wouldn't divert you. This is only a > solution for > > Resi accounts. > > You do realize, I assume, that if somebody thinks he's sending email > directly to a certain server, and you divert it to another server, > you're intercepting it under the terms of the Electronic > Communications > Privacy Act of 1986? > > That's allowed if it's necessary to provide the service, but good luck > winning on that argument with the plaintiffs trotting out > witnesses stating > it's not necessary, just your choice. > >

1 0

RE: EMAIL != FTP
by Robert Blayzor 25 May '01

25 May '01

> along the car driving vein: > > i wonder if automobile engineers have a list to vent about the incredible > inefficiency of modern cars, and why people buy these huge vehicles called > SUV's that consume far more fuel than a much smaller yet useful > car. i bet they > also wonder why people sit for an hour+ in traffic in many parts > of the country > to take overcrowded bridges, highways and tunnels to get > somewhere that many > of them really dont want to be. There are solutions to nearly every problem, but people often don't do the right thing because it is such a major inconvenience to them. People often just don't take the time to do things right or learn how to do them right. But in both cases it comes down to people either not having the knowledge, ignorance, or people simply just don't care. -- Robert Blayzor IP Network Engineer, BOFH BiznessOnline.com, Inc. rblayzor(a)thebiz.net noc(a)thebiz.net http://www.thebiz.net/ FreeBSD, Putting the 'Operating' back into OS! -- http://www.freebsd.org/

1 0

RE: Stealth Blocking
by Roeland Meyer 25 May '01

25 May '01

> From: Jason Slagle [mailto:raistlin@tacorp.net] > Sent: Thursday, May 24, 2001 12:57 PM > We tell users that if they roam they need to use the mail > server of the place they are roaming to. Not without an NDA from us, you're not. Corp traffic stays on corp servers and anyone diverting it elsewhere will get a sharp phone call from our legal department. It'll be called industrial espionage. Kashpureff went to jail for something similar. Of course, we usually use PPTP. > As a matter of fact, we are in the process of setting up a > set of rules to > divert all port 25 bound traffic on our dialups to local mail servers. Is this your actual place of business? I will make sure that our account reps are not allowed to use your service or POPS, whilst on the road. Also, since I'll be doing business with your competition, I'll clue their marketing departments in on this wonderful opportunity for them. Since this will also prevent your downstreams from running their own SMTP servers (which more than one of them probably are), you will probably lose them as well. > If everyone diverted all local traffic to a local mail > server, the problem of open relays would go away. Problems usually go away when the customers do... You probably should talk to your marketing and legal folks, before going quite that far.

3 3