home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / mail / misc / 4481 < prev    next >
Encoding:
Internet Message Format  |  1993-01-24  |  19.3 KB

  1. Xref: sparky comp.mail.misc:4481 comp.sources.wanted:5792 news.answers:5413
  2. Path: sparky!uunet!gatech!enterpoop.mit.edu!bloom-beacon!senator-bedfellow.mit.edu!athena.mit.edu!jik
  3. From: jik@athena.mit.edu (Jonathan I. Kamens)
  4. Newsgroups: comp.mail.misc,comp.sources.wanted,news.answers
  5. Subject: Mail Archive Server (MAS) software list
  6. Supersedes: <archive_servers_725263271@athena.mit.edu>
  7. Followup-To: comp.mail.misc
  8. Date: 24 Jan 1993 06:01:17 GMT
  9. Organization: Massachusetts Institute of Technology
  10. Lines: 486
  11. Approved: news-answers-request@MIT.Edu
  12. Distribution: world
  13. Expires: 9 Mar 1993 06:01:13 GMT
  14. Message-ID: <archive_servers_727855273@athena.mit.edu>
  15. NNTP-Posting-Host: pit-manager.mit.edu
  16.  
  17. Archive-name: mas-software
  18. Version: $Id: archive_servers,v 1.38 1993/01/07 18:02:27 jik Exp $
  19.  
  20.      A Summary of Available Mail Archive Server Software
  21.      ---------------------------------------------------
  22.  
  23.   For each server listed below, I provide the following information,
  24. if known:
  25.  
  26.     Name
  27.     Author
  28.     Maintainer
  29.     Latest known version
  30.     How to get it
  31.     Implementation language
  32.     Supported platforms
  33.     Comments
  34.  
  35.   If you can fill any of the blanks or have comments about anything
  36. written below, or if you have new servers to add to the list, please
  37. let me know.  If you would like to ask me to change this posting in
  38. some way, the method I appreciate most is for you to actually make the
  39. desired modifications to a copy of the posting, and then to send me
  40. the modified posting, or a context diff between my posted version and
  41. your modified version (if you do the latter, make sure to include in
  42. your mail the "Version:" line from my posted version).  Submitting
  43. changes in this way makes dealing with them easier for me and helps to
  44. avoid misunderstandings about what you are suggesting.
  45.  
  46.  
  47.   There are two sections below.  The first describes the various
  48. archive servers, and the second lists known sites from which the
  49. archive servers can be obtained, and how to access them.  The "How to
  50. get it" fields of the archive server descriptions refer to the site
  51. listings.
  52.  
  53.   John Bazik <jsb@cs.brown.edu>, Stephen R. van den Berg
  54. <gerg@physik.tu-muenchen.de>, Warren Burstein <warren@itex.jct.ac.il>,
  55. Nigel Metheringham <nigelm@ohm.york.ac.uk>, Mike Northam
  56. <mbn@fpssun.fps.com>, Chip Salzenberg <chip@tct.com>, and Serge
  57. Vakulenko <vak@kiae.su> provided comments about and corrections to
  58. this posting.
  59.  
  60. ------------------------------------------------------------------
  61.  
  62.  
  63.             Archive Server Summary
  64.             ----------------------
  65.  
  66.  
  67. Name: Almanac
  68. Authors: Erik Bennett and Chris Hansen
  69. Maintainer: almanac-admin@oes.orst.edu
  70. Implementation language: C (configured with Bourne shell)
  71. How to get it: ftp from /pub/almanac-x.x.tar.Z at oes.orst.edu
  72.                (where x.x is the current version)
  73. Latest know version: 1.4
  74. Supported platforms: SunOS, HP/UX, UTek, AIX (RS 6000), most BSD 4.3
  75. Comments: (Chris Hansen <hansenc@oes.orst.edu>)
  76.     Requires sendmail and gdbm
  77.     Can split files on user-defined size limit
  78.     Good user & admin documentation
  79.     Has blacklist
  80.     Logging (through syslog) and usage utilities
  81.     Comes with supplement for automatic mailing list management
  82.     Load checking or queuing left to sendmail
  83.     Main advantage is configuration table:
  84.        Maps user commands to shell commands
  85.        Can have any number of user commands
  86.        Encoding, Filtering, Compression all configurable
  87.        Most other things configurable
  88.        (Possible disadvantages:
  89.         Table can get complicated.
  90.         Good knowledge of shell advised).
  91.  
  92.  
  93. Name: B-Server
  94. Author: Budi Rahardjo <rahardj@ccu.umanitoba.ca>
  95. Implementation language: bourne shell
  96. How to get it: Get "b-server.shar" from pit-manager.
  97. Comments: (Dave Shaver <shaver@convex.com>)
  98.     - Don't need to create system-wide alias (uses sendmail
  99.         .forward file)
  100.     - One shell script
  101.     - Can refuse to provide service to certain people
  102.     - Has file and request limits
  103.     - 4 user commands: help, index, send, get
  104. Comments: (john.Latala@Waterloo.NCR.COM)
  105.     - Only does text files
  106.  
  107.  
  108. Name: Bart (Brode's Archive Retrieval Thang)
  109. Author: Jon Brode <brode@icpsr.umich.edu>
  110. Latest known version: beta release
  111. How to get it: Send E-mail to <brode@icpsr.umich.edu> and ask for it.
  112. Implementation Language: C
  113. Support platforms: Expects BSD, sendmail and ndbm, but might work with
  114.                     some tweaking in other environments.
  115. Comments: (from author)
  116.         Beta release can be obtained from the author but should not be
  117.             redistributed; the final release will have more lenient
  118.             distribution conditions.
  119.         Runs from alias or .forward file
  120.         Very careful about not overloading server. (does load checking on BSD
  121.             machines, in addition to the other things)
  122.         5 commands: help, index, path, send, sendb ("sendb" automatically
  123.             encodes the file, "send" determines whether the file needs to
  124.             be encoded first)
  125.         Can request files by parts. Useful for requesting files larger
  126.             than quota and retrieving pieces that get lost in the mail
  127.         Can do per-user quota checking.
  128.         It has a man page!
  129.         Has uuencode encoding built into C code, does not support other
  130.             encoding types yet.
  131.         No user error notification on bad requests.
  132.  
  133.     
  134. Name: Clarkson
  135. Author: Michael DeCorte
  136. How to get it: Get "archive-server" from CLARKSON.
  137. Implementation language: bourne shell, awk
  138. Comments: (Tom Fitzgerald <fitz@wang.com>)
  139.    Advantages:
  140.     Most flexible options for archiving, compressing, encoding and
  141.       slicing result.
  142.     Very nice load-limiting.
  143.    Disadvantages:
  144.     Many BSDism's (I tried porting it to SysV without much luck).
  145.     Can't return several requested items, one item per mail message.
  146.       It insists on packaging up all requests into a single archive,
  147.       splitting the archive at random points and mailing the result.
  148.     Can't store items compressed and have them mailed back to the
  149.       requestor decompressed.
  150.  
  151.  
  152. Name: DECWRL
  153. Author: Brian Reid.
  154. Implementation language: bourne shell, awk, a little bit of C
  155. How to get it: (1) Get "decwrl.shar" from pit-manager.  (2) Get
  156.     "/pub/unix/archive.tar.Z" via anonymous ftp from
  157.     ftp.cs.widener.edu (slightly modified).
  158. Comments: (Dave Shaver <shaver@convex.com>)
  159.     - Written with many shell scripts and a few AWK scripts
  160.     - Very careful about not overloading server machine
  161.         (Remember, this used to run on an over-worked VAX.)
  162.     - Very easy to install; best of the group?
  163.     - Code is all quite generic
  164.     - Good at letting person making request know what happened
  165.         (No black holes for mail.)
  166.     - Good user-level docs (especially the "help" file)
  167.     - Very fair queuing system; people can't make "pigs" of
  168.         themselves
  169.     - 4 user commands: help, index, send, path
  170. Comments: (Tom Fitzgerald <fitz@wang.com>)
  171.    Advantages:
  172.     Simplest.
  173.     Very nice load-limiting, can be set up to run only at night.
  174.     Easily configurable, and portable to Sys V with a little work.
  175.    Disadvantages:
  176.     All items in archive must be text, and are sent out as-is.  No
  177.       packaging options at all.
  178.     Written in sh, may be a heavy system load (when running).
  179. Comments: (Chris Siebenmann <cks@hawkwind.utcs.toronto.edu>)
  180.      We use the DECWRL server for the CA*NET info server; I picked
  181.     it over the other ones (primarily the Clarkson one) because it
  182.     was sufficiently small and clear that I could read all the
  183.     shell scripts and be pretty confidant that it had no surprises
  184.     and I understood what was going on. One could probably run it
  185.     out of a .forward file with some work writing at-based
  186.     frontends, but it prefers to be installed and run with cron
  187.     and an alias.
  188.  
  189.  
  190. Name: deliver
  191. Author: Chip Salzenberg <chip@tct.com>
  192. Latest known version: 2.1, patchlevel 10
  193. How to get it: From the comp.sources.reviewed archives.
  194. Implementation language: C
  195. Comments: This isn't a full-fledged archive server, it's just a
  196.     program to reroute incoming mail.  Which isn't to say that it
  197.     can't be used to write an archive server....
  198. Comments: (Brian.Onn@Canada.Sun.COM)
  199.     I've written our mail based archive server entirely in Deliver
  200.     shell scripts.  It's not as full featured as the other ones,
  201.     but it can easily be expanded to become that.  The beauty of
  202.     deliver is that it is entirely shell script based.
  203.  
  204.  
  205. Name: KISS
  206. Author: T. William Wells <bill@twwells.com>
  207. Latest known version: 1.0
  208. How to get it: (1) Get "kiss.shar" from pit-manager.  (2) Get
  209.     "misc/kiss.shar" from JASON-ARCHIVE (slightly modified).  (3)
  210.     Get "/pub/archives/alt.sources/kiss-server_bill" via anonymous
  211.     ftp from hydra.helsinki.fi.
  212. Implementation language: bourne shell
  213. Comments: (Dave Shaver <shaver@convex.com>)
  214.     - Simple.  8-)
  215.     - One shell script, plus a user-supplied program
  216.     - No batching, quotas, or scheduling.
  217.     - 5 user commands: help, index, send, path, quit
  218.     - Good install docs
  219.  
  220.  
  221. Name: listserv
  222. Author: Anastasios C. Kotsikonas (tasos@cs.bu.edu)
  223. Latest known version: 5.41
  224. How to get it: From /pub/listserv on cs.bu.edu via anonymous ftp.
  225.     Also in alt.sources archives with subject "unix-listserv" in
  226.     three parts.
  227. Implementation language: C, plus some UNIX-style shell scripts.
  228. Supported platforms: UNIX, presumably.
  229. Comments: This is a mailing list server rather than a mail archive
  230.     server.  It is meant to automatically run mailing lists,
  231.     dealing with subscriptions, unsubscriptions, message
  232.     distribution, etc.  Like the BITNET listserv system, but for
  233.     UNIX.  The newest version does appear to have some support for
  234.     archives as well.
  235.  
  236.  
  237. Name: Logix
  238. Author: Jan-Piet Mens
  239. Latest known version: 1.01
  240. How to get it: Get the posting entitled "Mail-Server Part 01/01" from
  241.     the alt.sources archives.  An improved version (Bill Silvert's
  242.     -- see his comments below) is available via anonymous ftp from
  243.     /pub/unix/mail-server.tar.Z on biome.bio.ns.ca.
  244. Implementation language: C
  245. Comments: (Bill Silvert <silvert@biome.bio.ns.ca>)
  246.     Changes I have made include support for optional (as opposed
  247.     to compulsary) uuencoding using the Dumas uuencode, which
  248.     makes it possible to run uudecode (the Dumas version) on a
  249.     complete multi-part mail file without editing it first, and
  250.     improved messages.
  251.  
  252.  
  253. Name: NETLIB
  254. Author: Jack J. Dongarra, Eric Grosse
  255. How to get it: Get "netlib from misc" from NETLIB.
  256. Implementation language: C
  257. Comments: (Dave Shaver <shaver@convex.com>)
  258.     - User-level docs a bit rough.    Assumes user is quite mail savvy.
  259.         (Not a fair assumption in my case.)
  260.     - Catches "pigs" effectively, but no queuing system for requests.
  261.     - Notices attempted security violations using magic shell characters
  262.     - Install docs adequate, but not outstanding
  263.     - Hard to install since site-specific stuff not centralized
  264.         in a config file.
  265.     - Has almost no interal documentation (i.e. comments)
  266.     - Eclectic mix of shell scripts and C programs
  267.     - Some sections of code very specific to serving libs.    Does
  268.         not generalize well to ASCII files.
  269. Comments: Tom Fitzgerald <fitz@wang.com>
  270.    Advantages:
  271.     Arbitrary directories can be made part of archives, archives don't
  272.       have to all be under a single directory tree.
  273.     Written in C, probably imposes the least system load.
  274.     Reasonably portable and configurable.
  275.    Disadvantages
  276.     Really complicated, with inadequate documentation
  277.     No queuing or load-balancing.  All requested items are sent out
  278.       immediately regardless of system load.
  279.     Poorest at figuring out return addresses.
  280.     All items in archive are sent out as-is.  No packaging options.
  281.       (They can be binary, they will be sent out uuencoded).
  282.  
  283.  
  284. Name: procmail
  285. Author: Stephen R. van den Berg <berg@pool.informatik.rwth-aachen.de>
  286. Latest known version: 2.71
  287. How to get it: (1) Get "procmail" from volume 31 of comp.sources.misc
  288.     archives.  (2) "/pub/unix/procmail.tar.Z" via anonymous ftp from
  289.     ftp.informatik.rwth-aachen.de (possibly more up-to-date).
  290. Implementation language: C
  291. Supported platforms: generic UNIX (or any posix compliant OS)
  292. Comments: This isn't a full-fledged archive server, it's a program to
  293.     parse incoming mail and sort/invoke other programs based on the
  294.     results, but it can be used as a very reliable front end to some
  295.     of the archive servers mentioned here.
  296.     - It includes a utility program called formail, which is
  297.       particularly intelligent in figuring out return addresses and
  298.       generating auto-reply headers.
  299.  
  300.  
  301. Name: qdms
  302. Author: Lars Magnusson <lmn@z.amu.se>
  303. Latest known version: 1.0
  304. How to get it: (1) Get "qdms - a simple mailserver for cramped disks."
  305.     from the alt.sources archives.  (2) Get a (possibly more
  306.     up-to-date) version from mailserver@z.amu.se.
  307. Implementation language: Bourne shell, requires shell functions
  308. Comments: Looks like it has some sort of access control and
  309.     blacklisting.  Don't know what else.
  310.  
  311.  
  312. Name: Relcom
  313. Author: vak@kiae.su (Serge Vakulenko)
  314. Maintainer: vak@kiae.su (Serge Vakulenko)
  315. Latest known version: 1.0
  316. How to get it: Send a message to mailserv@kiae.su with "get
  317.     mailserv.tar.Z" in the body.
  318. Implementation language: C
  319.  
  320.  
  321. Name: RNALIB
  322. Author: Paulo Ventafridda <venta@otello.sublink.org>, Marco Lorenzini
  323.     <marlor@gear.sublink.org>
  324. Latest known version: 2.2 beta-3
  325. Implementation language: bourne shell
  326. How to get it: (1) Get "rnalib2" from volume 15 of comp.sources.misc
  327.     archives.  (2) Get "RNALIB 2.2 beta" and "upgrade to beta-3"
  328.     from alt.sources archive on valhalla.ee.rochester.edu.
  329. Comments:
  330.     - Completely implemented in one bourne shell script plus
  331.       several data files.
  332.     - Allows libraries to be all over the filesystem hiearchy
  333.       (i.e. not in fixed data directory).
  334.     - Understands a variety of packing formats, and detects binary
  335.       file automatically (and uuencodes them).
  336.     - Requires bourne shell with support for functions.
  337.     - Very poor address parsing.
  338.     - No queueing.
  339.     - Has "blacklists" to prevent people from transferring and
  340.       "whitelists" to allow specific people to tell the server to
  341.       deliver to third parties.
  342.     - Detects "hogs" and imposes maximum credit limits.
  343.  
  344.  
  345. Name: Squirrel Mail Server
  346. Version: 3.1
  347. Author: Johan Vromans <jv@mh.nl>
  348. How to get it: (1) Send a mail message to <mail-server@nluug.nl> with 
  349.     contents
  350.  
  351.         begin
  352.         send mail-server
  353.         end
  354.  
  355.     (2) Get "mserv" from volume 34 of the comp.sources.misc
  356.     archives.
  357. Implementation language: perl
  358. Description (from the author):
  359.  
  360.     The Squirrel Mail Server is a mail response program. You can
  361.     send email to it, and it will try to react sensible to your
  362.     message. 
  363.  
  364.     Main purpose of the mail server is to obtain files from a
  365.     local archive or FTP server, but other functions can be added
  366.     easily.
  367.  
  368.     The Squirrel Mail Server Software is distributed under the
  369.     terms of the GNU Public Licence.
  370.  
  371.     New and improved features in version 3.1:
  372.  
  373.       - Transparent (anonymous) FTP interface. You can fetch files
  374.         from remote FTP servers. Files retrieved are cached
  375.         locally, so subsequent requests can be honoured from the
  376.         cache.
  377.  
  378.       - Delivery can take place via email or uucp or both.
  379.         Delivery via UUCP can be made preferred.
  380.  
  381.       - FTP requests can be restricted to UUCP delivery.
  382.  
  383.       - Multiple servers can be installed using the same software.
  384.  
  385.     A brief survey of old and new features:
  386.  
  387.       - All written in perl, hence portable and easily
  388.         maintainable.  Code is readable; useful, plentiful
  389.         comments. Very extentable and easily modified.
  390.       - Easy to install.
  391.       - Good at letting person making request know what happened.
  392.         Good "help" reply.
  393.       - Archives can be split over a number of directories or file
  394.         systems.
  395.       - Requests are queued and processed by a separate daemon
  396.         process (e.g. from cron). This cuts down on the system
  397.         load. Moreover, you can control when the queue is being
  398.         run.
  399.       - Requests can be honoured `as is' (name the file and you'll
  400.         get it), but the server can also perform directory
  401.         searches and index file lookup.  You need GNU find and
  402.         locate for the index lookup feature.
  403.       - While looking for files, the server knows about commonly
  404.         handled filenames (e.g. ".tar.Z" in "foo.tar.Z") and
  405.         pseudo-standard version numbering (e.g. "gcc-2.1.tar.Z").
  406.         It is quite well possible that a simple request for
  407.         "emacs" will actually transmit the file
  408.         "gnu/emacs-18.58/dist/emacs-18.58.tar.Z".
  409.       - Requests can be encoded using a number of encoding
  410.         schemes, e.g.  uuencode, xxencode, Dumas' uue and btoa.
  411.       - Requests that are too large to send in one piece are
  412.         automatically split and transferred in parts. The server
  413.         provides a smart unpacking program on request,
  414.       - Parts of requests can be re-transmitted in case of
  415.         failure.
  416.       - Requests can designate a directory. In this case the whole
  417.         directory tree is packed using some popular packing
  418.         programs (compressed tar, zoo or zip).
  419.       - Requests can be sent by email, or via uucp.
  420.       - The server can be asked to return a list of archive
  421.         entries that match a given request, thus obsoleting the
  422.         need to transfer huge "ls-lR" type index files to find out
  423.         whatsitcalled.
  424.       - All transfers can be logged. Maintenance procedures
  425.         include a reporting tool.
  426.       - Transparent anonymous FTP interface.  Files retrieved via
  427.         FTP can be stored locally, so subsequent requests can be
  428.         granted without new transfers.
  429.  
  430.     Probable future directions:
  431.  
  432.       - Automatic (and transparent) downloading of unknown archive
  433.         entries from other archive servers.
  434.       - Archive lookup by keyword.
  435.       - Notifier services (you'll be notified if archive entries
  436.         are added).
  437.       - Remote maintenance of the archives.
  438.  
  439.     Requirements:
  440.  
  441.       - Perl 4.0 patchlevel 35 or later.
  442.         NOTE that perl 4.0 pl35 contains a bug that can be fixed
  443.         by a patch obtainable from the NLUUG mail server -- see
  444.         below.
  445.       - GNU find 3.5 or later (only if you want to exploit the
  446.         index features).
  447.       - A decent mail system that can deliver mail to a process
  448.         (sendmail, smail3, or smail2.5 w/ mods).
  449.  
  450.     ===================== 
  451.     Some unofficial Patches to perl 4.0 patchlevel 35 can be
  452.     obtained from the NLUUG mail server by sending a mail to
  453.     <mail-server@nluug.nl> with contents:
  454.         begin
  455.         send XPatch-4.035.tar.Z
  456.         end
  457.  
  458.  
  459. ------------------------------------------------------------------
  460.  
  461.  
  462.               Archive Site Instructions
  463.               -------------------------
  464.  
  465. CLARKSON: Send mail to "archive-server@sun.soe.clarkson.edu" with
  466.     "send <what you want>" as the text of the message, e.g. "send
  467.     archive-server".  If you want it to be archived as a shar
  468.     file, then add a line saying "archiver shar" before the "send"
  469.     line.  You can also use "archiver tar".  If you don't specify
  470.     an archiver, then the files in the request will be separated
  471.     by "--- cut here ---" lines and you'll have to extract them by
  472.     hand or write some sort of script to do it.
  473.  
  474. JASON-ARCHIVE: Send mail to "penneyj@slc.com" with a subject line
  475.     containing the string "jason-archive-request" and a body
  476.     containing "send <what you want>", e.g. "send misc/kiss.shar".
  477.     If you want multiple files, you can specify multiple requests
  478.     on separate lines of the file.
  479.  
  480. NETLIB: Send mail to "netlib@research.att.com" with "send
  481.     <what you want>", e.g. "send netlib from misc", as the text of
  482.     the message.
  483.  
  484. pit-manager: Ftp to pit-manager.mit.edu [18.172.1.27] and look in
  485.     /pub/mail-servers, or send mail to
  486.     "mail-server@pit-manager.mit.edu" with "send
  487.     mail-servers/file", e.g. "send mail-servers/b-server.shar", in
  488.     the subject or body of the message.
  489.  
  490. UTRECHT: Anonymous ftp to ftp.cs.ruu.nl and look in the directory
  491.     /pub, or send mail to "mail-server@cs.ruu.nl" with the lines:
  492.  
  493.     begin
  494.     send <filename>
  495.     end
  496.  
  497.     You replace "<filename>" with the file you want to retrieve,
  498.     e.g. "send UNIX/mailserver.tar.Z".
  499.  
  500. -- 
  501. Jonathan Kamens                                         jik@MIT.Edu
  502. Aktis, Inc.                                    Moderator, *.answers
  503.