- db-wg - mailman.ripe.net

Proposed agenda (draft) for DB-WG at RIPE-29
by Wilfried Woeber, UniVie/ACOnet 21 Jan '98

21 Jan '98

This is the first draft agenda (proposal) for the DB-WG meeting next week. Some of the items with relevance for a broader audience are being put on the agenda for the plenary. Thus I suppose that we can finish business during the 1st of the two assigned slots. Nevertheless, there is a lot of things which could need attention, potentially by a bunch of people "representing" different WGs. Therefore I'd like to keep the 2nd slot open for last minute activities. As usual, comments, additions, etc. welcome! See you! Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Proposed Agenda for the Database Working Group Meeting RIPE-29, January 1998, Amsterdam Draft, Jan. 20, 1998 A. Administrative stuff (Wilfried Woeber, chair, 5min) - appointment of scribe - agenda bashing B. NCC Update (Ambrose Magee, 10min) C. DB Consistency: state of the database report (Kurt Dirnbauer, Horst Koenigshofer, 15min) D. DB SW Re-engineering (Mal Morris, 10min + discussion) - NCC proposal/status - new/changed functionality - user community involvment - implementation scenario(s) - application and/or environment specific aspects (exchange point administration, ...) E. Other developments - Registry data exchange (RIDE) - IRR security Y. Input from other WGs - t.b.d. Z. AOB -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)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 --------------------------------------------------------------------------

1 0

Specifying a layer-3 MLPA in the IRR
by Jake Khuon 16 Jan '98

16 Jan '98

