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@orbit.hooked.net>, nanog@merit.edu From: Phil Lawlor <phil@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@agis.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 28 Oct 1997 15:41:25 -0500 To: nanog@merit.edu From: Phil Lawlor <phil@agis.net> Subject: Re: Spam Control Considered Harmful In-Reply-To: <19971028143402.15058@scfn.thpl.lib.fl.us> Sender: owner-nanog@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@agis.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 28 Oct 1997 19:27:49 -0500 To: nanog@merit.edu From: Phil Lawlor <phil@agis.net> Subject: Re: Spam Control Considered Harmful In-Reply-To: <19971028183254.40102@scfn.thpl.lib.fl.us> Sender: owner-nanog@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@thoughtport.net> To: security@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@sprint.net, roll@stupi.se origin: AS1800 advisory: AS690 1:1800 2:1239 mnt-by: MAINT-AS1800 changed: selina@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@sprint.net, roll@stupi.se origin: AS1800 advisory: AS690 1:1800 2:1239 mnt-by: MAINT-AS1800 changed: selina@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 * * *
The problem with the 'Caller-ID' idea is verifying that an email address is >'valid' (assuming you have a reasonable definition for 'valid'). About
At 12:56 PM 10/29/97 -0600, Cal Thixton - President - ThoughtPort Authority of Chicago wrote: the only >thing that sendmail can do is verify a reverse lookup is equal to its forward >lookup. Exactly. I guess the question is, should we build more sender verification into sendmail, on both the sending and receiving side? Phil Lawlor President AGIS Voice - 313-730-1130 Fax - 313-563-6119
Phil Lawlor wrote:
The problem with the 'Caller-ID' idea is verifying that an email address is >'valid' (assuming you have a reasonable definition for 'valid'). About
At 12:56 PM 10/29/97 -0600, Cal Thixton - President - ThoughtPort Authority of Chicago wrote: the only >thing that sendmail can do is verify a reverse lookup is equal to its forward >lookup.
Exactly. I guess the question is, should we build more sender verification into sendmail, on both the sending and receiving side?
Phil Lawlor President AGIS Voice - 313-730-1130 Fax - 313-563-6119
It would seem like a nice feature for Sendmail, but do you think it is realistic to assume that everyone would upgrade? I know of many hosts which use "outdated" versions of Sendmail. Then you would be faced with the question of whether to only allow connections from the latest version of sendmail (with the sender verification), which would limit it's usefulness. Derek Andree derek@firstcomm.com
At 04:00 PM 10/29/97 -0800, Derek Andree wrote:
Phil Lawlor wrote:
Exactly. I guess the question is, should we build more sender verification into sendmail, on both the sending and receiving side?
It would seem like a nice feature for Sendmail, but do you think it is realistic to assume that everyone would upgrade? I know of many hosts which use "outdated" versions of Sendmail. Then you would be faced with the question of whether to only allow connections from the latest version of sendmail (with the sender verification), which would limit it's usefulness.
Right. Companies that don't have a need to upgrade, won't go through the expense. In many areas, caller ID is an optional feature that costs more to have. I found it very useful earlier this year when someone posted my home phone number on the Internet. If spam is really a big problem for an organization, than they will go through the pain to solve it. Phil Lawlor President AGIS Voice - 313-730-1130 Fax - 313-563-6119
On Wed, Oct 29, 1997 at 08:42:17PM -0500, Phil Lawlor wrote:
[ . . . ] In many areas, caller ID is an optional feature that costs more to have. I found it very useful earlier this year when someone posted my home phone number on the Internet.
This is _really_ too, too good to pass up... but I will, anyway. Chers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Pedantry. It's not just a job, it's an Tampa Bay, Florida adventure." -- someone on AFU +1 813 790 7592
On Wed, 29 Oct 1997, Derek Andree wrote:
It would seem like a nice feature for Sendmail, but do you think it is realistic to assume that everyone would upgrade? I know of many hosts which use "outdated" versions of Sendmail. Then you would be faced with the question of whether to only allow connections from the latest version of sendmail (with the sender verification), which would limit it's usefulness.
Derek Andree derek@firstcomm.com
Anyone running outdated versions of sendmail has not only not met their obligations as a sysadmin, but they are also asking to have their networks owned. Sendmail is updated so often because it has MAJOR security holes and bugfixes. I guarantee you that if you gave me one of the sites that is running outdated sendmail, they could be "owned" in a very short time. There are far too many remote sendmail exploits for older versions to not upgrade. Checking http://www.geek-girl.com/bugtraq and doing a search on sendmail will verify this. So, upgrading should be a prioity to anyone who's running anything less than Sendmail 8.8.8. Joe Shaw - jshaw@insync.net NetAdmin - Insync Internet Services
It would seem like a nice feature for Sendmail, but do you think it is realistic to assume that everyone would upgrade? I know of many hosts which use "outdated" versions of Sendmail.
The issue isn't so much everyone upgrading (tho ultimately that is an issue) but, rather, everyone cooperating. A spammer or other foul being can return anything they want on a "caller id" request in the current internet. They can send a msg supposedly from "bill@whitehouse.gov" and then when asked for verification say "ayup, it's bill@whitehouse.gov". The only reason caller-id works in the phone system is because it's the sole provenance of the highly regulated (and generally disinterested, as far as lying for you goes) telcos. And truth be told caller-id doesn't work very well even in the telephone system, except inasmuch as you're willing to refuse all unidentified calls. I suppose a scheme like this slows down the hit+run whackamoles who use throw-away dial-up accounts, but only so long as they can't use their own MTA (which they usually can if it's just a straight PPP connection.) I don't think we can get anywhere so long as one spends time addressing suggestions from individuals who admit they don't understand the technology and who clearly have as an agenda to keep taking monthly fees from spammers (the very few worst excepted.) The answer is two-fold: 1. Make the implicit theft-of-service specifically illegal and tortious. In particular, not identifying the source of the spam in the message (see the recently passed Nevada anti-spam law for some good language on this.) Screw technology on this one, if they defraud they go to jail. 2. Let advertisers devise voluntary schemes profitable to all parties involved. -- -Barry Shein Software Tool & Die | bzs@world.std.com | http://www.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD The World | Public Access Internet | Since 1989 *oo*
The problem with the 'Caller-ID' idea is verifying that an email address is >'valid' (assuming you have a reasonable definition for 'valid'). About
Phil, The analog to email in the real world is the US Postal service where we have even far weaker authentication systems in place. To cope with abuses, we passed laws governing the use the the mails when Ben Franklin got a anonymous and most unwelcomed solicitation from Thomas Jefferson. I personally see no practical technical means of eliminating the practise of spamming and rather than spending time trying to dream up fancier and smarter sendmail's, we should seek to simply expand the current mail fraud laws to cover electronic mail. Then we can simply sic the FBI on these people armed with terabytes of logs and spam emails and then see what happens when a few are convicted of electonic mail fraud and sent up the river for a rest. Cal "Yes, my house is made of brick, but the front door is made of glass. I do this because I have faith in the social contract I have with my neighbors that assures me that they won't break it and I won't call the cops (or, when I lived in Texas, use my gun)." Begin forwarded message: X-Sender: phil@agis.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 29 Oct 1997 18:06:33 -0500 To: Cal_Thixton@TPA.Net From: Phil Lawlor <phil@agis.net> Subject: Re: Spam Control Considered Harmful Cc: nanog@merit.edu At 12:56 PM 10/29/97 -0600, Cal Thixton - President - ThoughtPort Authority of Chicago wrote: the only >thing that sendmail can do is verify a reverse lookup is equal to its forward >lookup. Exactly. I guess the question is, should we build more sender verification into sendmail, on both the sending and receiving side? Phil Lawlor President AGIS Voice - 313-730-1130 Fax - 313-563-6119
On Wed, 29 Oct 1997, Cal Thixton - President - ThoughtPort Authority of Chicago wrote:
I personally see no practical technical means of eliminating the practise of spamming and rather than spending time trying to dream up fancier and smarter sendmail's, we should seek to simply expand the current mail fraud laws to cover electronic mail. Then we can simply sic the FBI on these people armed with terabytes of logs and spam emails
And what will the FBI do when spammers leave the US and do their deed from other countries? Spammers won't be stopped by legislation or technology...the average internet user can't handle the amount of technology necessary to keep spam out of their mail. The average sysadmin isn't much better off. I had to disable my latest anti-spam sendmail rule today (denying incoming mail from sites with no or incorrect in-addr.arpa DNS) because a client is trying to do business with a site that has existed for a year an a half and never setup in-addr.arpa DNS. Spam can only be stopped by responsible providers not allowing their clients to abuse the net. Phil's attitude of "We provide internet connectivity. If you don't like spam, _you_ do something about it." has nearly destroyed AGIS. Who's going to be next? BTW...Cal...obtain a linefeed. ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
And what will the FBI do when spammers leave the US...
In these cases, we normally turn them into international trade issues. If we all freely admit that this problem is beyond a technical solution, what are our alternatives? Even in the best of cases, sometimes we have no choices. In Agis's case, they recently took action and disconnected a known spammer site; they were taken to court and ordered to restore service. I am not sure how well my own Use Policy would hold up were we ever to be dragged into court. As the wild west days of the Internet wane and our Clint Eastwood heros, (e.g. the Honorable Paul Vixie) find themselves marginalized by savvy customers with court orders, we will find that migrating from gun slinging to organized law enforcement far cheaper and more effective in the long run. I am just as willing as the next 'responsible provider' to be responsible. However, if I cannot also have the authority that comes with it or at least can turn to someone who does, then we will end up in a free-for-all situation which, come to think of it, is what is happening now. No One on the Internet has the authority to turn Anyone off no matter what they do, nearly. Check my spamming report from last night, I see my top abuser yesterday was an MCI customer (see trace). Though I have sent lots of complaints to MCI, never have I ever gotten a human reply with followup. In fact, in my personal experience, I have never had any of the big backbone providers do much other than send me an automated reply, except for one; Agis. Perhaps it is because I am a customer that they listen to me whine, but it does seem than in all of the public discussions thus far, I have only seen one provider even willing to engage in a conversation on spamming. And yet who is the preferred whipping boy, since uunet, bellsouth, mci, et. al. are all bright enough to know when to duck an issue? hmmm. Cal Esse, my neighbor, asked, "are you letting people come and pick from your garden, honey?" "No, why do you ask?" "Well, the man on the top floor sent over his step daughter to pick some things and I was just thought you should know." Sure enough, my first crop of peaches were gone along with some other things. I installed a broken video camera on my house over looking the garden. I have not lost anything since. wickerpark 212) t netsgo.com traceroute to netsgo.com (210.115.123.108), 30 hops max, 40 byte packets 1 CHI-Cisco01.ThoughtPort.COM (199.171.236.1) 40 ms 10 ms 10 ms 2 CHI-DET-Cisco01.BB.ThoughtPort.COM (199.171.248.2) 30 ms 10 ms 10 ms 3 a0.1008.chicago4.agis.net (205.137.60.238) 30 ms 20 ms 20 ms 4 a0-0.1.chicago2.agis.net (205.254.173.250) 30 ms 20 ms 30 ms 5 aads.mci.net (198.32.130.12) 70 ms 4 ms 60 ms 6 aads.mci.net (198.32.130.12) 70 ms * 130 ms 7 * core1.Bloomington.mci.net (204.70.4.161) 190 ms 130 ms 8 core2-hssi-2.Sacramento.mci.net (204.70.1.138) 300 ms * 620 ms 9 border7-fddi-0.Sacramento.mci.net (204.70.164.51) 120 ms 110 ms 120 ms 10 yukong-ltd.Sacramento.mci.net (204.70.122.86) 250 ms 260 ms 280 ms 11 abs.netsgo.com (210.115.123.108) 260 ms 260 ms 270 ms Begin forwarded message: Date: Thu, 30 Oct 1997 00:24:46 -0500 (EST) From: Jon Lewis <jlewis@inorganic5.fdt.net> To: Cal_Thixton@TPA.Net cc: Phil Lawlor <phil@agis.net>, nanog@merit.edu Subject: Re: Spam Control Considered Harmful In-Reply-To: <199710300214.UAA12965@thoughtport.thoughtport.net> X-To-Stop-Spam-See: [An attachment was originally included here]http://inorganic5.fdt.net/~jlewis/spam.html On Wed, 29 Oct 1997, Cal Thixton - President - ThoughtPort Authority of Chicago wrote:
I personally see no practical technical means of eliminating the practise of spamming and rather than spending time trying to dream up fancier and smarter sendmail's, we should seek to simply expand the current mail fraud laws to cover electronic mail. Then we can simply sic the FBI on these people armed with terabytes of logs and spam emails
And what will the FBI do when spammers leave the US and do their deed from other countries? Spammers won't be stopped by legislation or technology...the average internet user can't handle the amount of technology necessary to keep spam out of their mail. The average sysadmin isn't much better off. I had to disable my latest anti-spam sendmail rule today (denying incoming mail from sites with no or incorrect in-addr.arpa DNS) because a client is trying to do business with a site that has existed for a year an a half and never setup in-addr.arpa DNS. Spam can only be stopped by responsible providers not allowing their clients to abuse the net. Phil's attitude of "We provide internet connectivity. If you don't like spam, _you_ do something about it." has nearly destroyed AGIS. Who's going to be next? BTW...Cal...obtain a linefeed. ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ______[An attachment was originally included here]http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____ Begin forwarded message: Date: Thu, 30 Oct 1997 00:24:46 -0500 (EST) From: Jon Lewis <jlewis@inorganic5.fdt.net> To: Cal_Thixton@TPA.Net cc: Phil Lawlor <phil@agis.net>, nanog@merit.edu Subject: Re: Spam Control Considered Harmful In-Reply-To: <199710300214.UAA12965@thoughtport.thoughtport.net> X-To-Stop-Spam-See: [An attachment was originally included here]http://inorganic5.fdt.net/~jlewis/spam.html On Wed, 29 Oct 1997, Cal Thixton - President - ThoughtPort Authority of Chicago wrote:
I personally see no practical technical means of eliminating the practise of spamming and rather than spending time trying to dream up fancier and smarter sendmail's, we should seek to simply expand the current mail fraud laws to cover electronic mail. Then we can simply sic the FBI on these people armed with terabytes of logs and spam emails
And what will the FBI do when spammers leave the US and do their deed from other countries? Spammers won't be stopped by legislation or technology...the average internet user can't handle the amount of technology necessary to keep spam out of their mail. The average sysadmin isn't much better off. I had to disable my latest anti-spam sendmail rule today (denying incoming mail from sites with no or incorrect in-addr.arpa DNS) because a client is trying to do business with a site that has existed for a year an a half and never setup in-addr.arpa DNS. Spam can only be stopped by responsible providers not allowing their clients to abuse the net. Phil's attitude of "We provide internet connectivity. If you don't like spam, _you_ do something about it." has nearly destroyed AGIS. Who's going to be next? BTW...Cal...obtain a linefeed. ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ______[An attachment was originally included here]http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____ Date: Thu, 30 Oct 1997 11:46:25 -0600 (CST) From: cthixton@thoughtport.net To: security@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 8 clifton ix.netcom.com.207.93.45.69 8 clifton ix.netcom.com.207.93.45.122 8 chadparsons prodigy.net.166.72.115.94 6 ygoldman hotmail.com.205.253.105.90 6 clifton ix.netcom.com.207.93.45.83 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 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.71 2 clifton ix.netcom.com.207.93.45.66 2 cheeto333 aol.com.208.197.20.27[208.197.20.27] 2 cheeto2323 aol.com.208.197.20.27[208.197.20.27] 2 cheeto178 aol.com.208.197.20.27[208.197.20.27] 2 chays911 aol.com.208.197.20.27[208.197.20.27] 2 cevans1977 aol.com.208.197.20.39[208.197.20.39] 2 cevans1948 aol.com.208.197.20.39[208.197.20.39] 2 cevans1464 aol.com.208.197.20.39[208.197.20.39] 2 cennypam aol.com.208.197.20.42[208.197.20.42] 2 cenntauri aol.com.208.197.20.42[208.197.20.42] 2 cennjcutie aol.com.208.197.20.42[208.197.20.42] 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 2004076 mcimail.com.153.35.127.59 2 2004075 mcimail.com.153.35.127.59 2 2004074 mcimail.com.153.35.127.59 2 2004073 mcimail.com.153.35.127.59 2 2004072 mcimail.com.153.35.127.59 2 2004071 mcimail.com.153.35.127.59 2 2004070 mcimail.com.153.35.127.59 2 2004069 mcimail.com.153.35.127.59 2 2004068 mcimail.com.153.35.127.59 2 2004067 mcimail.com.153.35.127.59 2 103467.2127 compuserve.com.206.133.160.189 1 No Relay Domains they are to: 44 netter.com.210.115.122.108 20 mcimail.com.153.35.127.59 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 prodigy.net.166.72.115.94 8 ix.netcom.com.207.93.45.69 8 ix.netcom.com.207.93.45.122 8 bdcast.com.206.156.255.28 8 aol.com.208.197.20.27[208.197.20.27] 6 ix.netcom.com.207.93.45.83 6 hotmail.com.205.253.105.90 6 aol.com.208.197.20.42[208.197.20.42] 6 aol.com.208.197.20.39[208.197.20.39] 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.71 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 netsgo.com 22 0.197.20.0 21 1Cust59.max6.cleveland.oh.ms.uu.net 18 d00408.msy.bellsouth.net 14 lachman-2.pr.mcs.net 14 d00168.msy.bellsouth.net 12 d00134.msy.bellsouth.net 12 d00107.msy.bellsouth.net 12 d00102.msy.bellsouth.net 10 day-fl2-58.ix.netcom.com 10 day-fl2-05.ix.netcom.com 9 slip166-72-115-94.mo.us.ibm.net 8 day-fl2-19.ix.netcom.com 8 ColumbiaMO-28.usi.com 7 1Cust114.tnt1.bloomington.il.da.uu.net 4 1Cust3.tnt1.bloomington.il.da.uu.net 4 0.124.30.0 3 greatideas-38.starnetinc.com 3 day-fl2-07.ix.netcom.com 2 transera.com 2 sdn-ts-011coauroP10.dialsprint.net 2 lachman-5.pr.mcs.net 2 lachman-3.pr.mcs.net 2 day-fl2-02.ix.netcom.com 2 bastion.mecklermedia.com 2 1Cust239.tnt14.dfw5.da.uu.net 2 0.208.223.0 Traces to sites that have no name trace these: 0.124.30.0 0.197.20.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@sprint.net, roll@stupi.se origin: AS1800 advisory: AS690 1:1800 2:1239 mnt-by: MAINT-AS1800 changed: selina@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.197.20.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@sprint.net, roll@stupi.se origin: AS1800 advisory: AS690 1:1800 2:1239 mnt-by: MAINT-AS1800 changed: selina@ans.net 951011 source: RADB Tracing to: 0.197.20.0 traceroute to 0.197.20.0 (0.197.20.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@sprint.net, roll@stupi.se origin: AS1800 advisory: AS690 1:1800 2:1239 mnt-by: MAINT-AS1800 changed: selina@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 * * *
And what will the FBI do when spammers leave the US...
This is really a red herring -- any spam control law, even one of the bad ones like the Murkowski bill applies to any resident of the U.S., even if he hires someone in Moldova to send out his spam. To escape U.S. law the spammer has to move his entire business offshore. In practice we're unlike to see much offshore spam because the goal of spammers is to collect money from suckers, and it's a whole lot harder to do so if you don't have a domestic mailing address and bank account. Also, as others have pointed out, there aren't a lot of other countries with low cost unmetered Internet connections and, other than Canada, even those are connected to the U.S. by long, thin, expensive undersea cables whose proprietors aren't likely to enjoy having them filled with spam and angry responses. -- John R. Levine, IECC, POB 640 Trumansburg NY 14886 +1 607 387 6869 johnl@iecc.com, Village Trustee and Sewer Commissioner, http://iecc.com/johnl, Finger for PGP key, f'print = 3A 5B D0 3F D9 A0 6A A4 2D AC 1E 9E A6 36 A3 47
On 30 Oct 1997, John R. Levine wrote:
And what will the FBI do when spammers leave the US...
This is really a red herring -- any spam control law, even one of the bad ones like the Murkowski bill applies to any resident of the U.S., even if he hires someone in Moldova to send out his spam. To escape U.S. law the spammer has to move his entire business offshore. In practice we're unlike to see much offshore spam because the goal of spammers is to collect money from suckers, and it's a whole lot harder to do so if you don't have a domestic mailing address and bank account.
So (hypotheticaly, if I were a spammer) if I rent a P.O. box from some mailbox rental place using a fake ID, buy an account overseas with another fake ID, and use that account to relay spam through old broken mail servers all over the world...servers that don't insert in the header the true IP of the sender...the FBI will somehow stop me? I suppose they could steak out the P.O. box, but lots of spam doesn't involve sending money. How about the offshore area codes (I think 809 was one) spammers urge you to call to collect your free prize or avoid having your credit record destroyed? You call and the telco bills you for them. They need no presence in the US, and I'd therefore assume are untouchable by the FBI. Since none of this does my Cisco any good, shouldn't we move the discussion to a more appropriate list, or create one for it? Perhaps netop-spam...a spam discussion list for network operators? If it doesn't already exist, I'll be happy to create it. ------------------------------------------------------------------ Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will Network Administrator | be proof-read for $199/message. Florida Digital Turnpike | ______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
On Fri, Oct 31, 1997 at 10:49:35AM -0500, Jon Lewis wrote:
Since none of this does my Cisco any good, shouldn't we move the discussion to a more appropriate list, or create one for it?
Perhaps netop-spam...a spam discussion list for network operators? If it doesn't already exist, I'll be happy to create it.
As noted previously, this _is_ on topic for nodlist@nodewarrior.net. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Pedantry. It's not just a job, it's an Tampa Bay, Florida adventure." -- someone on AFU +1 813 790 7592
[ On Sat, November 1, 1997 at 17:20:17 (-0500), Jay R. Ashworth wrote: ]
Subject: Re: Boy are we off-topic...was Re: Spam Control Considered Harmful
On Fri, Oct 31, 1997 at 10:49:35AM -0500, Jon Lewis wrote:
Perhaps netop-spam...a spam discussion list for network operators? If it doesn't already exist, I'll be happy to create it.
As noted previously, this _is_ on topic for nodlist@nodewarrior.net.
I don't think anyone really wants to subscribe to yet another list, or at least I don't, not without previewing it for a while and that's rather hard to do if there's no browsable archives or something. It's really too bad Usenet has more or less gone to the dogs.... Once upon a long time ago I had hoped most mailing lists would go the way of the wind and everyone would use Usenet for mulit-party discussion. -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
you want the Federal government to step in and regulate the industry...
Am I willing to give up some control to stop what seems to be rampant abuse. If 200 emails a day is not your threshold, what is? 400? 600? We have similar structures in plaec for the use of the mails, the phones, the highways. What makes the Internet so special? If we were to treat the Internet like the real world, we would be charging for each email sent instead of giving it away. Metering each letter and billing the source works in the real world. Sendmail is not Panacea. It is clever. Were that I was bright enough to write such a tool, even with the aid of creational drugs, but even so, it cannot out smart man. cal "Sendmail is the most widely used AI program in the world", Mike O'Dell. Begin forwarded message: From: "Brian W. Pendleton" <brian@cais.net> To: <Cal_Thixton@TPA.Net> Subject: Re: Spam Control Considered Harmful Date: Thu, 30 Oct 1997 08:58:13 -0500 Cal, I dislike email as much as the next person. I get over 200 emails a day and a lot of them are Spam. But it scares me to think that you want the Federal government to step in and regulate the industry in any form. And then to suggest that the FBI become involved just to send a message to the rest of the spammers is even more scary. This is a problem that the internet industry has to solve on its own. Their are technical ways to stop Spam. They may not be thought of yet but I believe that with a little bit of effort a way can be found. I read somewhere else on the list that if a new version of sendmail was created that not every one would change over to it just to stop Spam. What if everyone else on the net refused email from older sendmail versions. I admit it would be a hard task to do but with enough pressure everyone would make the switch. This is just a thought. Brian W. Pendleton CAIS Internet -----Original Message----- From: Cal Thixton - President - ThoughtPort Authority of Chicago <cthixton@thoughtport.net> To: Phil Lawlor <phil@agis.net> Cc: nanog@merit.edu <nanog@merit.edu> Date: Wednesday, October 29, 1997 9:14 PM Subject: Re: Spam Control Considered Harmful
Phil, The analog to email in the real world is the US Postal service where we
I personally see no practical technical means of eliminating the practise of spamming and rather than spending time trying to dream up fancier and smarter sendmail's, we should seek to simply expand the current mail fraud laws to cover electronic mail. Then we can simply sic the FBI on these
have even far weaker authentication systems in place. To cope with abuses, we passed laws governing the use the the mails when Ben Franklin got a anonymous and most unwelcomed solicitation from Thomas Jefferson. people armed with terabytes of logs and spam emails and then see what happens when a few are convicted of electonic mail fraud and sent up the river for a rest.
Cal
"Yes, my house is made of brick, but the front door is made of glass. I
do this because I have faith in the social contract I have with my neighbors that assures me that they won't break it and I won't call the cops (or, when I lived in Texas, use my gun)."
Begin forwarded message:
X-Sender: phil@agis.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 29 Oct 1997 18:06:33 -0500 To: Cal_Thixton@TPA.Net From: Phil Lawlor <phil@agis.net> Subject: Re: Spam Control Considered Harmful Cc: nanog@merit.edu
The problem with the 'Caller-ID' idea is verifying that an email address is >'valid' (assuming you have a reasonable definition for 'valid'). About
At 12:56 PM 10/29/97 -0600, Cal Thixton - President - ThoughtPort Authority of Chicago wrote: the only >thing that sendmail can do is verify a reverse lookup is equal to its forward >lookup.
Exactly. I guess the question is, should we build more sender verification into sendmail, on both the sending and receiving side?
Phil Lawlor President AGIS Voice - 313-730-1130 Fax - 313-563-6119
Cal Thixton - President - ThoughtPort Authority of Chicago put this into my mailbox:
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.
This has been my experience too. Is there a good reason why the throwway folks (those mentioned above) haven't blocked port 25 from their dialups to the outside internet? It seems that this would help stop the hijacking of other SMTP relays that occurs, and limit abuse to that ISP's own servers, where it can be better controlled. The only reason I can think of that would stop this would be if a user subscribes to earthlink, but uses a UUnet dialin, that customer's software would be set up to use the Earthlink SMTP servers. Keep in mind again I don't yet know much about how this would impact router performance..but wouldn't one be able to set up access-lists, then, that would allow port-25 connections to a defined list of SMTP servers (say, UUnet, MSN, and earthlink SMTP servers), and prohibit everything else? Why aren't they doing this? I've currently blocked all of UUnet and PSInet from my mail server - spam about dropped in half. But I'm still getting spam through what appear to be unsuspecting relays - and the source is one of those dialup, throwaway accounts. -dalvenjah -- Dalvenjah FoxFire (aka Sven Nielsen) "It brought me a Mr. Potato Head, Founder, the DALnet IRC Network Scully. It knew that I wanted a Mr. Potato Head!" e-mail: dalvenjah@dal.net WWW: http://www.dal.net/~dalvenjah/ whois: SN90 Try DALnet! http://www.dal.net/
On Wed, 29 Oct 1997, Dalvenjah FoxFire wrote:
Is there a good reason why the throwway folks (those mentioned above) haven't blocked port 25 from their dialups to the outside internet?
We are an ISP and we don't block our dialups from going to port 25 elsewhere because this would eliminate their ability to rightfully use another mail server. This frequently occurs when a user accesses a mail server at work from their home dialup account. If other ISPs did this, we would have a problem where a user dialing into their ISP couldn't reach their virtual mail server, hosted on our network. We currently don't have many going the other way, but that may change.
The only reason I can think of that would stop this would be if a user subscribes to earthlink, but uses a UUnet dialin, that customer's software would be set up to use the Earthlink SMTP servers.
In our case, this doesn't help since we and all the other local ISPs block relay access, so you have to use the mail server of the ISP you are currently connected to. John Tamplin Traveller Information Services jat@Traveller.COM 2104 West Ferry Way 205/883-4233x7007 Huntsville, AL 35801
On Wed, Oct 29, 1997 at 06:14:38PM -0600, John A. Tamplin wrote:
On Wed, 29 Oct 1997, Dalvenjah FoxFire wrote:
Is there a good reason why the throwway folks (those mentioned above) haven't blocked port 25 from their dialups to the outside internet?
We are an ISP and we don't block our dialups from going to port 25 elsewhere because this would eliminate their ability to rightfully use another mail server. This frequently occurs when a user accesses a mail server at work from their home dialup account. If other ISPs did this, we would have a problem where a user dialing into their ISP couldn't reach their virtual mail server, hosted on our network. We currently don't have many going the other way, but that may change.
This is roughly akin, though, isn't it, John, to the cache pollution problems that make it pretty much a requirement to run 2 separate nameservers: one for recursion and caching, and the other to be authoritative? Run a separate relay server, with some authentication, for users connecting from outside your AS.
The only reason I can think of that would stop this would be if a user subscribes to earthlink, but uses a UUnet dialin, that customer's software would be set up to use the Earthlink SMTP servers.
In our case, this doesn't help since we and all the other local ISPs block relay access, so you have to use the mail server of the ISP you are currently connected to.
Hold it. Didn't you just say the opposite above? I think I'm confused. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Pedantry. It's not just a job, it's an Tampa Bay, Florida adventure." -- someone on AFU +1 813 790 7592
On Wed, 29 Oct 1997, Jay R. Ashworth wrote:
We are an ISP and we don't block our dialups from going to port 25 elsewhere because this would eliminate their ability to rightfully use another mail server. This frequently occurs when a user accesses a mail server at work from their home dialup account. If other ISPs did this, we would have a problem where a user dialing into their ISP couldn't reach their virtual mail server, hosted on our network. We currently don't have many going the other way, but that may change.
This is roughly akin, though, isn't it, John, to the cache pollution problems that make it pretty much a requirement to run 2 separate nameservers: one for recursion and caching, and the other to be authoritative?
Run a separate relay server, with some authentication, for users connecting from outside your AS.
The point is there can be no useful authentication for outgoing email if you don't block it by IP address. However, that is a discussion about blocking spam relay, not about blocking outgoing SMTP. If we install a filter at the router that blocks all traffic from dialup connections to port 25 anywhere else, then it doesn't matter how many servers we run they can't get to another SMTP server, even if they are supposed to be doing it.
The only reason I can think of that would stop this would be if a user subscribes to earthlink, but uses a UUnet dialin, that customer's software would be set up to use the Earthlink SMTP servers.
In our case, this doesn't help since we and all the other local ISPs block relay access, so you have to use the mail server of the ISP you are currently connected to.
Hold it. Didn't you just say the opposite above?
He offered an example of a customer that has dialup access to two ISPs, and wants to connect to the SMTP server of the one he isn't currently connected to. Because of the relay blocking that we and all the other ISPs in town implement (and hopefully ISPs elsewhere), the customer can't do that anyway. What I said above is that there are other examples that our customers expect to work, specifically connecting to an SMTP server at work or connecting to a virtual domain hosted at another ISP (in our case it is primarily the vdom user dialup into another ISP and accessing the site here), that is why we can't block all traffic from dialup to port 25 anywhere. I think you are confusing the issue of blocking unauthorized relay access to your SMTP server, which is easy to do based on CIDR blocks, with that of preventing dialup customers from relaying through the SMTP servers of others. 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. John Tamplin Traveller Information Services jat@Traveller.COM 2104 West Ferry Way 205/883-4233x7007 Huntsville, AL 35801
On Wed, Oct 29, 1997 at 09:53:52PM -0600, John A. Tamplin wrote:
This is roughly akin, though, isn't it, John, to the cache pollution problems that make it pretty much a requirement to run 2 separate nameservers: one for recursion and caching, and the other to be authoritative?
Run a separate relay server, with some authentication, for users connecting from outside your AS.
The point is there can be no useful authentication for outgoing email if you don't block it by IP address. However, that is a discussion about blocking spam relay, not about blocking outgoing SMTP. If we install a filter at the router that blocks all traffic from dialup connections to port 25 anywhere else, then it doesn't matter how many servers we run they can't get to another SMTP server, even if they are supposed to be doing it.
Oh, ok. Sorry. Right. I misread the other gentleman's suggestion.
Hold it. Didn't you just say the opposite above?
He offered an example of a customer that has dialup access to two ISPs, and wants to connect to the SMTP server of the one he isn't currently connected to. Because of the relay blocking that we and all the other ISPs in town implement (and hopefully ISPs elsewhere), the customer can't do that anyway.
Right. Got it.
What I said above is that there are other examples that our customers expect to work, specifically connecting to an SMTP server at work or connecting to a virtual domain hosted at another ISP (in our case it is primarily the vdom user dialup into another ISP and accessing the site here), that is why we can't block all traffic from dialup to port 25 anywhere.
Rog. On deck now.
I think you are confusing the issue of blocking unauthorized relay access to your SMTP server, which is easy to do based on CIDR blocks, with that of preventing dialup customers from relaying through the SMTP servers of others. 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.
Right. Of course, that's a Small Matter of Administration. :-) Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Pedantry. It's not just a job, it's an Tampa Bay, Florida adventure." -- someone on AFU +1 813 790 7592
[ 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@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
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).)
Or for those who complain that "reconfiguration" to use the local mail relay is too difficult, howabout setting aside a /24 from somewhere (the swamp ?) and writing an RFC that says "thou shall not route this" ala private address space, but if you wish to offer "local" services, then the user only need caryy one "well known" address range around with them. Give it some well know DNS: "mail.local." :) and so on. (OK New TLD required). This could also fix deciding which DNS servers to use amongst other things. Peter -- Peter Galbavy @ Home in Wonderland http://www.wonderland.org/ http://www.whirl-y-gig.org.uk/ http://www.demon.net Be remembered not for your final destination, but for your journey.
[ On Wed, October 29, 1997 at 18:14:38 (-0600), John A. Tamplin wrote: ]
Subject: Re: Spam Control Considered Harmful
On Wed, 29 Oct 1997, Dalvenjah FoxFire wrote:
Is there a good reason why the throwway folks (those mentioned above) haven't blocked port 25 from their dialups to the outside internet?
We are an ISP and we don't block our dialups from going to port 25 elsewhere because this would eliminate their ability to rightfully use another mail server.
That's all fine and dandy just so long as you trust your customers and you are certain they will adhere to your AUP. However if you offer cheap dial-up accounts that can be opened either immediately, perhaps with a credit card number, then you've got no real way to establish *any* level of trust with your new customers and indeed the only way you can enforce your AUP is by technical means. I.e. if your AUP says no spamming then you *must* implement controls that prevent new customers from spamming. Period. Otherwise Joe Spammer just buys a one-time (throw-away) account from you and violates your AUP under false pretenses. I've even heard first-hand rumours that many spammers offer fraudulent credit card numbers and personal identification so you can't even try to bill them extra for breaking their contract.
This frequently occurs when a user accesses a mail server at work from their home dialup account. If other ISPs did this, we would have a problem where a user dialing into their ISP couldn't reach their virtual mail server, hosted on our network. We currently don't have many going the other way, but that may change.
There's no excuse for this. The user should (and must in the proposed plan) use the mail relay operated by the ISP they dial into for *all* outgoing mail. Only under a full roaming system where authentication information originates from the "home" ISP can you allow the user to connect to any other mail relay server, and in fact in this case you probably want to restrict them to only thie rhome ISP's mail relay server and not allow them to use your own local mail relay server.
In our case, this doesn't help since we and all the other local ISPs block relay access, so you have to use the mail server of the ISP you are currently connected to.
Exactly, so what's the problem? -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
On Thu, Oct 30, 1997 at 12:14:54AM -0500, Greg A. Woods wrote:
This frequently occurs when a user accesses a mail server at work from their home dialup account. If other ISPs did this, we would have a problem where a user dialing into their ISP couldn't reach their virtual mail server, hosted on our network. We currently don't have many going the other way, but that may change.
There's no excuse for this. The user should (and must in the proposed plan) use the mail relay operated by the ISP they dial into for *all* outgoing mail.
Yes, there is. It's a question of span of administrative control. If I decided to allow my users to make use of their telecommunting connectivity for personal use, I _do not want them_ using my mail server for that, so as to avoid any potential liability for my company under any theory. Sure, use the great high bandwidth connection, but get your mail and news services from a commercial provider. But then, you're probably the type that thinks an A record isn't enough to route mail, too... Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Pedantry. It's not just a job, it's an Tampa Bay, Florida adventure." -- someone on AFU +1 813 790 7592
[ On Thu, October 30, 1997 at 10:02:49 (-0500), Jay R. Ashworth wrote: ]
Subject: Re: Spam Control Considered Harmful
There's no excuse for this. The user should (and must in the proposed plan) use the mail relay operated by the ISP they dial into for *all* outgoing mail.
Yes, there is. It's a question of span of administrative control.
If I decided to allow my users to make use of their telecommunting connectivity for personal use, I _do not want them_ using my mail server for that, so as to avoid any potential liability for my company under any theory. Sure, use the great high bandwidth connection, but get your mail and news services from a commercial provider.
I think you're beginning to get the full picture! ;-) Yes, by forcing your users to use your outgoing mail relay server you are assuming liability for their actions and thus also assuming responsibility for controlling and limiting their actions. If you cannot provide externally visible audit trails that clearly show who is accountable for originating the mail then you must assume any liability for allowing that anonymous person to send such mail. My off the cuff rule to date for determining where I point the finger is to check and see who the IP address for the originating network is assigned to (i.e. in whois). -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
On Thu, 30 Oct 1997, Greg A. Woods wrote:
We are an ISP and we don't block our dialups from going to port 25 elsewhere because this would eliminate their ability to rightfully use another mail server.
That's all fine and dandy just so long as you trust your customers and you are certain they will adhere to your AUP.
However if you offer cheap dial-up accounts that can be opened either immediately, perhaps with a credit card number, then you've got no real way to establish *any* level of trust with your new customers and indeed the only way you can enforce your AUP is by technical means. I.e. if your AUP says no spamming then you *must* implement controls that prevent new customers from spamming. Period. Otherwise Joe Spammer just buys a one-time (throw-away) account from you and violates your AUP under false pretenses. I've even heard first-hand rumours that many spammers offer fraudulent credit card numbers and personal identification so you can't even try to bill them extra for breaking their contract.
There are costs of allowing spam and costs of stopping spam. If the costs of stopping it exceed the cost of allowing it, then obviously it is in our best interest to allow it. For example, there is a 100% certain way of stopping spam -- unplug the wire. However, the fact that we are all here attests to the fact we deem this too high a cost for the benefit gained. In our case, there are legitimate uses that customers expect to be able to do, and we are unwilling to lose their business. (More below). If a spammer supplies a fraudulent credit card number, they have just committed a crime and can be prosecuted for that. The spam they send out, to be useful, must have a way of contacting them so that leaves a way to track down who they are. If a spammer wants to risk jail time to send out some bulk email, anything I do isn't going to stop him. You don't see junk faxes since it was made illegal. If they do supply their own credit card number, we charge $1 per intended recipient for any outgoing spam. That can quickly cost them more than they get from it and thus serves as a significant disincentive for them to spam.
This frequently occurs when a user accesses a mail server at work from their home dialup account. If other ISPs did this, we would have a problem where a user dialing into their ISP couldn't reach their virtual mail server, hosted on our network. We currently don't have many going the other way, but that may change.
There's no excuse for this. The user should (and must in the proposed plan) use the mail relay operated by the ISP they dial into for *all* outgoing mail.
Ok, a customer is paying for a virtual domain service. They want their outgoing mail to appear as if they are running their own mail server, they don't want people to know they are using someone else for it. If they use their other ISP for SMTP relay, that shows up in the outgoing mail. I agree this is a minor issue for me, but it is not for some of our customers and since the customer is paying the bill, he gets what he wants.
In our case, this doesn't help since we and all the other local ISPs block relay access, so you have to use the mail server of the ISP you are currently connected to.
Exactly, so what's the problem?
I was simply saying that the example the original poster gave wasn't valid, but that there were other examples which explain why it is infeasible to implement blocking all access to port 25 elsewhere. John Tamplin Traveller Information Services jat@Traveller.COM 2104 West Ferry Way 205/883-4233x7007 Huntsville, AL 35801
[ On Thu, October 30, 1997 at 13:42:46 (-0600), John A. Tamplin wrote: ]
Subject: Re: Spam Control Considered Harmful
Ok, a customer is paying for a virtual domain service. They want their outgoing mail to appear as if they are running their own mail server, they don't want people to know they are using someone else for it. If they use their other ISP for SMTP relay, that shows up in the outgoing mail. I agree this is a minor issue for me, but it is not for some of our customers and since the customer is paying the bill, he gets what he wants.
If a customer is paying you for virtual domain service then you'll: a) probably have a much more substantial relationship with the customer than you would with an ordinary dial-up user, and thus much stronger contractual arrangements to ensure they abide by your AUP; and b) be telling those special customers to use a special outgoing mail relay that properly masquerades as the virtual host, i.e. not your generic outgoing mail relay used by your average ordinary dial-up users. -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
On Fri, 31 Oct 1997, Greg A. Woods wrote:
If a customer is paying you for virtual domain service then you'll: a) probably have a much more substantial relationship with the customer than you would with an ordinary dial-up user, and thus much stronger contractual arrangements to ensure they abide by your AUP; and b) be telling those special customers to use a special outgoing mail relay that properly masquerades as the virtual host, i.e. not your generic outgoing mail relay used by your average ordinary dial-up users.
Yes, that is precisely what we do. However, what I pointed out was that if the ISP they dial into blocked all traffic to port 25 elsewhere, as was suggested, then they wouldn't be able to get to their virtual host residing here to send out mail. John Tamplin Traveller Information Services jat@Traveller.COM 2104 West Ferry Way 205/883-4233x7007 Huntsville, AL 35801
[ On Fri, October 31, 1997 at 09:29:11 (-0600), John A. Tamplin wrote: ]
Subject: Re: Spam Control Considered Harmful
Yes, that is precisely what we do. However, what I pointed out was that if the ISP they dial into blocked all traffic to port 25 elsewhere, as was suggested, then they wouldn't be able to get to their virtual host residing here to send out mail.
One easy way around this problem is to forge closer relationships with the ISPs your customers use for connectivity. One of the easiest ways I can think of doing this would be to become a member of a roaming service like iPass and through that become a virtual ISP where you effectively purchase connectivity time from dial-up providers and resell it to your users. Then since you're providing the authentication of your users you can also provide in their profile a list of SMTP relay hosts that they should be permitted to connect to. Your users would then be free to choose to dial into any iPass dial-up provider anywhere in the world at any time without even needing an account opened with the particular dial-up provider they happen to be able to get through to today. -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
On Thu, 30 Oct 1997, Greg A. Woods wrote:
However if you offer cheap dial-up accounts that can be opened either immediately, perhaps with a credit card number, then you've got no real way to establish *any* level of trust with your new customers and indeed the only way you can enforce your AUP is by technical means. I.e. if
If your contract with them states that you will charge their credit card $500 for spamming and they agree to the contract, I'll bet they won't spam from the account. All of a sudden the account is not "throw away" - James D. Wilson netsurf@pixi.com
[ On Fri, October 31, 1997 at 15:09:57 (-1000), netsurf@pixi.com wrote: ]
Subject: Re: Spam Control Considered Harmful
If your contract with them states that you will charge their credit card $500 for spamming and they agree to the contract, I'll bet they won't spam from the account. All of a sudden the account is not "throw away"
That's what I'd like to see indeed! Unfortunately there are lots of more-or-less legal ways out of such things, not to mention the illegal ways. They could easily use a temporary card, or even run it up to the limit before spamming, etc., etc. I too would like to think there are ways to encourage users to follow the AUP, but in the end hard technical limits are still the best. Mabye you have to be like the phone company and charge a $500 deposit on all new accounts until some history has been established that indicates you're at least trustworthy on the surface. -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
I couldn't resist this: On %m %N, "Greg A. Woods" <woods@most.weird.com> wrote: [snip - about charging $500 spam-penalty.] |Mabye you have to be like the phone company and charge a $500 deposit on |all new accounts until some history has been established that indicates |you're at least trustworthy on the surface. They do. Their name is NTT, Its about 670$ (72000yen) per line and your chances of getting it back are nil[1]. this gets you 1 analogue line right. (for a bit more, you can have an ISDN line which is what I have now ..) Peter ----* [1] actually, you can sell your line right, but you wont get the full 72000yen back. -- The Lost Patrol. Level 30~36, HP 800, AC -2. The Highway Patrol of The Random Road, they keep the peace, they eat donuts. -TRR '97 O_u \\ // P-Chan ya \\ Global OnLine Japan U \Beh! \\ // P-Moji-Yo! \\ Steam Engineering
From: Peter Evans <peter@gol.ad.jp> They do. Their name is NTT, Its about 670$ (72000yen) per line and your chances of getting it back are nil[1]. heh, there _are_ a few things i don't miss about japan, and this is one of them. bathrooms that aren't big enough to turn around in are another... :) ---rob
On Wed, Oct 29, 1997 at 03:12:46PM -0800, Dalvenjah FoxFire wrote:
Is there a good reason why the throwway folks (those mentioned above) haven't blocked port 25 from their dialups to the outside internet?
This is on point. As long as the dialup providers do not see fit to impose _some_ sort of filtering on the outgoing mail of their customers, at least until the account is validated, this crap will continue.
The only reason I can think of that would stop this would be if a user subscribes to earthlink, but uses a UUnet dialin, that customer's software would be set up to use the Earthlink SMTP servers.
The instance of multihomed dialup customers can be dealt with without letting throwaway accounts cause the problem that they do, if the providers cared to do so. Personally, I think that blackholing entire commercial providers will solve the problem. I'd use a filter that bounced headers back to postmasters with a note explaining why the filter was in place. In fact, I may well do just this on my system... a Spaminator<tm> is in planning here, and we're not a paid system, so I can get away with more than some folks.
I've currently blocked all of UUnet and PSInet from my mail server - spam about dropped in half. But I'm still getting spam through what appear to be unsuspecting relays - and the source is one of those dialup, throwaway accounts.
See above. Until a concensus is reached on a legal way to force the administrations of these dialup providers to behave in a reasonable, ethical manner (cooperating with people engaging in fradulent behavior, when there's a method with a low bar to entry to avoid it, is unethical), this problem will continue to be of the order of magnitude it currently is. I think it will get fixed the first time some ISP is named as an accessory in a fraud suit, but I don't want to wait that long. Cheers, -- jra -- Jay R. Ashworth jra@baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "Pedantry. It's not just a job, it's an Tampa Bay, Florida adventure." -- someone on AFU +1 813 790 7592
[ On Wed, October 29, 1997 at 15:12:46 (-0800), Dalvenjah FoxFire wrote: ]
Subject: Re: Spam Control Considered Harmful
The only reason I can think of that would stop this would be if a user subscribes to earthlink, but uses a UUnet dialin, that customer's software would be set up to use the Earthlink SMTP servers.
This should only present a minor complexity. If the authentication information can be retrieved from the correct home ISP then there should be no trouble identifying that ISP and adding the right filter to their profile.
Keep in mind again I don't yet know much about how this would impact router performance..but wouldn't one be able to set up access-lists, then, that would allow port-25 connections to a defined list of SMTP servers (say, UUnet, MSN, and earthlink SMTP servers), and prohibit everything else?
One more filter rule in the existing list for preventing IP spoofing shouldn't make any significant difference.
Why aren't they doing this?
Probably because they're not preventing IP spoofing yet either. -- Greg A. Woods +1 416 443-1734 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
participants (15)
-
Barry Shein -
Cal Thixton - President - ThoughtPort Authority of Chicago -
Dalvenjah FoxFire -
Derek Andree -
Jay R. Ashworth -
Joe Shaw -
John A. Tamplin -
johnl＠iecc.com -
Jon Lewis -
NetSurfer -
Peter Evans -
Peter Galbavy -
Phil Lawlor -
Robert E. Seastrom -
woods＠most.weird.com