- NANOG - lists.nanog.org

subscribe
by sharono＠ukefl.demon.co.uk 20 Oct '95

20 Oct '95

subscribe nsfnet-cert(a)merit.edu sharono(a)ukefl.demon.co.uk

1 0

CERT Advisory CA-95:13 - Syslog Vulnerability (with sendmail workaround)
by CERT Advisory 19 Oct '95

19 Oct '95

============================================================================= CA-95:13 CERT Advisory October 19, 1995 Syslog Vulnerability - A Workaround for Sendmail ----------------------------------------------------------------------------- The CERT Coordination Center has received reports of problems with the syslog(3) subroutine. To the best of our current knowledge, the problem is present in virtually all versions of the UNIX Operating System except the following: Sony's NEWS-OS 6.X SunOS 5.5 (Solaris 2.5) Linux with libc version 4.7.2, released May 1995 We have received reports indicating that the vulnerability is being exploited with a script that has been written to be used with sendmail. This advisory includes a workaround that you can use with sendmail. It *does not* include workarounds for any other programs that use the syslog(3) subroutine--telnetd, ftpd, httpd, etc. The CERT Coordination Center recommends installing all appropriate syslog-related patches as soon as they are available from vendors. But, in the meantime, we suggest addressing at least the syslog problem in sendmail by installing sendmail version 8.7.1. We are aware that several workarounds concerning the syslog vulnerability have been published on the Internet, but the CERT staff has not formally evaluated them. As we receive additional information relating to this advisory, we will place it in ftp://info.cert.org/pub/cert_advisories/CA-95:13.README We encourage you to check our README files regularly for updates on advisories that relate to your site. ----------------------------------------------------------------------------- I. Description The syslog(3) subroutine uses an internal buffer for building messages that are sent to the syslogd(8) daemon. This subroutine does no range checking on data stored in this buffer. It is possible to overflow the internal buffer and rewrite the subroutine call stack. It is then possible to execute arbitrary programs. This problem is present in virtually all versions of the UNIX Operating System except the following: Sony's NEWS-OS 6.X SunOS 5.5 (Solaris 2.5) Linux with libc version 4.7.2 released in May, 1995 The sendmail(8) program uses the syslog(3) subroutine, and a script has been written and is being used to exploit the vulnerability. II. Impact Local and remote users can execute commands. Prior access to the system is not needed. Exploitation can lead to root access. III. Solution We recommend that you do all of A, B, and C. A. Install syslog patches from your vendor when they become available. Information we received from vendors as of the date of this advisory is attached as Appendix A and reproduced in CA-95:13.README. We will update the README file as vendors send updated information. When you install patches, you will need to recompile/relink any programs built on your system that have been compiled without shared libraries, that is, compiled statically. Be especially careful of programs that contain their own versions of the syslog(3) subroutine. You may need to do significant extra work to compile those programs to use the vendor-supplied patches. B. Install sendmail version 8.7.1. NOTE: This workaround addresses the syslog(3) vulnerability in sendmail only. The vulnerability still exists in all other programs that use syslog(3). When your vendor(s) provides a patch, we recommend that you rebuild sendmail version 8.7.1 with the patched syslog(3) and place that newly compiled version into service. Sendmail is available by anonymous FTP from ftp://info.cert.org/pub/tools/sendmail/ ftp://ftp.cs.berkeley.edu/ucb/sendmail/ ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/sendmail/ ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/ Checksum: MD5 (sendmail.8.7.1.tar.Z) = 4a66d07a059d1d5af5e9ea53ff1b396a Depending upon your currently installed sendmail program, switching to a different sendmail may require significant effort (such as rewriting the sendmail.cf file). See Section VI for additional notes on installation. In addition, Sections IV and V below contain scripts for building sendmail 8.7.1 for SunOS 4.1.X and Solaris 2.X, respectively. C. Install smrsh. To restrict the sendmail program mailer facility, install and use the sendmail restricted shell program (smrsh). We recommend that you do this regardless of whether you use the vendor's supplied sendmail or you install sendmail version 8.7.1. Smrsh is now included in the sendmail 8.7.1 distribution in the subdirectory smrsh. See the RELEASE_NOTES file for a description of how to integrate smrsh into your sendmail configuration file. IV. Building this package for SunOS 4.1.X Here is a script that is given as an illustration of how to build sendmail 8.7.1 for SunOS 4.1.X. Please refer to READ_ME in the src subdirectory for a more complete explanation of other options available during the compilation process. % uname -sr SunOS 4.1.2 % ls sendmail.8.7.1.tar.Z % zcat sendmail.8.7.1.tar.Z | tar xf - % cd sendmail-8.7.1/src % ./makesendmail LIBS='-lresolv' DBMDEF='-DNDBM -DNIS' \ INCDIRS= LIBDIRS= sendmail Configuration: os=SunOS, rel=4.1.2, rbase=4, arch=sun4, sfx= Creating obj.SunOS.4.1.2.sun4 using Makefile.SunOS Making dependencies in obj.SunOS.4.1.2.sun4 Making in obj.SunOS.4.1.2.sun4 ... See Section VI for final installation steps. V. Building this package for Solaris 2.X Here is a typescript that is given as an illustration for how to build sendmail 8.7.1 for Solaris 2.X. Note that this procedure assumes that you have the GNU gcc system. The examples below used gcc version 2.6.3. Again, please refer to READ_ME in the src sub-directory for a more complete explanation of other options available during the compilation process. % uname -sr SunOS 5.4 % ls sendmail.8.7.1.tar.Z % zcat sendmail.8.7.1.tar.Z | tar xf - % cd sendmail-8.7.1/src % ./makesendmail LIBS='-lresolv -lsocket -lnsl -lelf' \ INCDIRS= LIBDIRS= sendmail Configuration: os=SunOS, rel=5.4, rbase=5, arch=sun4, sfx= Creating obj.SunOS.5.4.sun4 using Makefile.SunOS.5.4 Making dependencies in obj.SunOS.5.4.sun4 ... Note: If you wish sendmail version 8.7.1 to use the aliases and configuration file directory conventions from SunOS 5.4, use the following command: ./makesendmail LIBS='-lresolv -lsocket -lnsl -lelf' \ ENVDEF='-DSOLARIS=204 -DUSE_VENDOR_CF_PATH' INCDIRS= \ LIBDIRS= sendmail VI. Final Installation Notes Sendmail can then be installed and configured with new configuration files as needed. We strongly recommend that if you change to sendmail 8.7.1, you also change to the configuration files that are provided with that version. Significant work has been done to make this task easier. It is now possible to build a sendmail configuration file (sendmail.cf) using the configuration files provided with this release. Consult the cf/READ_ME file for a more complete explanation. We recommended that you create your configuration files using this method because it provides a technique for incorporating any future changes to sendmail into your configuration files. In addition, we recommend that you recreate your configuration file (sendmail.cf) using the configuration files provided with 8.7.1. Finally, for Sun users, a paper is available to help you convert your sendmail configuration files from the Sun version of sendmail to one that works with version 8.7.1. The paper is entitled "Converting Standard Sun Config Files to Sendmail Version 8" and was written by Rick McCarty of Texas Instruments Inc. It is included in the distribution and is located in contrib/converting.sun.configs. --------------------------------------------------------------------------- The CERT Coordination Center staff thanks Eric Allman and Wolfgang Ley for their involvement in the development of this advisory, and thanks Karl Strickland and Neil Woods for reporting the vulnerability. --------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in the Forum of Incident Response and Security Teams (FIRST). If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the email be encrypted. The CERT Coordination Center can support a shared DES key, PGP (public key available via anonymous FTP on info.cert.org) or PEM (contact CERT staff for details). Internet email: cert(a)cert.org Telephone: +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. Fax: +1 412-268-6989 Postal address: CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 USA CERT advisories and bulletins are posted on the USENET newsgroup comp.security.announce. If you would like to have future advisories and bulletins mailed to you or to a mail exploder at your site, please send mail to cert-advisory-request(a)cert.org. Past CERT publications, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org. Copyright 1995 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for noncommercial purposes and the copyright statement is included. CERT is a service mark of Carnegie Mellon University. .............................................................................. Appendix A: Vendor Information Current as of October 19, 1995 See CA-95.13.README for updated information. Below is information we have received from vendors concerning the vulnerability described in this advisory. If you do not see your vendor's name, please contact the vendor directly for information. In addition to vendor information, note that the freely available Linux with libc version 4.7.2, released May 1995, is not vulnerable. -------------------- Eric Allman Sendmail version 8.7.1 is not vulnerable. This version is available by anonymous FTP from ftp://info.cert.org/pub/tools/sendmail/ ftp://ftp.cs.berkeley.edu/ucb/sendmail/ ftp://ftp.auscert.org.au/pub/mirrors/ftp.cs.berkeley.edu/ucb/sendmail/ ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/ Checksum: MD5 (sendmail.8.7.1.tar.Z) = 4a66d07a059d1d5af5e9ea53ff1b396a -------------------- Berkeley Software Design, Inc. Users of BSD/OS V2.0 and V2.0.1 by Berkeley Software Design, Inc. should install patch U201-001 which works for both versions. The patch is available to all BSDI customers in: ftp://ftp.bsdi.com/bsdi/patches/ md5 checksum: 88b3fd8c83a5926589d7b87b55bc4e14 -------------------- Cray Research Information about fixes for the syslog problem can be found in FN #2011, dated October 10, 1995. Customers should receive this information from their Cray Research service representative. For all source installations, your Cray Research service representative can obtain the fix via the getfix tool. Due to the number of executables which use this library routine, it is not possible to provide getfix packages for all binary installations. UNICOS binary update packages 8.0.4.2 and 9.0.1.2 include this mod. FIX AVAILABILITY ---------------- Release Level Fix Package Affected Product Containing Fix Availability ================ ============== =========== UNICOS 8.0 UNICOS 8.0.4.2 * source only UNICOS 8.3 ** source only UNICOS 9.0 UNICOS 9.0.1.2 * source only * This update is not yet available. ** No more updates planned -------------------- Digital Equipment Corporation At the time of writing this document, patches(binary kits) for Digital's ULTRIX platforms are in final testing and packaging. V4.3 (both VAX and RISC) thru V4.5. Similar patches(binary kits) for OSF/1 versions are in progress and testing is expected to begin the week of October 23, 1995 and then packaged for Customer distribution estimated to available in November. Digital will provide notice of the completion of the kits through AES services (DIA, DSNlink FLASH) and be available from your normal Digital Support channel. Digital's Software Security Response Team 10/18/95 -------------------- Open Software Foundation OSF cannot reproduce the security hole in OSF/1. However we have reproduced the problem with syslog(3). We have a fix for the syslog(3) problem. Support customers should contact OSF for the fix. The fix will be included in the OSF/1 R1.3.2 update release. -------------------- Silicon Graphics Inc. SGI has been in coordination with CERT regarding this issue. Specific SGI information was not complete before CERTs submission deadline for this advisory. SGI does have pending information and this information will be available via anonymous ftp (sgigate.sgi.com) and/or your SGI service provider and potential future CERT advisory addendums. -------------------- Solbourne (Grumman) Solbourne 2.5 is not vulnerable. -------------------- Sony Corporation NEWS-OS 6.0.3 and 6.1 are not vulnerable. -------------------- Sun Microsystems, Inc. SunOS 5.5 is not vulnerable.

