On Thu, 18 Nov 1999, Len Smith wrote:
> 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.
we have implemented this via an authenticating procmail. I will have
to check with my management as to whether I can share this code, but it
is mostly pretty simple; procmail has an "authenticate" function, and
an authenticate.c stub that you can populate with whatever you like.
We had to remove some userid/name checks from procmail (see below),
and i think there were some other issues (file locking, i suspect) that
came up requiring modifications to the code (someone else did the mods,
although I just re-added them to the most recent procmail distribution).
We create a pseudo-user for each user that receives mail into afs,
called "user.mail" (eg, danno.mail). These pseudo-users all have the
same password, which is stored in cleartext on the mail servers and read
by procmail to authenticate on each delivery.
We do not push this system very hard; we run a few hundred users' mail
through it, and use it to archive various mailing lists. Other than
issues with disksuite (see below) mail server and file server load
is negligible.
In general, it works well. We have run into some problems.
o disksuite vs afs. Our old standard server load uses sun disksuite for
mirroring. There are some serious performance problems with disksuite
on an AFS client; writing files into afs is very, very slow and
the CPU becomes very busy. I have not taken the time to figure out
what the real issue is (cache on a logging partition? cache on any
disksuite partition? afs client on any machine running disksuite?),
because our new standard server load uses hardware raid pretty much
everywhere, even on a dumb client like this, and i am in the midst
of switching the mail servers to the new load with a hardware raid.
o locking. occasionally, a user's mailbox file will stay locked, and
the volume will have to be flushed from the cache on server and on
the user's client before things are happy. We have not kept good
track of this, and cannot identify trends (eg, with various afs
client versions).
o locking (2). AFS will return success on lockf calls, but won't actually
do anything except log a message to console saying "make sure you are
the exclusive user of this file". Some mail clients use lockf calls.
This is a problem. We qualified a few clients to confirm that they
don't do lockf, and those are the supported clients. We attempt user
education to prevent them from using other clients.
o locking (3). Some programs lock the mailbox and keep it locked, eg
xmultibiff and pine 4.x. Prevents new mail from coming in. I have not
really troubleshot this other htan to tell users not to use these
clients. pine 3.x works fine.
Another issue that I imagine you will run into that hasn't been a big
problem for us is quota maintenance.
I think we will probably keep this stuff for the mail list archiving
functionality, but I expect we will eventually move to a POP/IMAP solution
for user mail, since we do not use AFS on windows and my group does not
support the windows infrastructure, and doesn't want to.
dan pritts
server operations - ann arbor, mi
uunet technologies
734-214-7409