Although I've already sent this to the routing WG mailing list, Gerald Winters suggested that the DB WG might be interested in at least the authorisation schema. I have written two draft proposals (one for RIPE-181 and the other for RPSL) on how to specify layer-3 MLPAs in the IRR. I'd like to welcome any comments. I'm including a copy of each draft below and they can also be found at: http://espresso.merit.net/~khuon/khuon-003.txt http://espresso.merit.net/~khuon/khuon-004.txt #include <khuon-003.txt> Specifying and Supporting a Layer-3 MLPA Using as-macros Jake Khuon Merit Network, Inc. Document ID: khuon-003 November, 1997 ABSTRACT This document describes a procedure and mechanism for implementing layer-3 MLPA support in the Internet Routing Registry using RIPE-181 as-macros. khuon-003.txt November, 1997 - 2 - Table of Contents 1 Introduction ................................................ 2 2 Organisation of this Document ............................... 2 3 Proposed Construction of an MLPA as-macro ................... 2 4 Architecture for an Authorisation and Control Mechanism for Maintaining an MLPA as-macro ................................ 3 5 References .................................................. 5 6 Author Address .............................................. 6 1. Introduction Several exchange points are making use of Multi-Lateral Peering Agreements to simplify both layer-2 and layer-3 peering. However, there is currently no mechanism to support those agreements to simplify router configuration. The most logical vehicle for specifying such an arrangement is the as-macro which is defined in [1]. Please refer to that document for more details. In the most general case, an MLPA is an agreement signed by members who wish to participate in a mutual full-mesh peering environment. This full-mesh may inhabit both layer-2 and/or layer-3. The concern with using as-macros for specifying an MLPA is that of scope of control. This macro must be modifiable by all organisations listed in the object, but one organisation should not be able to modify an attribute which references another organisation. I would like to acknowledge the contributions made by several people during the development of this document. Abha Ahuja helped in the initial design of the prescreening authorisation mechanism and Gerald Winters provided valuable input about the security considerations of the RIPE-181 language. 2. Organisation of this Paper This paper acts as both a guideline for registering MLPA-based as-macros and provides a schema for implementing a mechanism by which to handle proper control of those objects. Section 3 provides a suggested method for construction of the as-macro. Section 4 provides an architecture to be used to control maintenance of that object. 3. Proposed Construction of an MLPA as-macro The MLPA as-macro is constructed in much the same way as any other as-macro with the exception that the specified mnt-by references a controlling body which does not belong to any one organisation khuon-003.txt November, 1997 - 3 - listed. To provide for simpler implementation of the control mechanism, it is suggested that only one aut-num be referenced in each as-list attribute. It is also suggested that no as-macros be referenced by an as-list and that naming convention be strictly adhered to which would reference an aut-num to its mntner. Example: as-macro: AS-AADSMLPA descr: MLPA participants at the AADS NAP as-list: AS4550 as-list: AS683 as-list: AS2551 as-list: AS5646 as-list: AS2685 guardian: auto-mlpa(a)ameritech.net admin-c: Andrew Schmidt tech-c: Mark Cnota notify: mlpa-participants(a)ameritech.net mnt-by: MAINT-AADSMLPA mnt-by: MAINT-RSPEER changed: auto-mlpa(a)ameritech.net 971123 source: RADB The mntner MAINT-AADSMLPA referenced above may look something like: Example: mntner: MAINT-AADSMLPA descr: People authorised to make changes for the AADS MLPA as-macro admin-c: Andrew Schmidt upd-to: noc(a)ameritech.net mnt-nfy: noc(a)ameritech.net auth: PGP-FROM noc(a)ameritech.net auth: PGP-FROM auto-mlpa(a)ameritech.net mnt-by: MAINT-AADSMLPA changed: noc(a)ameritech.net 971123 source: RADB In the above examples you will notice a reference to auto-mlpa(a)ameritech.net. Behind this email address will reside the actual gateway by which each of the organisations listed in the as-lists can submit changes. The details of this mechanism will be described below in Section 4. 4. Architecture for an Authorisation and Control Mechanism for Maintaining an MLPA as-macro The difficulty with using as-macros to specify an MLPA is the inability to implement a distributed and scoped authorisation mechanism for a single object. This document proposes a workaround by which an automated mailing list feeds a preprocessor that in turn will pre-authorise any object submissions before it itself submits the object through the traditional auto-dbm processor. Using the example above, auto-mlpa(a)ameritech.net is authorised to submit changes to AS-AADSMLPA. The auto-mlpa(a)ameritech.net mail khuon-003.txt November, 1997 - 4 - alias should point to a process which examines the submitted object and performs the following actions in the following order: 1. Determine the difference between the submitted object and current object. It should categorise these differences as one of the following operations: A. Addition of a new as-list B. Deletion of a current as-list If the submitted object contains an addition, it is advised that an as-macro containing a list of all the organisation's ASes present at that exchange point be further interrogated to determine if the addition may proceed. This is to prevent someone from just simply adding bogus ASes to the as-macro. 2. Interogate the aut-num reference listed in the as-list and determine via that aut-num's mnt-by if the submitter of the object is authorised. 3. Extract the object from the original email submission and resubmit it to the auto-dbm process of the database using the authentication method listed in the mntner of the as-macro (PGP signed in the above example). The following outlines an example of the process architecture: Suppose AS61234 (bogus.com) wishes to add itself to the AS-AADSMLPA macro. The submitter at AS1234 would submit a copy of the changed as-macro to the auto-mlpa preprocessor/gateway... v===============================================v as-macro: AS-AADSMLPA descr: MLPA participants at the AADS NAP as-list: AS4550 as-list: AS683 as-list: AS2551 as-list: AS5646 as-list: AS2685 as-list: AS61234 guardian: auto-mlpa(a)ameritech.net admin-c: Andrew Schmidt tech-c: Mark Cnota notify: mlpa-participants(a)ameritech.net mnt-by: MAINT-AADSMLPA mnt-by: MAINT-RSPEER changed: auto-mlpa(a)ameritech.net 971123 source: RADB ^===============================================^ | | | [pgp -sta -u noc] [(sign via PGP) ] | +------------------- <noc(a)bogus.com> khuon-003.txt November, 1997 - 5 - | | | v [ -- auto-mlpa -- ] [1. Identified: add AS61234] [2. Query aut-num's mnt-by ] ????? ? ? ? v===============================================v aut-num: AS61234 descr: Bogus Organisation descr: Snerd Inc. as-in: from AS-AADSMLPA 100 accept ANY as-out: to AS-AADSMLPA announce AS61234 admin-c: Alonzo Snerd tech-c: Alonzo Snerd notify: noc(a)bogus.com mnt-by: MAINT-AS61234 changed: noc(a)bogus.com 970727 source: RADB ^===============================================^ | | | [3. Query mntner ] <---+ ? ????????????????????????????? ? ? ? v===============================================v mntner: MAINT-AS61234 descr: People authorised to make changes for AS61234 admin-c: Alonzo Snerd upd-to: noc(a)bogus.com mnt-nfy: noc(a)nogus.com auth: PGP-FROM noc(a)bogus.com mnt-by: MAINT-AS6234 changed: noc(a)bogus.com 970727 source: RADB ^===============================================^ | | | [4. Authentication satisfied] ---+ The preprocessor checks the submission and notices an addition for AS61234. It then queries for the mntner MAINT-AS61234 and checks the auth against the submitter. If the authentication scheme is satisfied, it will submit by-proxy the request to auto-dbm (using the proper auth scheme) thorisation against the mnt-by listed in the as-macro. Since the auth attribute lists auto-mlpa(a)ameritech.net as an authorised submitter, the checks will complete and the new macro with the addition of "as-list: AS61234" will take effect in RADB. khuon-003.txt November, 1997 - 6 - [5. Submit to auto-dbm ] | | v [auto-dbm] ??????????????????????? ? ? ? v===============================================v mntner: MAINT-AADSMLPA descr: People authorised to make changes for the AADS MLPA as-macro admin-c: Andrew Schmidt upd-to: noc(a)ameritech.net mnt-nfy: noc(a)ameritech.net auth: PGP-FROM noc(a)ameritech.net auth: PGP-FROM auto-mlpa(a)ameritech.net mnt-by: MAINT-AADSMLPA changed: noc(a)ameritech.net 971123 source: RADB ^===============================================^ 5. References [1] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M., Karrenberg, D., Terpstra, M., Yu, J., "Representation of IP Routing Policies in a Routing Registry", ripe-181, October 1994. 6. Author's Address Jake Khuon Merit Network Inc. Bldg. 1, Ste. C2122 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 USA +1 (313) 763-4907 khuon(a)Merit.Net khuon-003.txt November, 1997 #endinc /* khuon-003.txt */ #include <khuon-004.txt> Specifying and Supporting a Layer-3 MLPA Using as-sets Jake Khuon Merit Network, Inc. Document ID: khuon-004 December, 1997 ABSTRACT This document describes a procedure and mechanism for implementing layer-3 MLPA support in the Internet Routing Registry using RPSL as-sets. khuon-004.txt December, 1997 - 2 - Table of Contents 1 Introduction ................................................ 2 2 Organisation of this Document ............................... 2 3 Proposed Construction of an MLPA as-set ..................... 2 4 Architecture for an Authorisation and Control Mechanism for Maintaining an MLPA as-set .................................. 3 5 References .................................................. 5 6 Author Address .............................................. 6 1. Introduction Several exchange points are making use of Multi-Lateral Peering Agreements to simplify both layer-2 and layer-3 peering. However, there is currently no mechanism to support those agreements to simplify router configuration. The most logical vehicle for specifying such an arrangement is the as-set which is defined in [1]. Please refer to that document for more details. In the most general case, an MLPA is an agreement signed by members who wish to participate in a mutual full-mesh peering environment. This full-mesh may inhabit both layer-2 and/or layer-3. The concern with using as-sets for specifying an MLPA is that of scope of control. This macro must be modifiable by all member organisations listed in the object, but one organisation should not be able to modify an attribute which references another organisation. I would like to acknowledge the contributions made by several people during the development of this document. Abha Ahuja helped in the initial design of the prescreening authorisation mechanism and Gerald Winters provided valuable input about the security considerations of the RIPE-181 and RPSL languages. 2. Organisation of this Paper This paper acts as both a guideline for registering MLPA-based as-sets and provides a schema for implementing a mechanism by which to handle proper control of those objects. Section 3 provides a suggested method for construction of the as-set. Section 4 provides an architecture to be used to control maintenance of that object. 3. Proposed Construction of an MLPA as-set The MLPA as-set is constructed in much the same way as any other as-set with the exception that the specified mnt-by references a controlling body which does not belong to any one organisation khuon-004.txt December, 1997 - 3 - listed. To provide for simpler implementation of the control mechanism, it is suggested that only one aut-num be referenced in each members attribute. It is also suggested that no as-sets be referenced by a members attribute and that naming convention be strictly adhered to which would reference an aut-num to its mntner. Example: as-set: as-aadsmlpa descr: MLPA participants at the AADS NAP members: AS4550 members: AS683 members: AS2551 members: AS5646 members: AS2685 admin-c: Andrew Schmidt tech-c: Mark Cnota notify: mlpa-participants(a)ameritech.net mnt-by: MAINT-AADSMLPA mnt-by: MAINT-RSPEER changed: auto-mlpa(a)ameritech.net 19971123 source: RADB The mntner MAINT-AADSMLPA referenced above may look something like: Example: mntner: MAINT-AADSMLPA descr: People authorised to make changes for the AADS MLPA as-set admin-c: Andrew Schmidt upd-to: noc(a)ameritech.net mnt-nfy: noc(a)ameritech.net auth: PGP-FROM noc(a)ameritech.net auth: PGP-FROM auto-mlpa(a)ameritech.net mnt-by: MAINT-AADSMLPA changed: noc(a)ameritech.net 19971123 source: RADB In the above examples you will notice a reference to auto-mlpa(a)ameritech.net. Behind this email address will reside the actual gateway by which each of the organisations listed in the memberss can submit changes. The details of this mechanism will be described below in Section 4. 4. Architecture for an Authorisation and Control Mechanism for Maintaining an MLPA as-set The difficulty with using as-sets to specify an MLPA is the inability to implement a distributed and scoped authorisation mechanism for a single object. This document proposes a workaround by which an automated mailing list feeds a preprocessor that in turn will pre-authorise any object submissions before it itself submits the object through the traditional auto-dbm processor. Using the example above, auto-mlpa(a)ameritech.net is authorised to submit changes to as-aadsmlpa as-set. The auto-mlpa(a)ameritech.net mail alias should point to a process which examines the submitted object and performs the following actions in the following order: khuon-004.txt December, 1997 - 4 - 1. Determine the difference between the submitted object and current object. It should categorise these differences as one of the following operations: A. Addition of a new members B. Deletion of a current members If the submitted object contains an addition, it is advised that an as-set containing a list of all the organisation's ASes present at that exchange point be further interrogated to determine if the addition may proceed. This is to prevent someone from just simply adding bogus ASes to the as-set. 2. Interogate the aut-num reference listed in the members and determine via that aut-num's mnt-by if the submitter of the object is authorised. 3. Extract the object from the original email submission and resubmit it to the auto-dbm process of the database using the authentication method listed in the mntner of the as-set (PGP signed in the above example). The following outlines an example of the process architecture: Suppose AS61234 (bogus.com) wishes to add itself to the as-aadsmlpa macro. The submitter at AS1234 would submit a copy of the changed as-set to the auto-mlpa preprocessor/gateway... v===============================================v as-set: as-aadsmlpa descr: MLPA participants at the AADS NAP members: AS4550 members: AS683 members: AS2551 members: AS5646 members: AS2685 members: AS61234 admin-c: Andrew Schmidt tech-c: Mark Cnota notify: mlpa-participants(a)ameritech.net mnt-by: MAINT-AADSMLPA mnt-by: MAINT-RSPEER changed: auto-mlpa(a)ameritech.net 19971123 source: RADB ^===============================================^ | | | [pgp -sta -u noc] [(sign via PGP) ] | +------------------- <noc(a)bogus.com> | | | v [ -- auto-mlpa -- ] khuon-004.txt December, 1997 - 5 - [1. Identified: add AS61234] [2. Query aut-num's mnt-by ] ????? ? ? ? v========================================================v aut-num: AS61234 as-name: bogus descr: Bogus Organisation import: from as-aadsmlpa action pref=1; accept ANY export: to as-aadsmlpa announce AS61234 admin-c: Alonzo Snerd tech-c: Alonzo Snerd notify: noc(a)bogus.com mnt-by: MAINT-AS61234 changed: noc(a)bogus.com 19970727 source: RADB ^========================================================^ | | | [3. Query mntner ] <---+ ? ? ? ????????????????????????????? ? ? ? v===============================================v mntner: MAINT-AS61234 descr: People authorised to make changes for AS61234 admin-c: Alonzo Snerd upd-to: noc(a)bogus.com mnt-nfy: noc(a)nogus.com auth: PGP-FROM noc(a)bogus.com mnt-by: MAINT-AS6234 changed: noc(a)bogus.com 19970727 source: RADB ^===============================================^ | | | [4. Authentication satisfied] ---+ The preprocessor checks the submission and notices an addition for AS61234. It then queries for the mntner MAINT-AS61234 and checks the auth against the submitter. If the authentication scheme is satisfied, it will submit by-proxy the request to auto-dbm (using the proper auth scheme) thorisation against the mnt-by listed in the as-set. Since the auth attribute lists auto-mlpa(a)ameritech.net as an authorised submitter, the checks will complete and the new macro with the addition of "members: AS61234" will take effect in RADB. [5. Submit to auto-dbm ] | khuon-004.txt December, 1997 - 6 - | | v [auto-dbm] ??????????????????????? ? ? ? v===============================================v mntner: MAINT-AADSMLPA descr: People authorised to make changes for the AADS MLPA as-set admin-c: Andrew Schmidt upd-to: noc(a)ameritech.net mnt-nfy: noc(a)ameritech.net auth: PGP-FROM noc(a)ameritech.net auth: PGP-FROM auto-mlpa(a)ameritech.net mnt-by: MAINT-AADSMLPA changed: noc(a)ameritech.net 19971123 source: RADB ^===============================================^ 5. References [1] C. Alaettinoglu. Routing Policy Specification Language (RPSL)., Internet Draft draft-ietf-rps-rpsl-03.txt, July, 1997, Work in progress. 6. Author's Address Jake Khuon Merit Network Inc. Bldg. 1, Ste. C2122 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 USA +1 (313) 763-4907 khuon(a)Merit.Net khuon-004.txt December, 1997 #endinc /* khuon-004.txt */ -- /*====================[ Jake Khuon <khuon(a)Merit.Net> ]=====================+ | Systems Research Programmer, IE Group /| /|[~|)|~|~ N E T W O R K | | Vox: (734) 763-4907 Fax: (734) 747-3185 / |/ |[_|\| | Incorporated | +==[ Suite C2122, Bldg. 1 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 ]==*/

1 0

Re: memory leak in syncdb
by Steven Bakker 10 Jan '98

10 Jan '98

>>>>> On Mon, 5 Jan 1998, "WS" == W.Sylwestrzak(a)icm.edu.pl wrote: WS> is anyone else running daily the syncdb script experiencing huge vm WS> consumption by the process ? WS> I cannot find any obvious reason for this behaviour... Syncdb -- isn't that a Perl script? What version of Perl are you running? Any Perl5 version before 5.004_04 contains memory leaks of some sort, and even 5.004_04 probably still contains some. Perl 4.036 seemed not too bad, but that's an ancient version now, so I wouldn't bet on it. Hope this helps, Steven

3 2

(no subject)
by ipopov 05 Jan '98

05 Jan '98

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.

1 0

memory leak in syncdb
by W.Sylwestrzak＠icm.edu.pl 05 Jan '98

05 Jan '98

