If you're going to consider doing mail deliveries into AFS, I recommend you
consider using qmail w/ maildir instead of standard mbox style mailboxes. It
eliminates the problems with locking and simultaneous delivery across
multiple hosts.
That, combined with multiple equal priority MX hosts, and you should be able
to load distribute quite nicely.
-- Nathan
------------------------------------------------------------
Nathan Neulinger EMail: [EMAIL PROTECTED]
University of Missouri - Rolla Phone: (573) 341-4841
Computing Services Fax: (573) 341-4216
> -----Original Message-----
> From: Paul Blackburn [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, November 27, 1999 7:25 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: Delivering Email into AFS space
>
>
> >To all,
> >
> > I know that various places deliver incoming email into AFS
> >volumes. I am interested in hearing how various sites have
> implemented
> >this and if they have any docs/white-papers about it. We are
> looking into
> >doing this and need to make it scales, etc and have an idea
> of potential
> >problems we will encounter.
> >
> > thanx,
> > Len Smith
> > University of Michigan
> > College of LSA
>
> Hello Len,
>
> I have built a mail service at two sites where "auth-sendmail" [1]
> is used to deliver into $HOME/.mail for users with AFS homes.
>
> Basically, a re-authenticating daemon shares a PAG with the
> sendmail daemon on a (admin access only) mailserver. The sendmail
> daemon has AFS-id "sendmail" and the relevant ACLs are modified
> to allow writes to the user's mailbox via symbolic links:
>
> mpb@tricorder $ ls -ld .mail
> lrwxr-xr-x 1 mpb system 13 15 Jan 1999 .mail
> -> afsmail/.mail
>
> mpb@tricorder $ fs la afsmail
> Access list for afsmail is
> Normal rights:
> system:administrators rlidwka
> mpb rlidwka
> sendmail rliwk
>
> mpb@tricorder $ fs la .
> Access list for . is
> Normal rights:
> system:administrators rlidwka
> system:anyuser rl
> mpb rlidwka
> sendmail rl
>
> We have been restrictive about handling .forward files
> because we do not process .forward files on the AFS mailserver.
> The reason for this is because I have seen situations where
> users have (either accidentally or deliberately) set up
> mail loops via .forward. This has a bad effect on mailservers.
> In any case, the equivalent of .forward can be achieved
> via /etc/aliases in an approved way by the postmaster.
>
> The key advantages of delivering mail into /afs are:
>
> 1) Users may check their mailbox from any AFS client in the cell.
>
> 2) Since this is a regular mailbox, users have freedom of choice
> about which mail user agent (elm mush pine mh Netscape etc).
>
> 3) The processing load on accessing mailboxes is now distributed
> as opposed to being centralised on (say) a popserver.
>
> 4) Since mail is delivered into user's AFS space, they are
> responsible for managing their own quota. IMHO, this
> is better than attempting to provide a central mail spool
> because it is impossible to manage a central spool fairly.
> Some users inevitably hog more of a shared spool than others.
>
> 5) Now it is in /afs, it is backed up via normal AFS backup system.
> This is very nice for on-line recovery of mail deleted too
> hastily via the users' OldFiles Backup volume mountpoint.
>
> 6) It is quite simple to now have multiple AFS mailservers
> to scale up for a large site. This can be done by
> using /etc/aliases to deliver to different AFS mailservers
> in the cell.
>
> Disadvantages:
>
> 1) It seems to be difficult to enable procmail processing
> because this relies on .forward.
>
> 2) User can always mess up their ACLs and break their own
> mail delivery. But then again, they also have the "rm" command! ;-)
>
> I hope this helps!
> --
> cheers
> paul http://acm.org/~mpb
>
> "There can be no rainbow without a cloud and a storm."
> --John H. Vincent (1832-1920)
>
>
> References:
>
> [1] "auth-sendmail"
> http://www.angelfire.com/hi/plutonic/images/authsendmail.tar.Z
>