1 0

lost RADB transactions on 10/14
by Brian Renaud 18 Oct '95

18 Oct '95

On Saturday the 14th, a mail loop caused a disk partition to fill up on the RADB server machine. It appears that any transaction sent to the RADB between 17:00 and 23:58 EDT on 10/14 was not processed. If you sent in a transaction to auto-dbm(a)ra.net during that time and did not receive a positive acknowledgement from the database software, then you should re-send the transactions. -Brian

1 0

CERT Advisory CA-95:12 - Sun 4.1.X Loadmodule Vulnerability
by CERT Advisory 18 Oct '95

18 Oct '95

============================================================================= CA-95:12 CERT Advisory October 18, 1995 Sun 4.1.X Loadmodule Vulnerability ----------------------------------------------------------------------------- The CERT Coordination Center has received reports of problems with the loadmodule(8) program. An exploitation script is available and has been used by local users to gain root privileges. The problem is present in SunOS 4.1.X only, and there is a patch available for sun4 architectures. The CERT staff recommends that you install the appropriate patch as soon as possible and take the steps in Section III.B. to further protect your system. As we receive additional information relating to this advisory, we will place it in ftp://info.cert.org/pub/cert_advisories/CA-95:12.README We encourage you to check our README files regularly for updates on advisories that relate to your site. ----------------------------------------------------------------------------- I. Description The loadmodule(8) program is used by the xnews(1) window system server to load two dynamically loadable kernel drivers into the currently running system and to create special devices in the /dev directory to use those modules. These modules and special files are used to provide a SunView binary compatibility mode while running the X11/NeWS windowing system. Because of the way the loadmodule(8) program sanitizes its environment, unauthorized users can gain root access on the local machine. A script is publicly available and has been used to exploit this vulnerability. This problem is present in SunOS 4.1.X only. II. Impact Local users can gain root privileges. III. Solution The CERT staff recommends that you take the steps described in both A and B below. A. Obtain and install the appropriate patches according to the instructions included with the patches. Patches are available through your local Sun Answer Center and by FTP from ftp://sunsolve1.sun.com/pub/patches/100448-03.tar.Z Module Patch ID Filename ---------- --------- --------------- loadmodule 100448-03 100448-03.tar.Z Checksum: MD5 (100448-03.tar.Z) = 183a22f0a2f6020f1389b6aeea5ca6c6 B. Because, in general, a set-user-id program can lead to security exposures, you should also do at least step 1 below. We recommend doing steps 2 and 3 as well. The intent of these directions is make the loadmodule(8) program work only for the super-user (currently it works for all users because it is set-user-id) and to execute it each time the system boots. By following these directions, users who require SunView binary compatibility will have it available to them. 1. If you do not need SunView binary compatibility, then as root, turn off setuid root on the loadmodule(8) program with # /bin/chmod u-s /usr/openwin/bin/loadmodule 2. If your users need SunView binary compatibility, you can enable it immediately--that is without having to reboot your system--with the following script. ------------------------cut here--8<------------------------ ARCH=`/bin/arch -k` OBJ=/sys/${ARCH}/OBJ LM=/usr/openwin/bin/loadmodule /bin/chmod u-s $LM if [ -f $OBJ/evqmod-${ARCH}.o ]; then if /usr/etc/modstat | /bin/egrep -s evqmod ; then echo evq: already loaded elif $LM evqmod-${ARCH}.o evqload; then echo evq: loaded else echo evq: unable to load module fi fi if [ -f $OBJ/winlock-${ARCH}.o ]; then if /usr/etc/modstat | /bin/egrep -s winlock ; then echo winlock: already loaded elif $LM winlock-${ARCH}.o winlockload; then echo winlock: loaded else echo winlock: unable to load module fi fi ------------------------cut here--8<------------------------ As a suggestion, store this script in /tmp/esbc and then execute it as root with: # sh /tmp/esbc 3. If you've done step 2 above, the module loadings will disappear the next time you reboot your system. To make them permanent-- that is to make these module loadings occur each time your system is rebooted--add the script to the end of your /etc/rc.local file. --------------------------------------------------------------------------- The CERT Coordination Center staff thanks Wolfgang Ley and Sun Microsystems for their support in the development of this advisory. --------------------------------------------------------------------------- If you believe that your system has been compromised, contact the CERT Coordination Center or your representative in the Forum of Incident Response and Security Teams (FIRST). If you wish to send sensitive incident or vulnerability information to CERT staff by electronic mail, we strongly advise that the email be encrypted. The CERT Coordination Center can support a shared DES key, PGP (public key available via anonymous FTP on info.cert.org) or PEM (contact CERT staff for details). Internet email: cert(a)cert.org Telephone: +1 412-268-7090 (24-hour hotline) CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), and are on call for emergencies during other hours. Fax: +1 412-268-6989 Postal address: CERT Coordination Center Software Engineering Institute Carnegie Mellon University Pittsburgh, PA 15213-3890 USA CERT advisories and bulletins are posted on the USENET newsgroup comp.security.announce. If you would like to have future advisories and bulletins mailed to you or to a mail exploder at your site, please send mail to cert-advisory-request(a)cert.org. Past CERT publications, information about FIRST representatives, and other information related to computer security are available for anonymous FTP from info.cert.org. Copyright 1995 Carnegie Mellon University This material may be reproduced and distributed without permission provided it is used for non-commercial purposes and the copyright statement is included. CERT is a service mark of Carnegie Mellon University.

