rayan@ai.toronto.edu (Rayan Zachariassen) (02/04/88)
This is to solicit Alpha (and Beta) test sites/people for a new mailer, tentatively dubbed 'ZMailer'. If you think evolution shouldn't stop at Sendmail or MMDF (and if you know what these are), read on. The following is the "Design Summary" section from the Introduction of the documentation (ZMailer Operations Guide): 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, sn 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. This package has been running locally on a few machines for some time now, most recently installed on my "home" machine where it is processing 100-200 messages a day. The design of the user agent interface lends itself very well to a distributed filesystem environment, where for example a file/mail server can run this mailer and its clients need not run any mail-related daemons. The software compiles and runs under SunOS 3.4 and 4.3BSD (PC/RT). It compiles but is untested under 4.2BSD and SystemVr2v4. The Alpha test stage is intended (apart from finding and fixing bugs) to polish the features of ZMailer, as guided by feedback from the Alpha testers. If you have had run-ins with another mailer, if you are "battle-scarred", and if you looked at previous mailer designs and dreamt up a better way, participating in the Alpha test is the way to be heard before the ZMailer design is frozen. The Beta test will not be interesting, since everything will be in final form at that point (modulo bugs). This stage will hopefully be a huge porting exercise to variants of Unix, and other OS's if I can find people willing to do that (especially CMS and VMS are of interest). If you want to try ports during the Alpha test, you are of course welcome to do so. I plan no public distribution before the end of Beta test. This does not mean you should ask to become a tester just so you can get ahold of some nifty software. That is not good enough motivation for me to spend time on you. Alpha testers are expected to run ZMailer on one or more of the machines they "live" on, track down, report (and preferably fix :-) bugs, and participate in discussions about ZMailer features, bugs, design, interface, etc. The "debugging" aspect of the work is hopefully minimal. To get added to the list of Alpha testers, convince me you are serious, and briefly describe your mail and computing environment. If you require more information before committing, I am willing to send out the Operations Guide on request. In return I ask that you annotate it with your comments on the design and on the presentation, and return your annotated version to me. The document is approximately 70 pages. rayan 870128 rayan@ai.toronto.edu