🚀 go-pugleaf

Auf FTP.Informatik.TU-Muenchen.DE[131.159.0.110] ist neu:

 zmailer-2.1.tar.Z  - Package description:
 
 ZMailer Overview
 - What is this?
 This is a package that implements an internet message transfer agent called
 ZMailer. It is intended for gateways or mail servers or other large site
 environments that have extreme demands on the abilities of the mailer. It
 was motivated by the problems of the Sendmail design in such situations.
 ZMailer is intended and designed as a multi-protocol mailer. The only
 protocol supported in this distribution is RFC822 (and variations).
 - What good will it do me?
 Different people and sites differ in priorities. Keep that in mind
 when reading this ``features'' list:
 Code and Design features:
 + Strong limits on host impact.
 + Secure design (and hopefully implementation).
 + Natural fit for client/server environments.
 + Extremely customizable configuration mechanism.
 + Flexible database interface with support for: sorted files, unsorted
 files, dbm, ndbm, gdbm, nis (yellow pages), dns (BIND resolver),
 /etc/hosts file, and in-core data.
 + Efficient message queue management.
 + Fast binary-transparent SMTP server and client.
 + Low-technology implementation.
 Default configuration file features:
 + Default configuration will work for most sites.
 + Network protocol support for: smtp, uucp, bitnet, mail to news.
 + An easy way of overriding any external routing information.
 + Automatic handling of mailing lists.
 - How does it work?
 ZMailer is a multi-process mailer, using two daemon processes to manipulate
 messages. One of these processes is a router, and makes all decisions about
 what should happen to a message. The other daemon is a message queue manager,
 used to schedule delivery of messages. The Router uses a configuration file
 that closely follows Bourne shell script syntax and semantics with minimal
 magic. Message files are moved around in a series of directories, and the
 Scheduler and its Transport Agents run off of control files created by the
 Router.
 The Router will process messages one at a time, as it finds them in a
 directory where User Agents submit their outgoing messages. Envelope
 and Message Header information is all kept in the same message file along
 with the message body, and this file is never modified by any ZMailer
 program. After parsing the envelope and RFC822 header information, the
 Router validates the information extracted, and calls functions defined in
 the configuration file to decide exactly how to deliver the message and how
 to transform the embedded addresses. The algorithms that do this are easily
 reconfigurable, since the control flow and address manipulation is specified
 by familiar shell script statements. When the Router is finished, it will
 produce a message control file for use by the delivery processing stage of
 ZMailer, and move the original message file to another location.
 Once the Router has decided what to do with each of the addresses in a
 message, the Scheduler builds a summary of this information by reading the
 control file created by the Router. This knowledge is merged with a data
 structure it maintains that stores which messages are supposed to be sent
 where, and how. According to a pre-arranged agenda, the Scheduler will
 execute delivery programs to properly move the message envelope, header, and
 body, to the immediate destination. These delivery programs are called
 Transport Agents, and communicate with the Scheduler using a simple protocol
 that tells them which messages to process and returns status reports to the
 Scheduler. The Scheduler also manages status reports, taking appropriate
 action on delivery errors and when all delivery instructions for a message
 have been processed.
 There are several standard Transport Agents included with the ZMailer
 distribution. The collection currently includes a local delivery program,
 an SMTP client implementation, and a Transport Agent that can run
 Sendmail-compatible delivery programs.
 A separate utility allows querying the Scheduler for the state of its mail
 queues. For existing Sendmail installations, a Sendmail replacement program
 is included that simulates most of the Sendmail functionality in the ZMailer
 environment. This allows ZMailer to replace a working Sendmail installation
 without requiring changes in standard User Agents.
 If you have a client/server host environment, mail clients need not run
 any daemons. They only need two programs (the Sendmail replacement, and
 a mail queue querying program) and a view of the mail server's spool area.
 - How will it affect my current system?
 Two programs will be replaced: /usr/lib/sendmail (with a functionality
 emulator), and /bin/rmail (for completeness). Nothing else will be
 changed, so it is very easy to back out if you want to.
 - What problems can I expect?
 This software is in use on several major mail gateways. The development
 machine is a departmental system that processes 2000 messages a day. This
 mailer has been running on it in some form for 3 years. This means
 that you are unlikely to see crippling problems in the software.
 You may well encounter problems due to your local Operating System,
 libraries, compiler (this software makes a good compiler test suite),
 or other things about your environment that I have not considered.
 The ZMailer Router RFC822 implementation is rather picky about adherence
 to the protocol standards. You may run into cases where an error that
 has been ignorable or unknown so far, will generate automatic complaints
 from the mailer to users, and from users to you. Much of this pickyness is
 required. Some is not, and is deselectable.
 Due to the security mechanism, in particular the propagation and use of
 privilege levels associated with addresses, the default setup requires that
 the .forward and mailing list files be publically readable. Otherwise,
 unprivileged addresses (e.g., those specified from outside the host), will
 not be able to use the contents of such files. Similarly, if the source
 of an address is not ``secure'', the address will have no privileges.
 In particular, for an address to take on the privileges of whomever
 specified it (as in a .forward file), its source file must be owner-only
 writable, and in a directory which has the same ownership or is owned by
 root and is also owner-only writable. These checks may be disabled.
 
