From Mike.Norris at heanet.ie Fri Jan 2 15:13:12 1998 From: Mike.Norris at heanet.ie (Mike Norris) Date: Fri, 2 Jan 1998 14:13:12 -0000 Subject: Anti-spam measures Message-ID: <9801021413.AA04689@Tierce.hea.ie> The below is a belated summary of the the discussion of spamming on the lir-wg list soon after RIPE 28. I'm copying it to John Martin of TERENA as input to the BoF he is kindly organising during RIPE 29 later this month. Regards and happy new year. Mike Norris There was broad consensus that: - spammers can be clever and operate professionally - they can forge e-mail, IP addresses, even routes - they constitute at least a nuisance to users - they use inordinate levels of network and CPU resource without any charge - in some cases, the volume of traffic they generate impacts seriously on the performance of a network There were many calls for concerted action, for ISPs to back each other up, even for RIPE to take legal action against spammers. When it came to specifics, there were some points of good practice which were generally accepted and from which all could benefit. These included: - filter inbound routes on AS (lest spammers inject false routes and mail from the corresponding IP addresses) - configure sendmail to do relay only for specified hosts (to prevent spammers from using your mail server as a relay for spamming) - no-relay patches on http://www.sendmail.org/ - use sendmail patches to check From and To addresses - tighten up rules (and enforce them) for domain registration/de-registration - implement and enforce AUP and peering agreements - make address harvesting difficult e.g. www.e-scrub.com/wpoison Other anti-spamming defences, from the point of view of the recipient, included: - a daemon that checks the incoming mail queue for certain patterns of use, domains, volume of messages, etc. If a spam is detected, the daemon blocks reception of packets from the address/domain originating the spam for about 15 minutes. After that the reception is restored. - blocking SMTP access to bogus domains and addresses (not just CyberPromo) - accept the spam mail and don't deliver it On the supply side, too, ISPs suggested a range of measures to thwart spammers in their efforts to send bulk e-mail. - charge per item for delivery of e-mail with advertising material in it - regulate the number of RCPTs from a given MAIL FROM value (but how to authenticate the MAIL FROM value used?) - force dialup customers to use their ISPs SMTP relay, validate MAIL FROM value, check for forged headers, check sender identity There were those too who said that selective filtering, route denial and other practices by ISPs were not the way to go. Just because these were technically possible did not mean they had to be used; to do so could set a dangerous precedent which could be invoked in the future by outside agencies set on "controlling" the Internet. Rather, the users should be enabled to do their own filtering and many providers are equipping them with the means to do so. It is difficult, having seen the range of opinions expressed, to see a consensus about concerted action involving intervention in the mail transport mechanism, even in the European region. of spammers and dynamically blocking their routes, both of which are technically possible and already implemented in places. On balance however, it seems that the considered view is on the side of "freedom of speech". Whatever, people felt that European ISPs should act in concert and should adopt a common set of technical and administrative anti-spam measures. These would start with those listed above and might also include: - Set up a mailing list for LIR postmasters - Use digital signatures, with trusted SMTP servers - For dialup access, use TACACS+ Legal action, too, had its proponents and opponents. Instances of courts in Europe and USA finding against spammers were given, and used to suggest that RIPE might even take up legal cudgels against spammers and on behalf of its clients. As against this, there is the argument that the industry should be self-regulated, and that it should protect itself against itself. RIPE and the NCC have successfully adopted this approach to deal with IP address registration and other activities in Europe. Contributors to the discussion were: James Aldridge Sebastian Andersson Peppino Anselmi Alex Bligh Adrian Bool Pedro Ramalho Carlos Mickey Coggins Edgar Danielyan Jorgen Ericsson Ina Faye-Lund Clive D.W. Feather Kevin Ferguson Michael Ferioli gert at Space.Net Geert Jan de Groot Stephan Hermann Nick Hilliard Keith C. Howell Miroslaw Jaworski Poul-Henning Kamp Daniel Karrenberg Mihkel Kraav Andres Kroonmaa Simon Leinen Maarten E. Linthorst Javier Llopis Neil J. McRae Andre Oppermann Chris Panayis Morten Reistad Matt Ryan Luis Miguel Sequeira Paul Thornton Mario Valente Espen Vestre Francois Weil Toby Williams From ipopov at mail.wplus.net Mon Jan 5 17:26:42 1998 From: ipopov at mail.wplus.net (ipopov) Date: Mon, 5 Jan 1998 16:26:42 +0000 Subject: No subject Message-ID: <199801051339.QAA28419@lion.nevsky.net> Dear sirs, chiefs of the enterprises! Our company "Talan" offers cooperation and services on conditions very favourable to you. The company "Talan" is engaged in the real estate (purshase, sale and rent of apartments, houses, offices, factories, shops etc.) in St.-Petersburg, Leningrad area, other regions of Russia. The firm "Talan" is large, stable and reliable real estate company of St.-Petersburg with the ramified network of branches, has high reputation at the clients, gives attention qualitative complex to service. The especial attention is given to marketing of the market of the real estate and effective advertising. The company has an opportunity decrement of legislative and tax policy, has experience of work in the international market of the real estate. The company "Talan" is situated at historical centre of St.-Petersburg, - first on beauty and in the second-largest city of Russia. Incorporated by Peter The Greate as "window in Europe", St.-Petersburg remains large cultural, scientific and technical, port and industrial, trade and business centre of Russia with the population more than 5 mln persons. Annually St.-Petersburg is visited by millions tourists and visitors from the whole world. We agree to carry sufficient expenses for search in our country of the buyer of your real estate. In case of fulfilment of the joint bargain the unit of the commission is made in a proportion 50/50%. In other cases the size of agency fee is stipulated in the contract. For operative communication and transfer of the information about the characteristics of objects, offered you, it is convenient to use channels of a network INTERNET. Vizit our site www.real.spb.ru/index_en.htm and answer us if you are interested in business in Russia. Yours faithfully General Director Kuzmin Serge Nik. From martin at terena.nl Fri Jan 9 12:27:33 1998 From: martin at terena.nl (John Martin) Date: Fri, 9 Jan 1998 12:27:33 +0100 Subject: Anti-spam measures In-Reply-To: <9801021413.AA04689@Tierce.hea.ie> Message-ID: Mike and LIR members, At 3:13 pm +0100 2/1/98, Mike Norris wrote: >The below is a belated summary of the the discussion of spamming >on the lir-wg list soon after RIPE 28. I'm copying it to John >Martin of TERENA as input to the BoF he is kindly organising >during RIPE 29 later this month. Many thanks for this. [N.B. I'm sure most of you already know, but for those that didn't, there was also a BoF at the last IETF. Results can be found at: http://www.imc.org/ietf-ube-bof/ ] >It is difficult, having seen the range of opinions expressed, >to see a consensus about concerted action involving intervention >in the mail transport mechanism, even in the European region. >of spammers and dynamically blocking their routes, both of which >are technically possible and already implemented in places. However, it appears that many of us have been thinking the same thing for some time: the time for at least *some* deployment is here. The purpose of the BoF we proposed is to look at deployment of *existing* measures, as judging by conversations I have had with people, they can't afford to experiment with new-fangled anti-spam measures but, on the other hand, many are confounded by the myriad of tools available. If we can agree, therefore, I would like us to try to engineer this BoF towards some achievable short-term goals. [But then the purpose of having this BoF in the first place is to determine if this is feasible or not ;-) ] I'll produce a draft agenda real soon but in the meantime, any suggestions are more than welcome. Regards, John From phk at critter.freebsd.dk Fri Jan 9 13:21:53 1998 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Fri, 09 Jan 1998 13:21:53 +0100 Subject: Anti-spam measures In-Reply-To: Your message of "Fri, 09 Jan 1998 12:27:33 +0100." Message-ID: <5832.884348513@critter.freebsd.dk> One of the best things to do, would probably be to make a simple turnkey kind of sendmail config available to people. It should be possible for people to maintain four files on their system and have sendmail DTRT for them after that: /etc/sendmail.our_ip: 192.168.1.0/24 10.0.0.0/22 /etc/sendmail.our_domains: foo.bar.com some.customer.domain.xx some.other.domain.xx /etc/sendmail.we_mx_for: bar.foo.com c.i.a.gov /etc/sendmail.people_we_dont_talk_to cyberpromo.com nancynet.com 203.23.43.0/24 203.43.43.0/22 Now that would be a worthwhile project to do... (and no before you ask, I'm way too busy with FreeBSD as it is) -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." "Drink MONO-tonic, it goes down but it will NEVER come back up!" From edd at aic.net Fri Jan 9 13:31:31 1998 From: edd at aic.net (Edgar Danielyan) Date: Fri, 9 Jan 1998 15:31:31 +0300 (GMT) Subject: A Wake Up Call (fwd) Message-ID: <199801091231.PAA10258@aic.net> Please do not disregard this message. Thank you. Forwarded message: > > Would you like to see Kemal Ataturk elected as Man of the Century by Time Magazine ? > > Time Magazine has launched a campaign to choose the "Person of the Century" and Kemal Ataturk is already at the top of the list with over 1.7 million votes. We were informed that since this program's inception in June, time has been deluged by letters, > postcards, E-mail messages placing Kemal Ataturk in the top position, outpacing other prominent names such a Thomas Edison, Winston Churchill, Albert Einstein, and Madam Curie. More importantly, Time Inc. has confirmed that public opinion will in fact p > lay an influential role in their decision making process. > > There is no need to remind any of you about the horrible atrocities committed by this man toward Armenians and Greeks. Now is the time for every one of us to make our voices strenuously heard and feelings known in objecting to Time's consideration of Ke > mal Ataturk. Apparently, Time Inc. needs a total education regarding this blood-stained epoch. > > Regrettably there are at least 1.5 million "absentee ballots" crying out from their distant unmarked graves in Anatolia, protesting this potential travesty of justice. > > Please register your "NOT Kemal" vote today by > > Mail : Time 100, Room 25-48, Time & Life Building, > Rockefeller Center, New York, NY 10020 > > Fax : (212) 522-0003 or (212) 467-4736 > > E-Mail: time100 at time.com > > Phone: (212) 522-4859, Nancy Kearney, Assoc. Dir. Public Affairs > > Note: Time's President is Bruce Hallett (212) 522-5233 > From phk at critter.freebsd.dk Fri Jan 9 13:21:53 1998 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Fri, 09 Jan 1998 13:21:53 +0100 Subject: Anti-spam measures In-Reply-To: Your message of "Fri, 09 Jan 1998 12:27:33 +0100." Message-ID: <5832.884348513@critter.freebsd.dk> One of the best things to do, would probably be to make a simple turnkey kind of sendmail config available to people. It should be possible for people to maintain four files on their system and have sendmail DTRT for them after that: /etc/sendmail.our_ip: 192.168.1.0/24 10.0.0.0/22 /etc/sendmail.our_domains: foo.bar.com some.customer.domain.xx some.other.domain.xx /etc/sendmail.we_mx_for: bar.foo.com c.i.a.gov /etc/sendmail.people_we_dont_talk_to cyberpromo.com nancynet.com 203.23.43.0/24 203.43.43.0/22 Now that would be a worthwhile project to do... (and no before you ask, I'm way too busy with FreeBSD as it is) -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." "Drink MONO-tonic, it goes down but it will NEVER come back up!"  From Paul.Ridley at ripe.net Fri Jan 9 20:25:36 1998 From: Paul.Ridley at ripe.net (Paul Ridley) Date: Fri, 09 Jan 1998 20:25:36 +0100 Subject: IANA Progress Report Message-ID: <9801091925.AA02441@ncc.ripe.net> Dear all, This short report and attached document aim to keep you informed as to the developments involving IANA and the role that the RIPE NCC is playing in this. Discussions on the future of IANA are currently intensifying. During the recent IETF meeting Rob Blokzijl and Daniel Karrenberg, on behalf of the RIPE community, pursued this matter with all concerned. The US government plans to continue funding IANA until September 1998, at which time US government funding will definitely cease. The University of Southern California still holds our initial contribution and will use it if necessary. Jon Postel is working on a plan to incorporate IANA as a legal entity and to get support from IANA's direct users as well as the community at large. Incorporation is planned for the first half of this year. Consensus is emerging about the IANA services. Attached is a position paper that Rob, Daniel and myself wrote and sent as input for that process. This position paper can shortly be found on the tld-wg and lir-wg websites. A more detailed report including the latest developments will be given at the RIPE meeting. Regards Paul Ridley RIPE NCC Business Manager -------------- next part -------------- ____________________________________________________ Position Paper on IANA Structure Rob Blokzijl Daniel Karrenberg Paul Ridley Document: IANA-paper Status This document is a position paper reflected the views of the three authors. Scope The intended audience for this position paper is all interested parties concerned with the future struc- ture of IANA. Comments to the authors are welcome. 1. Introduction The position paper looks at the activities carried out by IANA and at the direct users of these activi- ties. A organisational structure for IANA is then proposed based upon the principle of bottom-up gov- ernance, in which the direct users of the IANA activities govern IANA. 2. Activities The activities that IANA now carries out have been, and will continue to be, critical for the growth and stability of the Internet. Since these activities are critical they should stand central in any ____________________________________________________ IANA-paper.txt Page 1 Position Paper on IANA Structure Blokzijl, Karrenberg, Ridley ____________________________________________________ discussion of the future structure of IANA. The activities currently carried out by IANA are the following: 2.1. Address Space Allocation and global policy forum * Provides an address space allocation/registra- tion service to the regional IRs (RIR). * Provides a process to establish global address space related policies. * Establishes a process for arbitration of con- flicts regarding these policies. * Provides coordination services to RIRs. 2.2. DNS TLD Allocation and Registration; Operation of Root Name Servers * Registers all TLDs. * Maintains root zone information. * Allocates nTLDs. gTLDs are allocated in a pro- cess outside IANA * Operates root name servers (may be delegated to individual operators). 2.3. Assigning Unique Parameters for Internet Protocols * Assigns and registers other unique parameters. 2.4. RFC Editor * Edits the RFC series of documents. * Provides a repository for these documents. 2.5. Internet Monthly Report (IMR) 3. Activity users Who are the direct users for these activities? It is stressed that the focus should be on the *direct* users as opposed to indirect users since persons even remotely connected with the Internet community could be classed as users. In order to allow scala- bility direct users who are inherently accountable (in good bottom-up fashion) to minor indirect users need to be the focus. ____________________________________________________ IANA-paper.txt Page 2 Position Paper on IANA Structure Blokzijl, Karrenberg, Ridley ____________________________________________________ If direct users are mapped to activities the follow- ing direct user groupings appear. 3.1. IP number allocation, RIR coordination and global policy forum This activity has the following direct users: * RIPE NCC * ARIN * AP-NIC * Any future RIR 3.2. DNS TLD Allocation and Registration; Operation of Root Name Servers This activity has the following direct users: * CORE * Any future coordinating points for individual TLD registries since individual representation does not scale 3.3. Assigning unique parameters for Internet protocols This activity has the following direct users: * IETF 3.4. RFC editor This activity has the following direct users: * IETF 3.5. Internet Monthly Report (IMR) This activity has the following direct users: * The Internet community in general, however it should be borne in mind that this activity is very minor in comparison to the others. It merely compliments them. From this direct user to activity mapping it becomes apparent that there are three main groupings of direct users. They are the RIRs the TLD coordination points (TLD Coord), and the IETF. It is apparent that direct users are typically regional or global ____________________________________________________ IANA-paper.txt Page 3 Position Paper on IANA Structure Blokzijl, Karrenberg, Ridley ____________________________________________________ entities. If at any time in the future other enti- ties than those mentioned become direct users of the IANA activities, then they should be recognised as such. In the discussion that follows this position paper other direct user groups will probably be mentioned. A few of these other groups are highlighted below with a explanation of why it is thought that they are not direct users but indirect users of the IANA activities. ISP's By means of the global bottom-up structures that are in place at the RIRs, the individual ISP has a voice within his own RIR community; the consensus of which the RIR brings to IANA. TLD Registries By means of the bottom up structures that are in place in the case of CORE or in the process of being started within the Regional areas (to more or less degrees) the individual TLD reg- istry has a voice within his own TLD Coord area community; the consensus of which the TLD Coord brings to IANA. Industry Industry is there to serve its client, normally an individual ISP or TLD registry, who is already represented by a direct user. If an individual industry player wants to get more involved then the option exists to put more input into the IETF or the Regional technical meetings which give advice to the RIRs. Government If, as is constantly espoused, the majority of governments want the Internet to be self-regu- lating then they should not be classed as direct users influencing policy. Their rela- tionship to the IANA activities is without doubt that they are indirect users or an inter- ested party. End user or individual An individual is always able to get involved in the IETF or the Regional technical meetings ____________________________________________________ IANA-paper.txt Page 4 Position Paper on IANA Structure Blokzijl, Karrenberg, Ridley ____________________________________________________ which give advice to the RIRs. 4. Direct user / IANA relations IANA provides (if all of the activities are kept within IANA) definite services to all three direct user groupings; the RIRs, the TLD Coords, and IETF. Thus the relationship between IANA and these groups should be concrete and governing, in the same manner as the RIRs relate with the ISPs in their region, i.e. truly bottom-up. In such a structured relation- ship only the three direct users would fund and gov- ern the IANA activities. 5. Proposed IANA organisational structure principles In order to be able to constructively discuss a pro- posed structure for IANA the various organs of the IANA organisation need to be defined. The aim here is to be clear as to what a particular organ is and does and not be discuss whether the name of a par- ticular organ is appropriate or not. It is proposed that there are three distinct organs in IANA; the general council, the executive board, and the man- agement. General Council This organ is the ruling organ in IANA and consists of representatives from every direct user. Executive Board This organ is subordinate to the general council and is responsible for the day-to-day governance of IANA. The members of the executive board are elected by the general council. Management This organ is subordinate to the executive board and is responsible for daily operations of IANA. The executive board hires the management In general the three organs are expected to interact in the following manner. All direct users have a right to have a representative(s) on the general council. Each individual direct user would be responsible for how his representative(s) are cho- sen. The general council being the ruling organ of IANA would have the responsibility to adopt annual accounts, budgets, charging schemes, and general activities of IANA. General council members would ____________________________________________________ IANA-paper.txt Page 5 Position Paper on IANA Structure Blokzijl, Karrenberg, Ridley ____________________________________________________ also be the sole funders of IANA. The general council would elect the executive board of approximately five members. The general council would be allowed to elect general council represen- tatives or external persons to be an executive board member. The terms of executive board members would be three years in a staggered rotation. The execu- tive board being responsible for day-to-day gover- nance would be responsible for, monitoring the finances of IANA, ensuring appropriate business pro- cedures are in place (including dispute procedures) and being used, legally representing IANA, and deciding upon IANAs activities within the mandate given by the general council. The executive board would report to the general council. The executive board would hire a management compris- ing of one or more persons. The management being responsible for the day-to-day operations of IANA would be responsible for IANA personnel hiring, exe- cuting of all IANA activities, financial management. The management would report to the executive board. The proposed IANA organisational structure outlined above is the governing structure. There could also be an advisory structure that compliments the gov- erning structure, but this advisory structure is not a critical success factor in the setting up of IANA. For that reason and to avoid complication, discus- sion of an advisory structure is not a topic of this position paper. 6. Open issues There are many details of the the proposed organisa- tion structure and operational rules that are not covered above. These details, the open issues, many well take time to agree upon but they are not insur- mountable. The authors feel that it is more impor- tant to first agree upon the organisation principles as outlined in this position paper before delving into the open issue details. Examples of open issues that must be addressed are: * although the direct users have been outlined in general the specific direct users need to be identified. * what criteria will be used to determine how many representatives each individual direct user has in the general council. ____________________________________________________ IANA-paper.txt Page 6 Position Paper on IANA Structure Blokzijl, Karrenberg, Ridley ____________________________________________________ * what mechanism will be used to elect executive board members * what is the usefulness of the IMR and can it be developed * what are the activity related budgets for IANA * what mechanism is used to determine how much each individual direct user is charged for the IANA services. 7. Summary The outline proposal given above is, in the opinion of the authors, the fairest and most stable way of structuring IANA in the future and thus gives most stability to the Internet. This proposal is true to the aim of global bottom-up governance within the Internet and is definitely global industry self-reg- ulating. By following a true bottom-up model (i.e. governance and funding by the direct users) democ- racy is enhanced together with the crucial impar- tiality of IANA. If parties other than the direct users were structurally able to fund and influence the IANA activities then this bottom-up democratic aim would not be achieved and more importantly the crucial impartiality of IANA would be questionable. ____________________________________________________ IANA-paper.txt Page 7 From tossu at katiska.clinet.fi Sat Jan 10 13:19:11 1998 From: tossu at katiska.clinet.fi (Sami Koskinen) Date: Sat, 10 Jan 1998 14:19:11 +0200 (EET) Subject: Anti-spam measures In-Reply-To: <5832.884348513@critter.freebsd.dk> Message-ID: On Fri, 9 Jan 1998, Poul-Henning Kamp wrote: > > One of the best things to do, would probably be to make a simple turnkey > kind of sendmail config available to people. What I think as the best solution is to patch sendmail to check from the name service if we really are in the mx list for the incoming mail. This would eliminate the need to store the same information to some other place, as we already have the information stored in the name service. To my understanding this is not possible to do simply by tweaking the configuration file, but it requires some patches to the actual code. And now some coffee to wake me up. :-) --sami From Paul.Ridley at ripe.net Fri Jan 9 20:25:36 1998 From: Paul.Ridley at ripe.net (Paul Ridley) Date: Fri, 09 Jan 1998 20:25:36 +0100 Subject: IANA Progress Report Message-ID: <9801091925.AA02441@ncc.ripe.net> Dear all, This short report and attached document aim to keep you informed as to the developments involving IANA and the role that the RIPE NCC is playing in this. Discussions on the future of IANA are currently intensifying. During the recent IETF meeting Rob Blokzijl and Daniel Karrenberg, on behalf of the RIPE community, pursued this matter with all concerned. The US government plans to continue funding IANA until September 1998, at which time US government funding will definitely cease. The University of Southern California still holds our initial contribution and will use it if necessary. Jon Postel is working on a plan to incorporate IANA as a legal entity and to get support from IANA's direct users as well as the community at large. Incorporation is planned for the first half of this year. Consensus is emerging about the IANA services. Attached is a position paper that Rob, Daniel and myself wrote and sent as input for that process. This position paper can shortly be found on the tld-wg and lir-wg websites. A more detailed report including the latest developments will be given at the RIPE meeting. Regards Paul Ridley RIPE NCC Business Manager -------------- next part -------------- ____________________________________________________ Position Paper on IANA Structure Rob Blokzijl Daniel Karrenberg Paul Ridley Document: IANA-paper Status This document is a position paper reflected the views of the three authors. Scope The intended audience for this position paper is all interested parties concerned with the future struc- ture of IANA. Comments to the authors are welcome. 1. Introduction The position paper looks at the activities carried out by IANA and at the direct users of these activi- ties. A organisational structure for IANA is then proposed based upon the principle of bottom-up gov- ernance, in which the direct users of the IANA activities govern IANA. 2. Activities The activities that IANA now carries out have been, and will continue to be, critical for the growth and stability of the Internet. Since these activities are critical they should stand central in any ____________________________________________________ IANA-paper.txt Page 1 Position Paper on IANA Structure Blokzijl, Karrenberg, Ridley ____________________________________________________ discussion of the future structure of IANA. The activities currently carried out by IANA are the following: 2.1. Address Space Allocation and global policy forum * Provides an address space allocation/registra- tion service to the regional IRs (RIR). * Provides a process to establish global address space related policies. * Establishes a process for arbitration of con- flicts regarding these policies. * Provides coordination services to RIRs. 2.2. DNS TLD Allocation and Registration; Operation of Root Name Servers * Registers all TLDs. * Maintains root zone information. * Allocates nTLDs. gTLDs are allocated in a pro- cess outside IANA * Operates root name servers (may be delegated to individual operators). 2.3. Assigning Unique Parameters for Internet Protocols * Assigns and registers other unique parameters. 2.4. RFC Editor * Edits the RFC series of documents. * Provides a repository for these documents. 2.5. Internet Monthly Report (IMR) 3. Activity users Who are the direct users for these activities? It is stressed that the focus should be on the *direct* users as opposed to indirect users since persons even remotely connected with the Internet community could be classed as users. In order to allow scala- bility direct users who are inherently accountable (in good bottom-up fashion) to minor indirect users need to be the focus. ____________________________________________________ IANA-paper.txt Page 2 Position Paper on IANA Structure Blokzijl, Karrenberg, Ridley ____________________________________________________ If direct users are mapped to activities the follow- ing direct user groupings appear. 3.1. IP number allocation, RIR coordination and global policy forum This activity has the following direct users: * RIPE NCC * ARIN * AP-NIC * Any future RIR 3.2. DNS TLD Allocation and Registration; Operation of Root Name Servers This activity has the following direct users: * CORE * Any future coordinating points for individual TLD registries since individual representation does not scale 3.3. Assigning unique parameters for Internet protocols This activity has the following direct users: * IETF 3.4. RFC editor This activity has the following direct users: * IETF 3.5. Internet Monthly Report (IMR) This activity has the following direct users: * The Internet community in general, however it should be borne in mind that this activity is very minor in comparison to the others. It merely compliments them. From this direct user to activity mapping it becomes apparent that there are three main groupings of direct users. They are the RIRs the TLD coordination points (TLD Coord), and the IETF. It is apparent that direct users are typically regional or global ____________________________________________________ IANA-paper.txt Page 3 Position Paper on IANA Structure Blokzijl, Karrenberg, Ridley ____________________________________________________ entities. If at any time in the future other enti- ties than those mentioned become direct users of the IANA activities, then they should be recognised as such. In the discussion that follows this position paper other direct user groups will probably be mentioned. A few of these other groups are highlighted below with a explanation of why it is thought that they are not direct users but indirect users of the IANA activities. ISP's By means of the global bottom-up structures that are in place at the RIRs, the individual ISP has a voice within his own RIR community; the consensus of which the RIR brings to IANA. TLD Registries By means of the bottom up structures that are in place in the case of CORE or in the process of being started within the Regional areas (to more or less degrees) the individual TLD reg- istry has a voice within his own TLD Coord area community; the consensus of which the TLD Coord brings to IANA. Industry Industry is there to serve its client, normally an individual ISP or TLD registry, who is already represented by a direct user. If an individual industry player wants to get more involved then the option exists to put more input into the IETF or the Regional technical meetings which give advice to the RIRs. Government If, as is constantly espoused, the majority of governments want the Internet to be self-regu- lating then they should not be classed as direct users influencing policy. Their rela- tionship to the IANA activities is without doubt that they are indirect users or an inter- ested party. End user or individual An individual is always able to get involved in the IETF or the Regional technical meetings ____________________________________________________ IANA-paper.txt Page 4 Position Paper on IANA Structure Blokzijl, Karrenberg, Ridley ____________________________________________________ which give advice to the RIRs. 4. Direct user / IANA relations IANA provides (if all of the activities are kept within IANA) definite services to all three direct user groupings; the RIRs, the TLD Coords, and IETF. Thus the relationship between IANA and these groups should be concrete and governing, in the same manner as the RIRs relate with the ISPs in their region, i.e. truly bottom-up. In such a structured relation- ship only the three direct users would fund and gov- ern the IANA activities. 5. Proposed IANA organisational structure principles In order to be able to constructively discuss a pro- posed structure for IANA the various organs of the IANA organisation need to be defined. The aim here is to be clear as to what a particular organ is and does and not be discuss whether the name of a par- ticular organ is appropriate or not. It is proposed that there are three distinct organs in IANA; the general council, the executive board, and the man- agement. General Council This organ is the ruling organ in IANA and consists of representatives from every direct user. Executive Board This organ is subordinate to the general council and is responsible for the day-to-day governance of IANA. The members of the executive board are elected by the general council. Management This organ is subordinate to the executive board and is responsible for daily operations of IANA. The executive board hires the management In general the three organs are expected to interact in the following manner. All direct users have a right to have a representative(s) on the general council. Each individual direct user would be responsible for how his representative(s) are cho- sen. The general council being the ruling organ of IANA would have the responsibility to adopt annual accounts, budgets, charging schemes, and general activities of IANA. General council members would ____________________________________________________ IANA-paper.txt Page 5 Position Paper on IANA Structure Blokzijl, Karrenberg, Ridley ____________________________________________________ also be the sole funders of IANA. The general council would elect the executive board of approximately five members. The general council would be allowed to elect general council represen- tatives or external persons to be an executive board member. The terms of executive board members would be three years in a staggered rotation. The execu- tive board being responsible for day-to-day gover- nance would be responsible for, monitoring the finances of IANA, ensuring appropriate business pro- cedures are in place (including dispute procedures) and being used, legally representing IANA, and deciding upon IANAs activities within the mandate given by the general council. The executive board would report to the general council. The executive board would hire a management compris- ing of one or more persons. The management being responsible for the day-to-day operations of IANA would be responsible for IANA personnel hiring, exe- cuting of all IANA activities, financial management. The management would report to the executive board. The proposed IANA organisational structure outlined above is the governing structure. There could also be an advisory structure that compliments the gov- erning structure, but this advisory structure is not a critical success factor in the setting up of IANA. For that reason and to avoid complication, discus- sion of an advisory structure is not a topic of this position paper. 6. Open issues There are many details of the the proposed organisa- tion structure and operational rules that are not covered above. These details, the open issues, many well take time to agree upon but they are not insur- mountable. The authors feel that it is more impor- tant to first agree upon the organisation principles as outlined in this position paper before delving into the open issue details. Examples of open issues that must be addressed are: * although the direct users have been outlined in general the specific direct users need to be identified. * what criteria will be used to determine how many representatives each individual direct user has in the general council. ____________________________________________________ IANA-paper.txt Page 6 Position Paper on IANA Structure Blokzijl, Karrenberg, Ridley ____________________________________________________ * what mechanism will be used to elect executive board members * what is the usefulness of the IMR and can it be developed * what are the activity related budgets for IANA * what mechanism is used to determine how much each individual direct user is charged for the IANA services. 7. Summary The outline proposal given above is, in the opinion of the authors, the fairest and most stable way of structuring IANA in the future and thus gives most stability to the Internet. This proposal is true to the aim of global bottom-up governance within the Internet and is definitely global industry self-reg- ulating. By following a true bottom-up model (i.e. governance and funding by the direct users) democ- racy is enhanced together with the crucial impar- tiality of IANA. If parties other than the direct users were structurally able to fund and influence the IANA activities then this bottom-up democratic aim would not be achieved and more importantly the crucial impartiality of IANA would be questionable. ____________________________________________________ IANA-paper.txt Page 7 From tossu at katiska.clinet.fi Sat Jan 10 13:19:11 1998 From: tossu at katiska.clinet.fi (Sami Koskinen) Date: Sat, 10 Jan 1998 14:19:11 +0200 (EET) Subject: Anti-spam measures In-Reply-To: <5832.884348513@critter.freebsd.dk> Message-ID: On Fri, 9 Jan 1998, Poul-Henning Kamp wrote: > > One of the best things to do, would probably be to make a simple turnkey > kind of sendmail config available to people. What I think as the best solution is to patch sendmail to check from the name service if we really are in the mx list for the incoming mail. This would eliminate the need to store the same information to some other place, as we already have the information stored in the name service. To my understanding this is not possible to do simply by tweaking the configuration file, but it requires some patches to the actual code. And now some coffee to wake me up. :-) --sami From johnpc at xs4all.net Mon Jan 12 09:52:31 1998 From: johnpc at xs4all.net (Jan-Pieter Cornet) Date: Mon, 12 Jan 1998 09:52:31 +0100 (MET) Subject: Anti-spam measures In-Reply-To: from Sami Koskinen at "Jan 10, 98 02:19:11 pm" Message-ID: <199801120852.JAA01480@xs1.xs4all.nl> Sami Koskinen wrote: > > One of the best things to do, would probably be to make a simple turnkey > > kind of sendmail config available to people. > > What I think as the best solution is to patch sendmail > to check from the name service if we really are in the > mx list for the incoming mail. This would eliminate > the need to store the same information to some other > place, as we already have the information stored in > the name service. To my understanding this is not possible > to do simply by tweaking the configuration file, but > it requires some patches to the actual code. Such a patch exists. Get it at http://homepage.cistron.nl/~miquels/nospam/ We use it, and have been using it for quite some time now. It only needs integration with the sendmail-8.8.8-cf suite, to call Parse0 to filter local crud before applying the anti-relay rules. -- #! ##### Jan-Pieter Cornet ##### ##### perl ++$_;$!=$_+++$_;($:,$,,$/,$*)=$!=~/.(.)...(.)(.).(.)/;$!=$_+$_; ($@,$\,$~)=$!=~/(.)(.).(.)/; $_="$,$/$:"; $@++; $~="$~$_";($_)= \$$=~/\((.)/;$|=++$_;$_++;$|++;$~="$~ $@$:";`$~$/$\$*$, $|>&$_` From zsako at banknet.net Mon Jan 12 10:00:46 1998 From: zsako at banknet.net (Janos Zsako) Date: Mon, 12 Jan 98 10:00:46 +0100 Subject: Anti-spam measures Message-ID: <9801120900.AA10930@banknet.banknet.net> > From owner-lir-wg at ripe.net Mon Jan 12 09:27:45 1998 > From: Sami Koskinen > On Fri, 9 Jan 1998, Poul-Henning Kamp wrote: > > > > > One of the best things to do, would probably be to make a simple turnkey > > kind of sendmail config available to people. > > What I think as the best solution is to patch sendmail > to check from the name service if we really are in the > mx list for the incoming mail. This would eliminate > the need to store the same information to some other > place, as we already have the information stored in > the name service. The idea is good indeed. I am, however, somewhat concerned about the following potential dangers: 1. The DNS can contain bogus info (including MX records). 2. You could be a victim of a malicious setup. For example, the primary of foo.domain puts an MX to one of your hosts protected in the way you suggest. When the secondaries have updated the zone, you get a large number of spam destined for foo.domain. Your resources may be abused, and you can even suffer a DoS. (At the same time, foo.domain may even filter out SMTP connections from you, to make sure *his* resources are not wasted...). To summarize, I feel it would be very good to use the info in the DNS, (in order to avoid redundancy in configuration and possible misconfigurations), however the DNS data may not be trustworthy, especially for the zones you are not authoritative for. One should balance between the advantages the suggested patch would bring and the dangers it exposes the user to... I personally would feel more confortable to explicitely allow myself the domains I want to relay, in spite of the extra work and possible misconfiguration. Just my 0.02$. Janos From andre at ml.ee Mon Jan 12 12:34:42 1998 From: andre at ml.ee (Andres Kroonmaa) Date: Mon, 12 Jan 1998 13:34:42 +0200 (EETDST) Subject: Anti-spam measures In-Reply-To: <9801120900.AA10930@banknet.banknet.net> Message-ID: <7F69EDD4109@mail.lbi.ee> > > > > > > One of the best things to do, would probably be to make a simple turnkey > > > kind of sendmail config available to people. > > > > What I think as the best solution is to patch sendmail > > to check from the name service if we really are in the > > mx list for the incoming mail. This would eliminate > > the need to store the same information to some other > > place, as we already have the information stored in > > the name service. > > The idea is good indeed. I am, however, somewhat concerned about > the following potential dangers: Here are some of my personal thoughts on spam problem and one idea on how to deal with it. I've had these for quite some time, but somehow was unsure about applicability, and actually still isn't. Maybe you'll find it interesting, or find it unusable pretty fast. Anyway, I'd like to hear any comments. Spam will not be gone until it is either impossible or technically much too troublesome. Legal regulations don't work and won't until most of the world follows this. What might worry ISP-s is that when actually major fake-mail case will pop up, causing some party major losses due to maliceous intent, lawyers would ask ISP's what have they done to restrict fake-mail possibility? Long before such case it can be easy to keep an URL on a web page stating that email is not secure, but when someone gets really bitten, they would claim its not enough. You SHOULD do something about it. And currently there is almost nothing you can do. Some SMTP mail software have to be modified, some RFC-s be written, followed and enforced. Who would do that? Whatever we might wish, fake mail and spam will not be gone until it is taken under the control. Who else should start the process if not the ISP-s who are the major cause of the damn trouble and the most victims? Spamming methods. 1) spam is anonymous fake email with fake headers almost always. 2) spam is injected to open relays with no authentication whatsoever. 3) site whose domain the spam is faking usually does not permit spamming, but has no control over its domain being used by spammers. Possible solution: 1) mail Sender is accepted ONLY from an IP address, that is on the list of MX hosts for the sender's domain. Relay on DNS authority. DNS fakings is probably solvable temporary problem. This: a) Rejects non-existing domain senders, configuration errors. b) Rejects mail from relays that are used for injecting unauthenticated email sender. c) Brakes happyness of those people, who love to use single email address but injects mail wherever they can... This is wrong behaviour in the first place, and could be fixed by 3) 2) Mail Recipient is accepted ONLY for domain, which is on the MX list with receiver SMTP server, AND is allowed to be relayed. 3) EMail can be injected into SMTP world only via pop3 or similar, after authenicating senders username/password. Envelope-senders return-path would be out of control of luser and ideally always correct. As dialin PC-s usually don't have MX, they would not be allowed to inject mail via SMTP server, but only via pop3 or similar. Or, ISP that hosts those dialins could define an MX for its mailserver, making it possible to its user population to inject mail via his mail server only and thus make slow transition. It would be needed to add POST method to pop3 or any other authenticated mail protocol widely used. This is the most problem with this scheme, but could be solved if principally accepted. End result: 1) End-users ideally would not be able to inject email into SMTP world otherwise than by authenticating themselves to their home-server. 2) SMTP world operates only with mail messages that are expected to be authenticated by some mail server. Without authentication, users cannot inject mail altogether, thus closed accounts are really cut off. 3) SMTP world relays mail only from valid MX-list to valid MX-list, anything that violates this is rejected. Control over originating sender hosts is given to remote domain DNS administration, control over relaying is given to local DNS administration. It is possible to ensure that no single mail message is faked within a community of SMTP servers implementing this. (IMHO) 4) SMTP servers that do not follow this continue to operate for their valid MX-ed domains, but are unable to deliver "fake" mail to those that do follow this scheme. Eventually this would force to take measures for all sites. 5) the more SMTP server become so strict, the less spam is left around. 6) SMTP servers that follow this scheme, but relay spam, are subject to RBL, blacklists or other means of Internet enforcement. ---------------------------------------------------------------------- Andres Kroonmaa mail: andre at online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ---------------------------------------------------------------------- From miquels at cistron.nl Mon Jan 12 14:08:11 1998 From: miquels at cistron.nl (Miquel van Smoorenburg) Date: Mon, 12 Jan 1998 14:08:11 +0100 Subject: Anti-spam measures In-Reply-To: <9801120900.AA10930@banknet.banknet.net>; from Janos Zsako on Mon, Jan 12, 1998 at 10:00:46AM +0100 References: <9801120900.AA10930@banknet.banknet.net> Message-ID: <19980112140811.59779@cistron.nl> According to Janos Zsako: > > What I think as the best solution is to patch sendmail > > to check from the name service if we really are in the > > mx list for the incoming mail. We have been doing that for half a year now, and it works fine. > The idea is good indeed. I am, however, somewhat concerned about > the following potential dangers: > > 1. The DNS can contain bogus info (including MX records). Well if the MX record is wrong, you won't get any email anyway. > 2. You could be a victim of a malicious setup. For example, the primary > of foo.domain puts an MX to one of your hosts protected in the way you > suggest. When the secondaries have updated the zone, you get a large > number of spam destined for foo.domain. Your resources may be abused, > and you can even suffer a DoS. (At the same time, foo.domain may even > filter out SMTP connections from you, to make sure *his* resources are > not wasted...). So they setup their *own* nameserver to spam their *own* domain using you as a relay? Not very likely.. No, the real problem is when a MX is moved to another host. Cached MX records on other nameservers will cause the mail to be sent to the old MX, which doesn't accept it anymore. This _can _ cause bounced email if you are not careful (like lowering TTL 1 day before the tranfer, etc) Mike. -- Miquel van Smoorenburg | The dyslexic, agnostic, insomniac lay in his bed miquels at cistron.nl | awake all night wondering if there is a doG From johnpc at xs4all.net Mon Jan 12 09:52:31 1998 From: johnpc at xs4all.net (Jan-Pieter Cornet) Date: Mon, 12 Jan 1998 09:52:31 +0100 (MET) Subject: Anti-spam measures In-Reply-To: from Sami Koskinen at "Jan 10, 98 02:19:11 pm" Message-ID: <199801120852.JAA01480@xs1.xs4all.nl> Sami Koskinen wrote: > > One of the best things to do, would probably be to make a simple turnkey > > kind of sendmail config available to people. > > What I think as the best solution is to patch sendmail > to check from the name service if we really are in the > mx list for the incoming mail. This would eliminate > the need to store the same information to some other > place, as we already have the information stored in > the name service. To my understanding this is not possible > to do simply by tweaking the configuration file, but > it requires some patches to the actual code. Such a patch exists. Get it at http://homepage.cistron.nl/~miquels/nospam/ We use it, and have been using it for quite some time now. It only needs integration with the sendmail-8.8.8-cf suite, to call Parse0 to filter local crud before applying the anti-relay rules. -- #! ##### Jan-Pieter Cornet ##### ##### perl ++$_;$!=$_+++$_;($:,$,,$/,$*)=$!=~/.(.)...(.)(.).(.)/;$!=$_+$_; ($@,$\,$~)=$!=~/(.)(.).(.)/; $_="$,$/$:"; $@++; $~="$~$_";($_)= \$$=~/\((.)/;$|=++$_;$_++;$|++;$~="$~ $@$:";`$~$/$\$*$, $|>&$_` From miquels at cistron.nl Mon Jan 12 14:08:11 1998 From: miquels at cistron.nl (Miquel van Smoorenburg) Date: Mon, 12 Jan 1998 14:08:11 +0100 Subject: Anti-spam measures In-Reply-To: <9801120900.AA10930@banknet.banknet.net>; from Janos Zsako on Mon, Jan 12, 1998 at 10:00:46AM +0100 References: <9801120900.AA10930@banknet.banknet.net> Message-ID: <19980112140811.59779@cistron.nl> According to Janos Zsako: > > What I think as the best solution is to patch sendmail > > to check from the name service if we really are in the > > mx list for the incoming mail. We have been doing that for half a year now, and it works fine. > The idea is good indeed. I am, however, somewhat concerned about > the following potential dangers: > > 1. The DNS can contain bogus info (including MX records). Well if the MX record is wrong, you won't get any email anyway. > 2. You could be a victim of a malicious setup. For example, the primary > of foo.domain puts an MX to one of your hosts protected in the way you > suggest. When the secondaries have updated the zone, you get a large > number of spam destined for foo.domain. Your resources may be abused, > and you can even suffer a DoS. (At the same time, foo.domain may even > filter out SMTP connections from you, to make sure *his* resources are > not wasted...). So they setup their *own* nameserver to spam their *own* domain using you as a relay? Not very likely.. No, the real problem is when a MX is moved to another host. Cached MX records on other nameservers will cause the mail to be sent to the old MX, which doesn't accept it anymore. This _can _ cause bounced email if you are not careful (like lowering TTL 1 day before the tranfer, etc) Mike. -- Miquel van Smoorenburg | The dyslexic, agnostic, insomniac lay in his bed miquels at cistron.nl | awake all night wondering if there is a doG From andre at ml.ee Mon Jan 12 12:34:42 1998 From: andre at ml.ee (Andres Kroonmaa) Date: Mon, 12 Jan 1998 13:34:42 +0200 (EETDST) Subject: Anti-spam measures In-Reply-To: <9801120900.AA10930@banknet.banknet.net> Message-ID: <7F69EDD4109@mail.lbi.ee> > > > > > > One of the best things to do, would probably be to make a simple turnkey > > > kind of sendmail config available to people. > > > > What I think as the best solution is to patch sendmail > > to check from the name service if we really are in the > > mx list for the incoming mail. This would eliminate > > the need to store the same information to some other > > place, as we already have the information stored in > > the name service. > > The idea is good indeed. I am, however, somewhat concerned about > the following potential dangers: Here are some of my personal thoughts on spam problem and one idea on how to deal with it. I've had these for quite some time, but somehow was unsure about applicability, and actually still isn't. Maybe you'll find it interesting, or find it unusable pretty fast. Anyway, I'd like to hear any comments. Spam will not be gone until it is either impossible or technically much too troublesome. Legal regulations don't work and won't until most of the world follows this. What might worry ISP-s is that when actually major fake-mail case will pop up, causing some party major losses due to maliceous intent, lawyers would ask ISP's what have they done to restrict fake-mail possibility? Long before such case it can be easy to keep an URL on a web page stating that email is not secure, but when someone gets really bitten, they would claim its not enough. You SHOULD do something about it. And currently there is almost nothing you can do. Some SMTP mail software have to be modified, some RFC-s be written, followed and enforced. Who would do that? Whatever we might wish, fake mail and spam will not be gone until it is taken under the control. Who else should start the process if not the ISP-s who are the major cause of the damn trouble and the most victims? Spamming methods. 1) spam is anonymous fake email with fake headers almost always. 2) spam is injected to open relays with no authentication whatsoever. 3) site whose domain the spam is faking usually does not permit spamming, but has no control over its domain being used by spammers. Possible solution: 1) mail Sender is accepted ONLY from an IP address, that is on the list of MX hosts for the sender's domain. Relay on DNS authority. DNS fakings is probably solvable temporary problem. This: a) Rejects non-existing domain senders, configuration errors. b) Rejects mail from relays that are used for injecting unauthenticated email sender. c) Brakes happyness of those people, who love to use single email address but injects mail wherever they can... This is wrong behaviour in the first place, and could be fixed by 3) 2) Mail Recipient is accepted ONLY for domain, which is on the MX list with receiver SMTP server, AND is allowed to be relayed. 3) EMail can be injected into SMTP world only via pop3 or similar, after authenicating senders username/password. Envelope-senders return-path would be out of control of luser and ideally always correct. As dialin PC-s usually don't have MX, they would not be allowed to inject mail via SMTP server, but only via pop3 or similar. Or, ISP that hosts those dialins could define an MX for its mailserver, making it possible to its user population to inject mail via his mail server only and thus make slow transition. It would be needed to add POST method to pop3 or any other authenticated mail protocol widely used. This is the most problem with this scheme, but could be solved if principally accepted. End result: 1) End-users ideally would not be able to inject email into SMTP world otherwise than by authenticating themselves to their home-server. 2) SMTP world operates only with mail messages that are expected to be authenticated by some mail server. Without authentication, users cannot inject mail altogether, thus closed accounts are really cut off. 3) SMTP world relays mail only from valid MX-list to valid MX-list, anything that violates this is rejected. Control over originating sender hosts is given to remote domain DNS administration, control over relaying is given to local DNS administration. It is possible to ensure that no single mail message is faked within a community of SMTP servers implementing this. (IMHO) 4) SMTP servers that do not follow this continue to operate for their valid MX-ed domains, but are unable to deliver "fake" mail to those that do follow this scheme. Eventually this would force to take measures for all sites. 5) the more SMTP server become so strict, the less spam is left around. 6) SMTP servers that follow this scheme, but relay spam, are subject to RBL, blacklists or other means of Internet enforcement. ---------------------------------------------------------------------- Andres Kroonmaa mail: andre at online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ---------------------------------------------------------------------- From pbj at DK.net Mon Jan 12 15:10:40 1998 From: pbj at DK.net (Peter B. Juul) Date: Mon, 12 Jan 1998 15:10:40 +0100 (MET) Subject: Anti-spam measures In-Reply-To: <19980112140811.59779@cistron.nl> Message-ID: On Mon, 12 Jan 1998, Miquel van Smoorenburg wrote: > So they setup their *own* nameserver to spam their *own* domain using > you as a relay? Not very likely.. Well, we have a number of customers, that use mail-software, which is unable to follow the mail the whole way through, and simply dumps it on out mail-server expecting us to do the hard work - which we gladly do, as they pay us to do so :-) > > No, the real problem is when a MX is moved to another host. Cached MX > records on other nameservers will cause the mail to be sent to the > old MX, which doesn't accept it anymore. This _can _ cause bounced email > if you are not careful (like lowering TTL 1 day before the tranfer, etc) > > Mike. > -- > Miquel van Smoorenburg | The dyslexic, agnostic, insomniac lay in his bed > miquels at cistron.nl | awake all night wondering if there is a doG > > Peter B. Juul, DKnet. From pbj at DK.net Mon Jan 12 15:19:55 1998 From: pbj at DK.net (Peter B. Juul) Date: Mon, 12 Jan 1998 15:19:55 +0100 (MET) Subject: Anti-spam measures In-Reply-To: Message-ID: On Mon, 12 Jan 1998, Peter B. Juul wrote: > Well, we have a number of customers, that use mail-software, which is > unable to follow the mail the whole way through, and simply dumps it on > out mail-server expecting us to do the hard work - which we gladly do, as > they pay us to do so :-) Oops, please disregard this mail, as I decided not to finish writing it, and hit ^X instead of ^C. Peter B. Juul, DKnet. From Daniel.Karrenberg at ripe.net Mon Jan 12 17:57:39 1998 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 12 Jan 1998 17:57:39 +0100 Subject: Anti-spam measures In-Reply-To: Your message of Mon, 12 Jan 1998 13:34:42 +0200. <7F69EDD4109@mail.lbi.ee> References: <7F69EDD4109@mail.lbi.ee> Message-ID: <9801121657.AA24611@ncc.ripe.net> > "Andres Kroonmaa" writes: > ... > 3) EMail can be injected into SMTP world only via pop3 or similar, after > authenicating senders username/password. > Envelope-senders return-path would be out of control of luser and > ideally always correct. > ... > It would be needed to add POST method to pop3 or any other > authenticated mail protocol widely used. This is the most problem with > this scheme, but could be solved if principally accepted. Some people use a hack sometimes called "submit after POP" which solves this problem. It allows a host that recently -say in the last 15 minutes- has had an authenticated POP session to retrieve mail, to relay mail to external domains. The beauty of this is that you do not need a new protocol or new client software. The only thing you need is to tell your users that they have to pick up mail before sending any. Experience shows that users understand that concept and most of them can successfully implement it. The downside of it is that you end up configuring your SMTP MTA from the POP logfiles... but you can use the authentication info in the log files to veryfy sender addresses ... Summary: A really gross hack but it works. Daniel From niels at euro.net Mon Jan 12 19:07:32 1998 From: niels at euro.net (Niels Bakker) Date: Mon, 12 Jan 1998 19:07:32 +0100 (MET) Subject: Anti-spam measures In-Reply-To: <199801120852.JAA01480@xs1.xs4all.nl> Message-ID: <980112190540.9980A-100000@venus.euro.net> > Such a patch exists. Get it at http://homepage.cistron.nl/~miquels/nospam/ JC! Guru! Great minds think alike. :-) (I noted it in private email) > We use it, and have been using it for quite some time now. It only needs > integration with the sendmail-8.8.8-cf suite, to call Parse0 to filter > local crud before applying the anti-relay rules. I actually just updated it for 8.8.8 (re-made the .diff and rewrote the .cf stuff so that it actually works!). Miquel van Smoorenburg has just updated his homepage. -- Niels Bakker, * * EuroNet Internet BV Network Operations * * Herengracht 208-214 * 1016 BS Amsterdam NJB9 * +31 (0)20 535 5555 From phk at critter.freebsd.dk Mon Jan 12 21:15:49 1998 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Mon, 12 Jan 1998 21:15:49 +0100 Subject: Anti-spam measures In-Reply-To: Your message of "Mon, 12 Jan 1998 13:34:42 +0200." <7F69EDD4109@mail.lbi.ee> Message-ID: <1069.884636149@critter.freebsd.dk> Andres, You have some very good ideas, which if concensus could be reached would help a few years down the road. I think most of your ideas a worth persuing and RIPE would be a good forum for doing so. I have been thinking about something much more easily implemented: Participating ISPs adds a TEXT record in DNS for the IP numbers of all their dial-in ports which say W.X.Y.Z.IN_ADDR.ARPA. IN TXT "NOSMTP" Sendmails refuse email from such IP#, unless specifically instructed otherwise (ie: at the home ISP of the ports). How is that for a short term solution ? This allows responsible ISPs to clearly signal to the rest of the net that "Don't trust this guy for SMTP". If we could get UUnet, sprint, ibm.net, compuserve.com and so on to add those records, then life would be much easier over here... -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." "Drink MONO-tonic, it goes down but it will NEVER come back up!" From andre at ml.ee Tue Jan 13 09:47:10 1998 From: andre at ml.ee (Andres Kroonmaa) Date: Tue, 13 Jan 1998 10:47:10 +0200 (EETDST) Subject: Anti-spam measures In-Reply-To: <1069.884636149@critter.freebsd.dk> References: Your message of "Mon, 12 Jan 1998 13:34:42 +0200." <7F69EDD4109@mail.lbi.ee> Message-ID: <80BD4730EFE@mail.lbi.ee> > > I have been thinking about something much more easily implemented: > > Participating ISPs adds a TEXT record in DNS for the IP numbers > of all their dial-in ports which say > > W.X.Y.Z.IN_ADDR.ARPA. IN TXT "NOSMTP" > > Sendmails refuse email from such IP#, unless specifically instructed > otherwise (ie: at the home ISP of the ports). > > How is that for a short term solution ? > > This allows responsible ISPs to clearly signal to the rest of the > net that "Don't trust this guy for SMTP". I believe there are lots of possible short term solutions, or hacks. Many of them are very good and working. But their most problem is that they call for free cooperation, not a standard. I believe that every single sysop already ten years ago knew dead sure that SMTP is totally unsecure and is calling for trouble. At these days perhaps noone could imagine that the first real trouble would be spam, perhaps people were more afraid of fake mail fraud. It is probably unrealistic to implement SMTP authentication or strict SMTP interdomain (or interAS) routing. SMTP so deeply depends on trust of remote site that it has overgrown for now. Your proposed method perhaps works ok, if all follow that, but it is IMHO allow-all-deny-some policy, and as such, prone to human errors and plain time-shortage (or carelessness). I'd wish to see a kind of follow-rules-or-it-simply-doesn't-work policy. To enforce that for now, we for eg. force all our dialin users to use our mail server as mail relay, thus we can always track down exactly who was the abuser. By also running anti-spam patches we filter our all sort of invalid domains. Spammers are not common here. So, we don't need that TXT record in the dns at all. If we have a spammer, we are very deeply worried about it, because we take responsibility for what our users do under our name. But this is not widely adopted policy, you know. Now, what I'd really like to be sure in, is that no other host on earth ever uses successfully our domain name for spamming, and I feel that the only way to ensure this would be a technical solution that makes this impossible. Simple rule that you can receive a message from a domain _only_ from a host responsible for that domain cuts off all kind of outsiders who might wish to spam with your name. But, for this rule to have any power, it have to be a standard. By implementing widely proposed method, we'd effectively force all internet users to use their home mail server, thus making it possible at least in theory to track down any spammer. And if added the only way to post mail message is via authenticated pop3 session, we can make sure that locked users never appear on the net again. Thus we can still make authenticated SMTP service, sort of.. Only then we can talk about trust between different sites. If you don't trust remote site, you can cut it off in worst case. If you do trust, then you rely on responsibility of remote administration and this usually works ok. What I basically propose, is to reduce anarchy in SMTP world before its too late. I'd love to see new RFC on SMTP, that pretty strictly specifies how SMTP servers and clients MUST behave, leaving out end-nodes and hinting that end-users should (or must) use other means to inject email messages to the SMTP world. Then, ideally, update RFC on pop3 to add method to inject mail from there and call for vendors to follow this RFC. After some time, when enough client software appears, make a slow switch, cutting off non-followers. ---------------------------------------------------------------------- Andres Kroonmaa mail: andre at online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ---------------------------------------------------------------------- From Daniel.Karrenberg at ripe.net Mon Jan 12 17:57:39 1998 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 12 Jan 1998 17:57:39 +0100 Subject: Anti-spam measures In-Reply-To: Your message of Mon, 12 Jan 1998 13:34:42 +0200. <7F69EDD4109@mail.lbi.ee> References: <7F69EDD4109@mail.lbi.ee> Message-ID: <9801121657.AA24611@ncc.ripe.net> > "Andres Kroonmaa" writes: > ... > 3) EMail can be injected into SMTP world only via pop3 or similar, after > authenicating senders username/password. > Envelope-senders return-path would be out of control of luser and > ideally always correct. > ... > It would be needed to add POST method to pop3 or any other > authenticated mail protocol widely used. This is the most problem with > this scheme, but could be solved if principally accepted. Some people use a hack sometimes called "submit after POP" which solves this problem. It allows a host that recently -say in the last 15 minutes- has had an authenticated POP session to retrieve mail, to relay mail to external domains. The beauty of this is that you do not need a new protocol or new client software. The only thing you need is to tell your users that they have to pick up mail before sending any. Experience shows that users understand that concept and most of them can successfully implement it. The downside of it is that you end up configuring your SMTP MTA from the POP logfiles... but you can use the authentication info in the log files to veryfy sender addresses ... Summary: A really gross hack but it works. Daniel From phk at critter.freebsd.dk Mon Jan 12 21:15:49 1998 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Mon, 12 Jan 1998 21:15:49 +0100 Subject: Anti-spam measures In-Reply-To: Your message of "Mon, 12 Jan 1998 13:34:42 +0200." <7F69EDD4109@mail.lbi.ee> Message-ID: <1069.884636149@critter.freebsd.dk> Andres, You have some very good ideas, which if concensus could be reached would help a few years down the road. I think most of your ideas a worth persuing and RIPE would be a good forum for doing so. I have been thinking about something much more easily implemented: Participating ISPs adds a TEXT record in DNS for the IP numbers of all their dial-in ports which say W.X.Y.Z.IN_ADDR.ARPA. IN TXT "NOSMTP" Sendmails refuse email from such IP#, unless specifically instructed otherwise (ie: at the home ISP of the ports). How is that for a short term solution ? This allows responsible ISPs to clearly signal to the rest of the net that "Don't trust this guy for SMTP". If we could get UUnet, sprint, ibm.net, compuserve.com and so on to add those records, then life would be much easier over here... -- Poul-Henning Kamp FreeBSD coreteam member phk at FreeBSD.ORG "Real hackers run -current on their laptop." "Drink MONO-tonic, it goes down but it will NEVER come back up!" From andre at ml.ee Tue Jan 13 09:47:10 1998 From: andre at ml.ee (Andres Kroonmaa) Date: Tue, 13 Jan 1998 10:47:10 +0200 (EETDST) Subject: Anti-spam measures In-Reply-To: <1069.884636149@critter.freebsd.dk> References: Your message of "Mon, 12 Jan 1998 13:34:42 +0200." <7F69EDD4109@mail.lbi.ee> Message-ID: <80BD4730EFE@mail.lbi.ee> > > I have been thinking about something much more easily implemented: > > Participating ISPs adds a TEXT record in DNS for the IP numbers > of all their dial-in ports which say > > W.X.Y.Z.IN_ADDR.ARPA. IN TXT "NOSMTP" > > Sendmails refuse email from such IP#, unless specifically instructed > otherwise (ie: at the home ISP of the ports). > > How is that for a short term solution ? > > This allows responsible ISPs to clearly signal to the rest of the > net that "Don't trust this guy for SMTP". I believe there are lots of possible short term solutions, or hacks. Many of them are very good and working. But their most problem is that they call for free cooperation, not a standard. I believe that every single sysop already ten years ago knew dead sure that SMTP is totally unsecure and is calling for trouble. At these days perhaps noone could imagine that the first real trouble would be spam, perhaps people were more afraid of fake mail fraud. It is probably unrealistic to implement SMTP authentication or strict SMTP interdomain (or interAS) routing. SMTP so deeply depends on trust of remote site that it has overgrown for now. Your proposed method perhaps works ok, if all follow that, but it is IMHO allow-all-deny-some policy, and as such, prone to human errors and plain time-shortage (or carelessness). I'd wish to see a kind of follow-rules-or-it-simply-doesn't-work policy. To enforce that for now, we for eg. force all our dialin users to use our mail server as mail relay, thus we can always track down exactly who was the abuser. By also running anti-spam patches we filter our all sort of invalid domains. Spammers are not common here. So, we don't need that TXT record in the dns at all. If we have a spammer, we are very deeply worried about it, because we take responsibility for what our users do under our name. But this is not widely adopted policy, you know. Now, what I'd really like to be sure in, is that no other host on earth ever uses successfully our domain name for spamming, and I feel that the only way to ensure this would be a technical solution that makes this impossible. Simple rule that you can receive a message from a domain _only_ from a host responsible for that domain cuts off all kind of outsiders who might wish to spam with your name. But, for this rule to have any power, it have to be a standard. By implementing widely proposed method, we'd effectively force all internet users to use their home mail server, thus making it possible at least in theory to track down any spammer. And if added the only way to post mail message is via authenticated pop3 session, we can make sure that locked users never appear on the net again. Thus we can still make authenticated SMTP service, sort of.. Only then we can talk about trust between different sites. If you don't trust remote site, you can cut it off in worst case. If you do trust, then you rely on responsibility of remote administration and this usually works ok. What I basically propose, is to reduce anarchy in SMTP world before its too late. I'd love to see new RFC on SMTP, that pretty strictly specifies how SMTP servers and clients MUST behave, leaving out end-nodes and hinting that end-users should (or must) use other means to inject email messages to the SMTP world. Then, ideally, update RFC on pop3 to add method to inject mail from there and call for vendors to follow this RFC. After some time, when enough client software appears, make a slow switch, cutting off non-followers. ---------------------------------------------------------------------- Andres Kroonmaa mail: andre at online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ---------------------------------------------------------------------- From Mike.Norris at heanet.ie Fri Jan 16 14:43:42 1998 From: Mike.Norris at heanet.ie (Mike Norris) Date: Fri, 16 Jan 1998 13:43:42 -0000 Subject: Local IR WG at RIPE 29 - draft agenda Message-ID: <9801161344.AA22435@Tierce.hea.ie> Draft agenda below. Additions and comments welcome. Mike Norris RIPE 29 - 28th to 30th January 1998 Local IR Working Group D R A F T A G E N D A 1. Preliminaries - select a minute-taker - agree agenda, times 2. RIPE 28 - minutes - actions 1:28 Mike Norris to put a link on the RIPE NCC web page and the working group page to useful LIR tools. 2:28 RIPE NCC to prepare an analysis of the reverse DNS error counts. 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. 4:28 RIPE NCC to produce web interface to archives of WG mailing lists. 3. Reports from registries - Global: IANA developments - European regional (RIPE NCC) - other registries, significant events - other regionals, coordination - APNIC - ARIN (formerly InterNIC) - AfriNIC 4. IP Address Space Assignment - policy (ripe-159, rip1-155) - ticketing system (ripe-183) - consistency and auditing (ripe-170) - other 5. Registry procedures - web-assisted assignment, reverse delegation - tools, forms for local registries 6. Input/Output with other Working Groups 7. Statistics - reverse DNS counts, errors 8. LIR WG General discussion of its role and raison d'etre 9. AOB From gjermund at nextel.no Mon Jan 19 18:45:24 1998 From: gjermund at nextel.no (Gjermund Sxrseth) Date: Mon, 19 Jan 1998 18:45:24 +0100 (MET) Subject: Anti-spam measures Message-ID: <199801191745.SAA28887@a.online.no> Not sure if this is the right forum to discuss methods for preventing spam/relaying with sendmail, but since the question came up, and what you describe here is pretty much exactly like a package I've already implemented: Poul-Henning Kamp wrote: > One of the best things to do, would probably be to make a > simple turnkey kind of sendmail config available to people. > > It should be possible for people to maintain four files on > their system and have sendmail DTRT for them after that: > > /etc/sendmail.our_ip: > 192.168.1.0/24 > 10.0.0.0/22 > > /etc/sendmail.our_domains: > foo.bar.com > some.customer.domain.xx > > /etc/sendmail.we_mx_for: > bar.foo.com > > /etc/sendmail.people_we_dont_talk_to > cyberpromo.com > 203.43.43.0/22 > > Now that would be a worthwhile project to do... My implementation uses two config files - one for access control and one for relay control. A typical access-control file could look like this: deny bozo at domain.com deny @cyberpromo.com permit 192.2.49 deny 192.2 The deny/permit rules work like you would expect - a most-exact-match is performed. In this case mail from sender address "bozo at domain.com" and from everyone at cyberpromo.com will not be accepted. Connections from clients with IP addresses that start with 192.2 will not be accepted either, except those that start with 192.2.49. A typical relay-control file could look like this: # IP address ranges that can relay anywhere: # 127 10.127.99 # Our own addresses 195.18.159 # Customer X 163.22 # Customer Y 100.22.2.56 # Mail server Z # # Domain names we accept mail for: # mydomain.com another-domain.com yet-another-domain.com # include sendmail.cw include mailertable include secondary-mx This file contains two types of information - a collection of IP address ranges that can relay mail anywhere through us, and a list of domain names that we accept mail from from anywhere. The mail server will accept mail destined for the domain names in this file from ANYWHERE, and will accept mail for OTHER domains ONLY from clients whose IP adresses are in this file. Which provides complete relay control. To make maintanance easier, you can see that you may "include" the contents of other common sendmail files so that you don't need to maintain more then one copy of the list of domain names you accept mail for. Useful for large ISP's like ourselves. (The URL is ftp://ftp.xyzzy.no/sendmail/access.tar.Z) -- Gjermund Sxrseth, Telenor Nextel From gjermund at nextel.no Mon Jan 19 18:45:24 1998 From: gjermund at nextel.no (Gjermund Sxrseth) Date: Mon, 19 Jan 1998 18:45:24 +0100 (MET) Subject: Anti-spam measures Message-ID: <199801191745.SAA28887@a.online.no> Not sure if this is the right forum to discuss methods for preventing spam/relaying with sendmail, but since the question came up, and what you describe here is pretty much exactly like a package I've already implemented: Poul-Henning Kamp wrote: > One of the best things to do, would probably be to make a > simple turnkey kind of sendmail config available to people. > > It should be possible for people to maintain four files on > their system and have sendmail DTRT for them after that: > > /etc/sendmail.our_ip: > 192.168.1.0/24 > 10.0.0.0/22 > > /etc/sendmail.our_domains: > foo.bar.com > some.customer.domain.xx > > /etc/sendmail.we_mx_for: > bar.foo.com > > /etc/sendmail.people_we_dont_talk_to > cyberpromo.com > 203.43.43.0/22 > > Now that would be a worthwhile project to do... My implementation uses two config files - one for access control and one for relay control. A typical access-control file could look like this: deny bozo at domain.com deny @cyberpromo.com permit 192.2.49 deny 192.2 The deny/permit rules work like you would expect - a most-exact-match is performed. In this case mail from sender address "bozo at domain.com" and from everyone at cyberpromo.com will not be accepted. Connections from clients with IP addresses that start with 192.2 will not be accepted either, except those that start with 192.2.49. A typical relay-control file could look like this: # IP address ranges that can relay anywhere: # 127 10.127.99 # Our own addresses 195.18.159 # Customer X 163.22 # Customer Y 100.22.2.56 # Mail server Z # # Domain names we accept mail for: # mydomain.com another-domain.com yet-another-domain.com # include sendmail.cw include mailertable include secondary-mx This file contains two types of information - a collection of IP address ranges that can relay mail anywhere through us, and a list of domain names that we accept mail from from anywhere. The mail server will accept mail destined for the domain names in this file from ANYWHERE, and will accept mail for OTHER domains ONLY from clients whose IP adresses are in this file. Which provides complete relay control. To make maintanance easier, you can see that you may "include" the contents of other common sendmail files so that you don't need to maintain more then one copy of the list of domain names you accept mail for. Useful for large ISP's like ourselves. (The URL is ftp://ftp.xyzzy.no/sendmail/access.tar.Z) -- Gjermund Sxrseth, Telenor Nextel From Mike.Norris at heanet.ie Wed Jan 21 17:40:55 1998 From: Mike.Norris at heanet.ie (Mike Norris) Date: Wed, 21 Jan 1998 16:40:55 -0000 Subject: Fw: 193/194 data Message-ID: <199801211641.QAA21168@Tierce.hea.ie> Below are the results of Bill Manning's host count of the reverse domains of 193.0.0.0/8 and 194.0.0.0/8, RIPE NCC's main allocation tranches. Note the measure of quality and its very slight improvement. Exercise: explain the significant upward blip in Q4 1997. Regards. Mike Norris ---------- > From: bmanning at ISI.EDU > To: dfk at ripe.net; Mike.Norris at heanet.ie > Subject: 193/194 data > Date: 19 January 1998 15:17 > > inital > zone total #correct % no-server other > 1q1998 > > 193 1805 21188 17197 81.1 3987 4 > 194 4118 28907 21925 75.8 6971 11 > > 4q1997 > > 193 1729 39937 30758 77.0 9175 4 > 194 3953 27747 21084 75.9 6658 5 > > 3q1997 > > 193 1659 20125 16164 80.3 3961 0 > 194 3892 26623 20149 75.6 6467 7 > > > --bill From Daniel.Karrenberg at ripe.net Wed Jan 21 17:51:33 1998 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 21 Jan 1998 17:51:33 +0100 Subject: Fw: 193/194 data In-Reply-To: Your message of Wed, 21 Jan 1998 16:40:55 GMT. <199801211641.QAA21168@Tierce.hea.ie> References: <199801211641.QAA21168@Tierce.hea.ie> Message-ID: <199801211651.RAA00608@kantoor.ripe.net> Also interesting to not that we are significantly better than average. Daniel inital zone runtime total# #correct no-svr refused error other 3q97 97667 657 h 380021 220030 57.9% 159991 26335 90832 42824 4q97 99587 654 h 478311 281368 58.8% 196861 26871 103108 66882 We will look at the distreibution of te errors locally. Daniel > bmanning at ISI.EDU writes: > inital > zone total #correct % no-server other > 1q1998 > > 193 1805 21188 17197 81.1 3987 4 > 194 4118 28907 21925 75.8 6971 11 > > 4q1997 > > 193 1729 39937 30758 77.0 9175 4 > 194 3953 27747 21084 75.9 6658 5 > > 3q1997 > > 193 1659 20125 16164 80.3 3961 0 > 194 3892 26623 20149 75.6 6467 7 > > > --bill > > "Mike Norris" writes: > > Below are the results of Bill Manning's host count of the > reverse domains of 193.0.0.0/8 and 194.0.0.0/8, RIPE NCC's > main allocation tranches. Note the measure of quality and > its very slight improvement. > > Exercise: explain the significant upward blip in Q4 1997. > > Regards. > > Mike Norris > > ---------- > > From: bmanning at ISI.EDU > > To: dfk at ripe.net; Mike.Norris at heanet.ie > > Subject: 193/194 data > > Date: 19 January 1998 15:17 > > > > inital > > zone total #correct % no-server other > > 1q1998 > > > > 193 1805 21188 17197 81.1 3987 4 > > 194 4118 28907 21925 75.8 6971 11 > > > > 4q1997 > > > > 193 1729 39937 30758 77.0 9175 4 > > 194 3953 27747 21084 75.9 6658 5 > > > > 3q1997 > > > > 193 1659 20125 16164 80.3 3961 0 > > 194 3892 26623 20149 75.6 6467 7 > > > > > > --bill > From woeber at cc.univie.ac.at Wed Jan 21 18:01:22 1998 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 21 Jan 1998 18:01:22 MET-DST Subject: Fw: 193/194 data Message-ID: <009C0A1F.0BDF066C.9@cc.univie.ac.at> Seems like I'm growing old and my mind is failing me more often these days... >Subject: Fw: 193/194 data >... >Exercise: explain the significant upward blip in Q4 1997. Could somebody please try to explain what the figures on Bill's wallpaper are supposed to mean? I would also be interesetd in an explanation of the method used to obtain these figures. Amongst others - does the script(s) check against the number registry (ASSIGNED YES/NO ?) and the like. Is there any reason why figures for 193 and 194 are given, but figures for 195 and 62.xx aren't? Thanks, 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 -------------------------------------------------------------------------- From Daniel.Karrenberg at ripe.net Wed Jan 21 17:51:33 1998 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 21 Jan 1998 17:51:33 +0100 Subject: Fw: 193/194 data In-Reply-To: Your message of Wed, 21 Jan 1998 16:40:55 GMT. <199801211641.QAA21168@Tierce.hea.ie> References: <199801211641.QAA21168@Tierce.hea.ie> Message-ID: <199801211651.RAA00608@kantoor.ripe.net> Also interesting to not that we are significantly better than average. Daniel inital zone runtime total# #correct no-svr refused error other 3q97 97667 657 h 380021 220030 57.9% 159991 26335 90832 42824 4q97 99587 654 h 478311 281368 58.8% 196861 26871 103108 66882 We will look at the distreibution of te errors locally. Daniel > bmanning at ISI.EDU writes: > inital > zone total #correct % no-server other > 1q1998 > > 193 1805 21188 17197 81.1 3987 4 > 194 4118 28907 21925 75.8 6971 11 > > 4q1997 > > 193 1729 39937 30758 77.0 9175 4 > 194 3953 27747 21084 75.9 6658 5 > > 3q1997 > > 193 1659 20125 16164 80.3 3961 0 > 194 3892 26623 20149 75.6 6467 7 > > > --bill > > "Mike Norris" writes: > > Below are the results of Bill Manning's host count of the > reverse domains of 193.0.0.0/8 and 194.0.0.0/8, RIPE NCC's > main allocation tranches. Note the measure of quality and > its very slight improvement. > > Exercise: explain the significant upward blip in Q4 1997. > > Regards. > > Mike Norris > > ---------- > > From: bmanning at ISI.EDU > > To: dfk at ripe.net; Mike.Norris at heanet.ie > > Subject: 193/194 data > > Date: 19 January 1998 15:17 > > > > inital > > zone total #correct % no-server other > > 1q1998 > > > > 193 1805 21188 17197 81.1 3987 4 > > 194 4118 28907 21925 75.8 6971 11 > > > > 4q1997 > > > > 193 1729 39937 30758 77.0 9175 4 > > 194 3953 27747 21084 75.9 6658 5 > > > > 3q1997 > > > > 193 1659 20125 16164 80.3 3961 0 > > 194 3892 26623 20149 75.6 6467 7 > > > > > > --bill > From 5WH6E822v at skywa1tches.net Thu Jan 22 08:44:05 1998 From: 5WH6E822v at skywa1tches.net (5WH6E822v at skywa1tches.net) Date: 22 Jan 98 8:44:05 PM Subject: Are You Happy? Message-ID: <8yrDQOoq0xnfbP> There is brilliant information available to you, that will enable you to fully understand yourself and everybody else. This knowledge can benefit you tremendously in many ways. It can help you to get the very best out of your career, or discover your most suitable new career, and of course being happy at work, really improves the finances. It can also really enhance your love life. If you're in a relationship, it works great, because you are able to fully understand your own and your partner's emotions and motivations. If you're not, you will know exactly what you want from your perfect mate and what they will find attractive about you. Another big advantage to becoming balanced and happy is that good health runs hand in hand. Take a closer look two free pages of information at: http://www.po9.com From stesin at gu.net Wed Jan 28 18:19:42 1998 From: stesin at gu.net (Andrew Stesin) Date: Wed, 28 Jan 1998 19:19:42 +0200 (EET) Subject: [ripe-167] Impressions brought from Moscow meeting In-Reply-To: Message-ID: Dear Mirjam, dear Daniel, Robert, Mr. Postel, and others, as ripe-167 story goes on, I'd like to inform you about some new impressions and information we got with regard to it. Abstract: Ukrainian LIRs in their vaste majority would not agree with the Russian approach there and vote against the project of a new RIR in Moscow. As you already know, a conference of LIR' represantatives from Russia took place in Moscow, January 22. Ukrainian representatives were also present (4 delegations from major Ukrainian LIRs, me among them). During the direct conversations with "new RIR in Moscow" project initiators many aspects became much more clear. Here my opinions are. 1. During the meeting, *nothing* from the argumentation provided in ripe-167 was recognized by community as a sugnificant argument which clarifies the "new RIR" approach. Document authors didn't even bother defending their former argumentation. I got an opinion that argumentation given in ripe-167 was written with the only goal to convince RIPE and IANA, it's pretty much irrelevant to the current state of affairs here. 2. It seems that the idea of "new RIR in Moscow" has a plain political background, with a scope limited to a single (though big) country -- Russia, or even to a single city -- Moscow. Our Russian collegues are now facing the trend of their goverment trying to establish a certain degree of control over Internet business in Russia. They also recognize that IP address space distribution is one of the most important things to ISP business. So they decided to extend the scope and sugnificance of RosNIIROS registry as much as possible, probably in order to prevent "some others" (whos?) attempt to monopolise IP space redistribution *in Russia*. 3. The very idea of defining a "region" for the projected RIR in terms of politics, not geography (as opposed to the existing practice) -- is not occasional, this is semi-intentional. The abbreviation "CIS" should really be understood as "a sphere of Russian business and political interests". Some details. Ukraine is a large East European country with population of about 50 million comparatively educated and skilled people (as opposed to about 150+ million population of Russia). The whole territory of Ukraine is in European continent. The estimated size of Internet (and similar) services market here is comparative to Russian. From the other hand, Ukraine got about 3 year delay in social, technological et al. development compared to Russia (partially due to the fact that Russia monopolized many achievements and infrastructure of ex-USSR). So Russia has it's business and communication structures being developed faster now and the market is more tight so far. Naturally, Russian companies are interested in joining Ukrainian market, where they might become a stronger players. Consider also the fact that Ukrainian ISPs all were the customers of their Russian collegues (note the ex-USSR infrastructure above) some 2-3 years ago, and were getting sugnificant amounts of funds from Ukraine. Being a RIR (esp. in case RIPE will delegate them monopolistic rights at the territory mentioned) will let certain people and organisations to continue getting their "traditional" funds from other countries, as they used to do before. 4. Also note that RIRs tend to have a sugnificant influence on the technical policies and "technical fashion" among their customers; also this means access to technical information about them and ability to monitor the development of their networks. With RIPE (RNA) this is not an issue for us, as RIPE doesn't represent any single (or group) entity who has strong business interests in Ukraine or anyone who is interested in monitoring our development. And with RosNIIROS this *is* an issue potentially. RosNIIROS doesn't represent a voluntary association of any kind, there isn't one even in a single Russia so far. RosNIIROS is a semi-govermental organization, established as a daughter structure of Moscow "Relcom" company; and Relcom venture is wellknown for it's numerous and continued attempts to become a monopolist on Russian Internet services market; and recently lost a sugnificant share in Ukrainian market due to rapid development of Ukrainian communication infrastructure, which allowed us to get a choice of whom to pay for services. A RIR in Russia, which will tend to fall under the influence of Russian goverment and several big semi-monopolistic companies, will be probably able to cope with intra-Russia issues, but will also serve the interests of Russian business and politics; it won't be able to serve the interests of international community. Baltic countries (Latvia, Lithuania, Estonia) tend to avoid just *any* contact with Russia due to the reasons above; we in Ukraine aren't so radical, but our reaction continues to be strictly negative. Being an official representative of LIR UA.GU, I'd like to get a confirmation that our registry will be served by RIPE directly in the forseeable future. We'd also like to see an official confirmation from RIPE, of the fact that any new LIR at Ukrainian territory will *always* be either served by RIPE directly or will have a choice between direct service contract from RIPE or indirect -- from other RIPE office wherever it might be established in future (Moscow, Berlin, Istambul, Kiev... who cares?) Thanks a lot for your attention. Best regards, Andrew Stesin nic-hdl: ST73-RIPE From stesin at gu.net Wed Jan 28 18:19:42 1998 From: stesin at gu.net (Andrew Stesin) Date: Wed, 28 Jan 1998 19:19:42 +0200 (EET) Subject: [ripe-167] Impressions brought from Moscow meeting In-Reply-To: Message-ID: Dear Mirjam, dear Daniel, Robert, Mr. Postel, and others, as ripe-167 story goes on, I'd like to inform you about some new impressions and information we got with regard to it. Abstract: Ukrainian LIRs in their vaste majority would not agree with the Russian approach there and vote against the project of a new RIR in Moscow. As you already know, a conference of LIR' represantatives from Russia took place in Moscow, January 22. Ukrainian representatives were also present (4 delegations from major Ukrainian LIRs, me among them). During the direct conversations with "new RIR in Moscow" project initiators many aspects became much more clear. Here my opinions are. 1. During the meeting, *nothing* from the argumentation provided in ripe-167 was recognized by community as a sugnificant argument which clarifies the "new RIR" approach. Document authors didn't even bother defending their former argumentation. I got an opinion that argumentation given in ripe-167 was written with the only goal to convince RIPE and IANA, it's pretty much irrelevant to the current state of affairs here. 2. It seems that the idea of "new RIR in Moscow" has a plain political background, with a scope limited to a single (though big) country -- Russia, or even to a single city -- Moscow. Our Russian collegues are now facing the trend of their goverment trying to establish a certain degree of control over Internet business in Russia. They also recognize that IP address space distribution is one of the most important things to ISP business. So they decided to extend the scope and sugnificance of RosNIIROS registry as much as possible, probably in order to prevent "some others" (whos?) attempt to monopolise IP space redistribution *in Russia*. 3. The very idea of defining a "region" for the projected RIR in terms of politics, not geography (as opposed to the existing practice) -- is not occasional, this is semi-intentional. The abbreviation "CIS" should really be understood as "a sphere of Russian business and political interests". Some details. Ukraine is a large East European country with population of about 50 million comparatively educated and skilled people (as opposed to about 150+ million population of Russia). The whole territory of Ukraine is in European continent. The estimated size of Internet (and similar) services market here is comparative to Russian. From the other hand, Ukraine got about 3 year delay in social, technological et al. development compared to Russia (partially due to the fact that Russia monopolized many achievements and infrastructure of ex-USSR). So Russia has it's business and communication structures being developed faster now and the market is more tight so far. Naturally, Russian companies are interested in joining Ukrainian market, where they might become a stronger players. Consider also the fact that Ukrainian ISPs all were the customers of their Russian collegues (note the ex-USSR infrastructure above) some 2-3 years ago, and were getting sugnificant amounts of funds from Ukraine. Being a RIR (esp. in case RIPE will delegate them monopolistic rights at the territory mentioned) will let certain people and organisations to continue getting their "traditional" funds from other countries, as they used to do before. 4. Also note that RIRs tend to have a sugnificant influence on the technical policies and "technical fashion" among their customers; also this means access to technical information about them and ability to monitor the development of their networks. With RIPE (RNA) this is not an issue for us, as RIPE doesn't represent any single (or group) entity who has strong business interests in Ukraine or anyone who is interested in monitoring our development. And with RosNIIROS this *is* an issue potentially. RosNIIROS doesn't represent a voluntary association of any kind, there isn't one even in a single Russia so far. RosNIIROS is a semi-govermental organization, established as a daughter structure of Moscow "Relcom" company; and Relcom venture is wellknown for it's numerous and continued attempts to become a monopolist on Russian Internet services market; and recently lost a sugnificant share in Ukrainian market due to rapid development of Ukrainian communication infrastructure, which allowed us to get a choice of whom to pay for services. A RIR in Russia, which will tend to fall under the influence of Russian goverment and several big semi-monopolistic companies, will be probably able to cope with intra-Russia issues, but will also serve the interests of Russian business and politics; it won't be able to serve the interests of international community. Baltic countries (Latvia, Lithuania, Estonia) tend to avoid just *any* contact with Russia due to the reasons above; we in Ukraine aren't so radical, but our reaction continues to be strictly negative. Being an official representative of LIR UA.GU, I'd like to get a confirmation that our registry will be served by RIPE directly in the forseeable future. We'd also like to see an official confirmation from RIPE, of the fact that any new LIR at Ukrainian territory will *always* be either served by RIPE directly or will have a choice between direct service contract from RIPE or indirect -- from other RIPE office wherever it might be established in future (Moscow, Berlin, Istambul, Kiev... who cares?) Thanks a lot for your attention. Best regards, Andrew Stesin nic-hdl: ST73-RIPE