is anyone else running daily the syncdb script experiencing huge vm consumption by the process ? I cannot find any obvious reason for this behaviour... --w

1 0

Majordomo results: Re: TICKET# 009041 [Global-Marketplace]
by Majordomo＠tradinghouse.com 19 Dec '97

19 Dec '97

-- >>>> This is to confirm that your message has been received by **** Command 'this' not recognized. >>>> Island Internet's support department. **** Command 'island' not recognized. >>>> >>>> Thank you, **** Command 'thank' not recognized. >>>> Island Internet **** Command 'island' not recognized. >>>> >>>> **** No valid commands found. **** Commands must be in message BODY, not in HEADER. **** Help for Majordomo(a)tradinghouse.com: This help message is being sent to you from the Majordomo mailing list management system at Majordomo(a)tradinghouse.com. This is version 1.94.3 of Majordomo. If you're familiar with mail servers, an advanced user's summary of Majordomo's commands appears at the end of this message. Majordomo is an automated system which allows users to subscribe and unsubscribe to mailing lists, and to retrieve files from list archives. You can interact with the Majordomo software by sending it commands in the body of mail messages addressed to "Majordomo(a)tradinghouse.com". Please do not put your commands on the subject line; Majordomo does not process commands in the subject line. You may put multiple Majordomo commands in the same mail message. Put each command on a line by itself. If you use a "signature block" at the end of your mail, Majordomo may mistakenly believe each line of your message is a command; you will then receive spurious error messages. To keep this from happening, either put a line starting with a hyphen ("-") before your signature, or put a line with just the word end on it in the same place. This will stop the Majordomo software from processing your signature as bad commands. Here are some of the things you can do using Majordomo: I. FINDING OUT WHICH LISTS ARE ON THIS SYSTEM To get a list of publicly-available mailing lists on this system, put the following line in the body of your mail message to Majordomo(a)tradinghouse.com: lists Each line will contain the name of a mailing list and a brief description of the list. To get more information about a particular list, use the "info" command, supplying the name of the list. For example, if the name of the list about which you wish information is "demo-list", you would put the line info demo-list in the body of the mail message. II. SUBSCRIBING TO A LIST Once you've determined that you wish to subscribe to one or more lists on this system, you can send commands to Majordomo to have it add you to the list, so you can begin receiving mailings. To receive list mail at the address from which you're sending your mail, simply say "subscribe" followed by the list's name: subscribe demo-list If for some reason you wish to have the mailings go to a different address (a friend's address, a specific other system on which you have an account, or an address which is more correct than the one that automatically appears in the "From:" header on the mail you send), you would add that address to the command. For instance, if you're sending a request from your work account, but wish to receive "demo-list" mail at your personal account (for which we will use "jqpublic(a)my-isp.com" as an example), you'd put the line subscribe demo-list jqpublic(a)my-isp.com in the mail message body. Based on configuration decisions made by the list owners, you may be added to the mailing list automatically. You may also receive notification that an authorization key is required for subscription. Another message will be sent to the address to be subscribed (which may or may not be the same as yours) containing the key, and directing the user to send a command found in that message back to Majordomo(a)tradinghouse.com. (This can be a bit of extra hassle, but it helps keep you from being swamped in extra email by someone who forged requests from your address.) You may also get a message that your subscription is being forwarded to the list owner for approval; some lists have waiting lists, or policies about who may subscribe. If your request is forwarded for approval, the list owner should contact you soon after your request. Upon subscribing, you should receive an introductory message, containing list policies and features. Save this message for future reference; it will also contain exact directions for unsubscribing. If you lose the intro mail and would like another copy of the policies, send this message to Majordomo(a)tradinghouse.com: intro demo-list (substituting, of course, the real name of your list for "demo-list"). III. UNSUBSCRIBING FROM MAILING LISTS Your original intro message contains the exact command which should be used to remove your address from the list. However, in most cases, you may simply send the command "unsubscribe" followed by the list name: unsubscribe demo-list (This command may fail if your provider has changed the way your address is shown in your mail.) To remove an address other than the one from which you're sending the request, give that address in the command: unsubscribe demo-list jqpublic(a)my-isp.com In either of these cases, you can tell Majordomo(a)tradinghouse.com to remove the address in question from all lists on this server by using "*" in place of the list name: unsubscribe * unsubscribe * jqpublic(a)my-isp.com IV. FINDING THE LISTS TO WHICH AN ADDRESS IS SUBSCRIBED To find the lists to which your address is subscribed, send this command in the body of a mail message to Majordomo(a)tradinghouse.com: which You can look for other addresses, or parts of an address, by specifying the text for which Majordomo should search. For instance, to find which users at my-isp.com are subscribed to which lists, you might send the command which my-isp.com Note that many list owners completely or fully disable the "which" command, considering it a privacy violation. V. FINDING OUT WHO'S SUBSCRIBED TO A LIST To get a list of the addresses on a particular list, you may use the "who" command, followed by the name of the list: who demo-list Note that many list owners allow only a list's subscribers to use the "who" command, or disable it completely, believing it to be a privacy violation. VI. RETRIEVING FILES FROM A LIST'S ARCHIVES Many list owners keep archives of files associated with a list. These may include: - back issues of the list - help files, user profiles, and other documents associated with the list - daily, monthly, or yearly archives for the list To find out if a list has any files associated with it, use the "index" command: index demo-list If you see files in which you're interested, you may retrieve them by using the "get" command and specifying the list name and archive filename. For instance, to retrieve the files called "profile.form" (presumably a form to fill out with your profile) and "demo-list.9611" (presumably the messages posted to the list in November 1996), you would put the lines get demo-list profile.form get demo-list demo-list.9611 in your mail to Majordomo(a)tradinghouse.com. VII. GETTING MORE HELP To contact a human site manager, send mail to Majordomo-Owner(a)tradinghouse.com. To contact the owner of a specific list, send mail to that list's approval address, which is formed by adding "-approval" to the user-name portion of the list's address. For instance, to contact the list owner for demo-list(a)tradinghouse.com, you would send mail to demo-list-approval(a)tradinghouse.com. To get another copy of this help message, send mail to Majordomo(a)tradinghouse.com with a line saying help in the message body. VIII. COMMAND SUMMARY FOR ADVANCED USERS In the description below items contained in []'s are optional. When providing the item, do not include the []'s around it. Items in angle brackets, such as <address>, are meta-symbols that should be replaced by appropriate text without the angle brackets. It understands the following commands: subscribe <list> [<address>] Subscribe yourself (or <address> if specified) to the named <list>. unsubscribe <list> [<address>] Unsubscribe yourself (or <address> if specified) from the named <list>. "unsubscribe *" will remove you (or <address>) from all lists. This _may not_ work if you have subscribed using multiple addresses. get <list> <filename> Get a file related to <list>. index <list> Return an index of files you can "get" for <list>. which [<address>] Find out which lists you (or <address> if specified) are on. who <list> Find out who is on the named <list>. info <list> Retrieve the general introductory information for the named <list>. intro <list> Retrieve the introductory message sent to new users. Non-subscribers may not be able to retrieve this. lists Show the lists served by this Majordomo server. help Retrieve this message. end Stop processing commands (useful if your mailer adds a signature). Commands should be sent in the body of an email message to "Majordomo(a)tradinghouse.com". Multiple commands can be processed provided each occurs on a separate line. Commands in the "Subject:" line are NOT processed. If you have any questions or problems, please contact "Majordomo-Owner(a)tradinghouse.com".

1 0

Majordomo results: Re: TICKET# 009041 [Global-Marketplace]
by Majordomo＠tradinghouse.com 19 Dec '97

19 Dec '97

