- NANOG - lists.nanog.org

Business Loans For You
by loans＠xitau.de 02 Nov '97

02 Nov '97

Do you need to increase profits in your business? Do you need venture capital to get you there? Are you frustrated with your bank turning you down for the capital your business needs to grow? Be frustrated no more. Zion Worldwide can put you in touch with hundreds of offshore investors waiting to invest in a viable business just like yours. What Is An Offshore Investor? An offshore investor may be an offshore bank or a group of offshore lenders looking to invest in and to lend money to viable business enterprises both in the United States and elsewhere around the world. Why Not My Own Bank? U.S. federal banking law permits American banks to tie up a lot of their money in overhead expenses and advertising costs. Which means that American banks have less money to lend out to their customers (the ones who gave the banks their money in the first place!). Offshore banks, on the other hand, are required by offshore banking rules and regulations to lend more of their customer's money to, you guessed it, their customers. And groups of offshore lenders (often referred to as 'conglomerates'), are not necessarily restricted to the number or type of businesses that they can invest in, as long as these businesses are viable and show potential for future growth and profit. How Do I Take Advantage Of These Offshore Lending Opportunities? Zion Worldwide works with literally dozens and dozens of offshore banks and conglomerates across the world to put American businesses in touch with reputable offshore lenders. By submitting an offshore loan application to Zion Worldwide, your businesss automatically becomes eligible for the following types of offshore funding: Venture Capital Loans, Signature Loans, Equipment Leasing, Cash Grants, Self Liquidating Loans and a $25,000 Line of Offshore Credit, as well as offshore corporate credit cards. How Do I Apply And How Much Does It Cost? To apply simply write to: Zion Worldwide 5015 W. Sahara Ave., Suite 125, Las Vegas, NV, 89102. ..and ask for an offshore loan application. There is a non-refundable application fee of $200US payable to Zion Worldwide via money order, cashier's check, Visa or Mastercard. Why The $200 Fee? When you make application for offshore lending opportunities, Zion Worldwide literally sends your company's loan application to several major funding institutions around the globe. The $200US application fee assists our organization to cover the costs of shipping your loan application documents around the world. How Does Zion Worldwide Make Its Money? When your company's loan application arrives back to our office, Zion Worldwide receives a brokerage fee from our offshore lenders for finding them viable businesses to invest in. Can I Apply? Any viable business in the US or abroad may make application to Zion Worldwide in order to receive serious consideration from Zion's offshore lenders. Is It Hard To Apply? Absolutely not. Simply prepare to provide your company's past earnings as well as future earnings potential, as well as some documented business plan and, of course, some basic business details (e.g. your company's name, address, phone, fax etc.) and you're set. In fact, we want you to succeed in securing your loan, because when you succeed, we succeed. Why Is Zion Worldwide Located In Las Vegas? Nevada is America's last haven for judgment proof corporations (better than Delaware, better than Wyoming). Zion Worldwide strives to take full advantage of all of the incorporation benefits that the State of Nevada provides. What's The Catch? Sometimes interest rates on offshore loans are higher than interests rates on similar loans in the United States. However, apply for an offshore loan, then immediately turn around and expand your business with it, and of course, enjoy the increased profits your business generates, repay your offshore loan early, and the interest charged to you on your offshore loan will total no more than the interest on a loan you can (or can't) get in the US. AnyThing Else? Nope, except 'Apply Today'

1 0

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: moving to IPv6
by Sean M. Doran 01 Nov '97

01 Nov '97

Phil Howard <phil(a)charon.milepost.com> writes: > IPv4 space is not enough for dedicating 1 IP address to > every person. Correction: IP space is not enough for dedicating 1 IP address with global scope permanently to every person. Remember: CIDR requires renumbering, which means that the permanence is no longer the case; this substantially added to the lifetime expectancy of IP. NAT translates at NAT borders which means addresses have local scope. This even more substantially adds to the lifetime expectancy of IP. NAT also mitigates the cost of renumbering to comply with CIDR. Note that with aa decent evolution towards describing services as a domain name and a service name that is relative to the domain name, then the IPv4 address space is essentially extended proportional to the number of autonomous NAT domains and within each such domain proportional to the number of useable ports to which the service names may map. > There are also increased costs involved in the processes being used to > manage allocations of IPv4 space. Allocations are local. ARIN/RIPE/APNIC allocate within one large NAT domain, and not within other NAT domains. As NAT continues being deployed, and in particular if very large scale NAT (e.g., between ISPs) becomes workable and efficient, then it is local registries and not ARIN/RIPE/APNIC that will be managing allocations of local IP addresses, and NATs managing translations at NAT domain borders. > With IPv4 space being managed better with CIDR, we do have more time to > find the right way to deploy IPv6. No, with IPv4 space being managed better with CIDR we have had time to develop and deploy NAT on a continually growing scale, and have had the time to reflect that this scales better than a migration to IPv6. What is not completely clear is that IPv4ever is the best approach, but what is completely clear is that NAT and the IPv6 work on protocol translation means that a better protocol than IPv6 can easily be deployed locally within a NAT/protocol translation domain. > Whether to IPv6 or not, maybe we should be looking at what next for BGP4. A chainsaw right through it. Sean.

2 1

RE: moving to IPv6
by Rodney Joffe 01 Nov '97

01 Nov '97

It seems to me that if there is going to be a change in the way that we look at addresses, routing, and NAT, it would be in everyone's interest if we were able to build border NAT devices that besides telling an incoming packet where to go, was also able to tell it what route to take through the internal network. Not just relying on the internal routing data, but also making decisions based on the real-time performance inside the network, and the nature of the traffic (TCP vs. UDP, HTTP vs FTP vs TELNET vs MAIL). I know it touches on QOS, but QOS is reactive, this could be proactive. Once the box has to do the work, and look at each packet and address, why not add smarts? And this 'knowledge does *not* have to be passed outside my network, even though it would be a 'good thing'. Rodney Joffe Chief Technology Officer Genuity Inc., a Bechtel company http://www.genuity.net > -----Original Message----- > From: Randy Bush [SMTP:randy@psg.com] > Sent: Saturday, November 01, 1997 12:55 PM > if global name to 'address' resolution is desired, then the directory > mechanism protocols, currently dns, need to be translated at address > and/or name domain boundaries. randy

1 0

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 Sean M. Doran 01 Nov '97

01 Nov '97

Peter Galbavy <peter(a)wonderland.org> writes: While I agree that a good technical goal is to have a pair like (wonderland.demon.co.uk, www) map to the http daemon on Peter's box, and continuously push to make that a reality, the appropriate way of doing this is to consider the pair to be an endpoint address which maps to different numbers that change relative to time and topology. That is, with some enhancements to the DNS and deployment of evolving NAT technology, how Demon allocates addresses locally will be Demon's business, and what those addresses look like here likely will be different. (Ignoring the fact that it could be redirected to a cache --:) ) MOreover, if Peter changes his location in the Internet the numbers will be different again, but the pair above will continue to map to his http daemon. > Security based on IP address. Here I disagree, not only for the obvious reason that forgery is easy, but also because basing anything on IP address that does not involve looking back up through the DNS (which is also not yet safe) is incompatible with NAT. Addresses change over time and over space. > I reiterate. It is not a waste. What is a waste is people like > Interop having an entire class A, like PSInet having a class A, > like MIT ... fill in the blanks. They just got their first, but I > cannot see anyone rushing to return them. Right. I want to NAT them. Anything bounded by NATs can use whatever address allocation scheme it likes, even to the extent of using the same IP addresses in use elsewhere in the concatenated Internet. Sean.

1 0

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