Well you need to look at a number of things besides just the delivery agent
that may need to deal with AFS. There are two cells at the University of
Maryland that do this, though just a bit differrently.
First, one of the real nice things about doing this is on the mailserver
side. "Wherever you go, there you are!". We have two main mailservers for
the undergraduate population, and which ever machine gets the mail will
deliver it into the AFS spool. If it looks like there is more power needed
we can add another machine to the pool to help out. (It is wierd getting
zephygrams three mailservers....) This has really help sendmail load
balancing and gotten rid of a number of extra hops.
If you are going to deliver mail to AFS then you are looking at delivering
to seperate subdirectories for each user, because of the ACL's on directories
rule. If you also have users with NFS homes and or mail spool space you
need to decide if you will also change their layout for consistancy.
We elected to do it to both. With each user having their own spool directory
you can things with AFS acl's and NFS permissions that are useful.
With NFS /var/spool/mail is now mode 755 and is no longer the network tmp
space our students were so fond of. With AFS the spool directory we gave
system:postmaster all and the user read access.
Now you need to decide your policy on access to the users home directory.
We choose to keep them private by default, so we needed to decide how to
deal with programs that run as pipes through sendmail, like vacation,
slocal(mh), procmail and filter(elm). One of our other outstanding issues
were the loading problems with NFS mounting of home directories to read
.forward's and the .files associated with the above filters. Of course
the security of pipes in sendmail is an issue as well as what permissions
are needed to access these .files and such. Our decision was to move the
.forward into the mail spool and change the filters to work out of their
also. This helps to tighten up security on the home directory and eliminates
NFS mounting of home directories for mail delivery. For our site the NFS/UFS
spool space is /var/spool/mail/$user/. We have about 30 mailservers, but
alot more homespace servers, and minimizing the number of mailservers to
maintain is why homeserver != mailserver. Another choice is not to
support these filters.
We use the smrsh (sendmail restricted shell) that comes with the current
sendmail so only those binaries we choose will run. Not like theirs would
anyway with the changes we made, but it is a good security measure for
everyone who wants to know what is running on their mailservers. This is
especially true with binaries running with AFS tokens. This has historically
been a security issue on Unix in general so take heed.
Lets discuss how one locates the mail spool directories for a bit. There
are a number of choices. Historically, sendmail, popper, imapd and the
like look in /var/spool/mail/ (or similar) for mail. In the NFS world
these often get {auto}mounted elsewhere and the users MAIL variable gets
set to the new location, or some fashion of links are employed so the mail
looks like its where the original binaries want. Otherwise you have to
login to the mailserver to read mail or be forced with a pop or imap only
solution. So any how we have been running AMD (the automounter) for a real
long time and we maintain the maps with Hesiod in our nameserver for a
pretty scalable solution. We just automount everyones mail spool as
/mail/$USER/ so their MAIL variable get set to /mail/$USER/$USER. This is
where the delivery agent (mail.local), imapd, popper, and the like are
trained to look also. For an NFS mail spool it will be a link to
/var/spool/mail/$USER/, and for AFS, a link elsewhere, but it makes it
consistent and managable. Again there are a number of choices here, but
the filters, delivery agents, and such do not have the users environment
so $MAIL will not work and you will need to deal with this issue.
The mail readers, you can either retrain or let the MAIL variable set the
spool location for you. On some system "Mail" does not look at $MAIL. I
believe those systems that i have that use mailx are all ok, as well as
pine, emacs-vm, emacs-rmail, mh, xmh, elm, and xbiff.
As an aside, we have a few users that still love the old suntool mailtool.
This does not work correctly under AFS, as the locking is messed up.
It is the only one so far that I have noticed that fairs poorly.
Let me describe the layout of a users volume for the wam.umd.edu and
glue.umd.edu cells at Maryland. The volume mounted as $USER has acl
rights of;
system:authuser k
system:anyuser rl
An "ls" of the user's volume shows;
backup home mail pub
with the following acls;
backup is
Normal rights:
system:authuser k
system:anyuser rl
home is
Normal rights:
rsw rlidwka
mail is
Normal rights:
system:postmaster rlidwka
rsw rlidwk
pub is
Normal rights:
system:anyuser rl
rsw rlidwka
The users "home directory" is a sub directory of the users volume. This
helps to keep the user from shooting themselves in the foot by inadvertantly
changing the acl's as they would do before we moved to this scheme.
The "backup" dir is the obvious backup volume mount point. The pub directory
beside being a location for users to share things and still keep their
home directories private is also where the httpd server looks for its
"Welcome.html" files for the users home page. We have either an automount
point or a link to /users/$USER to the top of the users volume.
On the sendmail side, we did not need to change the sendmail binary any
but we did need to play with the sendmail.cf file and put a wrapper around
the sendmail startup procedure. I do not really care for the wrapper thing
too much but it is quick and dirty.
One or both of either sendmail or the mail delivery agent needs to run under
a PAG and a token. We choose to do this with the sendmail daemon since it
is long running, versis having to authenticate everytime you deliver a
piece of mail. To keep localy started sendmail processes, like those exec'd
from binaries like binmail and others, from having to be authenticated,
we changed the sendmail.cf to make the default delivery mode "queue" on
AFS delivering mailservers. The sendmail deamon gets started with the
flag to deliver in the background, overriding what is in the sendmail.cf
file. With the newer sendmail-8.7.* you can set the queue time to 5 minutes
with the MinQueueAge set to 30 minutes. This way mail sent locally from the
mailserver (not through the sendmail daemon) will get a delivery attempt
in 5 minutes or less. (This feature also really helps balancing the load
for queue runs. No more load through the roof ever half hour!)
So all we need to have run authenticated is the sendmail daemon, so here
are a couple ways to do it. The best know way is everyones favorite reauth
and pagsh script. You can also give "postmaster" a real long life and just
kill and restart it once a month sort of like;
exec pagsh -c "cat /path/to/keyfile | klog postmaster -pipe;\
exec /usr/lib/sendmail -bd -q5m -odb -d99.100"
You have to remember to start sendmail so it will not fork or you will
lose the PAG. For sendmail-8.7.3 I use;
/usr/lib/sendmail -bd -q5m -odb -d99.100
For sendmail 8.6.* something more like;
/usr/lib/sendmail -bd -q30m -d0"
will work. You might also want a wrapper to run the queue by hand with.
especially with older sendmails where you can not run the queue every few
minutes with the MinQueueAge flag.
Since I also have MIT Kerberos libraries, I made a little program called
ksrvtoken that gets a TGT like ksrvtgt but then goes and gets a token
and will reauthenticate every N seconds, like reauth. So I make a
principle.instance pair for every host like $host.postmaster and make it
a member of system:postmaster. This was just to keep clear text passwords
from laying around. Now you can also further break this down so only
engineering mailservers can deliver to engineering mailserver (except for
the central mailserver)
So you can have an MX preferenceing like this;
earthsun.umd.edu preference = 5, mail exchanger = GEOL.UMD.EDU
earthsun.umd.edu preference = 10, mail exchanger = GLUE.UMD.EDU
and "system:geol-postmaster" will contain as members;
geol.postmaster
system:glue-postmaster
where system:glue-postmasters are my main mailservers. This way under
most circumstances the departmental mailservers deliver their own mail
but the central ones can act as backup as needed. Again;
"Wherever you go, there you are".
Any how I use a script like this;
/usr/afsws/bin/pagsh << ==EOF==
/usr/local/athena/bin/ksrvtoken 86400 postmaster
/usr/lib/sendmail -bd -q5m -odb -d99.100
==EOF==
We used the mail.local that came with the sendmail distribution and changed
it to find the mail spool and to deal a little with AFS. It is like bin
mail with out the mail reading ability; just the delivery side.
So here are a few pointer to what we are doing for the glue.umd.edu cell;
It has been runing for about a semeseter now. Some cleanup is still needed
but it should give you something to think about and hopefully help. Look
for #ifdef GLUE or #ifdef AFS soft of things and see what files are in
the RCS directories.
If you want to support pop3 and/or kpop look at;
/afs/glue.umd.edu/glue/popper/qpopper/qpopper2.1.4-r2
If you want pine/IMAP3 look at;
/afs/glue.umd.edu/project/glue/pine/pine3.91
If you want a vacation program that can work out of an alternate directory;
/afs/glue.umd.edu/project/glue/vacation
It uses the Berkeley .db format which works across platforms;(hton-clean)
If you need slocal(MH) to read .maildelivery from an alternate directory;
/afs/glue.umd.edu/project/glue/mh/mh-6.8.3/uip/slocal.c
If you need procmail's .procmailrc elsewhere look at;
/afs/glue.umd.edu/project/glue/procmail/procmail-3.11pre3
If you need elm's .elm/filter-rules also moved, look at;
/afs/glue.umd.edu/project/glue/elm/elm-2.4pl24me7/filter
For a mail delivery agent that knows a bit about AFS and spooling to subdirs;
/afs/glue.umd.edu/project/glue/sendmail/sendmail-8.7.Beta.13/mail.local
A good version of sendmail is sendmail-8.7.3. Ftp it from berkeley...or;
/afs/glue.umd.edu/project/glue/sendmail/sendmail-8.7.3/
Again hope I have help,
Randall
On Tue, 12 Dec 1995, Norman Hill wrote:
> We are planning on delivering mail into users' AFS volumes via some
> authenticated local mail delivery agent. I need to do this fairly soon
> and was wondering if anyone had such a mailer already available. If
> not, I will probably write such a beast over Christmas.
>
> Also, I'd be interested in how other cells with large user bases are
> dealing with mail delivery. One obvious answer which I do not find
> appealing is to have a very large mail spool and quota it or perhaps
> several quotaed spools.
>
> --
> Norman Hill, Systems Programmer Internet: [EMAIL PROTECTED]
> UNCG, Greensboro, North Carolina Voice: (910) 334-5977
>