1 0

New RA Tools Announcement
by labovit＠merit.edu 18 Oct '95

18 Oct '95

New Routing Arbiter Tools Announce ---------------------------------- The Routing Arbiter welcomes comments, bug-reports and suggestions for new tools. Please direct email to ra-team(a)ra.net. Please feel free to redistribute this announcement. A web version of this page lives at http://www.ra.net/~ra/tools ------------------------ Online Tools and Reports ------------------------ IRRWeb This graphical interface into the Internet Routing Registry makes it possible to use the Web to query the IRR and update RADB AS objects, Route objects, and Maintainer objects. Users can enter any value that can be submitted through a whois query, such as an AS number, network IP address, or maintainer. IRRWeb then displays the corresponding AS objects, Route objects, or Maintainer objects from the various registries in the IRR. Authorized maintainers can edit the objects directly; IRRWeb performs a cursory pre-check and mails the revised object to auto-dbm(a)ra.net. The user then receives e-mail from auto-dbm confirming and displaying the revised object, or explaining why the object was rejected. See http://www.ra.net/cgi-bin/ra/query-radb.pl Source code is available at ftp://ftp.ra.net/routing.arbiter/tools/irrweb.tar.gz Daily NAP Route Flap Reports</A> This new tool set generates daily reports of route flaps (link failures at regular and short intervals) throughout the Internet. Modeled after the reports originally produced by Curtis Villamizar of ANS, the new reports are generated using tools packaged with Merit's Multi-Threaded Routing Toolkit. The data is obtained from peering sessions with Route Servers at the interconnection points. The reports note the last state of the route (up or down), the length of time that a route existed (or did not exist) for that prefix, and the number of times a route for the prefix transitioned from down to up, up to down, or was replaced by a new route with changed attribute information. AS-path-specific information is also provided for every path announced for the prefix. See http://www.ra.net/~ra/tools/flap.html Route History Server The Route History Server provides a mechanism for tracking the announce/withdraw history of a given prefix for the last 24 hours. The History Server peers with the route servers at each NAP and records all BGP updates in History Server/Route Server peering session. See http://www.ra.net/cgi-bin/ra/rshist.pl ----------------------- Tools Available for FTP ----------------------- RSd The Route Server daemon (RSd) is an enhanced version of the GateD routing software that provides multiples views of routing information. The software provides a mechanism for network service provides to off-load the computational complexity of routing policy calculations from their routers. RSd supports configuration and transparent passing of BGP MEDs. The software also supports BGP route flap dampening. Available at ftp://ftp.ra.net/routing.arbiter/tools/rsd.tar.gz Peval A policy evaluator that inputs a RIPE-181 policy expression, performs essential background calculations such as symbolic evaluations and expansions, and outputs another RIPE-181 policy expression that is used by other tools, such as RTConfig. Available as part of the RAToolSet at ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet RTConfig A router configuration tool that can be used by providers to generate router configs directly from the RADB or other IRR registries. Currently in production use for the RA Route Servers, ANSNET, and CA*net, RTConfig is a front-end tool that uses peval and radbserver transparently to users. Available as part of the RAToolSet at ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet rrc2r/rrmerge This Cisco-to-RIPE-181 conversion package makes it possible for users to convert Cisco router configuration files to RIPE-181 objects that can be submitted to the Internet Routing Registry (IRR). The Cisco access-list can be converted into an explicit set of nets embedded in an AS object or represented as a community. The RADBserver is queried for any missing or previously registered information. Available at ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet/rrc2r-0.2.tar.gz CiscoBGP IRR users have long recognized the need for tools that check the IRR against routes actually propagated in the Internet. CiscoBGP obtains and analyzes routing information from production Ciscos, and compares the data with routes in the IRR. The software also flags prefixes that are reserved by RFC 1597, Address Allocation for Private Internets. Available as part of the MRT software distribution at http://www.merit.edu/~mrt BGPCheck BGPCheck obtains and analyzes routing information from BGP4 peering sessions, and compares the data with routes in the IRR. The software also flags prefixes that are reserved by RFC 1597, <em>Address Allocation for Private Internets</em>. Available as part of the MRT software distribution at http://www.merit.edu/~mrt PRtraceroute The 'prtraceroute' tool is a powerful form of traceroute that displays the Autonomous Systems that a packet traverses. PRtraceroute was developed by the Pride project. A version of prtraceroute that queries the RADB is available at ftp://ftp.ra.net/routing.arbiter/pride/prtraceroute-2.0beta2.shar.gz ------------------ Tool Announcements ------------------ PGP-Based Radb Authentication Follow these steps to take advantage of the new RADB support for PGP-based digital signatures: 1. Register your public key with the Routing Arbiter Service. 2. Modify your Maintainer object to reflect your use of digital signatures. 3. Use PGP to sign your RADB transactions. For detailed instructions, see: http://www.ra.net/routing.arbiter/RA/RADB.tools.docs/pgp.html -- Craig Labovitz labovit(a)merit.edu Merit Network, Inc. 4251 Plymouth Road, Suite C. (313) 764-0252 (office) Ann Arbor, MI 48105 (313) 747-3745 (fax)

