Hi Dharmendra,
Sorry I couldn't reply earlier - I was out of town the whole week. Anyway what I was
talking about wasn't actually a discussion I asked the question and got a lengthy
reply form one of the gurus in cyberspace :). So here you go.....
---------------------------
Item 292: Exotic sendmail configurations :)
Entered by Mithun Bhattacharya (mithun) on Wed, Sep 22, 1999 (03:42):
I was wondering whether anybody could think of a sane way to handle sendmail
once /var is full. By default it will dump everything into /var/spool/mail/
Maybe somebody could throw light on how to setup sendmail the way grex is
currently with all those subdirectories for each bunch of users.
2 responses total.
#1 of 2: by Marcus Watts (mdw) on Wed, Sep 22, 1999 (04:58):
Actually, sendmail doesn't know anything at all about /var/spool/mail .
To deliver mail on the local system, the only thing sendmail knows is
how to invoke the local mail delivery program, and even *that* is
specified in the configuration file. On grex, there is a line that
contains "Mlocal" that also defines the local mail delivery program to
be "/usr/lib/mail.local", and that's the program that actually does mail
delivery. Sendmail *does* use some disk space in /var --
/var/spool/mqueue (by convention, and again, it's specified in the
config file), which is used for mail that has not yet been delivered or
forwarded. If /var gets low on space, then sendmail will start bouncing
mail -- I think it does so with a temporary error code, but this can
cause load problems if the site is very busy, or if the remote mail
daemon is stupid and just tries again right away (yes, there *are* sites
that do this.)
A vanilla version of mail.local will put things into files immediately
under /var/spool/mail/ . This logic is compiled into the program logic.
Fortunately, mail.local is readily available as source, and the one
that's running on grex has been linked with a special custom library
routine, getmailfilename(3), which uses the file /etc/mailfmt to specify
where mail should live.
Besides the mail delivery program, there are many mail clients that also
know about where mail is delivered. Most of them already know to use
the "$MAIL" environment mailbox to locate incoming mail. So programs
like elm do not require changes. There are some minor gotchas. On
SunOS, /var/spool/mail comes with 2777 permissions, which allows anyone
to create or delete their own mailbox, but not to delete someone else's
mailbox. Unfortunately, it's also possible for vandals to create
someone else's mailbox, which is obviously a Bad thing. At the same
time we switched to a hierarchical directory scheme, we changed to mode
755 permissions. Users can still empty their own mailbox, but they
can't create or delete them (it's up to mail.local to create them, and
we only delete mailboxes when user accounts are reaped.) This also
means we can't use v7 locking -- that's ok, we were already using
flock(3) for locking. A few mail clients were a problem. /usr/ucb/mail
knows about $MAIL and uses flock, but for some reason, wants to be able
to delete the mailbox, which causes errors. We replaced /usr/ucb/mail
with mailx from bsd, with a few hacks to implement a few sunos features
that weren't in mailx but were being used on grex. Pine was the other
difficulty. Reading the source code for pine turned out to be an
exercise in futility. Pine supports a lot of different environments, so
it has a lot of similar looking code, and it turned out to be very hard
to figure out which one was actually being used on grex. In fact, it
turned out the mailbox name isn't defined in the source at all, but in a
system-wide configuration file. Once we had that figured out, teaching
it to use $MAIL was trivial. Pine had and still has one other annoying
feature -- if the user's mailbox doesn't yet exist, pine complains that
it can't create it. The source code fought us again, and successfully
defied our efforts to make the error disappear. We did manage to insert
an additional message to tell people to ignore the error, but people
still send us messages complaining about the "problem" (which of course
will disappear for good once we reply.)
There are a still a few programs that can't just use $MAIL, but actually
need to know how to map loginids to mailbox names, just like
/usr/lib/mail.local. The most obvious one is of course login -- the
program that creates this environment variable in the first place. We
already had a custom login program, so invoking getmailfilename(3) was
trivial. Another program is finger -- the grex version of finger
reports mail information. Since we had already customized finger,
teaching the custom code to use getmailfilename was again trivial. One
last program that *should* know about getmailfilename, but doesn't yet,
is sshd. It's on the list of bugs that should get fixed someday.
Of course, using hierarchical directories doesn't really do anything to
fix the "filesystem is full" problem. To do *that*, we had to implement
mailbox quotas. There are 4 programs on grex that know about mailbox
quotas. The first is /usr/lib/mail.local. Since it's the program
that's responsible for delivering mail and knows where mail lives, it
obviously has to enforce the quota. The second program is sendmail. We
didn't want to teach sendmail about where user mailboxes live, so
instead, we have mail.local add people's names to /var/adm/badmail, and
sendmail rejects mail to people whose name is listed in
/var/adm/badmail. The third program that has to know about the quota is
login. It doesn't actually *really* need to know about quotas, but we
wanted to tell people when they logged in if they were near or over
quota, and login is the obvious place to put the logic. The last
problem was once people were in the badmail file, how do they leave this
file? Obviously, we want this to happen if they empty their mailbox
file -- but we didn't want to teach the mail clients how to notice when
people had dropped below quota, nor did we want to give the mail client
programs permission to manipulate /var/adm/badmail directly, since they
don't run SUID. So, we have a 4th program, umailck, which is the only
program that would normally delete people from the /var/adm/badmail.
There are 3 ways umailck can be invoked:
(a) by login.
Login does 2 things. If the user is near or at quota,
login will say:
You are using %dK of your %dK mailbox quota (%.2f%%).
The other thing login does is, if the user is in /var/adm/badmail,
it runs umailck -l. Umailck will check to see if the user is
still over quota, and if so, will say:
Your mailbox is full. You must delete messages and rerun
umailck
before you will be able to receive more mail.
If the user had somehow dropped below quota but was
still in /var/adm/badmail, umailck will instead remove
the person from /var/adm/badmail.
(b) by the user. If the user has paid attention to what
umailck said, they'll get rid of some messages and run umailck.
Umailck will then do the same thing it did when the person logged in,
except it will be somewhat more verbose (without the -l switch).
(c) by cron. Once an hour, cron runs "umailck -a".
This checks everyone in /var/adm/badmail, and if anyone
has managed to free up enough space, but couldn't figure
out how to run umailck, the cron job will catch this
and remove them.
Pretty complicated, eh?
--------------------------
I will checkup on the pop3 deamon bit and get back to you later.
Regards
Mithun
---- Dharmendra Gurtata <[EMAIL PROTECTED]> wrote:
> Mithun,
>
> >A more permanent solution is something which cyberspace.org has done on their
> >system. They have adopted a heirarchical structure. All the users emails are b
> >unched into subdirectories depending on the first couple of characters of thei
> >r userid. This way if they run out of disc space they add a new drive and just
> > move off some of the directories to the new partition.
> >
> >As for the mails reaching their proper destination you have to write your own
> >program for that I guess. You might be able to hack up some kind of wrapper fo
> >r whatever is your local mailer......
> >
> >If anyone is interested I can post the whole discussion...
>
> I would be really interested in this stuff. Actually everybody would gain thru
> it. Also tell us how the pop3 client would look into that directory. writing
> a program for the mails reaching their proper destination can be done but how
> to pick mails from seperate-seperate directories.
>
> You can post the whole discussion or can mail me.
>
> TIA
>
> Dharmendra Gurtata.
>
___________________________________________________________________
To get your own FREE ZDNet onebox - FREE voicemail, email, and fax,
all in one place - sign up today at http://www.zdnetonebox.com
