Path: utzoo!attcan!uunet!decwrl!ucbvax!TRANSARC.COM!Craig_Everhart From: Craig_Everhart@TRANSARC.COM Newsgroups: comp.soft-sys.andrew Subject: Re: Interfacing WP, AMDS with other mailers Message-ID: Date: 3 Aug 90 14:34:53 GMT References: <14778@csli.Stanford.EDU> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 45 I'm sorry for the misunderstanding about what news services you wanted. Indeed, AMS doesn't come with an NNTP server; sorry. Or, it doesn't yet come with one; it's a small matter of programming, and maybe one will be written. Two of the problems that AMDS solves in the big-distributed-filesystem environment (read AFS with 10^4 users) are: - not relying on the centrality of /usr/spool/mail/, but instead delivering mail to a place relative to a user's home dir; and - not relying on distributed file systems to rewrite a potentially long file at every delivery time, but instead keeping every message separate (and relying on the DFS to maintain the directory of such messages). All I'm saying here is that the architecture for delivery (separate files under ~/Mailbox directory) was deliberate. I suppose that all you're asking for is a program to take all the files out of ~/Mailbox and append them in some quasi-safe fashion to /usr/spool/mail/, regardless of what /usr/spool/mail/... is on that system. Presumably you'd then use your mail system of choice to absorb all the messages out of /usr/spool/mail/. But now you have at least a small problem: if your favorite mail system doesn't empty out /usr/spool/mail/, then you still have mail sitting there. If that machine is a workstation, and /usr/spool/mail/ is just a local file on that workstation, what happens when the user walks to a different workstation to read mail next time? I guess this is no different than the problems that you're already living with. Whatever interfaces you're using are probably not prepared to handle transient failures, though, so you can't necessarily move them to run with all their files on AFS, without their users managing what happens when a file server becomes unavailable. Hey, here's another solution. Run AMDS, but initially provide everybody with a mail forwarding address that delivers mail to their favorite, current home. That is, when you add an account on your system (on which you run AMDS), also add a forwarding address (to the file wp-build-directory/hist/passwd.chg, or use the ``forward'' or ``wpi'' programs to add it). People read their mail exactly as before, delivered to their timesharing machine or workstation. When somebody wants to read mail with an AMS interface instead, they can stop their own mail forwarding; mail will be delivered to their own AFS home directory, and they can run Messages or the like to read it. How does this fit with your projected environment? Craig