At 14:55 2002-07-10 -0800, Matthew Schumacher did say:
Is there any work around to this? Perhaps call procmail with -m and pass
the user then instruct it to deliver to a user inside of the RC?
Rather than asking "how can I do this little part of what I'm trying to
accomplish", you should instead give a go at explaining what you're trying
to accomplish overall. You manage to do this later in your message, and
THAT clarifies some stuff.
An evil kludge would be to simply compile a separate version of procmail
which uses a different file for /etc/procmailrc, and use that as your
alternate LDA. However, the /etc/procmailrc should be able to deal with
what you want done easily enough.
Yes, I want to make two mailers so that one will deliver normally and the
other will do some spam filtering. The determining factor to which user
gets which mailer is actually stored in the users LDAP record as the
aptMailSpam attribute. I have the LDAP database setup in sendmail so
writing a rule to pick a mailer based on the attribute is easy.
Presumably all users should still get their own .procmailrc handled if they
have one, right? And /etc/procmailrc ?
Have you considered simply performing the LDAP lookup from within
/etc/procmailrc?
[/etc/procmailrc]
:0
* ? /path/ladplookuphelper $LOGNAME
{
# do stuff for certain users
}
:0E
{
# do stuff for other users (or, eliminate this stuff from the outer
# brace and flags, and it'll happen for ALL LDAs, AFTER the above is
# performed.
}
Yes I know I can do this, but I feel that I am calling procmail twice when
I should only need to do it once.
See above - procmail gets called once, runs some prog to tell us whether
the USER should be filtered differently and takes action.
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.
If you get your alternate delivery hack working, you might want to document
Where do I post my comments? This list?
As they apply to utilizing procmail in this fashion, yes. Or, document the
stuff (and any ongoing changes) on a page on your own site, and post a link
and brief commentary here.
---
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