Matthew Schumacher <matt(_dot_)s(_at_)aptalaska(_dot_)net> writes:
Professional Software Engineering wrote:
...
Presumably all users should still get their own .procmailrc handled if
they have one, right? And /etc/procmailrc ?
No, all of the users are in LDAP and none of them have a home dir.
If the recipient don't exist as real UNIX users (i.e., getpwnam(username)
fails) then "procmail -d username" will not work without modifying the
procmail source. So, do they exist as real UNIX users?
Have you considered simply performing the LDAP lookup from within
/etc/procmailrc?
Yes, but then I will be calling procmail twice and ldapsearch once.
Why would procmail be called twice? Wouldn't you just call ldapsearch
from the /etc/procmailrc and branch inside the rcfile based on the result?
That cause 2 binaries which depend on 9 libraries to start, plus the hit
to bring up and tear down an ldap session to the local ldap server which
is bound to a trusted interface on a TCP port and it also does away with
sendmail's ability to cache LDAP lookups and causes the system to
process mail the long hard way every time.
The process startup time is almost certainly ignorable. On the otherhand,
depending on how many message/sec you're looking at and whether you're
using TLS, the LDAP connection setup time may or may not be. Have you
actually tested to see how many invocations per second of ldapsearch your
machine can do? I'm just curious whether you're leery of this solution
because it really won't perform fast enough or because it's inelegant.
The drive for elegance is a Good Thing, as long as it doesn't become
the main goal.
I'm all for optimizations and the like, but frankly if calling procmail
twice in succession is going to cripple your mail server, you
desparately need to upgrade your mail server.
I don't think this will cripple the mail server, it's on decent hardware
but I would be adding signifigate work to the mail process.
Would it be "Good Enough"?
_Anyway_...
One possible solution that does the LDAP work in the sendmail.cf is to
have it put a 'prefix' on the +detail for the recipient based on whether
the user wanted spam filtering on not. This would have to be done in
ruleset 5, right before it reinvoked the local mailer for the last time.
The /etc/procmailrc file could then examine the $1 value and, based on
it, decide whether to INCLUDERC the spam filtering recipes. If you're
not using (and don't intend to ever use) +detail addresses, then it can
be done via a normal LOCAL_RULE_0 addition to your the sendmail.mc file.
The details of how to do that part of the job should of course be taken
to the comp.mail.sendmail newgroup, the only procmail bits would be
the stuff at the top of the /etc/procmailrc file, which would look
something like:
ARG = $1
:0
* ARG ?? ^^spamfilter
{
INCLUDERC = /path/to/spam/filtering/rcfile
}
Philip Guenther
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail