October 1997 - Test - lists.nanog.org

Re: Traffic Engineering (fwd)
by Sean M. Doran 19 Dec '97

19 Dec '97

Eric Germann <ekgermann(a)cctec.com> writes: > At 04:31 PM 9/18/97 -0400, Sean M. Doran wrote: > > > >Perhaps you could explain to me how you can find the > >shortest path between A and B using ping times, traceroute > >hop counts, and AS_PATHS observed at C, assuming that > >traffic between A and B is not exchanged through C? > > > > You're not trying to find it between A and B. A connects to B, but B has > every intention of redirecting to C1, C2, or C3, etc. The originally proposed idea was that search engines would present a list of hits sorted by the proximity to the client that made the query. What you are doing is rehashing the IBM scheme. Unfortunately the IBM scheme requires * an initial connection to a server * each server must know the location of its replicated data * each server must be able to determine the proximity of its replicated data to the client in reasonable time and without placing too much additional load on the server, the client, or the replicating sites Point (1) means that for short transactions, preserving locality is a net loss. If it is more work to redirect than to serve directly, there is no point in not serving directly. Point (2) means that copies of the data that may be nearer the client may not be known about. This is also a scaling problem. Point (3) is a difficult engineering challenge, not least because determining proximity (assuming proximity is a function of bandwidth, delay, and infrastructure) without inducing traffic load is hard. What is really needed is a scheme such that * the client learns the identity of the datum desired, and the ultimate, authoritative source of the datum, through user interaction (typing in a URL) or through a search database * the client or its proxy asks increasingly distant infrastructure if replicas are available; Van Jacobson suggests this is a good application for multicast and I'm inclined to agree somewhat * the client or its proxy retreives the found replicated datum if a replica exists and is found within a reasonable time or scope of multicast search or the client or its proxy turns to the ultimate source for a copy * should the client or its proxy hear a query for this same datum, it will offer it up for retrieval to other clients that is, everything in your client or proxy's local cache may be served up to nearby clients Note that the squid caching system emulates this scheme to a large degree. The difficulty is now reduced to constructing a spanning tree for all multicast queries and determining whether something found by the client or its proxy to be topologically nearby is a good choice for serving up the data. These problems seem much more tractable than the ones the IBM scheme needs to solve, and a great deal of theoretical work has gone into this sort of model already. > Anyone know of some reasonably available methods for > measuring end to end "performance" which are almost > universally implemented? No. See the CAIDA or IPPM efforts for why not. Sean. P.S.: Curtis Villamizar had another interesting approach which involved pushing content far afield to machines with the same transport-layer (IP) addresses, relying upon closest-exit routing to connect one to the topologically-closest replication machine. Unfortunately, while this could be really cool for NSPs to offload stuff towards peering points (public or private), it also has some poor scaling properties and is uncomfortably reliant upon the stability of routing. If he's done any more thinking about the idea, I'd love to hear about it though.

4 4

Re: Traffic Engineering
by James R Grinter 17 Dec '97

17 Dec '97