-- >>>> This is to confirm that your message has been received by **** Command 'this' not recognized. >>>> Island Internet's support department. **** Command 'island' not recognized. >>>> >>>> Thank you, **** Command 'thank' not recognized. >>>> Island Internet **** Command 'island' not recognized. >>>> >>>> **** No valid commands found. **** Commands must be in message BODY, not in HEADER. **** Help for Majordomo(a)tradinghouse.com: This help message is being sent to you from the Majordomo mailing list management system at Majordomo(a)tradinghouse.com. This is version 1.94.3 of Majordomo. If you're familiar with mail servers, an advanced user's summary of Majordomo's commands appears at the end of this message. Majordomo is an automated system which allows users to subscribe and unsubscribe to mailing lists, and to retrieve files from list archives. You can interact with the Majordomo software by sending it commands in the body of mail messages addressed to "Majordomo(a)tradinghouse.com". Please do not put your commands on the subject line; Majordomo does not process commands in the subject line. You may put multiple Majordomo commands in the same mail message. Put each command on a line by itself. If you use a "signature block" at the end of your mail, Majordomo may mistakenly believe each line of your message is a command; you will then receive spurious error messages. To keep this from happening, either put a line starting with a hyphen ("-") before your signature, or put a line with just the word end on it in the same place. This will stop the Majordomo software from processing your signature as bad commands. Here are some of the things you can do using Majordomo: I. FINDING OUT WHICH LISTS ARE ON THIS SYSTEM To get a list of publicly-available mailing lists on this system, put the following line in the body of your mail message to Majordomo(a)tradinghouse.com: lists Each line will contain the name of a mailing list and a brief description of the list. To get more information about a particular list, use the "info" command, supplying the name of the list. For example, if the name of the list about which you wish information is "demo-list", you would put the line info demo-list in the body of the mail message. II. SUBSCRIBING TO A LIST Once you've determined that you wish to subscribe to one or more lists on this system, you can send commands to Majordomo to have it add you to the list, so you can begin receiving mailings. To receive list mail at the address from which you're sending your mail, simply say "subscribe" followed by the list's name: subscribe demo-list If for some reason you wish to have the mailings go to a different address (a friend's address, a specific other system on which you have an account, or an address which is more correct than the one that automatically appears in the "From:" header on the mail you send), you would add that address to the command. For instance, if you're sending a request from your work account, but wish to receive "demo-list" mail at your personal account (for which we will use "jqpublic(a)my-isp.com" as an example), you'd put the line subscribe demo-list jqpublic(a)my-isp.com in the mail message body. Based on configuration decisions made by the list owners, you may be added to the mailing list automatically. You may also receive notification that an authorization key is required for subscription. Another message will be sent to the address to be subscribed (which may or may not be the same as yours) containing the key, and directing the user to send a command found in that message back to Majordomo(a)tradinghouse.com. (This can be a bit of extra hassle, but it helps keep you from being swamped in extra email by someone who forged requests from your address.) You may also get a message that your subscription is being forwarded to the list owner for approval; some lists have waiting lists, or policies about who may subscribe. If your request is forwarded for approval, the list owner should contact you soon after your request. Upon subscribing, you should receive an introductory message, containing list policies and features. Save this message for future reference; it will also contain exact directions for unsubscribing. If you lose the intro mail and would like another copy of the policies, send this message to Majordomo(a)tradinghouse.com: intro demo-list (substituting, of course, the real name of your list for "demo-list"). III. UNSUBSCRIBING FROM MAILING LISTS Your original intro message contains the exact command which should be used to remove your address from the list. However, in most cases, you may simply send the command "unsubscribe" followed by the list name: unsubscribe demo-list (This command may fail if your provider has changed the way your address is shown in your mail.) To remove an address other than the one from which you're sending the request, give that address in the command: unsubscribe demo-list jqpublic(a)my-isp.com In either of these cases, you can tell Majordomo(a)tradinghouse.com to remove the address in question from all lists on this server by using "*" in place of the list name: unsubscribe * unsubscribe * jqpublic(a)my-isp.com IV. FINDING THE LISTS TO WHICH AN ADDRESS IS SUBSCRIBED To find the lists to which your address is subscribed, send this command in the body of a mail message to Majordomo(a)tradinghouse.com: which You can look for other addresses, or parts of an address, by specifying the text for which Majordomo should search. For instance, to find which users at my-isp.com are subscribed to which lists, you might send the command which my-isp.com Note that many list owners completely or fully disable the "which" command, considering it a privacy violation. V. FINDING OUT WHO'S SUBSCRIBED TO A LIST To get a list of the addresses on a particular list, you may use the "who" command, followed by the name of the list: who demo-list Note that many list owners allow only a list's subscribers to use the "who" command, or disable it completely, believing it to be a privacy violation. VI. RETRIEVING FILES FROM A LIST'S ARCHIVES Many list owners keep archives of files associated with a list. These may include: - back issues of the list - help files, user profiles, and other documents associated with the list - daily, monthly, or yearly archives for the list To find out if a list has any files associated with it, use the "index" command: index demo-list If you see files in which you're interested, you may retrieve them by using the "get" command and specifying the list name and archive filename. For instance, to retrieve the files called "profile.form" (presumably a form to fill out with your profile) and "demo-list.9611" (presumably the messages posted to the list in November 1996), you would put the lines get demo-list profile.form get demo-list demo-list.9611 in your mail to Majordomo(a)tradinghouse.com. VII. GETTING MORE HELP To contact a human site manager, send mail to Majordomo-Owner(a)tradinghouse.com. To contact the owner of a specific list, send mail to that list's approval address, which is formed by adding "-approval" to the user-name portion of the list's address. For instance, to contact the list owner for demo-list(a)tradinghouse.com, you would send mail to demo-list-approval(a)tradinghouse.com. To get another copy of this help message, send mail to Majordomo(a)tradinghouse.com with a line saying help in the message body. VIII. COMMAND SUMMARY FOR ADVANCED USERS In the description below items contained in []'s are optional. When providing the item, do not include the []'s around it. Items in angle brackets, such as <address>, are meta-symbols that should be replaced by appropriate text without the angle brackets. It understands the following commands: subscribe <list> [<address>] Subscribe yourself (or <address> if specified) to the named <list>. unsubscribe <list> [<address>] Unsubscribe yourself (or <address> if specified) from the named <list>. "unsubscribe *" will remove you (or <address>) from all lists. This _may not_ work if you have subscribed using multiple addresses. get <list> <filename> Get a file related to <list>. index <list> Return an index of files you can "get" for <list>. which [<address>] Find out which lists you (or <address> if specified) are on. who <list> Find out who is on the named <list>. info <list> Retrieve the general introductory information for the named <list>. intro <list> Retrieve the introductory message sent to new users. Non-subscribers may not be able to retrieve this. lists Show the lists served by this Majordomo server. help Retrieve this message. end Stop processing commands (useful if your mailer adds a signature). Commands should be sent in the body of an email message to "Majordomo(a)tradinghouse.com". Multiple commands can be processed provided each occurs on a separate line. Commands in the "Subject:" line are NOT processed. If you have any questions or problems, please contact "Majordomo-Owner(a)tradinghouse.com".

1 0

Majordomo results: Re: TICKET# 009041 [Global-Marketplace]
by Majordomo＠tradinghouse.com 19 Dec '97

19 Dec '97

-- >>>> This is to confirm that your message has been received by **** Command 'this' not recognized. >>>> Island Internet's support department. **** Command 'island' not recognized. >>>> >>>> Thank you, **** Command 'thank' not recognized. >>>> Island Internet **** Command 'island' not recognized. >>>> >>>> **** No valid commands found. **** Commands must be in message BODY, not in HEADER. **** Help for Majordomo(a)tradinghouse.com: This help message is being sent to you from the Majordomo mailing list management system at Majordomo(a)tradinghouse.com. This is version 1.94.3 of Majordomo. If you're familiar with mail servers, an advanced user's summary of Majordomo's commands appears at the end of this message. Majordomo is an automated system which allows users to subscribe and unsubscribe to mailing lists, and to retrieve files from list archives. You can interact with the Majordomo software by sending it commands in the body of mail messages addressed to "Majordomo(a)tradinghouse.com". Please do not put your commands on the subject line; Majordomo does not process commands in the subject line. You may put multiple Majordomo commands in the same mail message. Put each command on a line by itself. If you use a "signature block" at the end of your mail, Majordomo may mistakenly believe each line of your message is a command; you will then receive spurious error messages. To keep this from happening, either put a line starting with a hyphen ("-") before your signature, or put a line with just the word end on it in the same place. This will stop the Majordomo software from processing your signature as bad commands. Here are some of the things you can do using Majordomo: I. FINDING OUT WHICH LISTS ARE ON THIS SYSTEM To get a list of publicly-available mailing lists on this system, put the following line in the body of your mail message to Majordomo(a)tradinghouse.com: lists Each line will contain the name of a mailing list and a brief description of the list. To get more information about a particular list, use the "info" command, supplying the name of the list. For example, if the name of the list about which you wish information is "demo-list", you would put the line info demo-list in the body of the mail message. II. SUBSCRIBING TO A LIST Once you've determined that you wish to subscribe to one or more lists on this system, you can send commands to Majordomo to have it add you to the list, so you can begin receiving mailings. To receive list mail at the address from which you're sending your mail, simply say "subscribe" followed by the list's name: subscribe demo-list If for some reason you wish to have the mailings go to a different address (a friend's address, a specific other system on which you have an account, or an address which is more correct than the one that automatically appears in the "From:" header on the mail you send), you would add that address to the command. For instance, if you're sending a request from your work account, but wish to receive "demo-list" mail at your personal account (for which we will use "jqpublic(a)my-isp.com" as an example), you'd put the line subscribe demo-list jqpublic(a)my-isp.com in the mail message body. Based on configuration decisions made by the list owners, you may be added to the mailing list automatically. You may also receive notification that an authorization key is required for subscription. Another message will be sent to the address to be subscribed (which may or may not be the same as yours) containing the key, and directing the user to send a command found in that message back to Majordomo(a)tradinghouse.com. (This can be a bit of extra hassle, but it helps keep you from being swamped in extra email by someone who forged requests from your address.) You may also get a message that your subscription is being forwarded to the list owner for approval; some lists have waiting lists, or policies about who may subscribe. If your request is forwarded for approval, the list owner should contact you soon after your request. Upon subscribing, you should receive an introductory message, containing list policies and features. Save this message for future reference; it will also contain exact directions for unsubscribing. If you lose the intro mail and would like another copy of the policies, send this message to Majordomo(a)tradinghouse.com: intro demo-list (substituting, of course, the real name of your list for "demo-list"). III. UNSUBSCRIBING FROM MAILING LISTS Your original intro message contains the exact command which should be used to remove your address from the list. However, in most cases, you may simply send the command "unsubscribe" followed by the list name: unsubscribe demo-list (This command may fail if your provider has changed the way your address is shown in your mail.) To remove an address other than the one from which you're sending the request, give that address in the command: unsubscribe demo-list jqpublic(a)my-isp.com In either of these cases, you can tell Majordomo(a)tradinghouse.com to remove the address in question from all lists on this server by using "*" in place of the list name: unsubscribe * unsubscribe * jqpublic(a)my-isp.com IV. FINDING THE LISTS TO WHICH AN ADDRESS IS SUBSCRIBED To find the lists to which your address is subscribed, send this command in the body of a mail message to Majordomo(a)tradinghouse.com: which You can look for other addresses, or parts of an address, by specifying the text for which Majordomo should search. For instance, to find which users at my-isp.com are subscribed to which lists, you might send the command which my-isp.com Note that many list owners completely or fully disable the "which" command, considering it a privacy violation. V. FINDING OUT WHO'S SUBSCRIBED TO A LIST To get a list of the addresses on a particular list, you may use the "who" command, followed by the name of the list: who demo-list Note that many list owners allow only a list's subscribers to use the "who" command, or disable it completely, believing it to be a privacy violation. VI. RETRIEVING FILES FROM A LIST'S ARCHIVES Many list owners keep archives of files associated with a list. These may include: - back issues of the list - help files, user profiles, and other documents associated with the list - daily, monthly, or yearly archives for the list To find out if a list has any files associated with it, use the "index" command: index demo-list If you see files in which you're interested, you may retrieve them by using the "get" command and specifying the list name and archive filename. For instance, to retrieve the files called "profile.form" (presumably a form to fill out with your profile) and "demo-list.9611" (presumably the messages posted to the list in November 1996), you would put the lines get demo-list profile.form get demo-list demo-list.9611 in your mail to Majordomo(a)tradinghouse.com. VII. GETTING MORE HELP To contact a human site manager, send mail to Majordomo-Owner(a)tradinghouse.com. To contact the owner of a specific list, send mail to that list's approval address, which is formed by adding "-approval" to the user-name portion of the list's address. For instance, to contact the list owner for demo-list(a)tradinghouse.com, you would send mail to demo-list-approval(a)tradinghouse.com. To get another copy of this help message, send mail to Majordomo(a)tradinghouse.com with a line saying help in the message body. VIII. COMMAND SUMMARY FOR ADVANCED USERS In the description below items contained in []'s are optional. When providing the item, do not include the []'s around it. Items in angle brackets, such as <address>, are meta-symbols that should be replaced by appropriate text without the angle brackets. It understands the following commands: subscribe <list> [<address>] Subscribe yourself (or <address> if specified) to the named <list>. unsubscribe <list> [<address>] Unsubscribe yourself (or <address> if specified) from the named <list>. "unsubscribe *" will remove you (or <address>) from all lists. This _may not_ work if you have subscribed using multiple addresses. get <list> <filename> Get a file related to <list>. index <list> Return an index of files you can "get" for <list>. which [<address>] Find out which lists you (or <address> if specified) are on. who <list> Find out who is on the named <list>. info <list> Retrieve the general introductory information for the named <list>. intro <list> Retrieve the introductory message sent to new users. Non-subscribers may not be able to retrieve this. lists Show the lists served by this Majordomo server. help Retrieve this message. end Stop processing commands (useful if your mailer adds a signature). Commands should be sent in the body of an email message to "Majordomo(a)tradinghouse.com". Multiple commands can be processed provided each occurs on a separate line. Commands in the "Subject:" line are NOT processed. If you have any questions or problems, please contact "Majordomo-Owner(a)tradinghouse.com".

1 0

Majordomo results: TICKET# 009041 [Global-Marketplace] Free
by Majordomo＠tradinghouse.com 19 Dec '97

19 Dec '97

-- >>>> This is to confirm that your message has been received by **** Command 'this' not recognized. >>>> Island Internet's support department. **** Command 'island' not recognized. >>>> >>>> If you have any other questions about this problem, or call our **** Command 'if' not recognized. >>>> technical support line, please be sure to refer to the ticket number **** Command 'technical' not recognized. >>>> that is given in the subject of this message. **** Command 'that' not recognized. >>>> >>>> When replying to messages that contain a ticket number in the subject **** Command 'when' not recognized. >>>> line, please do not remove the ticket number as this refers to this **** Command 'line,' not recognized. >>>> particular support problem. **** Command 'particular' not recognized. >>>> >>>> If you were replying to a previously opened ticket, and you have been **** Command 'if' not recognized. >>>> returned a NEW ticket number, this means the old ticket is closed and **** Command 'returned' not recognized. >>>> you have been assigned a new ticket number. **** Command 'you' not recognized. >>>> >>>> Thank you, **** Command 'thank' not recognized. >>>> Island Internet **** Command 'island' not recognized. >>>> >>>> **** No valid commands found. **** Commands must be in message BODY, not in HEADER. **** Help for Majordomo(a)tradinghouse.com: This help message is being sent to you from the Majordomo mailing list management system at Majordomo(a)tradinghouse.com. This is version 1.94.3 of Majordomo. If you're familiar with mail servers, an advanced user's summary of Majordomo's commands appears at the end of this message. Majordomo is an automated system which allows users to subscribe and unsubscribe to mailing lists, and to retrieve files from list archives. You can interact with the Majordomo software by sending it commands in the body of mail messages addressed to "Majordomo(a)tradinghouse.com". Please do not put your commands on the subject line; Majordomo does not process commands in the subject line. You may put multiple Majordomo commands in the same mail message. Put each command on a line by itself. If you use a "signature block" at the end of your mail, Majordomo may mistakenly believe each line of your message is a command; you will then receive spurious error messages. To keep this from happening, either put a line starting with a hyphen ("-") before your signature, or put a line with just the word end on it in the same place. This will stop the Majordomo software from processing your signature as bad commands. Here are some of the things you can do using Majordomo: I. FINDING OUT WHICH LISTS ARE ON THIS SYSTEM To get a list of publicly-available mailing lists on this system, put the following line in the body of your mail message to Majordomo(a)tradinghouse.com: lists Each line will contain the name of a mailing list and a brief description of the list. To get more information about a particular list, use the "info" command, supplying the name of the list. For example, if the name of the list about which you wish information is "demo-list", you would put the line info demo-list in the body of the mail message. II. SUBSCRIBING TO A LIST Once you've determined that you wish to subscribe to one or more lists on this system, you can send commands to Majordomo to have it add you to the list, so you can begin receiving mailings. To receive list mail at the address from which you're sending your mail, simply say "subscribe" followed by the list's name: subscribe demo-list If for some reason you wish to have the mailings go to a different address (a friend's address, a specific other system on which you have an account, or an address which is more correct than the one that automatically appears in the "From:" header on the mail you send), you would add that address to the command. For instance, if you're sending a request from your work account, but wish to receive "demo-list" mail at your personal account (for which we will use "jqpublic(a)my-isp.com" as an example), you'd put the line subscribe demo-list jqpublic(a)my-isp.com in the mail message body. Based on configuration decisions made by the list owners, you may be added to the mailing list automatically. You may also receive notification that an authorization key is required for subscription. Another message will be sent to the address to be subscribed (which may or may not be the same as yours) containing the key, and directing the user to send a command found in that message back to Majordomo(a)tradinghouse.com. (This can be a bit of extra hassle, but it helps keep you from being swamped in extra email by someone who forged requests from your address.) You may also get a message that your subscription is being forwarded to the list owner for approval; some lists have waiting lists, or policies about who may subscribe. If your request is forwarded for approval, the list owner should contact you soon after your request. Upon subscribing, you should receive an introductory message, containing list policies and features. Save this message for future reference; it will also contain exact directions for unsubscribing. If you lose the intro mail and would like another copy of the policies, send this message to Majordomo(a)tradinghouse.com: intro demo-list (substituting, of course, the real name of your list for "demo-list"). III. UNSUBSCRIBING FROM MAILING LISTS Your original intro message contains the exact command which should be used to remove your address from the list. However, in most cases, you may simply send the command "unsubscribe" followed by the list name: unsubscribe demo-list (This command may fail if your provider has changed the way your address is shown in your mail.) To remove an address other than the one from which you're sending the request, give that address in the command: unsubscribe demo-list jqpublic(a)my-isp.com In either of these cases, you can tell Majordomo(a)tradinghouse.com to remove the address in question from all lists on this server by using "*" in place of the list name: unsubscribe * unsubscribe * jqpublic(a)my-isp.com IV. FINDING THE LISTS TO WHICH AN ADDRESS IS SUBSCRIBED To find the lists to which your address is subscribed, send this command in the body of a mail message to Majordomo(a)tradinghouse.com: which You can look for other addresses, or parts of an address, by specifying the text for which Majordomo should search. For instance, to find which users at my-isp.com are subscribed to which lists, you might send the command which my-isp.com Note that many list owners completely or fully disable the "which" command, considering it a privacy violation. V. FINDING OUT WHO'S SUBSCRIBED TO A LIST To get a list of the addresses on a particular list, you may use the "who" command, followed by the name of the list: who demo-list Note that many list owners allow only a list's subscribers to use the "who" command, or disable it completely, believing it to be a privacy violation. VI. RETRIEVING FILES FROM A LIST'S ARCHIVES Many list owners keep archives of files associated with a list. These may include: - back issues of the list - help files, user profiles, and other documents associated with the list - daily, monthly, or yearly archives for the list To find out if a list has any files associated with it, use the "index" command: index demo-list If you see files in which you're interested, you may retrieve them by using the "get" command and specifying the list name and archive filename. For instance, to retrieve the files called "profile.form" (presumably a form to fill out with your profile) and "demo-list.9611" (presumably the messages posted to the list in November 1996), you would put the lines get demo-list profile.form get demo-list demo-list.9611 in your mail to Majordomo(a)tradinghouse.com. VII. GETTING MORE HELP To contact a human site manager, send mail to Majordomo-Owner(a)tradinghouse.com. To contact the owner of a specific list, send mail to that list's approval address, which is formed by adding "-approval" to the user-name portion of the list's address. For instance, to contact the list owner for demo-list(a)tradinghouse.com, you would send mail to demo-list-approval(a)tradinghouse.com. To get another copy of this help message, send mail to Majordomo(a)tradinghouse.com with a line saying help in the message body. VIII. COMMAND SUMMARY FOR ADVANCED USERS In the description below items contained in []'s are optional. When providing the item, do not include the []'s around it. Items in angle brackets, such as <address>, are meta-symbols that should be replaced by appropriate text without the angle brackets. It understands the following commands: subscribe <list> [<address>] Subscribe yourself (or <address> if specified) to the named <list>. unsubscribe <list> [<address>] Unsubscribe yourself (or <address> if specified) from the named <list>. "unsubscribe *" will remove you (or <address>) from all lists. This _may not_ work if you have subscribed using multiple addresses. get <list> <filename> Get a file related to <list>. index <list> Return an index of files you can "get" for <list>. which [<address>] Find out which lists you (or <address> if specified) are on. who <list> Find out who is on the named <list>. info <list> Retrieve the general introductory information for the named <list>. intro <list> Retrieve the introductory message sent to new users. Non-subscribers may not be able to retrieve this. lists Show the lists served by this Majordomo server. help Retrieve this message. end Stop processing commands (useful if your mailer adds a signature). Commands should be sent in the body of an email message to "Majordomo(a)tradinghouse.com". Multiple commands can be processed provided each occurs on a separate line. Commands in the "Subject:" line are NOT processed. If you have any questions or problems, please contact "Majordomo-Owner(a)tradinghouse.com".