1 0

Asymmetric Routing
by joliveto＠cwi.net 18 Oct '95

18 Oct '95

Analysis of some of our routes shows the potential for asymmetric routing...that is...the transmit path will be different than the return path for packets. Questions: How noticeable is this likely to be for customer traffic/applications? Are there failure conditions waiting to haunt us? For this type of route, how does one go about troubleshooting route failures? Any bad experiences out their with such routes in place? Am I being paranoid? Thanks; - jeff - Jeff Oliveto Sr.Mgr. Operations Technical Services ----------------------------------------------------------------------------- Cable & Wireless, Inc | Phone: +1.703.760.1764 1919 Gallows Road | Fax: +1.703.760.3321 Vienna, VA 22182 | Email: joliveto(a)cwi.net | URL: http://www.cwi.net/ -----------------------------------------------------------------------------

2 1

unsubscribe..
by gopi＠ece.iisc.ernet.in 18 Oct '95

18 Oct '95

unsubscribe nanog gopi(a)ece.iisc.ernet.in

1 0

Re: Legislative Relief - was Re: Motion for a new POST NSF AUP
by postel＠ISI.EDU 18 Oct '95

18 Oct '95

Hmm. I really dislike the email spam, and would like to find a technical means to stop it. I am not so sure we would be happy with the results of trying make it illegal, though. But just what is the legal definition of spam ? If it looks like spam, smells like spam, tastes like spam, then it must be spam! Or is it like obsenity, the definition of which even the Supreme Court seems to have trouble pinning down? I don't think we really want any more laws that criminalize ill defined acts. --jon.