freedman(a)netaxs.com (Avi Freedman) writes: > smd(a)clock.org (Sean Doran) writes: > > P.S.: Curtis Villamizar had another interesting approach > > which involved pushing content far afield to > > machines with the same transport-layer (IP) > > addresses, relying upon closest-exit routing to > > connect one to the topologically-closest replication > > machine. Unfortunately, while this could be really (this is something we've done a little of at work: we do have it in production use, and it's not so effective when there's asymmetric routing - which we have quite a bit for some European networks, eg two peerings with Ebone. Duplicating IP addresses definitely has its place, eg internal to a network for directing a bunch of RASs to a local version of a 'service' address.) > And Alec Peterson (now of Erols) has figured out an even > arguably slicker way to do it. This is a problem I've been musing over lately. The best way that I can see is to return suitable DNS answers to people. This avoids the route instability problems that Sean comments on, above: Client gets TCP session established. Routes change, their inbound route now reaches a different system which clearly doesn't know about the connection and *boom* goes the TCP session. Routes return to their previous situation but by this time it's too late. (Even worse is when the client connects *during* the route instability.) but with DNS you've still got to return a suitable answer. (You could route to your DNS server, but that doesn't address the asymmetry problems.) If the bulk of your data is from you to the client (web, euuw), then it's ok because you are in a position to decide what the best route back across your network is and pick the nearest/most appropriate server. Requests usually come from the client's nearest recursing/resolving DNS server and so that's just a SMOP to decide the best way back. Where you get really screwed up is having to support large numbers of IP addresses - good ol' HTTP/1.0 requests (it's that damn web, again). Using (n x number of "sites") isn't practical. Maybe the real operational issue is working out when we stop having to assign all these zillions of IP addresses for web servers. The marketting people don't want to make the change whilst their competitors aren't. James.

4 4

Problems with specific routing policies for each exchange point
by mark＠exodus.net 05 Dec '97

05 Dec '97

I ran in to a little problem yesterday with my peering sessions wih the various route servers around the country. The problem was that I was not receiving routes from particular ASNs anymore. With a little help from Jake at Merit we were able to pinpoint the problem in my rs-in configuration. It seems that I was importing two different AS macros that each referenced the other (AS-GENUITY and AS-NAPNET). This created a loop in the macro parser on the route server which in turn nullified my routing policy. I was wondering if anyone else had come across this little phenomenon. Mark Tripod Senior Backbone Engineer Exodus Communications

9 16

OK.
by Alex Rubenstein 02 Nov '97

02 Nov '97

I am a moron; I can't figure it out. How do you make a cisco so that you can rsh into it (to use Mr. Kerns looking glass)? TIA>

6 6

Re: Spam Control Considered Harmful
by Cal Thixton - President - ThoughtPort Authority of Chicago 01 Nov '97

01 Nov '97

Phil, The problem with the 'Caller-ID' idea is verifying that an email address is 'valid' (assuming you have a reasonable definition for 'valid'). About the only thing that sendmail can do is verify a reverse lookup is equal to its forward lookup. We do this and it helps because we can then block sites from MX'ing through us based on a ruleset (e.g. customer list). In an effort to research from where we get spammed, we get a daily report (see below) of the sites that spammed us, who they were trying to spam and from where they came from. The most frequent pattern we are seeing are spams from simple dialup PPP accounts purchased all across the country; AT&T, UUNET, SWBell, BellSouth, etc... I know where they came from and yet knowing that does not help. We cannot block all of UUNET just because some ppp customer used our servers to spam. cal "I live in a house of brick instead of a tent of canvas because I have little faith in my follow man (and mother nature) being 100% perfect 100% of the time; they are only 99% perfect 99% of the time. The remaining 1%'s are a real pain. So, I tuckpoint my mortor, own a dog and watch my things. This keeps me busy and gives me purpose." Begin forwarded message: Date: Tue, 28 Oct 1997 14:05:36 -0500 To: Scott Hazen Mueller <zorch(a)orbit.hooked.net>, nanog(a)merit.edu From: Phil Lawlor <phil(a)agis.net> Subject: Re: Spam Control Considered Harmful At 10:14 AM 10/28/97 -0800, Scott Hazen Mueller wrote: >That said, I feel that the only technological solution to the spam problem is >a large-scale re-structuring of Internet mail to provide for secure >authentication and cost sharing for received e-mail. The scale and cost of >such a deployment makes something like that a political and social problem, >however. What if the equivalent of "caller ID" was built into sendmail? Making sure that the sender is a valid email address. AGIS is looking for viable solutions to the overall problem. We have moved any customers that we receive UBE complaints into AS 3830 (which is getting emptier), making them even more visible. This assists in blocking SPAM domains at the router level. For those using the Vixie like approaches, this works. Notwithstanding, this thread focuses on the threat of such efforts. Phil Lawlor President AGIS Voice - 313-730-1130 Fax - 313-563-6119 X-Sender: phil(a)agis.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 28 Oct 1997 15:41:25 -0500 To: nanog(a)merit.edu From: Phil Lawlor <phil(a)agis.net> Subject: Re: Spam Control Considered Harmful In-Reply-To: <19971028143402.15058(a)scfn.thpl.lib.fl.us> Sender: owner-nanog(a)merit.edu At 02:34 PM 10/28/97 -0500, Jay R. Ashworth wrote: >Properly configured sendmail's do this, mostly. ^^^^^^ I am not a sendmail expert, but I am told that it is in the forgery area that it could be improved. Forgery and relay hijacking seem to be the largest areas of abuse. If these areas could be improved, it could go a long way to solving the problem. Phil Lawlor President AGIS Voice - 313-730-1130 Fax - 313-563-6119 X-Sender: phil(a)agis.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 28 Oct 1997 19:27:49 -0500 To: nanog(a)merit.edu From: Phil Lawlor <phil(a)agis.net> Subject: Re: Spam Control Considered Harmful In-Reply-To: <19971028183254.40102(a)scfn.thpl.lib.fl.us> Sender: owner-nanog(a)merit.edu At 06:32 PM 10/28/97 -0500, Jay R. Ashworth wrote: >Indeed. As we noted last month on the topic of ingress filtering, you >have to catch this stuff on the _intake_ side, to have any real hope of >spotting the offenders. Back to sender verification (equivalent of caller ID). This would allow better reporting of AUP violations to the sending domain from the receiving domain. Logs could be used to document the violation. Phil Lawlor President AGIS Voice - 313-730-1130 Fax - 313-563-6119 Date: Wed, 29 Oct 1997 02:15:52 -0600 (CST) From: Operator <root(a)thoughtport.net> To: security(a)thoughtport.net Subject: Relay Block SPAM: thoughtport Who they are to: 44 webmaster netter.com.210.115.122.108 8 kstrieke bdcast.com.206.156.255.28 6 ygoldman hotmail.com.205.253.105.90 4 service etrade.com.208.254.139.3 4 service etrade.com.208.254.139.114 4 majordomo bapp.com.205.253.105.90 4 flashflood flashflood.com 4 clifton ix.netcom.com.207.93.45.122 2 tuneup qdeck.com.205.253.105.91 2 slawson iu.net.207.227.183.38 2 silisanise aol.com.207.53.21.153 2 siliconel aol.com.207.53.21.153 2 sileyboy aol.com.207.53.21.153 2 silentz aol.com.207.53.21.153 2 silenth2o aol.com.207.53.21.153 2 silaswight aol.com.207.53.21.153 2 silasmanue aol.com.207.53.21.153 2 silant aol.com.207.53.21.153 2 sil228 aol.com.207.53.21.153 2 rpatel bitconsulting.com.208.254.139.114 2 redsoxbry aol.com.207.53.20.108 2 redsox8674 aol.com.207.53.20.108 2 redsox21 aol.com.207.53.20.108 2 redsox2000 aol.com.207.53.20.108 2 redsox2 aol.com.207.53.20.108 2 redsox1975 aol.com.207.53.20.108 2 qtgal100 aol.com.207.53.20.135 2 qtfiddler aol.com.207.53.20.135 2 qtetsinger aol.com.207.53.20.135 2 qtesweet aol.com.207.53.20.135 2 qtess14u aol.com.207.53.20.135 2 qtenc aol.com.207.53.20.135 2 php46 aol.com.207.53.20.169 2 phoyt31329 aol.com.207.53.20.169 2 phoxy8 aol.com.207.53.20.169 2 phoxphyre aol.com.207.53.20.169 2 phoxman aol.com.207.53.20.169 2 phoxeast aol.com.207.53.20.169 2 phoenixwmn aol.com.207.53.20.169 2 nwc gun.com.192.41.5.95 2 mreisel sn.no.205.253.105.93 2 majordomo bap.com.205.253.105.90 2 kmiche01 thoughtport.com? 2 jal pilot.net.165.124.30.53[165.124.30.53] 2 info flyfrontier.com.153.36.240.239 2 ez connected.com.205.253.105.90 2 dj01 netter.com.208.208.223.19[208.208.223.19] 2 clifton ix.netcom.com.207.93.45.66 2 aparker infonorth.com.tom_cunningham 2 aallen3939 aol.com.207.53.20.103 2 aallen365 aol.com.207.53.20.103 2 aallen3106 aol.com.207.53.20.103 2 aallen2177 aol.com.207.53.20.103 2 aallen1980 aol.com.207.53.20.103 2 aallen1 aol.com.207.53.20.103 2 MACIAS NETTER.COM.199.35.191.5 2 Chris_Ivers/NC/FD/USA/Kelly kellyservices.com.165.124.30.53[165.124.30.53] 2 103467.2127 compuserve.com.206.133.160.189 1 No Relay Domains they are to: 44 netter.com.210.115.122.108 18 aol.com.207.53.21.153 14 aol.com.207.53.20.169 12 aol.com.207.53.20.135 12 aol.com.207.53.20.108 12 aol.com.207.53.20.103 8 bdcast.com.206.156.255.28 6 hotmail.com.205.253.105.90 4 ix.netcom.com.207.93.45.122 4 flashflood.com 4 etrade.com.208.254.139.3 4 etrade.com.208.254.139.114 4 bapp.com.205.253.105.90 2 thoughtport.com? 2 sn.no.205.253.105.93 2 qdeck.com.205.253.105.91 2 pilot.net.165.124.30.53[165.124.30.53] 2 netter.com.208.208.223.19[208.208.223.19] 2 kellyservices.com.165.124.30.53[165.124.30.53] 2 ix.netcom.com.207.93.45.66 2 iu.net.207.227.183.38 2 infonorth.com.tom_cunningham 2 gun.com.192.41.5.95 2 flyfrontier.com.153.36.240.239 2 connected.com.205.253.105.90 2 compuserve.com.206.133.160.189 2 bitconsulting.com.208.254.139.114 2 bap.com.205.253.105.90 2 NETTER.COM.199.35.191.5 1 Relay Sites they are from: 45 abs.netsgo.com 18 d00408.msy.bellsouth.net 14 d00168.msy.bellsouth.net 12 d00134.msy.bellsouth.net 12 d00107.msy.bellsouth.net 12 d00102.msy.bellsouth.net 8 ColumbiaMO-28.usi.com 7 1Cust114.tnt1.bloomington.il.da.uu.net 5 day-fl2-58.ix.netcom.com 4 1Cust3.tnt1.bloomington.il.da.uu.net 4 0.124.30.0 3 greatideas-38.starnetinc.com 2 transera.com 2 sdn-ts-011coauroP10.dialsprint.net 2 day-fl2-02.ix.netcom.com 2 1Cust239.tnt14.dfw5.da.uu.net 2 0.208.223.0 1 bastion.mecklermedia.com Traces to sites that have no name trace these: 0.124.30.0 0.208.223.0 Looking Up 0.124.30.0 route: 0.0.0.0/1 descr: HALF-DEFAULT-ZERO descr: The Reasonable Default Network Project descr: This prefix is one of three which is designed descr: to accomplish several things. Firstly, ICM descr: will be offering a set of robust and hardened descr: default-oriented prefixes which will be made descr: reliably available to some of AS1800's peers and descr: things downstream from them. The routing announcements descr: will be supplemented with a box that sends back descr: appropriate ICMP messages; at some point we will descr: also make a view of the default-announcing box's descr: knowledge of global routing available to folks descr: who wish to accept the default announcement. descr: Secondly, this announcement is designed to assist descr: ANS in the transition away from advisories. We expect descr: that this will allow people to send in far fewer descr: advisory updates than is done currently, without descr: breaking reachability between ANS's customers and descr: the rest of the world. This is good for both ANS descr: and everyone else. descr: Thirdly, ICM will be running some experiements on descr: sheer amount of traffic that follows an ultimate descr: default, although this must be done without descr: examining that traffic for content without explicit descr: permission from the originator. We expect that this descr: will help identify and fix problems in the global descr: routing system. descr: questions, comments and flames to: smd(a)sprint.net, roll(a)stupi.se origin: AS1800 advisory: AS690 1:1800 2:1239 mnt-by: MAINT-AS1800 changed: selina(a)ans.net 951011 source: RADB Tracing to: 0.124.30.0 traceroute to 0.124.30.0 (0.124.30.0), 30 hops max, 40 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Looking Up 0.208.223.0 route: 0.0.0.0/1 descr: HALF-DEFAULT-ZERO descr: The Reasonable Default Network Project descr: This prefix is one of three which is designed descr: to accomplish several things. Firstly, ICM descr: will be offering a set of robust and hardened descr: default-oriented prefixes which will be made descr: reliably available to some of AS1800's peers and descr: things downstream from them. The routing announcements descr: will be supplemented with a box that sends back descr: appropriate ICMP messages; at some point we will descr: also make a view of the default-announcing box's descr: knowledge of global routing available to folks descr: who wish to accept the default announcement. descr: Secondly, this announcement is designed to assist descr: ANS in the transition away from advisories. We expect descr: that this will allow people to send in far fewer descr: advisory updates than is done currently, without descr: breaking reachability between ANS's customers and descr: the rest of the world. This is good for both ANS descr: and everyone else. descr: Thirdly, ICM will be running some experiements on descr: sheer amount of traffic that follows an ultimate descr: default, although this must be done without descr: examining that traffic for content without explicit descr: permission from the originator. We expect that this descr: will help identify and fix problems in the global descr: routing system. descr: questions, comments and flames to: smd(a)sprint.net, roll(a)stupi.se origin: AS1800 advisory: AS690 1:1800 2:1239 mnt-by: MAINT-AS1800 changed: selina(a)ans.net 951011 source: RADB Tracing to: 0.208.223.0 traceroute to 0.208.223.0 (0.208.223.0), 30 hops max, 40 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * *

15 34

RE: Spam Control Considered Harmful
by Paul Peterson 01 Nov '97

01 Nov '97

How about a new RFC outlining a method of dynamically delivering a relay host native to whatever service provider you dial in to ?? That way, any e-mail can be traced to a supposedly responsible end-user by the victimized ISP ?? Naaaaa. Paul. > -----Original Message----- > From: woods(a)most.weird.com [SMTP:woods@most.weird.com] > Sent: Wednesday, October 29, 1997 9:47 PM > To: John A. Tamplin > Cc: nanog(a)merit.edu > Subject: Re: Spam Control Considered Harmful > > [ On Wed, October 29, 1997 at 21:53:52 (-0600), John A. Tamplin wrote: > ] > > Subject: Re: Spam Control Considered Harmful > > > >[....] > > The difficulty in the latter is finding a way to determine what SMTP > servers > > they are supposed to have access to and then implementing that in a > router > > access list. > > There should be no difficulty at all in doing this. If they dial into > your network then they use your outgoing mail relay server, and yours > alone. Period. (Unless you have some kind of agreement in a roaming > system where you authenticate your own users to someone else's dial-up > and vice versa, in which case you only allow the user to connect to > the > the "home" ISP's mail relay host(s).) > > -- > Greg A. Woods > > +1 416 443-1734 VE3TCP <gwoods(a)acm.org> > <robohack!woods> > Planix, Inc. <woods(a)planix.com>; Secrets of the Weird > <woods(a)weird.com>

7 7

Re: Spam Control Considered Harmful
by Scott Hazen Mueller 01 Nov '97

01 Nov '97

>From: Phil Lawlor <phil(a)agis.net> Welcome to the discussion, Phil. >>a large-scale re-structuring of Internet mail to provide for secure >>authentication and cost sharing for received e-mail. >What if the equivalent of "caller ID" was built into sendmail? Making sure >that the sender is a valid email address. It's a necessary precondition, but not sufficient by itself. Also, simple address verification may or may not be enough. There is no statute or case law that makes the owner of an address legally liable for the mail emitting from there - this could be an issue for claims of forgery and the like. The above notwithstanding, assume for the sake of argument that one could develop and deploy a secure mail system that authenticated message origin to the account level. This would meet the first requirement, and could *possibly* be the infrastructure for building the second. However, limiting anonymity likely wouldn't provide a strong deterrent by itself, since spammers could still run through multiple non-anonymous dialup accounts over the lifetime of a spam campaign. The other piece that would be needed - in this technological solution world - would be a fast, secure universal electronic payment system such that each mail message would be accompanied by some offer of payment. A friend or some other previous acquaintance would presumably send messages with a 0 cent payment and assume that you would recognize their name and address and accept the message anyway. An advertiser would include some amount and you - or your filters - would decide to accept or reject the message based on that and possibly some other tagging information. The scheme has generally not been sketched in much further detail because the deployment issues typically overwhelm any discussion. -- Scott Hazen Mueller zorch(a)wenet.net +1 415 281 6550 x269 Vice President Engineering, Whole Earth Networks (Hooked and The Well)

4 3

SPAM, IEMMC, and Caller ID
by Steve Sobol 01 Nov '97

01 Nov '97

Hi there -- I subscribed to this mailing list for the express purpose of replying to things that have been said on the subject of unsolicited bulk e-mail. Phil Lawlor of AGIS has suggested that a "Caller-ID" type of functionality be built into sendmail. Do I think that is a good idea? In a general sense, it probably is -- accountability is a Good Thing, and a mechanism such as he suggests will probably help situations where mailbombs, Denial of Service attacks, or harrassment have occurred and the perpetrator has to be found. Will it help reduce spam? Absolutely not. People will find ways to "block" the "caller ID", and not everyone uses sendmail as a mail server anyhow. Phil also mentioned that he spent a sizable sum of money on the IEMMC and it ended up going nowhere. That might possibly be because the IEMMC was run, apparently, by Walter Rines. Walter Rines is owner of Quantum Communications, a big spamhaus that was (until recently) hosted by AGIS. I question the wisdom of putting a spammer in charge of an organization that is supposed to reduce spam levels for people who don't want to be spammed. Would you put a convicted murderer in charge of a program designed to rehabilitate criminals? Probably not. Incidentally, Mr. Lawlor, if you really *are* participating in this discussion because you are interested in lowering the level of spam that gets dumped on the Net on a daily basis, I commend you for your change of heart. Those of us who frequent the news.admin.net-abuse newsgroups would be quite proud of you. -- NACS.NET ** Steve Sobol (sjsobol @ nacs.net) *** 216 619-2000, 1-888-273-NACS Tech Support, Programming, Postmaster, DNS dude, Real-Live Human Abuse Auto- Responder & Spam Fighter who is waiting for his Netscum Page. (Where is it, Boursy??) ** http://www.nacs.net ** Net Abuse Hotline: abuse @ nacs.net

7 8

Thoughts on spam control
by Patrick Lynch 01 Nov '97

01 Nov '97

I saw an interesting link suggested in this group for the spam problem: http://www.e-scrub.com/wpoison/ >From there I saw this program. http://www.e-scrub.com/cgi-bin/deadbolt.cgi/show_demo_entry These are both interesting programs, but may have inherent problems. wpoison: Traps e-mail web crawlers, but what is to stop it from trapping other web crawlers that altavista, webcrawler, excite, yahoo and other people use? It boasts that it can provide an almost infinite number of bogus e-mail addresses as well as hyperlinks. (these hyperlinks point directly back to the same page) Why would you want to trap a web crawler on your site, using your bandwidth and resources almost indefinitely? Deadbolt(tm): This filters out known e-mail spammers, from an automatically update-able lists, provided by E-scrub Technologies. What happens when a majority of ISPs are using a filter like this and a legitimate e-mail address is accidently put in the list? That e-mail address would then be denied by a majority of the ISPs. -- Patrick Lynch -- INDnet Network Engineer E-mail -- plynch(a)ind.net, noc(a)ind.net Phone: 317.263.8966 FAX: 317.263.8831

2 1

to control spam let's break the net?
by Robert Laughlin 01 Nov '97

01 Nov '97

Well spam is bad, but I do not think this is the answer either. DataXchange has spent lots of efforts at spam control, but apparently Karl does not think we have done enough. Based on receiving this one email, relayed thru us, he has decided to put a block in place. Most of our customers use portal.dx.net and other machines in the same address block as a mail relay, so he has effectively cut off most of our ISPs and their customers from his net. Of course maybe his network is pure, and he has found the magic bullet that stops any of his customers from spamming or relaying spam from any of his hosts or his customer's hosts. Regards, Robert Laughlin president ---------------------------------------------------------------------------- DataXchange sales: 800-863-1550 http://www.dx.net Network Operations Center: 703-903-7412 -or- 888-903-7412 ---------------------------------------------------------------------------- On Fri, 31 Oct 1997, Karl Denninger wrote: > > > Dear Site Administrator: > > Your netblock has been banned from our service for one or more of > the following offenses: > > 1) You have been used as a mail relay for spam or other unsolicited > electronic mail, and we are unable to determine if you are an > unwilling victim or a participant in the scheme. > > 2) Your domain ORIGINATED a spam or other unsolicited transmission > of electronic mail to multiple accounts on our service, and we > have received complaints or otherwise detected this unsolicited > transmission. > > 3) A customer of your service appears to have used *OUR* servers > as a relay for unsolicited email or other traffic to other > unwitting users of the Internet. > > If the offense is (2) or (3), your netblock has been PERMANENTLY blocked > until and unless you do one of the following: > > 1) Identify and remove the perpetrator of this offense. We require > documentation that the perpetrator has been removed from your > service and will not be sold access through your organization > or any affiliate or subsidiary in the future. Note that this > option will be offered only ONCE per perpetrator (ie: if you > misrepresent that a given organization has been removed, we will > not allow you this option a second time) > > 2) Identify *TO US* the source and perpetrator of this offense. > This includes their physical address, telephone number, and > sufficient unambiguous identifying information so that we may > take remedial action ourselves against this party if we so > choose to do so. > > 3) You may choose to pay MCSNet a fee for the processing of the spam > or other UCE which your organization originated, whether by yourself > or on behalf of one of your customers who you choose to protect. > The fee is currently US $500.00, doubled for each offense (ie: the > first offense is $500, the second $1000, the third $2000, etc). > The block will be removed when the fee has been paid in good US > funds. HOWEVER, note that paying the fee does not prevent the > block from being reinstated if you spam us again (in which case > the fee escalates as stated above). > > If the offense is (1) above, the block will be removed when you demonstrate > to our satisfaction that further relaying from the originating source is no > longer possible. > > Since you can no longer transmit email to our domain, to correspond with us > you must call our technical department at +1 312-803-6271 (press "T"). A > technical support representative will assist you. This department is open > from 8:00 AM - Midnight Monday through Friday, and 9-5 on weekends. > > Thank you. > > MCSNet Management > > > -----Forwarded message from 56694256(a)compuserve.com----- > > Received: from portal.dx.net (portal.dx.net [199.190.65.2]) by Mailbox.mcs.net (8.8.7/8.8.2) with ESMTP id EAA05582; Fri, 31 Oct 1997 04:03:14 -0600 (CST) > From: 56694256(a)compuserve.com > Received: from dx.net (ppp-206-171-250-28.vntrcs.pacbell.net [206.171.250.28]) > by portal.dx.net (8.8.5/8.8.5) with SMTP id FAA10023; > Fri, 31 Oct 1997 05:00:10 -0500 (EST) > Date: Fri, 31 Oct 97 01:04:14 EST > To: FreeSatellite(a)aol.com > Subject: FREE SATELLITE DISH > Message-ID: <> > > WOULD YOU LIKE TO USE A FREE SATELLITE DISH ??? > > Sounds too GOOD to be TRUE, right? Believe me, it's not! All you have to do is > call 800-733-8643, tell them that you want special offer # 954123595, leave your > name and telephone number. We will call you shortly and arrange for you to > receive your FREE Satellite Dish. A small $99.00 installation charge is > all that you pay (you will not want to install it yourself!) and the small monthly > television charge just like cable but YOU DO NOT PAY FOR THE DISH! > > Now, you can receive cable channels over a Satellite Dish - pretty hot huh? > And eventually you might use the same dish for high speed internet access. > > Digital clarity, many options, 2 FREE Remotes AND a FREE DISNEY WATCH. > Just in time for the Holidays. There are many more features available to you > for free, but first call 800-733-8643 and remember to mention Special Offer > # 954123595, your name and telephone number. > > SIMPLE - EASY - AFFORDABLE - AND A GREAT DEAL!!! > DON'T DELAY - CALL TODAY!!! > > > -----End of forwarded message----- >

3 2