Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uakari.primate.wisc.edu!sdd.hp.com!ucsd!ucbvax!TRANSARC.COM!Craig_Everhart From: Craig_Everhart@TRANSARC.COM Newsgroups: comp.soft-sys.andrew Subject: Re: Forwarded:AMS & sendmail Message-ID: <0acodiD0BwwOM3P4p1@transarc.com> Date: 17 Jul 90 17:27:10 GMT References: Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 48 AMDS is a local delivery agent: it essentially replaces /bin/mail for purposes of putting a piece of mail into a local recipient's in-box. When coupled with AFS, it does have one property of a long-haul mail system: it can deliver mail to users at a remote AFS site if that remote AFS site has indicated its willingness to cooperate with such attempts (by indicating that it also runs AMDS). You don't need AMDS to send and receive multi-media mail. The multi-media nature of AMS/ATK mail is represented just fine within the confines of RFC822 (of which BSD Sendmail is (part of) one implementation). This message is going out in multi-media form to several recipients of the info-andrew list, most of whom are not receiving it via AMDS. You can later switch to using AMDS, but you don't have to, and there's not much rationale in doing this unless AMDS is helping you deal with a distributed file system of some sort. AMDS and sendmail generally don't coexist on the same machine, though AMDS uses some external mechanism (sendmail, by default) for its long-haul transport/SMTP needs that it can't itself meet. The /bin/mail and /usr/lib/sendmail replacements are essentially to be installed only when you have AMDS running on your site, you don't run sendmail or /bin/mail on most machines, and you want to trap all the old uses of these programs that are buried in lots of applications that think they know how to create and send mail. AMS user agents handle both ordinary and multi-media mail just fine. Multi-media mail is tagged as such via the Content-type: header (RFC 1049). In non-AMDS mode, AMS will send such messages via a configurable path name to an executable (default ``/usr/lib/sendmail'') and will retrieve messages from a file with another configurable name (default ``/usr/spool/mail'' or ``/usr/mail''). I don't think you'll have to worry a lot about choosing an installation name, though from your description you'd be happy with ``idt.unit.no'' (since you would expect any central service to handle mail to ``anyname@idt.unit.no''). You can set the ThisDomainSuffix variable in AndrewSetup to something like ``idt.unit.no'' if you want From: lines to look like foo@bar.idt.unit.no (user foo on local machine bar). I think most of your questions have the same answer: you don't really want to be running AMDS in your environment. Craig