At 13:37 2003-09-17 -0700, Enzo wrote:
# Test if the email's sender is in user defined whitelist, if so deliver it.
:0
* ? formail -x"From" -x"From:" -x"Sender:" -x"Reply-To:" -x"Return-Path:"
-x"To:" | fgrep -is -f /usr/local/apache/htdocs/secure/usermaint/
nobounce/${USER}
What is $USER set to? $LOGNAME?
Take a large amount of mail from your own mailbox and run it trough these
recipes in a sandbox, within a "time" invocation, so you can see how long
it's taking to run the whole procmail process. Then, disable some checks,
such as the above.
If you really want scaleability, you might need to look at running a daemon
that takes parameters passed to it by a small stub process which you call
from procmail. Then, the grep operation is simplified. You'd also
nominally speed things up if you extracted the various fields to their
component parts rather than the entire content of the individual headers
(the From_ date info for instance). But hey, if your users expect to block
based on a person's given name in the From: field instead of their address,
that wouldn't be appropriate to trim out.
| /usr/sbin/sendmail -t
You know, as long as processes which procmail calls haven't yet returned,
PROCMAIL won't itself finish. Have you considered the possibilty that the
procmail processes you're seeing in your process table are associated with
the rejection messages you mail?
see 'man sendmail', then search for "DeliveryMode". You want b, q, or d,
but *NOT* i. q or d are generally best for this sort of message.
use "-odq" on the SENDMAIL line set queue for instance.
---
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