12 11

Legislative Relief - was Re: Motion for a new POST NSF AUP
by Robert Raisch, The Internet Company 18 Oct '95

18 Oct '95

On 15 Oct 95 at 15:24, George Herbert wrote: > Just as a warning, some of us on the recieving end of more than our fair > share of net abuse (the collected Usenet moderators) are starting to get > more than a little short fuzed about this. I would like to propose that we seek legislative relief from this ever-increasing problem. I have spoken with counsel and now understand what is required to support the enactment of federal legislation to prohibit the misuse of electronic mail and Usenet news by unprincipled "spammers." There is already law which prohibits marketing via facsimile and cellular telephone. My position is that e-mail and Usenet news are similar vehicles in the sense that there is a measurable cost on the receiver's end. I believe that this has the potential of being a high-visibility legal issue, and one that would be a "vote getter" as it speaks directly to an educated, active voting constituency. I plan on pursuing this with Sen. Edward Markey's office, as he is my local legislative representative and chairs the House Telecommunications Committee which is responsible for the facsimile law, as I understand it. To do this effectively, such an effort would require certain financial resources to support things like a state by state search for existing legislative and the creation of new draft legislation. I'll be providing information about this at our booth at Internet World at the end of the month and would like to see if there is enough support for this project to sponsor it at the grassroots. Please respond to me directly with your thoughts. </rr> Robert Raisch, Chief Scientist The Internet Company 96 Sherman Street Cambridge, MA 021040 617-547-3600 617-547-3300 FAX -- The Internet Company - info(a)internet.com We Bring Only Value to the Global Internet