1164721 bytes is the size of this package; possible locations are:
 
 ftp.cs.toronto.edu - /pub/zmailer.tar.Z
 ftp.informatik.tu-muenchen.de - /pub/communication/zmailer/zmailer-2.1.tar.Z
End of entry.
 xnetdb-2.02.tar.Z  - Package description:
 
 This is to announce the availability of xnetdb version 2.02 (the current 
 version being 2.01).  Major improvements/additions from v2.01 -> v2.02 
 include:
 *  assorted bugs fixed
 *  support for hosts has been added
 *  a graphical traceroute function has been added
 DESCRIPTION
      Xnetdb is a network monitoring tool based on X  Windows  and
      SNMP  which also has integrated database and statistic view-
      ing capabilities.  Xnetdb will  determine  and  display  the
      status  of  routers and circuits it has been told to monitor
      by querying the designated sites and displaying the  result.
      Additionally,  it also has integrated database functionality
      in that it can display additional information about  a  site
      or  circuit  such  as the equipment at the site, the contact
      person(s)  for  the  site,  and  other  useful  information.
      Finally  it  can  gather  designated statistical information
      about a circuit or router and display it on demand.
 OPTIONS
      -v        This enables the verbose mode of xnetdb.  This  is
                useful only when used with the -monitor option.
      -monitor  This enables the monitor mode of xnetdb  in  which
                it  will actively query routers to determine their
                status and update the map to reflect that  status.
                The  default  is not to monitor so that unecessary
                SNMP traffic is avoided.
      -display host
                This will display  the  xnetdb  map  on  the  host
                specified.
      -cpath path
                This gives the path in which it will find  all  of
                the  xnetdb  configuration  files.  Note that this
                defaults to the setting in the xnetdb.h  file  set
                at compilation.
 USING XNETDB
      Invoking any of the  database  or  statistics  functions  is
      merely  a  function of pressing the left mouse button on the
      proper item and selecting the choice of  interest  from  the
      menu.   For  example,  to  invoke  the router menu, move the
      pointer on top of the router  you  desire  more  information
      about  and  the  press  the left mouse button, to invoke the
      circuit menu press the left mouse button on top  of  a  cir-
      cuit, and to invoke the summary/stats menu to press the left
      mouse button anywhere  else.   To  quit  xnetdb,  press  "q"
      within the xnetdb window.
 CONFIGURATION FILE
      The configuration file xnetdb.cf specifies all of the things
      that  you  want  xnetdb  to  monitor and/or keep information
      about.  There are three types of things which can be 
      configured into the file - routers, hosts, and variables.
      ROUTER <path> <routername> <mapname> <ipaddress> <community>
         The <path> entry specifies the  path  into  the  database
         where  xnetdb can find information about the router.  The
         <routername> entry specifies the name of  the  router  in
         the  database.   The  <mapname>  entry specifies the name
         which will be displayed on the xnetdb  map.   The  <ipad-
         dress>  entry  specifies  the  ip  address of the router.
         Finally, the <community> entry specifies the SNMP commun-
         ity name to use when querying the router.
      HOST <path> <hostname> <mapname> <ipaddress> <community>
         The <path> entry specifies the  path  into  the  database
         where  xnetdb  can  find information about the host.  The
         <hostname> entry specifies the name of the  host  in  the
         database.   The  <mapname> entry specifies the name which
         will be displayed on the  xnetdb  map.   The  <ipaddress>
         entry specifies the ip address of the host.  Finally, the
         <community> entry specifies the SNMP  community  name  to
         use when querying the host.
      VARIABLE <rtraddr> <variable> <variabletype> <community>
         The <rtraddr> entry is the ip address of the router.  The
         <variable>  entry  is  the  name of the snmp variable you
         wish to monitor.  The <variabletype> entry is the type of
         the variable that the agent will return (such as Integer,
         IPAddr, etc.).  Finally, the <community> entry  specifies
         the SNMP community name to use when querying the entity.
 
145884 bytes is the size of this package; possible locations are:
 
 ftp.informatik.tu-muenchen.de - /pub/X.V11R4/net/clients/xnetdb-2.02.tar.Z
 thor.oar.net[131.187.1.135] - /pub/xnetdb-v2.02.tar.Z
End of entry.

Gruss,
    Armin.

ps. Unser FTP-Archiv ist auch per E-Mail abrufbar, naeheres durch E-Mail
mit Mail-Body "help" an ftp-mailer@ftp.informatik.tu-muenchen.de.

--
                                                                     ____
                    Armin Gruner, Technische Universitaet, Muenchen  \  /
             Nur wer sich aendert, bleibt sich treu - Wolf Biermann   \/