🚀 go-pugleaf

Excerpts from internet.other.info-andrew: 11-Jan-93 New to Andrew Igal
Iancu@ucbvax.Berkel (966)

> We are a site with roughly 600 workstations (AIX 3.2, i486 SVR4 on NCR and
> a bunch of Sparc and sun386i).  We have AFS installed for the AIX machines
> and the rest use NFS. In addition, we have ~200 PCs using PC-NFS and Novell.

> Mail is heavily based on an Ultrix server which speaks smtp (sendmail) and
> DECnet.  It houses also a central /usr/spool/mail which is mounted by
> all clients using NFS.   

> I am looking for a system which will not have a single point of failure,
> and maybe supplies some other goodies.

This seems like the obvious time to mention AMDS (Andrew Message
Delivery System), which is part of the Andrew distribution.  AMDS itself
is a local mail system for AFS clients.  It can be configured without a
single point-of-failure for the system as a whole.  It was originally
developed jointly with AFS and the rest of Andrew, including AMS
message-handling clients that know how to exploit features of AMDS.

AMDS accepts mail for local users of the AFS cell and delivers each
message into a separate file in a subdirectory of the user's AFS home
directory (~userid/Mailbox by default, but configurable).  Outgoing mail
is sent through a variety of queues (in AFS).  AMDS expects that some
other system will be responsible for off-site mail delivery.  As
delivered, it expects to use sendmail in this role, but most any system
would be OK.  The usual configuration has sendmail running only on a
subset of the AFS cell's machines, called ``post office machines'' (PO
machines).  (These machines are generally listed as the MX recipients of
mail going to the domain with the name of the AFS cell.)  Mail for the
AFS cell's domain arrives from outside via SMTP at one of these PO
machines and is injected into the AMDS queues.  AMDS daemons running on
the PO machines deliver mail from these queues to its recipients,
whether local or remote.  Remote delivery is accomplished by invoking
the long-haul mailer of choice, configured as sendmail as AMDS comes out
of the box.

So why AMDS?
    - it deals with AFS transient failures
    - it is relatively well-featured, including a decent distribution
    list mechanism and fancy name pattern-matching
    - it is well-integrated with the rest of Andrew
    - it can be made independent of a single-point-of-failure, with
    replicated AFS volumes and multiple PO machines

Why not AMDS?
    - mail arrives in ~userid/Mailbox/*, not exactly the same as
    /usr/spool/mail/userid
    - it's something novel to administer

AMDS uses a ``white pages'' database of AFS accounts, ultimately listing
mail destinations or addresses for all accounts in the cell.  Users who
want their mail in places other than the AFS cell can easily forward
AMDS mail to that other address.

Carnegie-Mellon, by all measures a large installation, runs several
server machines running Unix (AFS clients) where people using PCs and
Macs can connect up their client programs to special AMS services.  The
software that they use for this, on both the PC and Mac end as well as
on the Unix end, isn't on the Andrew distribution, but the last I heard
there was no problem anticipated with releasing this software on roughly
the same terms as the existing Andrew distribution.

To be reasonably complete, the folks at Carnegie-Mellon are looking for
a successor to AMS (including AMDS).  My reading of that, which they're
clearly able to challenge, is that AMS (the mail user agent end)
provides a bboard system that's pretty expensive to implement as mere
AFS files and directories, but most AMDS features are still useful in
their environment.

Hope this helps.

		Craig