From Geert.Jan.de.Groot at solair1.inter.NL.net Wed Oct 1 02:43:12 1997 From: Geert.Jan.de.Groot at solair1.inter.NL.net (Geert Jan de Groot) Date: Wed, 1 Oct 1997 02:43:12 +0200 (MET DST) Subject: More on spamming.. Message-ID: <199710010043.CAA00861@solair1.inter.NL.net> People may be interested to read http://maps.vix.com. It is my understanding that this list is also available as a BGP4-feed, so that you can build a blacklist that automatically adjusts to the spammer's moves. This adds more thrust to the effort and keeps support staff costs low (much lower than maintaining a list manually at least). It would be *great* if may ISP's would use this list to make one focused effort which would be more effective than everyone-for-his-own. Geert Jan PS: what's with the European IP numbers on the MAPS RBL? From sh at nwu.de Wed Oct 1 08:44:04 1997 From: sh at nwu.de (Stephan Hermann) Date: Wed, 01 Oct 1997 08:44:04 +0200 Subject: More on spamming.. In-Reply-To: <199710010043.CAA00861@solair1.inter.NL.net> Message-ID: <3.0.3.32.19971001084404.00844250@mail.nwu.de> Good morning from Germany, At 02:43 01.10.97 +0200, Geert Jan de Groot wrote: > >People may be interested to read http://maps.vix.com. It is my understanding >that this list is also available as a BGP4-feed, so that you >can build a blacklist that automatically adjusts to the spammer's >moves. > >This adds more thrust to the effort and keeps support staff costs low >(much lower than maintaining a list manually at least). But, the customers of the ISPs behind this IPs aren't not only spammers. We (Europe ISPs/Local Registries/Local Providers etc.) must begin a discussion, how we can stop those spammers. I think, it's not a solution to build a frontier to the ISPs who are housing such spammers. We must stop those spammers with commercial ideas not with technical solutions such as filtering out IPs with as-path access lists. One (technical) idea can be, to install two smtp server: One, who can only receive mails for known domains and IPs. This SMTP Server use second relay smtp server for delivering the mails to the customers. Customers, especially dial-up customer or uucp-feeds) use this second smtp server for sending mails out. The second smtp server checks a known domain/ip list, only those domains/IPs can send mail through this relay. For the first smtp server anyone can use qmail (http://www.qmail.org/), which has an anti-spam filter (checking some to:/from:/sender:-addresses, so the first smtp server can be used as a filter for customer spamming and don't function as relay for spammers. we're installing in the next weeks such a smtp hirarchie for our servers. we're using qmail for our smtp servers, 'cause it's not mentioned in the CERT advisories I've read. Kind regards, sh -- Stephan Hermann, techn. Leiter Netzwerk u. Telekommunikation eMail: sh at nwu.de NWU Gesellschaft fuer Netzwerke und Telekommunikation mbH Tel.: +49-231-9860143 Heinrichstr. 51, 44536 Luenen FAX : +49-231-9860148 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 355 bytes Desc: not available URL: From nh at iol.ie Wed Oct 1 10:55:57 1997 From: nh at iol.ie (Nick Hilliard) Date: Wed, 1 Oct 1997 09:55:57 +0100 (IST) Subject: More on spamming.. In-Reply-To: <199710010043.CAA00861@solair1.inter.NL.net> from "Geert Jan de Groot" at Oct 1, 97 02:43:12 am Message-ID: <199710010855.JAA17393@beckett.earlsfort.iol.ie> > PS: what's with the European IP numbers on the MAPS RBL? Most of them appear to be sites who were used as 3rd party relay hosts. Nick From amb at gxn.net Wed Oct 1 11:13:56 1997 From: amb at gxn.net (Alex Bligh) Date: Wed, 01 Oct 1997 10:13:56 +0100 Subject: More on spamming.. In-Reply-To: Your message of "Wed, 01 Oct 1997 08:44:04 +0200." <3.0.3.32.19971001084404.00844250@mail.nwu.de> Message-ID: <199710010913.KAA28046@diamond.xara.net> Stephan Hermann wrote: > At 02:43 01.10.97 +0200, Geert Jan de Groot wrote: > >People may be interested to read http://maps.vix.com. It is my understanding > > I think, it's not a solution to build a frontier to the ISPs who are > housing such spammers. We must stop those spammers with commercial ideas > not with technical solutions such as filtering out IPs with as-path access > lists. Um, please read how the list works - it doesn't use as-path access list. It sends /32 routes (normally) for specific hosts which orginate spam, and transiently for specific relays currently being used to propogate spam. Sure it's no defence, but every 3rd party (and, in one instance, a customer - tut tut) who has been on this list and complained about lack of connectivity to my network has since fixed their mail relay not to forward spam (we take the feed). It's very effective at reducing the amount of spam you get (at least for those zones which don't have topologically distant backup MX). > One (technical) idea can be, to install two smtp server: All this does is stop you relaying. You can do this on one server with the no relay patches on http://www.sendmail.org/ if you can get the IP address stuff to work right, though we use two servers for other reasons. -- Alex Bligh GX Networks (formerly Xara Networks) From sa at hogia.net Wed Oct 1 11:28:16 1997 From: sa at hogia.net (Sebastian Andersson) Date: Wed, 1 Oct 1997 11:28:16 +0200 (MET DST) Subject: More on spamming.. In-Reply-To: <3.0.3.32.19971001084404.00844250@mail.nwu.de> Message-ID: On Wed, 1 Oct 1997, Stephan Hermann wrote: > One (technical) idea can be, to install two smtp server: > One, who can only receive mails for known domains and IPs. > This SMTP Server use second relay smtp server for delivering the mails to > the customers. This would require a way to distribute which domains belong to which IP number and this alone is a huge technical and administrative problem which would make it hard to be solved. Considering that each person wants their own domain these days to get a "cool" e-mail/webserver address you will have to have a list of more than 10 million domains and some domains use more than one outgoing mailserver so you will probably have to store at least 8 bytes of address info (in IPv4) per domain. If you also want fast lookups in this database you'll have to add space for some huge indexes (50% extra?). But while we are talking about fundamental technical changes to the SMTP standard, why not simply add an digital signature to each mail your SMTP server guarentees to be spamfree, your public key could be sent out via the DNS and it should be signed by a trusted third party (like RIPE). Each SMTP server that don't want to recieve spam, simply filters away all mail without a signature, with an incorrect signature or those that have a signature from an untrusted SMTP server. To get your public key signed by the trusted parties, you have to sign a contract there you guarentee not to send spam through this SMTP server. Those that use your SMTP server as a relay would obviously have to sign such a contract with you. Old SMTP clients (without spam protection) can still recieve all their mail (they'll not list the signature command in their EHLO response) but they will have to relay their mail via some new SMTP server. Most ISPs use sendmail today and if the support was added to sendmail most internet connected sites could relay their mail through their provider if the provider can authenticate their client. I am far from a legal expert but I don't think there are many countries there it is illegal to digitaly sign a message as long as the plaintext is provided with the encrypted data or it is known how to produce the plaintext and verify that the plaintext and the data is the same. Some facist countries prevent their citizens to export implementations of well known cryptoalgorithms (and to use some algorithms because of different patents) so the sendmail patch would probably have to be implemented in a free country where people are not prevented from exporting the patch or the patch could be based on one of the well known crypto programs like PGP or SSLeay, which in turn would have to be gotten from different places depending on the laws of the target language. > For the first smtp server anyone can use qmail (http://www.qmail.org/), > which has an anti-spam filter (checking some to:/from:/sender:-addresses, > so the first smtp server can be used as a filter for customer spamming and > don't function as relay for spammers. Even though I myself prefer qmail I must say that it can be added to sendmail quite easily (once you've banged your head against the batbook enough...). There are links to these rules from www.sendmail.org. /Sebastian See http://www.hogia.net/keys/sa-pgp.asc for public pgp key. From sh at nwu.de Wed Oct 1 11:51:38 1997 From: sh at nwu.de (Stephan Hermann) Date: Wed, 01 Oct 1997 11:51:38 +0200 Subject: More on spamming.. In-Reply-To: <199710010913.KAA28046@diamond.xara.net> References: Message-ID: <3.0.3.32.19971001115138.0083e7e0@mail.nwu.de> Hi, At 10:13 01.10.97 +0100, Alex Bligh wrote: >Stephan Hermann wrote: >> At 02:43 01.10.97 +0200, Geert Jan de Groot wrote: >> >People may be interested to read http://maps.vix.com. It is my understanding >> >> I think, it's not a solution to build a frontier to the ISPs who are >> housing such spammers. We must stop those spammers with commercial ideas >> not with technical solutions such as filtering out IPs with as-path access >> lists. > >Um, please read how the list works - it doesn't use as-path access list. >It sends /32 routes (normally) for specific hosts which orginate spam, >and transiently for specific relays currently being used to propogate >spam. Well...how can I filter hosts out, which are connected dynamically. The most spams I get, are from several IPs which are dial-up customers of (well known) ISPs in USA. Sure, I can stop them, if I know the whole subnet for the dial-in servers from the ISPs. I can filter out the relay hosts, ok...but our customers gets e.g. mail from customers of sprint, and I block the incoming connection from customer-mail-relay.sprint.net (e.g.!!!). Well...then I can go and close my business ;) No, if we want to stop those spammers, the logical idea is, that all ISPs which are housing such spammers must ban them from their servers. They must disconnect every PoP, which is housing such spam customers. Well, in Germany we have several problems with aol germany and t-online (a service by Deutsche Telekom). What can we do ? Block the connections to aol.com ? block the connections to t-online ? if I do that, I'm going to get so much angry mails from my customers, that I wish: "Give me Spams..but no more mails from my customers". I don't know the situation in other countries, but blocking is not the answer of our problem. We must find an answer, in a quite "commercial sense". Those people, IMHO, stop spamming, if they get an invoice for IP traffic or a letter from our lawyer. >Sure it's no defence, but every 3rd party (and, in one instance, >a customer - tut tut) who has been on this list and complained about >lack of connectivity to my network has since fixed their mail relay not >to forward spam (we take the feed). It's very effective at reducing >the amount of spam you get (at least for those zones which don't >have topologically distant backup MX). well..some of the customers wants to get those mails (yes...it's the truth...I don't know why, I think they're happy to receive email ;)) The only way to stop this is, to get a position in the contract between service provider and PoP, or between service provider and customers, that the PoP and/or the customer are billed for such traffic. You know, "money makes the world go round". > >> One (technical) idea can be, to install two smtp server: > >All this does is stop you relaying. You can do this on one server >with the no relay patches on > http://www.sendmail.org/ >if you can get the IP address stuff to work right, though we use >two servers for other reasons. well...we're changing our internal network to a secure server network (SSN). So, my second smtp server is in this SSN and the first smtp server is in front of that network. so, our second smtp can go out, but no one can get in and use my second smtp for relaying :) ReadU, sh -- Stephan Hermann, techn. Leiter Netzwerk u. Telekommunikation eMail: sh at nwu.de NWU Gesellschaft fuer Netzwerke und Telekommunikation mbH Tel.: +49-231-9860143 Heinrichstr. 51, 44536 Luenen FAX : +49-231-9860148 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 355 bytes Desc: not available URL: From prt at prt.org Wed Oct 1 12:52:07 1997 From: prt at prt.org (Paul Thornton) Date: Wed, 1 Oct 1997 11:52:07 +0100 (BST) Subject: More on spamming.. In-Reply-To: <199710010913.KAA28046@diamond.xara.net> Message-ID: On Wed, 1 Oct 1997, Alex Bligh wrote: > All this does is stop you relaying. You can do this on one server > with the no relay patches on > http://www.sendmail.org/ > if you can get the IP address stuff to work right, though we use > two servers for other reasons. I have to agree with Alex here. If we can persuade ISPs (and customers who have mail servers which can relay) to fix their configurations to deny relaying except for their own hosts/networks then we have made a big step forward. Spammers tend to rely on having an innocent 3rd party's relay - it makes the irate recipients flame the postmaster at that site, not them. -- Paul -= Paul Thornton, 2 Durnford Way, Cambridge, CB4 2DP, UK. +44 1223 575384 =- From mjaw at ikp.ikp.pl Sat Oct 4 02:58:43 1997 From: mjaw at ikp.ikp.pl (Miroslaw Jaworski) Date: Wed, 1 Oct 1997 12:58:43 -6000 Subject: More on spamming.. In-Reply-To: <97Oct1.105457met.14341@gateway.hq.atm.com.pl> Message-ID: On Wed, 1 Oct 1997, Stephan Hermann wrote: > from the ISPs. > I can filter out the relay hosts, ok...but our customers gets e.g. mail > from customers of sprint, and I block the incoming connection from > customer-mail-relay.sprint.net (e.g.!!!). Well...then I can go and close my > business ;) > > No, if we want to stop those spammers, the logical idea is, that all ISPs > which are housing such spammers must ban them from their servers. They must > disconnect every PoP, which is housing such spam customers. yea... close all PoP's and "I can go and close my business ;)" I don't know how it is in other countries but here most of the customers are POP users. Direct lines ? Geee.. Only bigger companies can afford it. So when u get a spam, its from dial-line. most often.try to find who was it ? > Well, in Germany we have several problems with aol germany and t-online (a > service by Deutsche Telekom). What can we do ? Block the connections to > aol.com ? block the connections to t-online ? there is an ISP called Polbox here in Poland. they've got about 50 000 accounts ( people says that ). all these accounts are for free. people can get their www for free too... U can imagine what kind of people are on this server ( free.polbox.pl ). > if I do that, I'm going to get so much angry mails from my customers, that > I wish: "Give me Spams..but no more mails from my customers". I don't know > the situation in other countries, but blocking is not the answer of our > problem. exactly. appropiate filters should be huge... > We must find an answer, in a quite "commercial sense". Those people, IMHO, > stop spamming, if they get an invoice for IP traffic or a letter from our > lawyer. or there is another solution: if all administrators will be consequent ( is it right word ? ), and not to give accounts to people who are on "Great Index of Spammers - year XXXX". :))) but this happens only in heaven :( > well..some of the customers wants to get those mails (yes...it's the > truth...I don't know why, I think they're happy to receive email ;)) :))))) > The only way to stop this is, to get a position in the contract between > service provider and PoP, or between service provider and customers, that > the PoP and/or the customer are billed for such traffic. > You know, "money makes the world go round". special fees for spamming ? :) > >> One (technical) idea can be, to install two smtp server: > > > >All this does is stop you relaying. You can do this on one server > >with the no relay patches on > > http://www.sendmail.org/ > >if you can get the IP address stuff to work right, though we use > >two servers for other reasons. > > well...we're changing our internal network to a secure server network > (SSN). So, my second smtp server is in this SSN and the first smtp server > is in front of that network. so, our second smtp can go out, but no one can > get in and use my second smtp for relaying :) yes, but his is solution for a company not for ISP [ when u are at end of line ]. not when u've got connection to 2 or more AS's. Miroslaw Jaworski ___________________________________________________________________________ Miroslaw.Jaworski at ikp.com.pl (Psyborg) MJ102-RIPE ATM S.A. - IKP division WAN/UNIX adm From mjaw at ikp.ikp.pl Sat Oct 4 03:02:18 1997 From: mjaw at ikp.ikp.pl (Miroslaw Jaworski) Date: Wed, 1 Oct 1997 13:02:18 -6000 Subject: More on spamming.. In-Reply-To: <97Oct1.115138met.14341@gateway.hq.atm.com.pl> Message-ID: On Wed, 1 Oct 1997, Paul Thornton wrote: > I have to agree with Alex here. If we can persuade ISPs (and customers who > have mail servers which can relay) to fix their configurations to deny > relaying except for their own hosts/networks then we have made a big step > forward. but it still doesn't solve problem of spamming. MJ ___________________________________________________________________________ Miroslaw.Jaworski at ikp.com.pl (Psyborg) MJ102-RIPE ATM S.A. - IKP division WAN/UNIX adm From amb at gxn.net Wed Oct 1 13:09:53 1997 From: amb at gxn.net (Alex Bligh) Date: Wed, 01 Oct 1997 12:09:53 +0100 Subject: More on spamming.. In-Reply-To: Your message of "Wed, 01 Oct 1997 13:02:18." Message-ID: <199710011109.MAA02064@diamond.xara.net> > On Wed, 1 Oct 1997, Paul Thornton wrote: > > > I have to agree with Alex here. If we can persuade ISPs (and customers who > > have mail servers which can relay) to fix their configurations to deny > > relaying except for their own hosts/networks then we have made a big step > > forward. > > but it still doesn't solve problem of spamming. Long term: It doesn't solve it, but it helps it. One of the main problems is traceability. IE you don't know where the spam has come from. If noone third-party relayed, then when my users get spam, I'd know the IP address of the machine it came from originally. This would be good. Another necessary fix is for ISPs to keep record of which user had which IP address at any given time, and to keep contact details for all their users (this is desirable for secuirity and legal reasons too). If you build these two things together with a term in peering agreements that classifies spam abuse in a similar manner to the way most agreements currently classify security problems (i.e. mutual terms for traceability and action), and one hopes that similar terms are already in place in transit agreements, then one should be better able to get spammers removed. Short term: The other more obvious reason why it helps in the short term is that in conjunction with a realtime BGP feed like that on http://maps.vix.com, you (a) ensure that you have no 3rd party relayed spam, and (b) have the addresses of many commercial spammers blackholed. Of course they move IP addresses, but the larger ones soon get their networks blocked as a whole. Then they have to go back to their provider to change IPs. Eventually the provider will become bored of this (vz. Cyberpromo & AGIS). But it *does* reduce the amount of spam. -- Alex Bligh GX Networks (formerly Xara Networks) From neil at COLT.NET Wed Oct 1 13:08:01 1997 From: neil at COLT.NET (Neil J. McRae) Date: Wed, 01 Oct 1997 12:08:01 +0100 Subject: More on spamming.. In-Reply-To: Your message of "Wed, 01 Oct 1997 13:02:18." Message-ID: <199710011108.MAA15407@NetBSD.noc.COLT.NET> On Wed, 1 Oct 1997 13:02:18 -6000 Miroslaw Jaworski wrote: > On Wed, 1 Oct 1997, Paul Thornton wrote: > > > I have to agree with Alex here. If we can persuade ISPs (and customers who > > have mail servers which can relay) to fix their configurations to deny > > relaying except for their own hosts/networks then we have made a big step > > forward. > > but it still doesn't solve problem of spamming. > I doubt that you'll ever solve this problem fully, and to be honest you'd have to live in cloud cuckoo land if you thought you could stop spam in a single step. What is suggested is that pressure or advice is given to people so that they stop having open email relays. If enough people do this then the spammer has one less way to spam the world and steal network resources. [i.e. it will cost the spammer money, and the average spammer doesn't like that]. Regards, Neil. -- Neil J. McRae - Alive and Kicking. C O L T I N T E R N E T neil at COLT.NET Ascend GRF: 100% CpF [Cisco protection Factor] Free the daemon in your computer! From peppo at inet.it Wed Oct 1 13:10:32 1997 From: peppo at inet.it (Peppino Anselmi) Date: Wed, 1 Oct 1997 13:10:32 +0200 (MET DST) Subject: More on spamming.. In-Reply-To: from "Miroslaw Jaworski" at Oct 1, 97 01:02:18 pm Message-ID: <199710011110.NAA25550@saturno.inet.it> > > On Wed, 1 Oct 1997, Paul Thornton wrote: > > > I have to agree with Alex here. If we can persuade ISPs (and customers who > > have mail servers which can relay) to fix their configurations to deny > > relaying except for their own hosts/networks then we have made a big step > > forward. > > but it still doesn't solve problem of spamming. > > MJ My opinion is that this mail exchange is much more dangerous and boring than the spam itself. More then half of the messages I get is about spamming. Bye Peppo > ___________________________________________________________________________ > Miroslaw.Jaworski at ikp.com.pl (Psyborg) MJ102-RIPE ATM S.A. - IKP division > WAN/UNIX adm > From mjaw at ikp.ikp.pl Sat Oct 4 03:18:05 1997 From: mjaw at ikp.ikp.pl (Miroslaw Jaworski) Date: Wed, 1 Oct 1997 13:18:05 -6000 Subject: More on spamming.. In-Reply-To: <199710011108.MAA15407@NetBSD.noc.COLT.NET> Message-ID: On Wed, 1 Oct 1997, Neil J. McRae wrote: > I doubt that you'll ever solve this problem fully, and to be honest > you'd have to live in cloud cuckoo land if you thought you could stop > spam in a single step. everything is hard. [ "Not for first time was built Krakow" ] > What is suggested is that pressure or advice is given to people so > that they stop having open email relays. i agree that this is the very first one what people should do. > network resources. [i.e. it will cost the spammer money, and the average > spammer doesn't like that]. hmmm from my point of view it will cost MY money (ISP) not real spammer. when spam will have as source address my network 157.25.0.0/16, u mean that i am this spammer ? MJ ___________________________________________________________________________ Miroslaw.Jaworski at ikp.com.pl (Psyborg) MJ102-RIPE ATM S.A. - IKP division WAN/UNIX adm From neil at COLT.NET Wed Oct 1 13:22:48 1997 From: neil at COLT.NET (Neil J. McRae) Date: Wed, 01 Oct 1997 12:22:48 +0100 Subject: More on spamming.. In-Reply-To: Your message of "Wed, 01 Oct 1997 13:18:05." Message-ID: <199710011122.MAA15510@NetBSD.noc.COLT.NET> On Wed, 1 Oct 1997 13:18:05 -6000 Miroslaw Jaworski wrote: > hmmm from my point of view it will cost MY money (ISP) not real spammer. Thats all academic, there will always be someone trying to spem you, if you reduce the ways this is possible then you help to reduce the spam, longer term it reduces costs in theft of network resources. > > when spam will have as source address my network 157.25.0.0/16, u mean > that i am this spammer ? > Obviously not, but you could help us in tracking any such offender, and help put a stop to it, InterISP co-ordination is important, and I'd guess thats why organisations like RIPE, LINX and so on, are keen to be a focal point for action. Regards, Neil -- Neil J. McRae - Alive and Kicking. C O L T I N T E R N E T neil at COLT.NET Ascend GRF: 100% CpF [Cisco protection Factor] Free the daemon in your computer! From sh at nwu.de Wed Oct 1 13:24:53 1997 From: sh at nwu.de (Stephan Hermann) Date: Wed, 01 Oct 1997 13:24:53 +0200 Subject: More on spamming.. In-Reply-To: References: <97Oct1.105457met.14341@gateway.hq.atm.com.pl> Message-ID: <3.0.3.32.19971001132453.007af100@mail.nwu.de> Hi, At 12:58 01.10.97 -6000, Miroslaw Jaworski wrote: >On Wed, 1 Oct 1997, Stephan Hermann wrote: > >> from the ISPs. >> I can filter out the relay hosts, ok...but our customers gets e.g. mail >> from customers of sprint, and I block the incoming connection from >> customer-mail-relay.sprint.net (e.g.!!!). Well...then I can go and close my >> business ;) >> >> No, if we want to stop those spammers, the logical idea is, that all ISPs >> which are housing such spammers must ban them from their servers. They must >> disconnect every PoP, which is housing such spam customers. > >yea... close all PoP's and "I can go and close my business ;)" Nono..disconnecting, not closing. If any PoPs of an ISP (such as our PoPs), are housing those spammers, I would disconnect them...if it's an problem with their smtp server...well I help them to close it for spams :) > >I don't know how it is in other countries but here most of the customers >are POP users. Direct lines ? Geee.. Only bigger companies can afford it. >So when u get a spam, its from dial-line. most often.try to find who was >it ? well, in USA the leased lines are very cheap, I think many spammers have leased lines to cheap PoPs/ISPs. >> Well, in Germany we have several problems with aol germany and t-online (a >> service by Deutsche Telekom). What can we do ? Block the connections to >> aol.com ? block the connections to t-online ? > >there is an ISP called Polbox here in Poland. they've got about 50 000 >accounts ( people says that ). all these accounts are for free. >people can get their www for free too... >U can imagine what kind of people are on this server ( free.polbox.pl ). Yes :) >> We must find an answer, in a quite "commercial sense". Those people, IMHO, >> stop spamming, if they get an invoice for IP traffic or a letter from our >> lawyer. > >or there is another solution: >if all administrators will be consequent ( is it right word ? ), and not >to give accounts to people who are on "Great Index of Spammers - year >XXXX". :))) >> The only way to stop this is, to get a position in the contract between >> service provider and PoP, or between service provider and customers, that >> the PoP and/or the customer are billed for such traffic. >> You know, "money makes the world go round". > >special fees for spamming ? :) Well..."commercial sense" I mean: a letter from my lawyer...increasing the charges for the connection or something like that. take the money from the people who are using the net for their unsocialize things, and they are crying. Money is the only thing they want to make, and money is the only thing you let them stop. Net Charging Rates for those business (especially many "hardcore"-businesses) must be high...and metaprovider like sprint, uunet and of course every isp who is connected through them, must increase those rates for those customers. you know what I want to say ? >> well...we're changing our internal network to a secure server network >> (SSN). So, my second smtp server is in this SSN and the first smtp server >> is in front of that network. so, our second smtp can go out, but no one can >> get in and use my second smtp for relaying :) > >yes, but his is solution for a company not for ISP [ when u are at end of >line ]. not when u've got connection to 2 or more AS's. Nono..our internal network == my own network to provide access for our customers. For our PoPs we cannot solve the spam probblem, we can help them to stop this problem, but we're not the parents of our PoPs admins ;) they must close their smtp themself. only for our internal network (with dial-in ports and the whole crap you need for providing ;)) ReadU, sh -- Stephan Hermann, techn. Leiter Netzwerk u. Telekommunikation eMail: sh at nwu.de NWU Gesellschaft fuer Netzwerke und Telekommunikation mbH Tel.: +49-231-9860143 Heinrichstr. 51, 44536 Luenen FAX : +49-231-9860148 From neil at COLT.NET Wed Oct 1 13:24:36 1997 From: neil at COLT.NET (Neil J. McRae) Date: Wed, 01 Oct 1997 12:24:36 +0100 Subject: More on spamming.. In-Reply-To: Your message of "Wed, 01 Oct 1997 13:10:32 +0200." <199710011110.NAA25550@saturno.inet.it> Message-ID: <199710011124.MAA15533@NetBSD.noc.COLT.NET> On Wed, 1 Oct 1997 13:10:32 +0200 (MET DST) Peppino Anselmi wrote: > My opinion is that this mail exchange is much more dangerous and boring > than the spam itself. And opinions are like arseholes - everybody has one. As for this exchange if more people prevented spam [and its not hard work] then you wouldn't have to real this "dangerous and boring mail exchange". -- Neil J. McRae - Alive and Kicking. C O L T I N T E R N E T neil at COLT.NET Ascend GRF: 100% CpF [Cisco protection Factor] Free the daemon in your computer! From chris at freedom2surf.net Wed Oct 1 13:41:57 1997 From: chris at freedom2surf.net (Chris Panayis) Date: Wed, 1 Oct 1997 12:41:57 +0100 Subject: More on spamming.. Message-ID: <21A42D5A9C95D011A7FC00A0246811DA084C13@kick.freedom2surf.net> We do not allow external mail relaying and encourage our customers to do the same. Is this the same for the big ISPs too? Regards Chris Panayis Freedom To Surf plc From sh at nwu.de Wed Oct 1 13:45:32 1997 From: sh at nwu.de (Stephan Hermann) Date: Wed, 01 Oct 1997 13:45:32 +0200 Subject: More on spamming.. In-Reply-To: <199710011124.MAA15533@NetBSD.noc.COLT.NET> References: Message-ID: <3.0.3.32.19971001134532.007a2540@mail.nwu.de> howdy, At 12:24 01.10.97 +0100, Neil J. McRae wrote: >On Wed, 1 Oct 1997 13:10:32 +0200 (MET DST) > Peppino Anselmi wrote: > >> My opinion is that this mail exchange is much more dangerous and boring >> than the spam itself. > >And opinions are like arseholes - everybody has one. As for this exchange if >more people prevented spam [and its not hard work] then you wouldn't have >to real this "dangerous and boring mail exchange". hey, calm down...:) we can switch from local-ir ML to another ML for such purposes (technical nature etc.) Questions: Is there a working-group for anti-spam discussions ??? if not, should we make one ? Cu, sh -- Stephan Hermann, techn. Leiter Netzwerk u. Telekommunikation eMail: sh at nwu.de NWU Gesellschaft fuer Netzwerke und Telekommunikation mbH Tel.: +49-231-9860143 Heinrichstr. 51, 44536 Luenen FAX : +49-231-9860148 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 355 bytes Desc: not available URL: From mrr at norway.eu.net Wed Oct 1 14:01:11 1997 From: mrr at norway.eu.net (Morten Reistad) Date: Wed, 01 Oct 1997 14:01:11 +0200 Subject: More on spamming.. In-Reply-To: Your message of "Wed, 01 Oct 1997 12:09:53 BST." <199710011109.MAA02064@diamond.xara.net> Message-ID: <199710011201.OAA27443@kirov.eunet.no> In message <199710011109.MAA02064 at diamond.xara.net>, Alex Bligh writes: > > On Wed, 1 Oct 1997, Paul Thornton wrote: > > > > > I have to agree with Alex here. If we can persuade ISPs (and customers who > > > have mail servers which can relay) to fix their configurations to deny > > > relaying except for their own hosts/networks then we have made a big step > > > forward. > > > > but it still doesn't solve problem of spamming. > > Long term: > > It doesn't solve it, but it helps it. One of the main problems is > traceability. IE you don't know where the spam has come from. If > noone third-party relayed, then when my users get spam, I'd know the > IP address of the machine it came from originally. This would be > good. Another necessary fix is for ISPs to keep record of which > user had which IP address at any given time, and to keep contact > details for all their users (this is desirable for secuirity and > legal reasons too). This is elementary; know who your customers are and what they are doing with your infrastructre. > If you build these two things together with > a term in peering agreements that classifies spam abuse in a similar > manner to the way most agreements currently classify security > problems (i.e. mutual terms for traceability and action), and > one hopes that similar terms are already in place in transit > agreements, then one should be better able to get spammers > removed. Almost all peering on the Internet today is 'soft'; in that it is 'just packets' that is moved. If we are to get tough on enforcing this we'll need lawyer-based peering aggreements. Remember the Internet of 1993 ? How fearful we all were about getting such 'firm' peering aggreements, because it would force us into a PTT-stand on almost all the models of pricing, transit etc. that the Internet Community loathed (does it still?). Are we ready for the 'firm' peering aggreement ? > > Short term: > > The other more obvious reason why it helps in the short term > is that in conjunction with a realtime BGP feed like that > on http://maps.vix.com, you (a) ensure that you have no 3rd > party relayed spam, and (b) have the addresses of many commercial > spammers blackholed. Of course they move IP addresses, but the > larger ones soon get their networks blocked as a whole. Then > they have to go back to their provider to change IPs. Eventually > the provider will become bored of this (vz. Cyberpromo & AGIS). > But it *does* reduce the amount of spam. The other way is to keep up the self-justice. Drop the peering with the bozo generating the spam. > > > > -- > Alex Bligh > GX Networks (formerly Xara Networks) > > -- ___ === / / / __ ___ _/_ === Morten Reistad, Network Manager === /--- / / / / /__/ / === EUnet Norway AS, Sandakerveien 64, Oslo === /___ /__/ / / /__ / === === Connecting Europe since 1982 === phone +47 2209 2940 From phk at critter.freebsd.dk Wed Oct 1 14:07:29 1997 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Wed, 01 Oct 1997 14:07:29 +0200 Subject: More on spamming.. In-Reply-To: Your message of "Wed, 01 Oct 1997 13:45:32 +0200." <3.0.3.32.19971001134532.007a2540@mail.nwu.de> Message-ID: <1898.875707649@critter.freebsd.dk> >we can switch from local-ir ML to another ML for such purposes (technical >nature etc.) >Questions: Is there a working-group for anti-spam discussions ??? if not, >should we make one ? Yes, we should. -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." From sh at nwu.de Wed Oct 1 14:16:55 1997 From: sh at nwu.de (Stephan Hermann) Date: Wed, 01 Oct 1997 14:16:55 +0200 Subject: More on spamming.. In-Reply-To: <1898.875707649@critter.freebsd.dk> References: Message-ID: <3.0.3.32.19971001141655.0083a930@mail.nwu.de> Hi, At 14:07 01.10.97 +0200, Poul-Henning Kamp wrote: >>we can switch from local-ir ML to another ML for such purposes (technical >>nature etc.) >>Questions: Is there a working-group for anti-spam discussions ??? if not, >>should we make one ? > >Yes, we should. Ok, I'm installing tonight the majordomo to a special machine (my home machine)...I make the address public to all on this list. who wants to subscribe is welcome :) ReadU, sh -- Stephan Hermann, techn. Leiter Netzwerk u. Telekommunikation eMail: sh at nwu.de NWU Gesellschaft fuer Netzwerke und Telekommunikation mbH Tel.: +49-231-9860143 Heinrichstr. 51, 44536 Luenen FAX : +49-231-9860148 From sh at nwu.de Wed Oct 1 14:17:26 1997 From: sh at nwu.de (Stephan Hermann) Date: Wed, 01 Oct 1997 14:17:26 +0200 Subject: More on spamming.. In-Reply-To: <199710011109.MAA02064@diamond.xara.net> References: Message-ID: <3.0.3.32.19971001141726.00808e60@mail.nwu.de> Hi, At 12:09 01.10.97 +0100, Alex Bligh wrote: >Long term: > >It doesn't solve it, but it helps it. One of the main problems is >traceability. IE you don't know where the spam has come from. If >noone third-party relayed, then when my users get spam, I'd know the >IP address of the machine it came from originally. This would be >good. Another necessary fix is for ISPs to keep record of which >user had which IP address at any given time, and to keep contact >details for all their users (this is desirable for secuirity and >legal reasons too). If you build these two things together with >a term in peering agreements that classifies spam abuse in a similar >manner to the way most agreements currently classify security >problems (i.e. mutual terms for traceability and action), and >one hopes that similar terms are already in place in transit >agreements, then one should be better able to get spammers >removed. But what, when there are laws, which disallow such loggins like IP Address <-> Username at a specific time for a long time ? Cu, sh -- Stephan Hermann, techn. Leiter Netzwerk u. Telekommunikation eMail: sh at nwu.de NWU Gesellschaft fuer Netzwerke und Telekommunikation mbH Tel.: +49-231-9860143 Heinrichstr. 51, 44536 Luenen FAX : +49-231-9860148 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 355 bytes Desc: not available URL: From gert at Space.Net Wed Oct 1 14:18:08 1997 From: gert at Space.Net (gert at Space.Net) Date: Wed, 1 Oct 1997 14:18:08 +0200 (MET DST) Subject: More on spamming.. In-Reply-To: <1898.875707649@critter.freebsd.dk> from Poul-Henning Kamp at "Oct 1, 97 02:07:29 pm" Message-ID: <19971001121808.28582.qmail@moebius.space.net> Hi, Poul-Henning Kamp wrote: > >we can switch from local-ir ML to another ML for such purposes (technical > >nature etc.) > >Questions: Is there a working-group for anti-spam discussions ??? if not, > >should we make one ? > > Yes, we should. I second this. Gert Doering -- NetMaster -- SpaceNet GmbH Mail: netmaster at Space.Net Frankfurter Ring 193a Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From amb at gxn.net Wed Oct 1 14:24:00 1997 From: amb at gxn.net (Alex Bligh) Date: Wed, 01 Oct 1997 13:24:00 +0100 Subject: More on spamming.. In-Reply-To: Your message of "Wed, 01 Oct 1997 14:01:11 +0200." <199710011201.OAA27443@kirov.eunet.no> Message-ID: <199710011224.NAA05093@diamond.xara.net> > > Another necessary fix is for ISPs to keep record of which > > user had which IP address at any given time, and to keep contact > > details for all their users (this is desirable for secuirity and > > legal reasons too). > > This is elementary; know who your customers are and what they > are doing with your infrastructre. If you keep all your servers time sync'd and keep full Radius accounting records, yes, you can translate an (IP address, time) pair into a username. Some ISPs can do this reliably. Many don't. Seconds may well matter. The next problem is to associate that user name with a person. Dead easy you may think. But the user may claim that someone else has been using their account. Thus you also need to log CLI (calling number identity), which in turn means your telecom provider has to present it. The ISP must also have a policy on what to do with withheld or unavailable CLI. So while this seems simple, actually it isn't. Very few ISPs actually do the whole of this (IMHO). > > If you build these two things together with > > a term in peering agreements that classifies spam abuse in a similar > > manner to the way most agreements currently classify security > > problems (i.e. mutual terms for traceability and action), and > > one hopes that similar terms are already in place in transit > > agreements, then one should be better able to get spammers > > removed. > > Almost all peering on the Internet today is 'soft'; in that > it is 'just packets' that is moved. If we are to get tough on > enforcing this we'll need lawyer-based peering aggreements. Mmmm... About 30% of my US peers have paper based agreements. Most of them (probably all) have security based agreements, but ... > Remember the Internet of 1993 ? How fearful we all were about > getting such 'firm' peering aggreements, ... wasn't most of the fear about a price being attached to them? (for exactly the reasons you state below). The academic networks have always had AUPs you are expected to abide by to some extent as peers. JANET in the UK being a good example. > because it would > force us into a PTT-stand on almost all the models of pricing, > transit etc. that the Internet Community loathed (does it still?). > > Are we ready for the 'firm' peering aggreement ? I think this is largely orthogonal. You can equally well implement the "if you don't track down spam, we'll cease this arrangement" in an email based, lawyer-free peering environment. And you make this point yourself below (*), My personal view is that firm peering agreements are inevitable. But this is another issue entirely. (*) - > The other way is to keep up the self-justice. Drop the peering > with the bozo generating the spam. -- Alex Bligh GX Networks (formerly Xara Networks) From mvalente at esoterica.pt Wed Oct 1 12:29:45 1997 From: mvalente at esoterica.pt (Mario Valente) Date: Wed, 01 Oct 1997 11:29:45 +0100 Subject: More on spamming.. In-Reply-To: <3.0.3.32.19971001115138.0083e7e0@mail.nwu.de> References: <199710010913.KAA28046@diamond.xara.net> Message-ID: <3.0.3.32.19971001112945.0072e438@mail.esoterica.pt> >>> I think, it's not a solution to build a frontier to the ISPs who are >>> housing such spammers. We must stop those spammers with commercial ideas >>> not with technical solutions such as filtering out IPs with as-path access >>> lists. >> >>Um, please read how the list works - it doesn't use as-path access list. >>It sends /32 routes (normally) for specific hosts which orginate spam, >>and transiently for specific relays currently being used to propogate >>spam. > >Well...how can I filter hosts out, which are connected dynamically. The >most spams I get, are from several IPs which are dial-up customers of (well >known) ISPs in USA. I'm going to describe once again how were dealing with spam. We've installed sendmail (latest) with several patches, namely the no relay patch (unless the host is listed as allowed to use the relay) and also patches for checking the existence of the From and To addresses. We have a daemon on the background scanning the mail log. We accept mail from everywhere, anyplace. As long as its one message at a time or within a reasonable interval. If a spam is detected (several incoming messages from the same domain, or from "weird domains" like cyberpromo.com, 344234.com, etc we just use the packet filtering capabilities of Linux to refuse packets from the incoming IP address doing the spam. About 15 minutes later the daemon cleans up the IP filters in existence and rescans the mail log. This means that an ongoing spam will be continually blocked. It also means that instead of refusing the message, or sending back an error, or whatever, the spammer thinks that the server is out of reach, the network is not working, the server is not responding, etc stopping him from retaliation measures like we had in the past from spammers who got mad with us stopping them with other techniques. Mail from every domain is always accepted, even from well known spammers. They are able to get messages through, as long as they arent patterned. If they are they will be able to send 4 or 5 of them, but them the server will be unreachable. C U! -- Mario Valente From andre at pipeline.ch Wed Oct 1 14:49:33 1997 From: andre at pipeline.ch (IBS / Andre Oppermann) Date: Wed, 01 Oct 1997 14:49:33 +0200 Subject: More on spamming.. References: <199710010913.KAA28046@diamond.xara.net> <3.0.3.32.19971001112945.0072e438@mail.esoterica.pt> Message-ID: <343246DD.AF23C9D0@pipeline.ch> Can you make this code public (for RIPE ISP's - BSD license or GPL)? Mario Valente wrote: -snip- > We have a daemon on the background scanning the mail log. We accept > mail from everywhere, anyplace. As long as its one message at a time -snip- -- Andre Oppermann CEO / Geschaeftsfuehrer Internet Business Solutions Ltd. (AG) Hardstrasse 235, 8005 Zurich, Switzerland Fon +41 1 277 75 75 / Fax +41 1 277 75 77 http://www.pipeline.ch ibs at pipeline.ch From mjaw at ikp.ikp.pl Sat Oct 4 04:59:40 1997 From: mjaw at ikp.ikp.pl (Miroslaw Jaworski) Date: Wed, 1 Oct 1997 14:59:40 -6000 Subject: More on spamming.. In-Reply-To: <199710011109.MAA02064@diamond.xara.net> Message-ID: On Wed, 1 Oct 1997, Alex Bligh wrote: > It doesn't solve it, but it helps it. One of the main problems is > traceability. IE you don't know where the spam has come from. If > noone third-party relayed, then when my users get spam, I'd know the > IP address of the machine it came from originally. This would be > good. I agree : knowing real source address is the base for success. It's nothing new... > Another necessary fix is for ISPs to keep record of which > user had which IP address at any given time, and to keep contact > details for all their users (this is desirable for secuirity and > legal reasons too). I've got everything in my logs. all sendmail jobs and from which user it cames from. > If you build these two things together with > a term in peering agreements that classifies spam abuse in a similar > manner to the way most agreements currently classify security > problems (i.e. mutual terms for traceability and action), and > one hopes that similar terms are already in place in transit > agreements, then one should be better able to get spammers > removed. and what to do ? tell customers "sorry u generate spam, we don't want u on our server" ? OK, but a couple hours later he will get new accounts from other ISP. Cooperation of all ISP is needed. Index od spammers. Absolute rule : before setting up new accounts, check customer in spammers index. And for more : official documents about spam. It should be announced and published over network so EVERY user can read it and imagine what will happen with him if..... MJ ___________________________________________________________________________ Miroslaw.Jaworski at ikp.com.pl (Psyborg) MJ102-RIPE ATM S.A. - IKP division WAN/UNIX adm From mjaw at ikp.ikp.pl Sat Oct 4 05:24:29 1997 From: mjaw at ikp.ikp.pl (Miroslaw Jaworski) Date: Wed, 1 Oct 1997 15:24:29 -6000 Subject: More on spamming.. In-Reply-To: <199710011122.MAA15510@NetBSD.noc.COLT.NET> Message-ID: On Wed, 1 Oct 1997, Neil J. McRae wrote: > Obviously not, but you could help us in tracking any such offender, and > help put a stop to it, InterISP co-ordination is important, and I'd guess > thats why organisations like RIPE, LINX and so on, are keen to be > a focal point for action. i see solution : every new ISP must own his IP. He gets it from RIPE. maybe he should sign such a document containing rules of servicing new customers. One part should inform that in case of spam spammer will be added to "Index" and no ISP will set up an account for him in the future. Maybe then people can understand what they can loose by inproper using of e-mail ? MJ ___________________________________________________________________________ Miroslaw.Jaworski at ikp.com.pl (Psyborg) MJ102-RIPE ATM S.A. - IKP division WAN/UNIX adm From phk at critter.freebsd.dk Wed Oct 1 15:25:09 1997 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Wed, 01 Oct 1997 15:25:09 +0200 Subject: More on spamming.. In-Reply-To: Your message of "Wed, 01 Oct 1997 14:59:40." Message-ID: <5608.875712309@critter.freebsd.dk> >and what to do ? tell customers "sorry u generate spam, we don't want u >on our server" ? Yes. >OK, but a couple hours later he will get new accounts from other ISP. If he hits you, you tell that ISP: "stop this customer please", if they don't you blackhole their route. >Cooperation of all ISP is needed. Index od spammers. YES, that's what this entire discussion is about. >Absolute rule : before setting up new accounts, check customer in >spammers index. yes. >And for more : official documents about spam. It should be announced and >published over network so EVERY user can read it and imagine what >will happen with him if..... yes. -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." From phk at critter.freebsd.dk Wed Oct 1 15:44:11 1997 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Wed, 01 Oct 1997 15:44:11 +0200 Subject: More on spamming.. In-Reply-To: Your message of "Wed, 01 Oct 1997 15:24:29." Message-ID: <5695.875713451@critter.freebsd.dk> In message , Miroslaw Jawo rski writes: >i see solution : > >every new ISP must own his IP. He gets it from RIPE. >maybe he should sign such a document containing rules of servicing new >customers. One part should inform that in case of spam spammer will be >added to "Index" and no ISP will set up an account for him in the future. > >Maybe then people can understand what they can loose by inproper using >of e-mail ? I would vote for this. -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." From mjaw at ikp.ikp.pl Sat Oct 4 06:09:56 1997 From: mjaw at ikp.ikp.pl (Miroslaw Jaworski) Date: Wed, 1 Oct 1997 16:09:56 -6000 Subject: More on spamming.. In-Reply-To: <199710011224.NAA05093@diamond.xara.net> Message-ID: On Wed, 1 Oct 1997, Alex Bligh wrote: > If you keep all your servers time sync'd and keep full Radius > accounting records, yes, you can translate an (IP address, time) > pair into a username. Some ISPs can do this reliably. Many don't. it's so easy. for dialup : I've got an authentication tool. Have You ever heard about Tacacs+ ? all informations are clear : when, which ip (which port on which router), username, result of authentication for leased : SYSLOG contains entries for sendmail. > Seconds may well matter. The next problem is to associate that > user name with a person. Dead easy you may think. But the > user may claim that someone else has been using their account. most often company has one account and a few people had passwd to it. So... I can tell when it was. Then they should search inside their company. > Thus you also need to log CLI (calling number identity), > which in turn means your telecom provider has to present it. :( its impossible here. TPSA (telecommunication company ) is monopolist so they most often don't want to cooperate with people. even if u have an information which number was the source it's not everything. As i said - many companies use one PC to e-mail. When someone wants to check his mailbox simply call ( source phone is always the same ) and check it. MJ ___________________________________________________________________________ Miroslaw.Jaworski at ikp.com.pl (Psyborg) MJ102-RIPE ATM S.A. - IKP division WAN/UNIX adm From mjaw at ikp.ikp.pl Sat Oct 4 06:36:03 1997 From: mjaw at ikp.ikp.pl (Miroslaw Jaworski) Date: Wed, 1 Oct 1997 16:36:03 -6000 Subject: More on spamming.. In-Reply-To: <5608.875712309@critter.freebsd.dk> Message-ID: On Wed, 1 Oct 1997, Poul-Henning Kamp wrote: > >and what to do ? tell customers "sorry u generate spam, we don't want u > >on our server" ? > > Yes. i want to :) but i work for ISP :) > >OK, but a couple hours later he will get new accounts from other ISP. > If he hits you, you tell that ISP: "stop this customer please", if they > don't you blackhole their route. then many customers are wining "Why can't I.... ??!!Why did You ??!! What with my e-mail ???!!".... :( > YES, that's what this entire discussion is about. > yes. > yes. Wow.. triple YES for me :) like in voting couple years ago in my country :) so... there is an idea. there is an beginning of solution.. who can accept it ? maybe we can try to create such a document which should be signed by every existing and every new ISP ? MJ ___________________________________________________________________________ Miroslaw.Jaworski at ikp.com.pl (Psyborg) MJ102-RIPE ATM S.A. - IKP division WAN/UNIX adm From mvalente at esoterica.pt Wed Oct 1 16:53:49 1997 From: mvalente at esoterica.pt (Mario Valente) Date: Wed, 01 Oct 1997 15:53:49 +0100 Subject: More on spamming.. In-Reply-To: <343246DD.AF23C9D0@pipeline.ch> References: <199710010913.KAA28046@diamond.xara.net> <3.0.3.32.19971001112945.0072e438@mail.esoterica.pt> Message-ID: <3.0.3.32.19971001155349.0072d124@mail.esoterica.pt> At 14:49 01-10-1997 +0200, IBS / Andre Oppermann wrote: >Can you make this code public (for RIPE ISP's - BSD license or GPL)? > >Mario Valente wrote: >-snip- >> We have a daemon on the background scanning the mail log. We accept >> mail from everywhere, anyplace. As long as its one message at a time >-snip- > OK find at the end of this message the shell scripts that we currently use to block spams dynamically. Understand that this is a work in progress, begun a couple of months ago, tailored to our system. As such its not configurable; and its not optimized. It should probably be rewritten in Perl or C, commented, etc It was partly written by me and partly by my cohort Paulo Laureano. We have commented the code just now to help in understanding it. Some variables and files are named in Portuguese :-) Paulo also wrote some of the comments below. Since several people have been asking us for these scripts, we are now thinking of rewriting this, comenting and optimizing. C U! -- Mario Valente & Paulo Laureano (looking over my shoulder) ------------------------------------------------------ This is the main script I run on the cron every 5 minutes... the value of the "tail" numbers of lines to read should be adjusted for your own system since this sets the amount of time a IP address is left with denyed access to port 25 of your machine. The values of 1000 & 2000 used on my server provide suspensions of access for 15/30 minutes depending on the reason that caused the cut (i.e. the script checks the last 5 minutes and cuts access to spammers it found for the next 15/30 minutes). --- cut here (begin /usr/local/bin/lockrelayers) --- #!/bin/sh # script file used for real-time cut of access to port 25 # must be "chmod +s"... # # # Clean up list of commands that will deny access to port 25 # :> /usr/local/bin/cortados.new # # temporary file used to store IP addresses of spamming hosts :> /tmp/spamlist # find relayers and cut access to port 25 on ilegal ones (temporary! # just to break the flow of incomming messages) # # # findspamrelayers addresses using our server as a relay (see below) # /usr/local/bin/findspamrelayers_auto | cut -f3 -d"[" | cut -f1 -d"]" | sort -u | while read endereco do if grep $endereco /usr/local/bin/cortados >/dev/null # Address already in the list of denied addresses then echo "Relay access already cuted..." >/dev/null else # Add address to the list of addresses to deny echo $endereco >>/tmp/spamlist fi done # find domains started with numbers (i.e. ilegal) and # 1- add them to list of known spammers (block'em in the future # based on the domain name)... # 2- deny access to port 25 for the machine that is delivering the # messages (this is temporary just to break the flow of messages) # # # find in the maillog fakedomains (started with a digit) tail -1000 /var/log/maillog | grep "from=" | cut -f2 -d"<" | cut -f2 -d"@" | cut -f1 -d">" | grep ^[0-9] | sort -u | while read fakedomain do if grep $fakedomain /etc/mailspamdomains >/dev/null then # Fake domain already blocked echo $fakedomain is already blocked here >/dev/null else # Add domain to /etc/mailspamdomains, used by sendmail to stop spammers echo Added $fakedomain to domains blacklist echo $fakedomain >>/etc/mailspamdomains fi # Add fake domain to list of addresses to block, since they're currently spamming grep $fakedomain /var/log/maillog | grep "from=" | cut -f3 -d"[" | cut -f1 -d"]" | grep "." >>/tmp/spamlist done # cut access to port 25 (temporary!) on anyone atempting to deliver # messages from our list of known spammers... cat /etc/mailspamdomains | while read spamdomain do # Find IP address of known spammers tail -2000 /var/log/maillog | grep "from=" | grep $spamdomain | cut -f3 -d"[" | cut -f1 -d"]" | grep "." | while read foundip do # Add IP address of known spammers to list of addresses to block echo $foundip >>/tmp/spamlist done done # sort/unique the list of IP's to block so far and add them to the # list about to loose access to the mail port... sort -u /tmp/spamlist | while read endereco do # Create the script with list of commands used to block addresses # denyaccess is a script (see below) # echo /usr/local/bin/denyaccess $endereco >>/usr/local/bin/cortados.new done rm -f /tmp/spamlist cp /usr/local/bin/cortados.new /tmp/spamlist # if we have three or more IP's blocked, lock ALL ip's that we know # relay spam mail to us (have done so in the past...)! This literally # makes esoterica unreachable to loads of people for a while and makes # spam close to impossible by relaying mail thru major ISP's. We only # lock the entire list on the third IP locked to allow space for a # couple of "ilegal" relaying (some new customer not yet known to the # mail postmaster, etc). cat /tmp/spamlist | grep "\." | while read nome do let quantos=$quantos+1 echo $quantos >/dev/null if test $quantos -eq 3 then cat /usr/local/bin/cortados.relay >>/usr/local/bin/cortados.new fi done # cut the access and log it excluding from the log the big list of # IP's cuted because they are know relayers and the list of IP's we # have cuted on a permanent basis... # Run the fixed script (see below) that blocks known spammers /usr/local/bin/cortados >/dev/null # # Put date into log date >>/var/log/maillocked # # Run the dynamic (previously created) script that will block current spammers /usr/local/bin/cortados.new >/dev/null 2>/dev/null # # Use the Linux ip firewall admin command to list the current blocks /sbin/ipfwadm -I -l -n | grep tcp >/tmp/spamlist # Take out of /tmp/spamlist the domains that are always blocked grep denyaccess /usr/local/bin/cortados | cut -f2 -d" " | while read defcut do grep -v $defcut /tmp/spamlist >/tmp/spamlist2 mv /tmp/spamlist2 /tmp/spamlist done # Take out of /tmp/spamlist addresses known as using us as relay # and log the rest of addresses (those discovered in this run of the # script) grep denyaccess /usr/local/bin/cortados.relay | cut -f2 -d" " | while read defcut do grep -v $defcut /tmp/spamlist >/tmp/spamlist2 mv /tmp/spamlist2 /tmp/spamlist done cat /tmp/spamlist >>/var/log/maillocked echo >>/var/log/maillocked ---- cut here (end /usr/local/bin/lockrelayers) ---- The script file "cortados" that follows has a list of addresses permanently blocked from delivering mail to Esoterica ; ---- cut here (begin /usr/local/bin/cortados) ---- /sbin/ipfwadm -I -f # exceptions (addresses that are never cuted down; my relay mail machine) echo 194.130.254.3 >/dev/null echo 195.22.0.33 >/dev/null # The script denyaccess is used (see below) #cyberpromo/savetrees /usr/local/bin/denyaccess 204.137.223.0/24 /usr/local/bin/denyaccess 204.137.222.0/24 /usr/local/bin/denyaccess 204.137.220.0/24 #regulus.net/bulk-e-mail.com/nancynet.com,etc e um ISP para spammers... /usr/local/bin/denyaccess 205.199.4.0/24 #mail-response.com/nancynet.com/nevwest.com/etc,etc,etc /usr/local/bin/denyaccess 205.254.167.0/24 /usr/local/bin/denyaccess 205.254.165.0/24 /usr/local/bin/denyaccess 207.51.48.0/24 #1stfamily.com /usr/local/bin/denyaccess 208.15.229.0/24 #kustom.on.ca /usr/local/bin/denyaccess 204.101.226.0/24 #onlinebiz.net /usr/local/bin/denyaccess 205.164.68.0/24 #netrecruiters.com, uniquepo,com, etc /usr/local/bin/denyaccess 205.198.78.0/24 #asianinvestments.com.au /usr/local/bin/denyaccess 203.32.208.0/24 #spamrelay.grandbikes.com /usr/local/bin/denyaccess 208.219.218.0/24 ---- cut here (end /usr/local/bin/cortados) ---- The file /usr/local/bin/cortados.relay has a list of IP's/pools that in the past were used as relay to deliver junk mail to us. These addresses are ALWAYS blocked on our secondary mail server. This is done because if/when they were denied mail delivery to the primary mail server, the spam would get delivered to the secondary. This script runs if we are being bombed from three or more IP addresses. We cut these down for a couple of minutes also (spammers have a limited number of IP's that they can use for relay, and we cut those in a block whenever we know about them). Since all cuts on the main mail machine are temporary there is no problem on making mistakes... it will delay delivery to the next mail queue processing... only these intervals make mail bombing close to impossible! ---- cut here (begin /usr/local/bin/cortados.relay) ---- /usr/local/bin/denyaccess 12.70.46.0/24 /usr/local/bin/denyaccess 12.70.47.0/24 /usr/local/bin/denyaccess 128.148.157.0/24 /usr/local/bin/denyaccess 128.163.1.0/24 [ ... big list of address pools including machines from uunet and other big ISPs frequently used as relay for spam ... ] /usr/local/bin/denyaccess 208.206.112.0/24 /usr/local/bin/denyaccess 208.206.176.0/24 /usr/local/bin/denyaccess 208.6.192.0/24 /usr/local/bin/denyaccess 209.1.135.0/24 /usr/local/bin/denyaccess 209.30.0.0/24 /usr/local/bin/denyaccess 209.68.1.0/24 /usr/local/bin/denyaccess 209.75.5.0/24 ---- cut here (end /usr/local/bin/cortados.relay) ---- The file /usr/local/bin/cortados.new is empty and has the executable bit active (i.e. it is a script with content filled in real time) and called "at the end" of "lockrelayers". It is filled dynamically with sequence of commands to block addresses. A script used to find relayers by "lockrelayers" is "/usr/local/bin/findspamrelayers"... content follows... ---- cut here (begin /usr/local/bin/cortados.relay) ---- # Find entries in maillog telling of relay use grep relay /var/log/maillog >/tmp/xpto2 tail -600 /tmp/xpto2 >/tmp/xpto # Extracting friendly virtual domains from the list of relayers ... those that # we allow relaying and do mail forwarding # cat /etc/sendmail.cw | grep -v ^# | grep "\." | while read nome do grep -v $nome /tmp/xpto >/tmp/xpto2 mv /tmp/xpto2 /tmp/xpto done # # Extract domains for leased line customers and expanded # addresses from the list of relayers # # cat /etc/legalrelay | grep -v ^# | grep "\." | while read nome do grep -v $nome /tmp/xpto >/tmp/xpto2 mv /tmp/xpto2 /tmp/xpto done #echo "Extracting known spammers (we already filter) from the list..." cat /etc/mailspamdomains | while read nome do grep -v $nome /tmp/xpto >/tmp/xpto2 mv /tmp/xpto2 /tmp/xpto done # Separate maillog relay entries into two lists, to find out # those that are currently relaying (have both a From entry and # a To entry). Those that dont have both, are either local deliveries, # locally originated or are coming from known spammers and were # not delivering them (no To:) # cat /tmp/xpto | grep " from=" >/tmp/froms cat /tmp/xpto | grep " to=" >/tmp/tos # Output on stdout addresses that are in both lists (and so are # currently relaying illegaly). The stdout will be used by other scripts # cat /tmp/tos | if grep " " >/dev/null then cat /tmp/tos | cut -f7 -d" " | while read msgid do grep $msgid /tmp/froms done else cat /tmp/tos | cut -f6 -d" " | while read msgid do grep $msgid /tmp/froms done fi #Cleanup rm -f /tmp/xpto2 rm -f /tmp/xpto rm -f /tmp/tos rm -f /tmp/froms ---- cut here (end /usr/local/bin/findspamrelayers_auto) ---- To examine the logs on my system I run from the comand line the following scrip called "viewspam" (every day to check spamming atempts of the last hours)... it requires the "/etc/mailspamdomains" file to determine what spammers to look for. ---- cut here (begin /usr/local/bin/viewspam) ---- cat /etc/mailspamdomains | while read nome do if grep $nome /var/log/maillog >/dev/null then echo $nome echo "------------------------------------------------" grep $nome /var/log/maillog | if grep " " >/dev/null then grep $nome /var/log/maillog | cut -f7 -d" " | while read msgid do grep " $msgid " /var/log/maillog echo done echo else grep $nome /var/log/maillog | cut -f6 -d" " | while read msgid do grep " $msgid " /var/log/maillog echo done echo fi fi done ---- cut here (end /usr/local/bin/viewspam) ---- The denyaccess script that cuts access (/usr/local/bin/denyaccess) is; ---- cut here (begin /usr/local/bin/denyaccess) ---- # Deny TCP packets coming from source $1 into dest "Our mail server" /sbin/ipfwadm -I -i deny -P tcp -S $1 -D 195.22.0.135 25 >/dev/null 2>/dev/null # Same for UDP /sbin/ipfwadm -I -i deny -P udp -S $1 -D 195.22.0.135 25 >/dev/null 2>/dev/null # Same for ICMP /sbin/ipfwadm -I -i deny -P icmp -S $1 -D 195.22.0.135 >/dev/null 2>/dev/null ---- cut here (end /usr/local/bin/denyaccess) ---- Hufff... now, I have some sendmail related files that are used to deny access based on domain names on "/etc/mailspamdomains" and a list of legal relayers (leased line customers, alias expansion that does not appear in the logs) on "/etc/legalrelayers". My sendmail locks out delivery from/to domains in "/etc/mailspamdomains". I got the domain based lockout scheme for sendmail from "www.sendmail.org"... I also have installed the checking of domains patch from the experimental anti-spam counter-measures for sendmail; this does reverse DNS lookups to check for validity of From and To addresses (also handy to find out your clients misconfigurations). In short the files are; /usr/local/bin/lockrelayers main script to do real time locking running out of crontab /usr/local/bin/findspamrelay_auto used by "lockrelayers" to find out current spammers /usr/local/bin/cortados permanently cuted IP's used by "lockrelayers" /usr/local/bin/cortados.new new IP's to cut; built and used by "lockrelayers" /usr/local/bin/cortados.relay list of machines used in the past to relay to us... used to lock in a block a lot of paths to esoterica and permanently cuted on our relay mail machines... used by "lockrelayers"... /usr/local/bin/viewspam look at log entries related to spam based on /etc/mailspamdomains /usr/local/bin/denyaccess cuts access to port 25 from and address... used by "lockrelayers" /etc/mailspamdomains list of domains to be cuted by sendmail /etc/legalrelay list of domains/users we allow relay to/from... Ouch... this is the first time I actually atempted to explain to someone the anti-spam measures in place here. If something fail to works as it should just drop me a line and I'll add whatever is needed. Basically this systems does not prevent mailspam but makes it impossible to work (i.e. reach more than the firts few addresses) by allowing only a small time windows of uncontrolled access, cuting access to offenders in a three/six time larger time window, and rendering mailspamdomains unusable for more that one time window. Also it detects when a IP address is atempting relay thru our system and shuts it up for a while, it shuts up knows pools of ips (for a couple of minutes only) used for relay if attacks persist, etc. From what I gathered some spammers are going nuts with this; they even forged mail and placed esoterica on the headers out of revenge. The reason is simple; they start spamming us, or using us for relay from some dial-in on aol/whatever, it seems to work in the first few minutes (some messages may even reach their intended destination) and then... esoterica is no longer reachable... they can't even ping us... then, they try another dial-in, get another IP address and... BINGO, working again for a few minutes, but then it stops working also... on the third atempts things repeat themselfs but then it seems that at the fourth atempt not even new IP's get to esoterica... to make them REALLY MAD everything works again a few minutes later; the problem is it would take hours to deliver mass mailings thru this "less that five minutes" windows; worst than that, on the next atempt mail has to be forged again since fake domains are blocked, etc. Spam received/relayed by esoterica has dropped 99% in the last weeks. From aw at eunet.ch Wed Oct 1 16:58:13 1997 From: aw at eunet.ch (Alex Wilansky) Date: Wed, 1 Oct 1997 16:58:13 +0200 (MET DST) Subject: More on spamming.. Message-ID: <199710011458.QAA29269@magnolia.eunet.ch> Miroslaw.Jaworski wrote: > On Wed, 1 Oct 1997, Poul-Henning Kamp wrote: > > > >and what to do ? tell customers "sorry u generate spam, we don't want u > > >on our server" ? > > > > Yes. > > i want to :) but i work for ISP :) > > > >OK, but a couple hours later he will get new accounts from other ISP. > > If he hits you, you tell that ISP: "stop this customer please", if they > > don't you blackhole their route. > > then many customers are wining "Why can't I.... ??!!Why did You ??!! > What with my e-mail ???!!".... :( > > > YES, that's what this entire discussion is about. > > yes. > > yes. > > Wow.. triple YES for me :) like in voting couple years ago in my country :) > > so... there is an idea. there is an beginning of solution.. > who can accept it ? > maybe we can try to create such a document which should be signed by > every existing and every new ISP ? > Interestingly enough, I reported to a major ISP recently (no names) a considerable problem with a spammer hijacking one of our machines. Traces showedup the originating machine, one on their lines a few domain levels down, and asked them to do something about it, or we would have to, in a way which would affect all their traffic to us. Their response was "Thank you for your interest, but this is not our problem. We rely on our client's discression for their correct use of the internet". So, who's gonna sign this lovely document? Aleks With kind regards Aleksandr Wilansky; The comments in the above mail are my own, and in no way reflect company policy........ === ____ === hostmaster at eunet.ch === / / / ___ ___ _/_ === EUnet AG === /---- / / / / /___/ / === Zweierstrasse 35 === /____ /___/ / / /___ / === CH-8004 Zuerich ===== ===== Tel. +41 1 298 60 30 ===== Connecting Europe since 1982 ===== Fax +41 1 291 46 42 "In a world without fences, who needs Gates?" From boss at incoma.com Wed Oct 1 19:02:49 1997 From: boss at incoma.com (Gregory Dmitriev) Date: Wed, 1 Oct 1997 19:02:49 +-300 Subject: unsubscribe Message-ID: <01BCCE9C.9D92E0C0@boss.incoma.ru> unsubscribe From simon at limmat.switch.ch Wed Oct 1 18:13:20 1997 From: simon at limmat.switch.ch (Simon Leinen) Date: Wed, 1 Oct 1997 18:13:20 +0200 Subject: More on spamming.. In-Reply-To: <3.0.3.32.19971001084404.00844250@mail.nwu.de> References: <199710010043.CAA00861@solair1.inter.NL.net> <3.0.3.32.19971001084404.00844250@mail.nwu.de> Message-ID: <199710011613.SAA02559@babar.switch.ch> >>>>> "Stephan" == Stephan Hermann writes: Stephan> We must stop those spammers with commercial ideas not with Stephan> technical solutions such as filtering out IPs with as-path Stephan> access lists. I agree that we should not get trapped by the technocratic view that we have to solve this problem with some kind of filtering mechanism, just because we can. In fact, I would go farther and point out that getting involved in such filtering is actually a dangerous path for us as ISPs to go down. Remember the debate about censoring stuff like bomb-building instructions or certain kinds of pornography? When some policitians suggested that ISPs should be held responsible for the content transmitted over their networks, ISPs rejected this idea with arguments like: We are just common carriers, we cannot play our customers' Big Brother, censorship is a bad thing etc. Now what's the difference between this and the UCE problem when ISP responsibility is concerned? I claim that there really isn't any. We're just more concerned about UCE because it is unsolicited and we receive so much of this SPAM ourselves. While it is understandable that we take every measure to solve this problem for ourselves, I don't think we should solve it FOR OUR CUSTOMERS. In fact all technical solutions result in some sort of censorship. We should not start censor mail (other than to ourselves as individuals of course) unless we're prepared to censor to other content we transport. Otherwise our political position will be very weak. Real solutions to the UCE problem will include laws(*). Personally I see this as a feature, not a bug, as long as those laws are reasonable. In the USA, there are currently three projects (see http://www.vtw.org/bigboard/index.shtml#junkemail or listen to http://www.hotwired.com/synapse/hotseat/97/39/stuff/antispam.ram). I think that there is a real chance that such laws will eventually bring UCE under control. What we can do is look at the proposals and help get similar projects on track in our respective countries. This is where I see a role for RIPE. On the other hand, the technical solutions proposed so far look quite dangerous to me, because they all try to solve the problem for end users in the mail transport infrastructure, rather than give users ways to solve it themselves. Such "end-to-end" mechanisms also exist and are worthwhile to study. One of my favourites are traceable one-time e-mail addresses which would be linked (cryptographically) to a specific context. You could use a different From-address for each mailing list you're on and for each USENET News thread you post to, and discard it when you're no longer interested in this context or when you want to reduce the UCE you receive. Of course this is my personal opinion and doesn't reflect the views of SWITCH or anyone else for that matter. -- Simon. *) Commercial pressure also seems to work to some extent: witness the recent problems of some spammers to find ISPs for their business. From javier at bitmailer.com Wed Oct 1 18:29:34 1997 From: javier at bitmailer.com (Javier Llopis) Date: Wed, 01 Oct 97 18:29:34 Subject: More on spamming.. Message-ID: On Wed, 1 Oct 1997 14:59:40 -6000, Miroslaw Jaworski wrote: >Cooperation of all ISP is needed. Index od spammers. >Absolute rule : before setting up new accounts, check customer in >spammers index. > >And for more : official documents about spam. It should be announced and >published over network so EVERY user can read it and imagine what >will happen with him if..... Hmmm... I think that this could be HIGHLY illegal for the following reasons: - Spamming, although annoying is not illegal (even if the only reason is that laws evolve at a very slow speed) - Putting someone in a black list can greatly affect a person's or a small company's reputation and business. Most EU national laws forbid publishing that kind of information, let alone an agreement between ISP's not to service that fellow. In addition, if all the proof you have is based in your logs, which anyone can alter just with 'vi' and imagination, it is the spammer who will sue you for huge amounts of money. Making the spammers rich is not the optimal way to stop spamming. The only legal loophole would be if ISPs put a disuasive price for spamming practices in their service contract. A price so high that no spammer would pay. Then spammers would be invoiced, and the invoice would become unpaid after the invoice due date. Publishing a list of people who won't pay you is not illegal as long as the debt is well documented (with the invoice) nor is denying service because of being on that list. (We could have legal problems anyway, but the case would be harder for the spammer) And the only way out of the list would be paying the bill. Regards Javier Llopis BitMailer, S.L. javier at bitmailer.com Juan Bravo 51, Dup. 1-Izq Tel: +34 1 402 1551 28006 Madrid Fax: +34 1 402 4115 SPAIN From mjaw at ikp.ikp.pl Sat Oct 4 08:51:11 1997 From: mjaw at ikp.ikp.pl (Miroslaw Jaworski) Date: Wed, 1 Oct 1997 18:51:11 -6000 Subject: More on spamming.. In-Reply-To: <97Oct1.173418met.14342@gateway.hq.atm.com.pl> Message-ID: On Wed, 1 Oct 1997, Javier Llopis wrote: > The only legal loophole would be if ISPs put a disuasive price for spamming > practices in their service contract. A price so high that no spammer would > pay. Then spammers would be invoiced, and the invoice would become unpaid > after the invoice due date. thats the end of idea... 'black books' shouldn't be accessible by everyone. Rules, only rules ( what is spam, what u can do, what is 'illegal' ) should be published. Spammer can pay i dont know ... maybe in ripe ... for example . standard fee can be for example 1000$ for documented. all this is ..maybe... maybe... its beginning of good idea. i know that logs are not a proof. but logs from hundred servers which were 'attacked' with SPAM - it can be base to adding such a company to 'black list'. Such a list should be accessible only by ISP. > Publishing a list of people who won't pay you is not illegal as long as the > debt is well documented (with the invoice) nor is denying service because of > being on that list. (We could have legal problems anyway, but the case would > be harder for the spammer) And the only way out of the list would be paying > the bill. thats right. MJ ___________________________________________________________________________ Miroslaw.Jaworski at ikp.com.pl (Psyborg) MJ102-RIPE ATM S.A. - IKP division WAN/UNIX adm From phk at critter.freebsd.dk Wed Oct 1 19:03:08 1997 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Wed, 01 Oct 1997 19:03:08 +0200 Subject: More on spamming.. In-Reply-To: Your message of "Wed, 01 Oct 1997 18:29:34." Message-ID: <1258.875725388@critter.freebsd.dk> In message , "Javier Llopis" writes: >On Wed, 1 Oct 1997 14:59:40 -6000, Miroslaw Jaworski wrote: >- Putting someone in a black list can greatly affect a person's or a small >company's reputation and business. Most EU national laws forbid publishing >that kind of information, let alone an agreement between ISP's not to >service that fellow. This is in fact >not< correct. You can do that. You have to apply for approval of such a register, but it is legal and present in many other areas of business. The general requirement is that "doing business with the person or company can negatively impact the prosperity of the subscribers of the register." (A number of people in Denmark has started discussing such a register, if danish people on this list are interested, please contact me). -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." From davidk at isi.edu Wed Oct 1 21:12:57 1997 From: davidk at isi.edu (davidk at isi.edu) Date: Wed, 1 Oct 1997 12:12:57 -0700 (PDT) Subject: More on spamming.. In-Reply-To: from "Sebastian Andersson" at Oct 1, 97 11:28:16 am Message-ID: <9710011912.AA29540@brind.isi.edu> Sebastian, Sebastian Andersson writes: > > Some facist countries prevent their citizens to export implementations of > well known cryptoalgorithms (and to use some algorithms because of > different patents) ... And some ISPs prevent their customers from making the decision to read what they want and having the ability to receive and send anonymous mail which can be considered an important asset in a truely democratic system ... ISPs have the responsibility to protect against abuse of their infrastructure (relaying, denial of service attacks) but *not* to make decisions on what mail the customer can receive and what not. That is pure censorship which should only be carried out by the customer itself. There exist many tools to assist to make those decisions. For example, the customers can decide for themselves to reject not properly signed incoming messages and only mail from a selected group of people as a reliable but very extreme measure against unsolicited mail. David K. --- From sa at hogia.net Thu Oct 2 08:54:43 1997 From: sa at hogia.net (Sebastian Andersson) Date: Thu, 2 Oct 1997 08:54:43 +0200 (MET DST) Subject: More on spamming.. In-Reply-To: <9710011912.AA29540@brind.isi.edu> Message-ID: On Wed, 1 Oct 1997 davidk at ISI.EDU wrote: > > Sebastian, > > Sebastian Andersson writes: > > > > Some facist countries prevent their citizens to export implementations of > > well known cryptoalgorithms (and to use some algorithms because of > > different patents) ... > > And some ISPs prevent their customers from making the decision to read > what they want and having the ability to receive and send anonymous mail > which can be considered an important asset in a truely democratic system ... They are free to choose another ISP. It's much harder to choose another country. Further I don't know any ISP in any reasonably free country that prevents their users from sending mail to/from e-mail anonymiser but there are too many to keep count. Adding the requirement that it should be possible to see who is responsible for sending a message doesn't invade on anyones privacy. If they want to be anonymous, they send their message through a anonymizing server which they thrust and that server would in turn resign the message (and change the headers and such in the normal way). > ISPs have the responsibility to protect against abuse of their > infrastructure (relaying, denial of service attacks) but *not* to make > decisions on what mail the customer can receive and what not. That is > pure censorship which should only be carried out by the customer itself. Of course not. Adding a signature to the message that can be used to track who is responsible for the usage of my mailserver does not prevent my users from reading anything except bad messages (those messages that wouldn't follow the SMTP standard which would require signed messages) and they can't read all messages today either for the same technical reason (if the message doesn't follow the SMTP standards it might get dropped/bounced). > There exist many tools to assist to make those decisions. For example, > the customers can decide for themselves to reject not properly signed > incoming messages and only mail from a selected group of people as a > reliable but very extreme measure against unsolicited mail. And if you use qmail you can send out a personal email address to everyone you want to get e-mail from and only autoanswer to all mail that is sent to your "real" e-mail address. A simple script checks that the destination address is valid for the sending address or it will drop the message otherwice. It is also possible to give out timelimiteded emailaddresses that works for any sender (which in turn is nice for newspostings...). BUT: In theory this would be enough but the internet is used by people that has never had a computer until they decided to connect to the internet. They have bad clients which doesn't support signing nor any filtering. They don't know how to upgrade their clients and they don't care. It is working for them. They get a bit dissapointed when they get to download mail for ten minutes only to find spam but most of them don't complain. Some want us ISPs to "fix it". When you tell them to require signatures and that all their personal friends will have to get a new mailclient they will laugh at you for good reasons. /Sebastian See http://www.hogia.net/keys/sa-pgp.asc for public pgp key. From ifl at online.no Thu Oct 2 10:19:12 1997 From: ifl at online.no (Ina Faye-Lund) Date: Thu, 02 Oct 1997 10:19:12 +0200 Subject: More on spamming.. In-Reply-To: References: <97Oct1.105457met.14341@gateway.hq.atm.com.pl> Message-ID: <3.0.1.32.19971002101912.012c98a4@online.no> At 12:58 01.10.97 -6000, Miroslaw Jaworski wrote: >I don't know how it is in other countries but here most of the customers >are POP users. Direct lines ? Geee.. Only bigger companies can afford it. > >So when u get a spam, its from dial-line. most often.try to find who was >it ? Well, we, at least, log every login. So if someone does something stupid (which happens often enough), we need the IP-address and the exact time, and we can trace the user without problems. What surprises me, is that it seems like a lot of ISPs don't do this. I would have thought that it was natural to log; not only for tracing abuse-cases, but also for support, statistics etc. It's actually easier to trace spamming made by a dial-up customer than one with a leased line, since we, with dial-up accounts, can trace back to _one_ person, not a whole company. -- Med vennlig hilsen/Regards Ina Faye-Lund Telenor Nextel AS From prc at co.ip.pt Thu Oct 2 14:28:58 1997 From: prc at co.ip.pt (Pedro Ramalho Carlos) Date: Thu, 02 Oct 1997 13:28:58 +0100 Subject: More on spamming.. In-Reply-To: <3.0.3.32.19971001112945.0072e438@mail.esoterica.pt> References: <3.0.3.32.19971001115138.0083e7e0@mail.nwu.de> <199710010913.KAA28046@diamond.xara.net> Message-ID: <3.0.3.32.19971002132858.00d393b0@jaguar.ip.pt> At 11:29 01-10-1997 +0100, Mario Valente wrote: > > I'm going to describe once again how were dealing with spam. > [...Mario's description of his bulk-email detector/ip-filter...] just as a side note, Mario, you seem to be on the Vixie's black hole: in http://maps.vix.com/rbl/current.html :-( ... 195.22.0.135 ... It looks like one of your mail servers > dig -x 195.22.0.135 ptr ... ;; ANSWERS: 135.0.22.195.in-addr.arpa. 38932 PTR brilthor.esoterica.pt. ... --- pedro ramalho carlos Pedro.Carlos at co.ip.pt IP SA tel: +351-1-3166724 Av. Duque de Avila, 23 fax: +351-1-3166701 1000 LISBOA - PORTUGAL PGP Key fingerprint = B7 45 B2 F9 F3 1F 67 19 1F 24 76 67 8D F6 2C B2 From ifl at online.no Thu Oct 2 15:16:37 1997 From: ifl at online.no (Ina Faye-Lund) Date: Thu, 02 Oct 1997 15:16:37 +0200 Subject: More on spamming.. In-Reply-To: <199710011224.NAA05093@diamond.xara.net> References: Message-ID: <3.0.1.32.19971002151637.01273574@online.no> At 13:24 01.10.97 +0100, Alex Bligh wrote: >Seconds may well matter. The next problem is to associate that >user name with a person. Dead easy you may think. But the >user may claim that someone else has been using their account. In most cases, we then tell the user to change his or her password, and that if anything like this happens again, we will still close his or her account. Also, with so many people using ISDN, we can see what numbers the customer has connected from. Some have tried that one; that somebody else used their account. So, when you ask them: "Is xxxxx your phone-number?" and they answer "yes", we can tell them that the connection was made from that phonenumber. >Thus you also need to log CLI (calling number identity), >which in turn means your telecom provider has to present it. >The ISP must also have a policy on what to do with withheld >or unavailable CLI. So while this seems simple, actually it >isn't. Very few ISPs actually do the whole of this (IMHO). I think we focus on the wrong problem. Most of the spam we see, come from USA. There is not much spam originating in Europe. At least not compared with USA. So, if we could get rules that prevent our own users from spamming, before it becomes a problem, we would mainly have to deal with relayed spam. If larger parts of Europe can maintain a decent policy, and especially if the larger ISPs in Europe would have such a thing, the smaller would have to follow. That is, the large ISPs in Europe must deal with spam. If the larger ISPs, who can afford to lose one or two customers because they are not willing to house spammers, refuse to take in spammers as customers, and start blocking, or at least threaten to block, mail from ISPs that _do_ accept this, most ISPs will realize that they loose more customers by not being able to offer a satisfactory service. -- Med vennlig hilsen/Regards Ina Faye-Lund Telenor Nextel AS From mvalente at esoterica.pt Thu Oct 2 17:41:51 1997 From: mvalente at esoterica.pt (Mario Valente) Date: Thu, 02 Oct 1997 16:41:51 +0100 Subject: More on spamming.. In-Reply-To: <3.0.3.32.19971002132858.00d393b0@jaguar.ip.pt> References: <3.0.3.32.19971001112945.0072e438@mail.esoterica.pt> <3.0.3.32.19971001115138.0083e7e0@mail.nwu.de> <199710010913.KAA28046@diamond.xara.net> Message-ID: <3.0.3.32.19971002164151.0072af2c@mail.esoterica.pt> At 13:28 02-10-1997 +0100, Pedro Ramalho Carlos wrote: >At 11:29 01-10-1997 +0100, Mario Valente wrote: >> >> I'm going to describe once again how were dealing with spam. >> [...Mario's description of his bulk-email detector/ip-filter...] > >just as a side note, Mario, you seem to be on the Vixie's black hole: >in http://maps.vix.com/rbl/current.html :-( >... >195.22.0.135 > >It looks like one of your mail servers > >> dig -x 195.22.0.135 ptr >... >;; ANSWERS: >135.0.22.195.in-addr.arpa. 38932 PTR brilthor.esoterica.pt. Thanks for the tip Pedro. It seems that we were blocked because of some spam that was relayed through us back in early September. I do not know if this was because our spam filter was not working at the time or if it was because of a small amount of spam that was relayed (I remind you that our system DOES relay some spam through, until a pattern is detected in the mail relaying or until an address is permanently blocked). Anyway, I've requested from MAPS the removal of our address from the RBL and offered to send them the scripts were using for stopping spam. C U! -- Mario Valente From mel at csi.ch Thu Oct 2 18:14:25 1997 From: mel at csi.ch (Maarten E. Linthorst) Date: Thu, 02 Oct 1997 18:14:25 +0200 Subject: spamming Message-ID: <3433C861.3D71584A@csi.ch> can we please discuss spamming on different mail list. regards GoldNet maarten linthorst From kevinf at rom.net Thu Oct 2 18:19:18 1997 From: kevinf at rom.net (Kevin Ferguson) Date: Thu, 2 Oct 1997 17:19:18 +0100 Subject: spamming Message-ID: <01BCCF57.5198BD00.kevinf@rom.net> Hear, hear! Over the last few days I have received more mail via this mail list than I have received from spammers! Regards, Kevin. On Thursday, October 02, 1997 5:14 PM, Maarten E. Linthorst [SMTP:mel at csi.ch] wrote: > can we please discuss spamming on different mail list. > regards > GoldNet maarten linthorst From Boaz at Star.net.il Thu Oct 2 18:42:13 1997 From: Boaz at Star.net.il (Boaz Minitzer) Date: Thu, 02 Oct 1997 18:42:13 +0200 Subject: spamming References: <01BCCF57.5198BD00.kevinf@rom.net> Message-ID: <3433CEE4.8A1E524F@Star.net.il> I Agree, :) I considered putting this list on a /etc/spammers ban until this discussion was over... Please STOP local-ir-about-spam at ripe.net ! Thanks Kevin Ferguson wrote: > Hear, hear! Over the last few days I have received more mail via this mail > list than I have received from spammers! > > Regards, > > Kevin. > > On Thursday, October 02, 1997 5:14 PM, Maarten E. Linthorst [SMTP:mel at csi.ch] > wrote: > > can we please discuss spamming on different mail list. > > regards > > GoldNet maarten linthorst From jhma at EU.net Thu Oct 2 18:47:39 1997 From: jhma at EU.net (James Aldridge) Date: Thu, 02 Oct 1997 18:47:39 +0200 Subject: spamming In-Reply-To: Your message of "Thu, 02 Oct 1997 17:19:18 BST." <01BCCF57.5198BD00.kevinf@rom.net> Message-ID: <199710021647.SAA27262@aegir.EU.net> In message <01BCCF57.5198BD00.kevinf at rom.net> you write: > Hear, hear! Over the last few days I have received more mail via this mail > list than I have received from spammers! > > Regards, > > Kevin. > > On Thursday, October 02, 1997 5:14 PM, Maarten E. Linthorst [SMTP:mel at csi.ch] > wrote: > > can we please discuss spamming on different mail list. > > regards > > GoldNet maarten linthorst > I can't help thinking that as this discussion is more concerned with operational issues than registry issues it would be better moved to the European Operators' Forum . Any comments? James ----- ___ - James Aldridge, Senior Network Engineer, ---- / / / ___ ____ _/_ -- EUnet Communications Services BV --- /--- / / / / /___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___/ / / /___ /_ ---- Tel: +31 20 530 5327; Fax: +31 20 622 4657 - ----- 24hr emergency number: +31 20 421 0865 From preynes at dnstelecom.fr Thu Oct 2 18:49:31 1997 From: preynes at dnstelecom.fr (Pierre Reynes) Date: Thu, 2 Oct 1997 18:49:31 +0200 Subject: spamming Message-ID: <01BCCF63.EBBC4F30@thor.dnstelecom.fr> Right. Could you guys discuss spamming in, lets say, something like 'lir-spam at ripe.net' I am tired of pressing the delete key all the time... Thanks, ======================> D N S T E L E C O M <====================== Pierre REYNES Immeuble La Fayette 2, place des vosges 92051 Paris la Defense 5 Tel: +33 (0)1 43 34 10 17 Fax: +33 (0)1 49 05 46 89 Email: preynes at dnstelecom.fr ==================================================================== -----Original Message----- From: Maarten E. Linthorst [SMTP:mel at csi.ch] Sent: Thursday, October 02, 1997 6:14 PM To: lir-wg at ripe.net Subject: spamming can we please discuss spamming on different mail list. regards GoldNet maarten linthorst From ncc at ripe.net Thu Oct 2 19:54:11 1997 From: ncc at ripe.net (RIPE NCC Document Annoucement Service) Date: Thu, 02 Oct 1997 19:54:11 +0200 Subject: New Document available: RIPE-167 Message-ID: <9710021754.AA24517@ncc.ripe.net> New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-167 Title: A Regional Internet Registry for the CIS Author: R. Blokzijl, D.Karrenberg, A. Platonov Date: 02 October 1997 Format: PS=47638 TXT=2153 Obsoletes: Obsoleted by: Updates: Updated by: See also: Short content description ------------------------- This memorandum is intended to focus discussion about the establishment of a Regional Internet Registry serving the CIS and surrounding areas. Public comments are invited. The ultimate aim of this process is to achieve rough consensus about the issue within the region concerned. This memo represents the views of the individual authors only. It has not been endorsed by any organisation. Accessing the RIPE document store --------------------------------- The RIPE document store is available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-167.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-167.txt plain text version You can also access the RIPE documents in HTML format via WWW. RIPE-167 is not available from the WWW at this moment, but will be soon, at the following URL: http://www.ripe.net/docs/ripe-167.html Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to with "send HELP" in the body text. From mrjohn at Internex.NET Fri Oct 3 01:27:56 1997 From: mrjohn at Internex.NET (Michael Johnson) Date: Thu, 2 Oct 1997 16:27:56 -0700 (PDT) Subject: Remove me from mailing list. Message-ID: Please, remove me from this mailing list. Michael -- InterNex Information Services | Michael R. Johnson Network Engineering | mrjohn at internex.net 2306 Walsh Avenue | Tel: (408) 327-2209 Santa Clara, Ca. 95051 | Fax: (408) 496-5484 From mrjohn at Internex.NET Fri Oct 3 01:30:16 1997 From: mrjohn at Internex.NET (Michael Johnson) Date: Thu, 2 Oct 1997 16:30:16 -0700 (PDT) Subject: Remove from mail list Message-ID: Please, remove me from this mailing list. Michael -- InterNex Information Services | Michael R. Johnson Network Engineering | mrjohn at internex.net 2306 Walsh Avenue | Tel: (408) 327-2209 Santa Clara, Ca. 95051 | Fax: (408) 496-5484 From mihkel at eenet.ee Fri Oct 3 10:22:54 1997 From: mihkel at eenet.ee (Mihkel Kraav) Date: Fri, 03 Oct 1997 10:22:54 +0200 Subject: More on spamming.. References: <5695.875713451@critter.freebsd.dk> Message-ID: <3434AB5E.2A86DF06@eenet.ee> > >added to "Index" and no ISP will set up an account for him in the future. > > > >Maybe then people can understand what they can loose by inproper using > >of e-mail ? > > I would vote for this. It would be good idea if you had a proper organ to put spammers in that index but I can not see any normal mechanism for this. You have to have commonly accepted 'court' which can do that. Else can every people put his 'friend' in this index. Unfortunately this does not hear very Internet-like. Mikk From mihkel at eenet.ee Fri Oct 3 10:40:41 1997 From: mihkel at eenet.ee (Mihkel Kraav) Date: Fri, 03 Oct 1997 10:40:41 +0200 Subject: More on spamming.. References: Message-ID: <3434AF89.66C017DC@eenet.ee> > The only legal loophole would be if ISPs put a disuasive price for spamming > practices in their service contract. A price so high that no spammer would > pay. Then spammers would be invoiced, and the invoice would become unpaid > after the invoice due date. This solution is as good as saying 'spammer - you are not welcome in my network'. He goes and finds another ISP, whose pricing policy is different. Mikk From s.dezottis at telecomitalia.it Fri Oct 3 09:44:35 1997 From: s.dezottis at telecomitalia.it (Stefano De Zottis) Date: Fri, 03 Oct 1997 09:44:35 +0200 Subject: spamming References: <199710021647.SAA27262@aegir.EU.net> Message-ID: <3434A262.EBDCCFA6@telecomitalia.it> I agree, perhaps replying to all these messages is like spamming for the recipients, however this mailing list isn't the right place for an heavy mailing of messages concerning spamming. Regards, -- Stefano De Zottis - e-mail: s.dezottis at telecomitalia.it Telecom Italia SpA - International Department Phone: +39 6 5734 6263 - Fax: +39 6 5734 3438 James Aldridge wrote: > In message <01BCCF57.5198BD00.kevinf at rom.net> you write: > > Hear, hear! Over the last few days I have received more mail via this mail > > list than I have received from spammers! > > > > Regards, > > > > Kevin. > > > > On Thursday, October 02, 1997 5:14 PM, Maarten E. Linthorst [SMTP:mel at csi.ch] > > > wrote: > > > can we please discuss spamming on different mail list. > > > regards > > > GoldNet maarten linthorst > > > > I can't help thinking that as this discussion is more concerned with > operational issues than registry issues it would be better moved to the > European Operators' Forum . Any comments? > > James > > ----- ___ - James Aldridge, Senior Network Engineer, > ---- / / / ___ ____ _/_ -- EUnet Communications Services BV > --- /--- / / / / /___/ / --- Singel 540, 1017 AZ Amsterdam, NL > -- /___ /___/ / / /___ /_ ---- Tel: +31 20 530 5327; Fax: +31 20 622 4657 > - ----- 24hr emergency number: +31 20 421 0865 From mnorris at hea.ie Fri Oct 3 15:29:48 1997 From: mnorris at hea.ie (Mike Norris) Date: Fri, 03 Oct 97 14:29:48 +0100 Subject: Draft minutes of LIR WG at RIPE 28 Message-ID: <199710031329.OAA18895@dalkey.hea.ie> Below are the draft minutes of the LIR WG mtg at RIPE 28, prepared by Anne Lord (many thanks, Anne). Corrections, comments to me, please, certainly before Hallowe'en ;-) Mike Norris D R A F T D R A F T D R A F T Local IR Working Group at RIPE 28, Amsterdam Chair: Mike Norris Scribe: Anne Lord 1. Preliminaries Mike opened the meeting and welcomed the attenders to the session. Anne Lord volunteered to be scribe. There were 70 attenders at the working group session. 2. Open action items Minutes of RIPE 27 have been circulated and corrections made. There are no open action items from the previous meeting. 3. Report from Registries RIPE NCC - Mirjam Kuehne Graph of current EU DNS hostcount shown - likely to hit 5 million before the end of the month. New staff - two new hostmasters : Julia Edwards from the US and Sabrina Waschke from Germany. Brings the total staff to 11 full time and 1 part time staff. Response time to requests is now 1 working day (for an acknowledgement). Wait queue is now growing again (additional load caused by hiring of new hostmasters). Staff getting an increased number of phone calls now with mostly IP related questions. Automation improvements have helped. Reverse delegation is now fully automated. Ticketing system improved in performance and functionality. A web interface has been developed for allowing queries of ticket status (see report by Mal Morris below). A registry now has one main handler (hostmaster) for each registry plus one or two backup handlers (hostmasters). Auditing and monitoring work extends to 3 parts: 1) Monitoring in daily work * database accuracy * complete documentation available * compliance with policies 2) Proactive Audits LIRs that they have little contact with e.g. those established for a long time will be contacted to see if they are in touch with latest procedures. 3) Audits on request If you wish to discuss procedures/practices of local IR's you can send your comments to the RIPE NCC. They will then investigate. John Crain is working on the quality initiative with respect to local IRs. Most LIRs do follow the guidelines. The main problem is due to dangling references in the RIPE db. A RIPE document is in preparation about the auditing process and the statistics found after a consistency check of the RIPE db. This is expected to be published soon after the meeting. Internal QA Internal procedures are now documented more clearly. They also have more structured staff training. Monitoring of internal database also started. LIR Training courses 5 courses have been given since the last RIPE meeting. Ukraine course was cancelled due to lack of interest. The NCC has a "no show" policy. This is as follows: New LIRs get priority in their first year; "local" LIRs get priority - 2 places per local IR. After places are used they have no priority anymore - this means either attended or not shown up. Plans and Promises Plan to continue quality activities and more resources have been added to this activity. Work flow management which is more structured will be introduced. Internal procedures will be further automated. Next LIR courses (planned) October : Paris (in conjunction with Interop) October : London November: Berlin November: Prague December: Rome They run a script to see where most new local IRs are coming from to determine city where to give training course. Slides: ftp://ftp.ripe.net/ripe/presentations/ripem28-mir-RS-REPORT.ps http://www.ripe.net/meetings/ripe/ripe-28/pre/ncc-reg APNIC Decision on city of relocation not final - but it will be in Australia. Plan to relocate involves keeping two offices - one in Tokyo for a short period of time. ARIN On course to go live in approximately 2-3 weeks time. Encountered some legal problems which are now overcome. AFRI-NIC Nothing has been formalised apart from it's principle of establishment. 4. IP Address Space Assignment Policy document revision Please note : ripe-159 is now the policy document [replacing ripe-140, which replaced ripe-104]. Accompanying documents are still ripe-141 and ripe-142. Use of class A address space Registries can have two allocations: one traditional and one from class A address space. Caveats are that you may encounter difficulties with classless routing out in the Internet. There was a question about amount allocated so far. So far about 50 ranges have been allocated. Question was asked about amount of allocations announced on the Internet, but the answer was not known. Web interface to the Ticketing System Maldwyn Morris gave a "live" demonstration of the RIPE NCC ticketing system which will shortly be available via the web pages. Check out: http://www.ripe.net/cgi-bin/rttquery Question: How much longer you have to wait in queue once handed off to hostmaster. Answer: This should not be more than one day. This information would be added to the web page. Suggestion to add name of the hostmaster dealing with your request to the web page. There was quite some discussion about this and it was not agreed to do so explicitly. Plans also to include information about closed tickets. 5. Registry procedures Suggestions to couple reverse delegations to assignments and to make this tool web based. Discussion on the list as to how to go about this. Suggestions included using "mnter" based authentication, SSL, PGP etc... Further discussions needed with the Database group on formats & mechanisms for protection. Carol gave a report on the status of IP address web allocation. Work is being done on auto-parsing the email message before it goes to the hostmaster on a sanity check on what you have sent in. Now needed is the web interface. There is still the area of security for consideration when sending in requests. So far, this has not been considered. Furthermore, we could consider functionality like if the request is accepted, to have it automatically update the RIPE database (and go further in updating reverse db?). There was quite some discussion about this but no action items emerged. So to conclude, the mechanisms for parsing are in place but are not yet released. Wilfried suggested to put security mechanisms on the "input from other working groups" so as to start a discussion and think some more about this. Tools for local registries ripe-141.{ps,txt} forms are available for use with customers of local IRs. There was a suggestion to put links from any useful web pages on tools to Local IR page and the "tools" page at the RIPE NCC. There was an action item place on Mike Norris to make this happen. (A1:28 see below). 6. Input/output with other working groups None discussed at this meeting. 7. Statistics i) Reverse DNS counts, errors are archived on RIPE web site. Blasco suggested doing some analysis of DNS reverse error counts. RIPE NCC agreed this was a good idea and at some stage was to be put on the activity plan. This was taken as an action item by the RIPE NCC. ii) Effect of NAT etc on PI address space. Diminuation of PI address space usage? Should every ISP use PI address space for multihoming? There was actually little discussion on this issue. 8. AOB i) Mailing lists Clarification of the RIPE NCC mailing lists. "Open" mailing lists are: * ripe-list at ripe.net * db-wg at ripe.net * dns-wg at ripe.net * lir-wg at ripe.net etc.. lir-wg at ripe.net working group is for discussions, open to anyone, not monitored right now but will be in the future. All maintained by majordomo. Blasco suggested to have a web interface to read archives of working group mailing lists [action NCC] "Closed" Mailing lists for contributors only: local-ir at ripe.net ncc-co at terena.nl Not managed by majordomo. is open only to contributing local IRs. Is automatically subscribed to. Used for announcements relevant to registries only. Low traffic. Is monitored to filter out spam and to deal with bounces. Requests or questions to Question of duplication was raised and how to handle it. Carol added that NCC has proposed a new activity to look at filtering out duplicate messages. Anti-Spam Spam topic related. Want to close public submission to the open lists. so that we can limit the spam. Suggestion to match against a list of domain names that mail is allowed to be posted to the list from. Geert Jan had another suggestion which involved blocking specific addresses that people spam from against a list of permitted addresses. However people can forge headers. Discussion moved to plenary and to working group lists. Suggestions to give some consideration to email discussions on this prior to the plenary discussion. Recommendation to gather together individuals that are contributing on this topic and to collate information on how to deal with Spam attacks. Daniel suggested that the local IR working group continue working on this. Mike Norris took an action to gather the various propoals on spamming and circulate to the working group list. Summary of open action items: Action 1:28 Mike Norris to put a link on the RIPE NCC web page and the working group page to useful LIR tools. Action 2:28 RIPE NCC to prepare an analysis of the reverse DNS error counts. Action 3:28 Mike Norris to collect information on anti-spamming policies and circulate to the list in a draft paper the recommendations on dealing with spam. Action 4:28 RIPE NCC to produce web interface to archives of WG mailing lists. ------- End of Forwarded Message From flirtman at love.flirt.de Sat Oct 4 15:32:02 1997 From: flirtman at love.flirt.de (Stephan 'FlirtMan' Hermann) Date: Sat, 04 Oct 1997 15:32:02 +0200 (CEST) Subject: More on spamming.. In-Reply-To: <19971001121808.28582.qmail@moebius.space.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hello, ok..the mailinglist is setup for using it. write to majordomo at love.flirt.de with subscribe anti-spam in the body of the mail. (you can use subscribe anti-spam , too. Thx for your time.... sh - -- Stephan 'FlirtMan' Hermann home: flirtman at love.flirt.de Funk: +49-172-2335538 dienst: sh at nwu.de -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: latin1 Comment: Waiting for PGP5.0i iQCVAwUBNDZFv+PPfOiqGZ2ZAQGJygP/aqew9RqkUnRhSv6Cjp5Q1++v9cVB1OeD i75WXBAg1ahEk9gOYc//lHgELKeYIQTlA2KvjgZVkKtPsr6aS51DAP9Swbib1aZI JOkei+PMznpIHhvxrBdgOSPWhXnN8D3YkLlcAGfanvhSMXIHZv1gb313JdQGg+Cv BS/4QbNSNQA= =5QG+ -----END PGP SIGNATURE----- From Mirjam.Kuehne at ripe.net Mon Oct 6 12:00:27 1997 From: Mirjam.Kuehne at ripe.net (Mirjam Kuehne) Date: Mon, 06 Oct 1997 12:00:27 +0200 Subject: announcements in 62/8 Message-ID: <9710061000.AA17212@ncc.ripe.net> Dear local IRs, During the LIR WG at the RIPE Meeting two weeks ago a question came up on how many of the allocations from 62/8 are actually announced. >From a snapshot taken of our routing table on 29th Sept we could see that 37 of the 50 allocations are also announced (almost 75%). This is not bad, even though 100% would of course be better ;-) Kind Regards, Mirjam Kuehne Manager Registration Services RIPE NCC From mrjohn at Internex.NET Mon Oct 6 15:32:58 1997 From: mrjohn at Internex.NET (Michael Johnson) Date: Mon, 6 Oct 1997 06:32:58 -0700 (PDT) Subject: Remove me from email list Message-ID: Remove me from email list. Michael -- InterNex Information Services | Michael R. Johnson Network Engineering | mrjohn at internex.net 2306 Walsh Avenue | Tel: (408) 327-2209 Santa Clara, Ca. 95051 | Fax: (408) 496-5484 ---------- Forwarded message ---------- Date: Mon, 06 Oct 1997 12:00:27 +0200 From: Mirjam Kuehne To: lir-wg at ripe.net Subject: announcements in 62/8 Dear local IRs, During the LIR WG at the RIPE Meeting two weeks ago a question came up on how many of the allocations from 62/8 are actually announced. >From a snapshot taken of our routing table on 29th Sept we could see that 37 of the 50 allocations are also announced (almost 75%). This is not bad, even though 100% would of course be better ;-) Kind Regards, Mirjam Kuehne Manager Registration Services RIPE NCC From Carol.Orange at ripe.net Thu Oct 30 12:20:15 1997 From: Carol.Orange at ripe.net (Carol Orange) Date: Thu, 30 Oct 1997 12:20:15 +0100 Subject: Who should do entries in RIPE database? In-Reply-To: Your message of "Tue, 28 Oct 1997 16:18:36 +0100." <3456024C.70C28953@contrib.com> Message-ID: <9710301120.AA14856@ncc.ripe.net> Dear Carsten, Yes indeed, the consistency problems in the RIPE database are well known and are even well documented in: ftp://ftp.ripe.net/ripe/dbase/info/consistency* and ftp://ftp.ripe.net/ripe/presentations/ripe-m26-orange-dbcons.ps.gz or http://www.ripe.net/meetings/ripe/ripe-26/pres/db-consist/ Our plans to deal with them are also documented in: ftp://ftp.ripe.net/ripe/presentations/ripe-m27-orange-woeber-dbcons.ps.gz or http://www.ripe.net/meetings/ripe/ripe-27/pres/db/consistency/ We do plan to try to eliminate multiple objects pointing to the same person, as well as other clean ups of the person data. [As a side note, this project is now well underway.] We have not however discussed limiting the ability to enter data in the RIPE database, outside of the current and proposed authorization mechanisms. That would certainly be a significant change of course, and for that reason, I have cc'd the RIPE Database working group on this mail to get their feedback on this idea. Greetings, Carol Orange RIPE NCC In message <3456024C.70C28953 at contrib.com>, Carsten Schiefner writes: >> As a result of a voluminous discussion with one of POPs I would like to >> point your interest on the following topic I am a little bit upset of: >> >> Almost everybody who knows about about the RIPE database schema (which >> is no secret at all!) can do entries just by sending a mail to >> 'auto-dbm at ripe.net'. This leads to an overwhelming bunch of multiple, >> bad maintained or what-ever-you-want entries - especially person >> objects - without any fun in grepping through them and selecting the >> right one to create a new object. Example: >> >> There are four(!) entries for the entity "Joerg Schmidt" of "ZWF >> Digitale Informations Technologie GmbH": JS893-RIPE, JS1161-RIPE, >> JS1163-RIPE and JS1438-RIPE. This should be definitely stopped! >> >> My idea is that we should discuss future restrictions on the possibility >> for everybody to put entries in the RIPE database, maybe by setting up >> and maintaing access lists for every LIR. >> >> For me this database is a central tool in my daily work and I am very >> interested in keeping quality and reliability of stored data as high >> as possible. >> >> Kind regards, >> >> Carsten Schiefner >> -- >> >> Carsten Schiefner mailto:schiefner at contrib.com >> TCP/IP GmbH, Berlin (Germany) - Contrib.Net http://www.contrib.com >> Phone: +49.30.44 33 66-0 Fax: +49.30.44 33 66-15 >> ====================================================================== From schiefne at contrib.com Fri Oct 31 14:56:25 1997 From: schiefne at contrib.com (Carsten Schiefner) Date: Fri, 31 Oct 1997 14:56:25 +0100 Subject: Who should do entries in RIPE database? References: <9710301120.AA14856@ncc.ripe.net> Message-ID: <3459E389.5E272AB1@contrib.com> Hi Carol, > Yes indeed, the consistency problems in the RIPE database are well > known and are even well documented in: > > [...] > > Our plans to deal with them are also documented in: > > [...] > > We do plan to try to eliminate multiple objects pointing to the same > person, as well as other clean ups of the person data. [As a side > note, this project is now well underway.] I know - this was mentioned by you(?) at the last RIPE CoCo meeting in September. I also know that RIPE NCC did, does an most probably will do a hard but nevertheless excellent job in "cleaning up" the RIPE database. But this is just one point for me. > We have not however discussed limiting the ability to enter data in > the RIPE database, outside of the current and proposed authorization > mechanisms. That would certainly be a significant change of course, > and for that reason, I have cc'd the RIPE Database working group on > this mail to get their feedback on this idea. The other point is to prevent the RIPE database from further pollution. There should be some settings to guarantee this. What is your opinion: should I post my suggestions just to 'lir-wg at ripe.net'and 'db-wg@ ripe.net' or in addition also to 'local-ir at ripe.net'? Many greetings, Carsten -- Carsten Schiefner mailto:schiefner at contrib.com TCP/IP GmbH, Berlin (Germany) - Contrib.Net http://www.contrib.com Phone: +49.30.44 33 66-0 Fax: +49.30.44 33 66-15 ====================================================================== From woeber at cc.univie.ac.at Fri Oct 31 16:54:13 1997 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 31 Oct 1997 16:54:13 MET Subject: Who should do entries in RIPE database? Message-ID: <009BC9A6.1468479E.5@cc.univie.ac.at> Folks, thanks for bringing this up for discussion! >The other point is to prevent the RIPE database from further pollution. >There should be some settings to guarantee this. What is your opinion: >should I post my suggestions just to 'lir-wg at ripe.net'and 'db-wg@ >ripe.net' or in addition also to 'local-ir at ripe.net'? I'll try to summarize from my point of view (both as DB-WG chair, Local-IR rep and of course as a dumb user :-) We have long since worked from the assumption that the "owner" of an object is responsible for it's on-going maintenance. We have always felt, that tigthening the rules too much would have a negative impact on all parties' willingness to register (at all) or to perform updates regularly. Then we introduced measures to protect *existing* objects by limiting the sources where updates (+ deletes :-) are accepted from (maintainer mechanism). This is particularly relevant for the IP Registry and for the Routing Registry. The next step has been protection of hierarchies in the object space with the mnt-lower mechanism, in particular for the Domain-Registry. Right now the Routing-WG and the NCC are working on the implementation of cross-notification for the routing registry. All of these mechanism can by now (or very soon) be used to ascertain a useful level of security and update control, including the referenced objects. This leaves us with two major weaknesses - or features: - A considerable percentage of the objects is not yet protected by the mechanisms which are readily available, and "tightening" the ropes requires a more careful approach by the various registries - leading to more work, in the end. In particular if we think about "owning" and protecting the person objects as referenced by data for the various registries.... - Nothing is there to prevent *any* party to put e.g. person objects into the DB. (And I certainly appreciate that myself!) Also, I suppose some other types of objects can be put into the DB without problems, unless they are in dircet conflict with one of the well-managed object spaces for a particular registry. This leaves us with a legacy of entries from the "Dark Ages" of DB deployment and with the on-going pollution of object space by way of "user error". This aspect is being addressed by the DB-Consistency Project. We work towards offering mechanisms to identify inconsistencies as described by a "catalogue of frequent problems" as well as by coming up with the logistics to repair these deficiencies. Again, to be successful, the registries shall be required to spend (considerable?) effort to participate in that activity. So what can be done on top of that to improve the situation? - We can offer improved mechaisms to deal with identification and authentication: this is on the agenda for the DB-Security Task Force. - We can try to improve the user interface. In particular to help the end-users to avoid the popular crimes like putting in just another person object as soon as there's a new reference: We (the AT-TLD administration) are in the process of designing and prototyping an interactive interface that should prevent most of these incidents. We're in contact with the NCC to determine the usefulness of that approach. Please stay tuned. - Last but not least we could think about "closing" the DB for public, that is anonymous, update or registration of objects. I think *that* would require *very* careful consideration, discussion, and establishing a broad consensus across (all of) the RIPE-WGs. I'd also expect considerable impact on activities like RIDE. But it is certainly not impossible to get that discussion going. Although (wearing no hat at all right now :-) I do not see a pressing need right now - taking into account that we have a set of mechanisms in the works to improve the situation. Comments and input welcome! Apologies for the lengthy speech... Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB (&NIC) Handle: WW144 --------------------------------------------------------------------------