1 0

[Global-Marketplace] Free Subscription
by Global-Marketplace-Digest 19 Dec '97

19 Dec '97

Global-marketplace-digest is pleased to invite you to join a genuine emagazine for fresh trade inquiries worldwide from over 130 countries. Our subscribers are very serious business executives involved in all sectors of trade and industry and look forward to get new business opportunties through our digest sent by email. We monitor it very regularly and try hard to keep it open only for genuine businesses. If you are interested to subscribe you only have to send a new email message mailto:majordomo@tradinghouse.com Just write : subscribe global-marketplace-digest (DO NOT write anything else in subject or content area). If you are not sure if you wish to subscribe but want to know more details and a brief report on how to write a good trade offer/demand please write a message and mailto:majordomo@tradinghouse.com ONLY WRITE: info global-marketplace-digest Upon your message, you will receive a reply and confirmation and introduction to the digest with instructions on how to participate. If you do not wish to further receive any messages pls send a message to : nomail(a)tradinghouse.com We wish you a happy and prosperous new year if we dont hear from you. We apologize for any incovenience this mail may cause but if you are not interested please delete it. But we write you thinking you may benefit from this offer. Take care and wish you the best Global-Marketplace-digest

1 0

Lasers/Optics/Optical Tables - Save!
by K8156mpg4＠offsh1or.com 07 Dec '97

07 Dec '97

MWK INDUSTRIES SALE! JUST A QUICK LETTER TO SHOW YOU SOME LASERS- OPTICS AND OPTICAL TABLES SURPLUS THAT WE JUST RECEIVED. ITEM TRIMMU12 14 WATT ARGON LASER MADE FOR HEART SURGERY, TRIMEDYNE MODEL 900 TEMOO, POLORIZED,220VAC INPUT , WATER COOLED , FIBER LAUNCH, ALL ON ROLLAROUND CART EXCELENT FOR LAB USE, THE POWER WAS MEASURED AT 13 TO 14 WATTS. PRICE $9500 12 MONTH WARRANTEE. ITEM: COHERENT ARTICULATING ARM FROM A MODEL 451 CO2 MEDICAL LASER. ECCELLENT COND. $200 ITEM CO220A: CO2 LASER MADE BY PFIZER ,1990, FOR SURGERY, TATTOO REMOVAL ECT. 20 WATT OUTPUT , TESTED AND IN EXC. COND. 110 VAC INPUT, COST $40,000 NEW OUR PRICE 4,900. MODEL 20-C ITEM:PDA-1U1 SPECTRA PHYSICS QUANTRA RAY PULSED DYE LASER , GOOD FOR SPARE PARTS MODEL PDA-1 $500 ITEM NEWU1 NEWPORT OPTICAL TABLE 16" BY 36" 4" THICK, 1 " HOLE SPACING, COMES WITH A RUBBER ISOLATED TABLE STAND, NOT AIR SUPPORTED, $750 ITEM: HEPSN1 HELIUM NEON POWER SUPPLY KIT OPERATES UP TO A 15 mW LASER, INCLUDES ALL COMPONENTS AND PRINTED CIRCUIT BOARD, ALL YOU HAVE TO DO IS STUFF AND SOLDER THE CIRCUIT BOARD . 4" BY 3" BY 3", PRICE $75 ITEM HENEU12 1 TO 1.5 MW HE-NE LASER 632.8 nM INCLUDES 12VDC INPUT POWER SUPPLY ALL IN A PLASTIC HOUSING 6.25 IN. BY 1.375IN BY 2.25 IN. TEMOO,RANDOM POL. ,1.7 MR DIVERGENCE. 12 MONTH WARRANTEE , PRICE $45 ITEM MELU12 1 TO 2 mW HE-NE LASER 632.8 NM , PULLS FROM MEDICAL EQUIPMENT .EACH UNIT INCLUDES HE-NE HEAD AND POWER SUPPLY[110VAC INPUT]. ALL YOU NEED TO PROVIDE IS A POWER CORD AND A FUSE TO MAKE THE UNIT OPERATIONAL. THE BEAM IS TEM00, POLORIZED WE WILL COVER EACH UNIT WITH A 12 MONTH UNLIMITED HOUR WARRANTEE, EXCELLENT FOR FOR LAB OR HOME USE. NEW THESE COST APPROX. $350 OUR PRICE $85. DIMENSIONS 9.75 BY 1.25 INCHES, P.S. 4.25 BY 3.25BY 1.25 INCHES. ITEM RAMCNS1: RAMAN CELL OPTICS 308 nm AR/AR 4600 A 0=0 DEGREES 1000 MM FL. 2" DIA. NEW. ORIGINAL PRICE $520 OUR PRICE $175 ITEM TFPOLNS1: POLARIZERS , THIN FILM FOR 532 nm , NEW, ORIGINAL COST $590 EACH OUR PRICE $200 EACH 10 MM DIA. ITEM CO2OCNS1: CO2 HIGH REFECTOR AND OUTPUT COUPLER 10.5 MM DIA, OC =79%R NEW. $200 A SET. ITEM 25MNS1: DIELECTRIC BROADBAND MIRRORS 450 TO 700NM , NEW WITH PLASTIC PROTECTIVE COATINGS , 2 SIZES 25 MM SQ. AND 50 MM SQ. RECOMENDED FOR HIGHER POWER LASERS. 25MM SIZE ITEM 25MNS1 $20 50MM SIZE ITEM 50MNS1 $25 ITEM # BSDNS1: 50/50 DIELECTRIC COATED PLATE BEAM SPLITTER 630 TO 660 NM COMES IN A TRIANGLE SHAPE EACH SIDE APPROX. 1" PRICE $20 ITEM # 45NS1 45 DEGREE RED REFLECTOR , PASSES 488 TO 532NM , CAN BE USED TO COMBINE RED AND GREEN/BLUE LASERS TO CREATE A WHITE LIGHT LASER. 1" SQ. PRICE $15 ITEM# PCINS1 PLANO/CONVEX LENS COATED FOR YAG 1064NM , AR COATED, 10MM DIA. NEW, ORIG. COST $250 OUR PRICE $100 ITEM# INFILTER : INTERFERENCE FILTERS USED FOR PASSING A PARTICULAR SPECTRAL LINE , 11.8 MM DIA. CAREFULLY REMOVED FROM MEDICAL EQUIPMENT AND WRAPPED IN LENSE PAPER. THE FOLLOWING WAVE LENGTHS ARE AVAILABLE. 523.5, 547.4 , 572.1, 512.9, 550.6, 488, 505.7 nm price $20 each. FOR A COMPLETE LINE OF NEW AND USED LASERS - OPTICS -ELECTRO OPTICS- LASER SHOWS ORDER A COMPLETE CATALOG AT MWKINDUSTRIES.COM TO: ORDER GO TO OUR WEB SITE MWKINDUSTRIES.COM {SECURE ORDERING SITE} QUESTIONS OR REMOVAL FROM MAILING LIST EMAIL: MWK(a)WORLDNET.ATT.NET MWK INDUSTRIES 1269 POMONA RD CORONA CA 91720 PHONE 909-278-0563 FAX 909-278-4887

1 0

We will mail 4 U
by 73fz0Vyhp＠le1ttrbox.com 25 Nov '97

25 Nov '97

LET US DO YOUR BULK MAILINGS!!! ..$250 PER MILLION THE WAY OF THE FUTURE FOR SUCCESS IN YOUR BUSINESS! Our company will do bulk emailing for your product/service. Addresses are extracted daily by four of our computers, which run 24 hours a day 7 days a week, scanning the net for new addresses. They are fresh! Over 36 million addresses on file. No more than 2 pages (50 lines), no porn and no foul language. We do not do targeted mailings at this price. Targeted mailings $150 per 50,000 addresses extracted. There are no lower prices on the net. Your mailing can be done in a matter of hours. We have 4 computers extracting addresses 24/7. For the fastest service, cheapest prices and cleanest mailings call our processing and new accounts office at 904-282-0945, Monday - Friday 9 - 5 EST. If the line is busy, please keep trying, as bulk mailing is growing fast. We do want to work with you to advertise your product. $250 per million expires December 1, 1997. Price increases to $350 per million, $250 per 500,000. All orders received before December 1 will not reflect the increase. Even with the increase, we will still be the best prices on the net. To have your name removed, call our processing office. Any negative responses will be dealt with accordingly.

1 0

RE: fancy route objects
by Paul Dyke 04 Nov '97

04 Nov '97

