At 15:58 2002-06-15 +0800, aj(_at_)ns2(_dot_)umcsd(_dot_)um(_dot_)edu(_dot_)my
did say:
As I want to set up user quota on each user, I found out it's easier to
move the incoming mails to /home directory for the quota control.
Okay, so is the PROCMAIL question, "how do I move the messages elsewhere",
or is it "how do I properly handle filesystem quotas" ?
If you enforced quota control on a filesystem mounted at /home/, you'd wrap
the user's mail and other file use into one quota -- which would have
administrative benefits - people publishing lots of web stuff would have
less space for mail (unless they received extra allocation in their quota),
whereas people not hitting you for webspace and just using email services
would have more space left for email. Everybody is equal - they can divvy
up their personal 10MB or whatever as they see fit.
As result, all the new incoming mails go to /home/user/maildir/new
Unless I missed something (and admittedly, I didn gloss over your code
changes, not wanting to refer to the source to verify what the settings
were BEFORE your changes), the following, placed in /etc/procmailrc should
have accomplished much the same thing without requiring any source code change:
DEFAULT=$HOME/maildir/new
This even could have been defined based on, say, the user belonging to the
"webmail" group:
# if user is a member of the webmail group, change their default delivery
# as appropriate to their webmail-ness. You could write a simple "checkgroup"
# utility to check to see if a given user is a member of a given group - the
# system calls are simple, and this would result in less overhead.
:0
* ? groups $LOGNAME | grep -q \\\<webmail\\\>
{
DEFAULT=$HOME/maildir/new
# and conceivably do other things as well.
}
How can I let my webmail knows where to look for the new directory?
Uhm, isn't this like a job for your webmail application, completely
independant of procmail? Ostensibly, somewhere in the webmail program it
must have been looking to /var/spool/mail originally -- so change the code
to look to the user dir which you've changed procmail to deposit the
messages in!
A bigger problem (and perhaps it relates to your POP3 access by the webmail
interface?) is users who use POP3 to retrieve email (if you permit it) --
your POP3 (and imap for that matter) daemon needs to be modified to look
elsewhere for the mailbox. Not surprisingly, this isn't something you are
going to achieve with procmail -- you'll need to hack the sources to those
programs, looking to their respective support channels for information on
how to do that. In the end, you might find that leaving the mail spool in
the standard location provides for considerably less grief on many fronts.
BTW - when enforcing mail quotas, watch out for tools which make a _copy_
of the mailbox file when it is open (being downloaded by the user or
whatever), as new mail arriving during that time can conceivably be bounced
even though the user is barely over half their quota. No, I don't have
specific daemons to cite here, but if you're going to enforce mailbox
quotas, you should consider whether this is a possibility in your case.
Ive tried to set up my /etc/profile as below too :
LOGNAME=$USER
MAIL="/HOME/$USER/.mail"
/etc/profile is used by certain shells. That is, when users log in
interactively via a shell. I rather doubt your webmail stuff it going to
make use of anything you put there. It is likely that your webmail is
running as the webuser (the user which the webserver is running as).
My main problem is : to set up mail quota for each user as I dont want
users to receive any mails once they have exceeded the mail quota set up
for them.
Keep in mind that you still get hit for the network reception of the full
message and THEN your MDA rejects it because of quota issues (in some
cases, sending the WHOLE MESSAGE BACK in the bounce to the sender,
thankyouverymuch). You might consider how much you really need to enforce
mail quotas (say, monitor how many users go over the proposed limit and how
often and then gauge the true need - or perhaps you've done this already),
or consider billing based on use (average daily mbox size or something like
that - if the users receive lots of email (perhaps having a 10MB mailbox
for 30 minutes - but promptly pull it down off the server rather than
letting it accumulate, they're not being a big problem - no more so than
the users who check mail every five minutes and have a constant stream of
email coming in).
System administrators often use the default /var/spool/mail for mail
because it's the standard location for mail. Because it's one dir (instead
of dirs underneath the individual user dirs), you can also make it a mount
point for a different filesystem (with it's own mail-specific standard
filesystem quotas). Alternatley, you could make another filesystem and
link each /home/user/maildir/ directory to it (a benefit to this is that
root and other select users need not have their email stored on the same
filesystem as the users who may collectively overflow their filesystem if
the system administrator isn't paying attention to disk use, regardless of
whether root and the other special users may not have defined quotas - but
that's a lot of links you really shouldn't need).
Using procmail as the LDA should automatically result in quota handling on
accounts where there is user quota enabled on the filesystem where the
message is being delivered. Have you simply tried setting a filesystem
quota for a test user and throwing messages at them?
I do hope you can advise me on my problem. I've explored on the internet
about this problem and most of it points to procmail. I just dont know how
to integrate the procmail with the webmail.
How is it that you're trying to integrate it? Procmail could place
messages into different mailboxes and be done. The webmail webmail
software should be able to retrieve the messages from where you're placing
them (and one would assume you're choosing where to place them based on
your desire to have the webmail access them at that location, or is there
something I'm missing?). Procmail could insert extra headers to identify
destination mailboxes and still drop the message into the mail spool:
(presuming that DEFAULT is set to the users' system mailbox)
:0:
* some condition
| formail -A"X-Webmail-MB: SOMEMAILBOX" >> $DEFAULT
If you're asking how to allow for web users to create procmail rules via a
web interface, well, this was brought up again in just the past couple of
days, so a review of the list archives might be order, and you could
participate in that separate discussion. Procmail itself doesn't include
any web interface components, but other people have had the desire to make
canned recipes and allow users to configure them via the web.
If procmail can successfully deposit messages where you want it to, it
would seem that your webmail application is what needs to be changed to
look in the right place. Thus, the change needs to occur in your webmail
app (and as nifty as PHP may be for web scripting, it isn't what this list
here is about).
BTW - if the webmail is homegrown, you might implement a "X messages
totalling Y kbytes of mail have been bounced since you last checked email
because your mailbox was full" indicator so that repeat offenders KNOW that
they should be checking email more often -- many users with mailbox full
problems are oblivious to the fact that they're not recieving all of their
email, or why -- after all, it isn't them receiving the bounces. It'd be
nice if AOL and Hotmail did this for their users -- who are by far the most
prolific "mailbox full" users on mailing lists which I manage.
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail