>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