The entry by myself was generated by RIPE as an error to an email. I did try to delete it but have had no success. Can you help. Regards Paul Dyke -----Original Message----- From: Gabor Kiss (Bitman) [SMTP:kissg@sztaki.hu] Sent: 03 November 1997 12:20 To: ripe-dbm(a)ripe.net Cc: db-wg(a)ripe.net; Paul.Dyke(a)bt.net; bridge(a)unisource.ch; gaga(a)elte.hu Subject: fancy route objects Dear Colleagues, Are there these route objects correct (is this some very new feature?) or they come from some software bug? Three independent user can't get mad the same time. Note: these objects cannot be queried. I've browsed the mirrored DB file. Gabor *rt: 127.255.255.255/24 *de: TAT GmbH Systeme der grafische Datenverarbeit *or: AS2856 *mb: BTNET-MNT *ch: Paul.Dyke(a)bt.net 970916 *so: RIPE *rt: 127.255.255.255/16 *de: upstream provider: Swisscom (formerly Unisource Business Networks) *or: AS3303 *mb: CH-UNISOURCE-MNT *ch: bridge(a)unisource.ch 971017 *so: RIPE *rt: 127.255.255.255/24 *de: upstream provider: Swisscom (formerly Unisource Business Networks) *or: AS3303 *mb: CH-UNISOURCE-MNT *ch: bridge(a)unisource.ch 971017 *so: RIPE *rt: 127.255.255.255/23 *de: HU-CEU *or: AS2012 *mb: AS2012-MNT *ch: gaga(a)elte.hu 971027 *so: RIPE

1 0

IMPORTANT; Aut-num objects.
by RIPE Database Administration 03 Nov '97

03 Nov '97

Dear Colleagues, The data file and index file of the aut-num objects were corrupted this morning. This caused the aut-num objects not to be available. We regenerated the indexes. However, we discovered that some aut-num objects were missing. Thus, we rebuilt the data file using a back-up copy and generated new indexes. The aut-num objects file was reliable until 00:00 hours UTC on Monday, 3 November. The whois service was reliable again at 17:00 hours UTC this evening and the ftp copy of the aut-num objects was valid again at 20:00 hours UTC tonight. We are aware that this may have caused you some inconvenience; we therefore fixed the problem as fast as we could. If you use the data in the aut-num objects file as a basis for build routing tables or any similar purpose, we recommend that you obtain a new copy of this data from our ftp-site. Only the aut-num objects were affected this morning. The other database objects appeared not to be affected. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

1 0

Re: Who should do entries in RIPE database?
by Wilfried Woeber, UniVie/ACOnet 03 Nov '97

03 Nov '97

>There is another problem too: some objects do have a mnt-by, however the >mntner has auth: NONE! :( Can we assume that these objects are well maintained? >My answer is: no. I wouldn't follow that particular line of reasoning! The fact that you/he/she/someone does not *restrict access* to objects does not mean that the maintainer does not *maintain* the objects!? I think we're still mixing aspects of - access rights to objects (=access authorization) - access rights to "registry spaces" (=object creation) - authentication & identification (=credibility of data) and last but not least - object aging and checkpointing, dangling pointers, non-ref.s, duplicates etc. >Janos > >PS. I have seen this with both inetnum and route objects. Wilfried.

1 0

fancy route objects
by Gabor Kiss (Bitman) 03 Nov '97

03 Nov '97

Dear Colleagues, Are there these route objects correct (is this some very new feature?) or they come from some software bug? Three independent user can't get mad the same time. Note: these objects cannot be queried. I've browsed the mirrored DB file. Gabor *rt: 127.255.255.255/24 *de: TAT GmbH Systeme der grafische Datenverarbeit *or: AS2856 *mb: BTNET-MNT *ch: Paul.Dyke(a)bt.net 970916 *so: RIPE *rt: 127.255.255.255/16 *de: upstream provider: Swisscom (formerly Unisource Business Networks) *or: AS3303 *mb: CH-UNISOURCE-MNT *ch: bridge(a)unisource.ch 971017 *so: RIPE *rt: 127.255.255.255/24 *de: upstream provider: Swisscom (formerly Unisource Business Networks) *or: AS3303 *mb: CH-UNISOURCE-MNT *ch: bridge(a)unisource.ch 971017 *so: RIPE *rt: 127.255.255.255/23 *de: HU-CEU *or: AS2012 *mb: AS2012-MNT *ch: gaga(a)elte.hu 971027 *so: RIPE

2 1

Re: Who should do entries in RIPE database?
by zsako＠banknet.net 03 Nov '97

03 Nov '97

> From owner-db-wg(a)ripe.net Mon Nov 3 11:27:09 1997 > > What about creating two databases? (Two categories of objects.) > > One for objects sent by non-registries, > > and one for well maintained, authentic objects. > > This may be an orthogonal categorization. Sorry, but many of the duplicates > (triplicates ...) already carry the "mnt-by" attribute, sometimes > even two instances the same one. There is another problem too: some objects do have a mnt-by, however the mntner has auth: NONE! :( Can we assume that these objects are well maintained? My answer is: no. Janos PS. I have seen this with both inetnum and route objects.

1 0

Re: Who should do entries in RIPE database?
by Gabor Kiss (Bitman) 03 Nov '97

03 Nov '97

> - Last but not least we could think about "closing" the DB for public, > that is anonymous, update or registration of objects. I think *that* > would require *very* careful consideration, discussion, and > establishing a broad consensus across (all of) the RIPE-WGs. > I'd also expect considerable impact on activities like RIDE. I got further (not too serious) ideas: What about creating two databases? (Two categories of objects.) One for objects sent by non-registries, and one for well maintained, authentic objects. Peoples could send objects to the level1 database, and registries could move the correct ones to level2. Level1 objects older than 6 months will be automatically and silently deleted. Level2 objects should be updated at least once a year, otherwise a warning message goes to the maintainer registry. After a certain period forgotten level2 objects go back to level1. All current object is on level1. Regards Gabor

2 1

Re: Who should do entries in RIPE database?
by Wilfried Woeber, UniVie/ACOnet 31 Oct '97

31 Oct '97

Folks, thanks for bringing this up for discussion! >The other point is to prevent the RIPE database from further pollution. >There should be some settings to guarantee this. What is your opinion: >should I post my suggestions just to 'lir-wg(a)ripe.net'and 'db-wg@ >ripe.net' or in addition also to 'local-ir(a)ripe.net'? I'll try to summarize from my point of view (both as DB-WG chair, Local-IR rep and of course as a dumb user :-) We have long since worked from the assumption that the "owner" of an object is responsible for it's on-going maintenance. We have always felt, that tigthening the rules too much would have a negative impact on all parties' willingness to register (at all) or to perform updates regularly. Then we introduced measures to protect *existing* objects by limiting the sources where updates (+ deletes :-) are accepted from (maintainer mechanism). This is particularly relevant for the IP Registry and for the Routing Registry. The next step has been protection of hierarchies in the object space with the mnt-lower mechanism, in particular for the Domain-Registry. Right now the Routing-WG and the NCC are working on the implementation of cross-notification for the routing registry. All of these mechanism can by now (or very soon) be used to ascertain a useful level of security and update control, including the referenced objects. This leaves us with two major weaknesses - or features: - A considerable percentage of the objects is not yet protected by the mechanisms which are readily available, and "tightening" the ropes requires a more careful approach by the various registries - leading to more work, in the end. In particular if we think about "owning" and protecting the person objects as referenced by data for the various registries.... - Nothing is there to prevent *any* party to put e.g. person objects into the DB. (And I certainly appreciate that myself!) Also, I suppose some other types of objects can be put into the DB without problems, unless they are in dircet conflict with one of the well-managed object spaces for a particular registry. This leaves us with a legacy of entries from the "Dark Ages" of DB deployment and with the on-going pollution of object space by way of "user error". This aspect is being addressed by the DB-Consistency Project. We work towards offering mechanisms to identify inconsistencies as described by a "catalogue of frequent problems" as well as by coming up with the logistics to repair these deficiencies. Again, to be successful, the registries shall be required to spend (considerable?) effort to participate in that activity. So what can be done on top of that to improve the situation? - We can offer improved mechaisms to deal with identification and authentication: this is on the agenda for the DB-Security Task Force. - We can try to improve the user interface. In particular to help the end-users to avoid the popular crimes like putting in just another person object as soon as there's a new reference: We (the AT-TLD administration) are in the process of designing and prototyping an interactive interface that should prevent most of these incidents. We're in contact with the NCC to determine the usefulness of that approach. Please stay tuned. - Last but not least we could think about "closing" the DB for public, that is anonymous, update or registration of objects. I think *that* would require *very* careful consideration, discussion, and establishing a broad consensus across (all of) the RIPE-WGs. I'd also expect considerable impact on activities like RIDE. But it is certainly not impossible to get that discussion going. Although (wearing no hat at all right now :-) I do not see a pressing need right now - taking into account that we have a set of mechanisms in the works to improve the situation. Comments and input welcome! Apologies for the lengthy speech... Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)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 --------------------------------------------------------------------------

1 0

Re: Who should do entries in RIPE database?
by Carol Orange 31 Oct '97

31 Oct '97

Dear Carsten, Yes indeed, the consistency problems in the RIPE database are well known and are even well documented in: ftp://ftp.ripe.net/ripe/dbase/info/consistency* and ftp://ftp.ripe.net/ripe/presentations/ripe-m26-orange-dbcons.ps.gz or http://www.ripe.net/meetings/ripe/ripe-26/pres/db-consist/ Our plans to deal with them are also documented in: ftp://ftp.ripe.net/ripe/presentations/ripe-m27-orange-woeber-dbcons.ps.gz or http://www.ripe.net/meetings/ripe/ripe-27/pres/db/consistency/ We do plan to try to eliminate multiple objects pointing to the same person, as well as other clean ups of the person data. [As a side note, this project is now well underway.] We have not however discussed limiting the ability to enter data in the RIPE database, outside of the current and proposed authorization mechanisms. That would certainly be a significant change of course, and for that reason, I have cc'd the RIPE Database working group on this mail to get their feedback on this idea. Greetings, Carol Orange RIPE NCC In message <3456024C.70C28953(a)contrib.com>, Carsten Schiefner writes: >> As a result of a voluminous discussion with one of POPs I would like to >> point your interest on the following topic I am a little bit upset of: >> >> Almost everybody who knows about about the RIPE database schema (which >> is no secret at all!) can do entries just by sending a mail to >> 'auto-dbm(a)ripe.net'. This leads to an overwhelming bunch of multiple, >> bad maintained or what-ever-you-want entries - especially person >> objects - without any fun in grepping through them and selecting the >> right one to create a new object. Example: >> >> There are four(!) entries for the entity "Joerg Schmidt" of "ZWF >> Digitale Informations Technologie GmbH": JS893-RIPE, JS1161-RIPE, >> JS1163-RIPE and JS1438-RIPE. This should be definitely stopped! >> >> My idea is that we should discuss future restrictions on the possibility >> for everybody to put entries in the RIPE database, maybe by setting up >> and maintaing access lists for every LIR. >> >> For me this database is a central tool in my daily work and I am very >> interested in keeping quality and reliability of stored data as high >> as possible. >> >> Kind regards, >> >> Carsten Schiefner >> -- >> >> Carsten Schiefner mailto:schiefner@contrib.com >> TCP/IP GmbH, Berlin (Germany) - Contrib.Net http://www.contrib.com >> Phone: +49.30.44 33 66-0 Fax: +49.30.44 33 66-15 >> ======================================================================

2 1

Re: Who should do entries in RIPE database?
by NCC local-ir list Moderator 30 Oct '97

30 Oct '97

------- Forwarded Message From: Dale Amon as Operator <root(a)starbase1.gpl.net> Date: Thu, 30 Oct 97 11:21:59 GMT To: Carsten Schiefner <schiefne(a)contrib.com> Subject: Re: Who should do entries in RIPE database? Cc: local-ir(a)ripe.net Reply-To: amon(a)galileo.gpl.com References: <3456024C.70C28953(a)contrib.com> > There are four(!) entries for the entity "Joerg Schmidt" of "ZWF > Digitale Informations Technologie GmbH": JS893-RIPE, JS1161-RIPE, > JS1163-RIPE and JS1438-RIPE. This should be definitely stopped! > Why? > My idea is that we should discuss future restrictions on the possibility > for everybody to put entries in the RIPE database, maybe by setting up > and maintaing access lists for every LIR. > Please let's not add more things to remember. The job of admin people at ISP's is rough enough as it is. I'd personally rather see every possible effort made to decrease work loads on everyone's part, and to decrease the number of things that need to be remembered. I applaud the improvements made in the RIPE database over the last 5 years. The "smarts" in the process are a real help for people who are trying to do so many things at once that errors are inevitable. > For me this database is a central tool in my daily work and I am very > interested in keeping quality and reliability of stored data as high > as possible. It is also a central tool in my work and I am more interested in simplicity of the process of working with my own data than I am in simplicity of others using my data. So long as my routing and DNS work, I could care less if someone has 500 entries under their name. ------- End of Forwarded Message

1 0

Re: Who should do entries in RIPE database?
by NCC local-ir list Moderator 30 Oct '97

30 Oct '97

------- Forwarded Message From: Christian Kratzer <ck(a)toplink.net> Message-Id: <199710301109.MAA17929(a)toplink1.toplink.net> Subject: Re: Who should do entries in RIPE database? To: schiefne(a)contrib.com (Carsten Schiefner) Date: Thu, 30 Oct 1997 12:09:58 +0100 (MET) Cc: local-ir(a)ripe.net In-Reply-To: <3456024C.70C28953(a)contrib.com> from "Carsten Schiefner" at Oct 28, 97 04:18:36 pm X-Mailer: ELM [version 2.4 PL24 ME8a] Content-Type: text Content-Length: 1555 Hi > As a result of a voluminous discussion with one of POPs I would like to > point your interest on the following topic I am a little bit upset of: > > Almost everybody who knows about about the RIPE database schema (which > is no secret at all!) can do entries just by sending a mail to > 'auto-dbm(a)ripe.net'. This leads to an overwhelming bunch of multiple, > bad maintained or what-ever-you-want entries - especially person > objects - without any fun in grepping through them and selecting the > right one to create a new object. Example: > > There are four(!) entries for the entity "Joerg Schmidt" of "ZWF > Digitale Informations Technologie GmbH": JS893-RIPE, JS1161-RIPE, > JS1163-RIPE and JS1438-RIPE. This should be definitely stopped! > > My idea is that we should discuss future restrictions on the possibility > for everybody to put entries in the RIPE database, maybe by setting up > and maintaing access lists for every LIR. > > For me this database is a central tool in my daily work and I am very > interested in keeping quality and reliability of stored data as high > as possible. it would propably be sufficient to require a passphrase for auto-dbm(a)ripe.net so only regisitiers with registered passwords could submit entries or change records. This would definetely keep the "internet experts" from mucking around in the database.d Greetings Christian - -- TopLink GbR, Internet Services info(a)toplink.net Christian Kratzer http://www.toplink.net/ Phone: +49 7032 2701-0 Fax: +49 7032 2701-19 FreeBSD spoken here! ------- End of Forwarded Message

1 0

RIPE Database software release 2.1
by Chris Fletcher 27 Oct '97

27 Oct '97

RIPE Database software Version 2.1 is now available from: ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-2.1.tar.gz The release notes are included below. There a some new features including a new installation procedure and conversion to perl5. Please let us know if you have problems. Replies to <ripe-dbm(a)ripe.net>. Regards, Chris Fletcher - RIPE NCC RELEASE NOTES for RIPE Database 2.1 SUPPORTED SYSTEMS This release has been tested with perl5.00401 on bsdi2.1 and GNU/linux systems. Please let us know if you have problems running it on other systems. FEATURES When an update sends an acknowledgement and a notification to the same mail address one or the other can be suppressed see SUPPRESSMESS in the config file. New concise format for acknowledgements and notifications. '-v' provides detailed object descriptions. Re-implemented Makefiles and package configuration for ease of use. Includes an 'uninstall' target to carefully remove the executable and libraries when upgrading. Now two help files, one about the whois interface delivered by whois and one about the mail interface delivered by mail. Notifications are sent when an object is created with a notify: attrib. Whole package runs under perl5.004 with DB_File interface to Berkley db. Perl5 hides a lot of platform specific things from scripts so various configuration options have been made obsolete and removed. DB_File allows you to increase the size of the in memory db file cache which greatly improves indexing performance. see DBCACHESIZE We have not tried it with other DBM packages but it should not be hard to change if you want to use GDBM_File. This could become a configuration option (or maybe use AnyDBM_File) if there is demand for it. Changed syntax of 'changed:' & 'withdrawn:' to allow a 4 digits in the year part of the date (8 digits in total rather than 6). Automatically added dates are 8 digits. Existing 6 digit date fields are left unchanged. BUG FIXES added word boundary matches to subject line parsing now matches 'new object' and not 'My Apple Newton'. added 'i' to regexp check of MAIL-FROM so is not case-sensitive changed code to match comments in ripedb.config won't log incoming serial updates to files if SERIALINCOMINGDIR is not defined. MISC Added copyright message to all source files to better assert our rights but licence has not changed from previous versions. I have had problems with bitwise operations on the large integers used to represent IP addresses. With some versions of perl5 a bitwise '&' returns a signed result. This causes classless lookups to fail. See comments about iprightzeromask in misc.pl. It seems to work with perl5.00401 Changes to ripedb.config The following values have been removed... HELP (replaced by WHOISHELP & AUTODBMHELP) RENICECMD (optional - will use setpriority(2) if not set) The following values have been added... WHOISHELP AUTODBMHELP ATTDESC OBJDESC DBCACHESIZE SUCCESSTXT HELPHEADER FAILURETXT

1 0

Re: some problem in syntax.pl
by Steven Bakker 20 Oct '97

20 Oct '97

>>>>> On Sat, 18 Oct 1997, "HH" == Hwang Hyojung wrote: HH> why do you eval check ? Isn't this necessary ? Rather, I think, HH> $regex is checked if it is valid email address. How do you think HH> about it ? If it is necessary, please explain why this is needed . HH> Thanks in advance !! Please read RIPE-157, section 2.3.3., Authorization Schemes (shouldn't that be "Authorisation", Ambrose? :-). There is a section labeled, `The "MAIL-FROM" scheme:', which explains that the MAIL-FROM value in the "mntner" object is treated as a regular expression, against which From:- headers will be matched. So, yes the "eval" is necessary to make sure people submit a valid regex in their "mntner" objects. While we are on the subject, RIPE-157 mentions that the regex should comply to the rules in "POSIX 1003.2 section 2.8." Not having read that document, I wonder if the POSIX syntax and Perl are identical. "syntax.pl" checks whether the regex is Perl-compliant. For example, does '(abc)' mean "the literal string '(abc)'", or (a-la Perl), "the subpattern 'abc'"? Cheers, Steven

1 0

some problem in syntax.pl
by Hwang Hyojung 18 Oct '97

18 Oct '97

Hi, I am Hyojung Hwang and working for Korea Telecom. I am using ripe dbase software. I found some problem or starnge things in this code. In syntax.pl, checking 'auth' attribute, --- elsif ($authstr[0] eq "MAIL-FROM") { local($regex) = $value; $regex =~ s/^\s*MAIL\-FROM\s*//; eval "/$regex/;"; if ($@) { return $O_ERROR, "\"$regex\" is not a legal regular expression"; } else { return $O_OK; } } --- why do you eval check ? Isn't this necessary ? Rather, I think, $regex is checked if it is valid email address. How do you think about it ? If it is necessary, please explain why this is needed . Thanks in advance !! -- * _ _ ==GD@: 56@L0m Hq8A@: 1$1b@L4Y. ||_|| ||_| Hwang, Hyojung / jung(a)jean.kotel.co.kr / 82-2-526-5235 |_| _|_ Internet Team / Multimedia Laboratory / KT R&D Group |_| 137-792, 17 Umyun-Dong, Seocho-Gu, Seoul, Korea

1 0