5 4

SECOND CALL FOR AUP MOTION
by Tim Bass 17 Oct '95

17 Oct '95

Ladies and Gentlemen: I think it is fair to say the motion on the table calling for a post NSF AUP is not ready to be withdrawn nor tabled and that there is sufficient support to call for a group to work together to create a rough draft. It will be very challenging to see a diverse and informed crowd such as the cross-section of com-priv and nanog attempt to reach an 80 to 90 percent concensus on what constitutes "Acceptable Usage" of the Internet. Maybe we could begin by trying to faq an "Acceptable Usage of the Internet" FAQ. I volunteer to try to keep the FAQ on track and make the latest draft available on our server. The $1,000,000 question is who is qualified and interested and bold enough to take a first cut at a draft. Second, where should the discussion take place? com-priv, nanog, another group, or a new group? There is a blank page called http://www.silkroad.com/aup/aup.html eagerly awaiting a bold first draft by an Internet Oracle. Internet Oracle, please put your draft forward :-) The alternative is to table the motion and forget about the issue. I believe that a non-binding AUP is a necessary 'first step' that is causal to all other events congruent to the 'spam and son-of-spam' issue. It has been demonstrated that enough people on nanog and com-priv are interested in trying to come to consensus on a draft AUP. What do you say? Shall we table the motion or move forward? Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include<campfire.h> | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+

5 5