Ok, I continued playing around with procmail for about 2 hrs now...
I added the following line to /etc/aliases:
foo.bar.com: "|procmail -m /etc/procmailrc foo.bar.com"
and the /etc/procmailrc contains things like this:
<--snip-->
BASEDIR=/mail
LOGFILE=${BASEDIR}/logfile
VERBOSE=on
LOGABSTRACT=all
USER=$1
DEFAULT=${BASEDIR}/users/$1
BLACKSND=${BASEDIR}/blacklists/sender
BLACKSUB=${BASEDIR}/blacklists/subject
# The subject is only extracted once to avoid a notification overload
SUBJECT=`formail -x"Subject:" | expand | sed -e 's/^[ ]*//g' -e 's/[ ]*$//g
`
# [...some code left out here...]
# Searching for typical spam subjects
:0
* ? formail -x"Subject:" | egrep -is -f ${BLACKSUB}
{
:0 fw
| formail -I"Subject: [SPAM SUBJECT] ${SUBJECT}"
:0:
${DEFAULT}
}
# Delivering all other mail
:0:
${DEFAULT}
<--snap-->
The mail gets delivered fine into the mailbox. But matching eg. senders
doesn't
work. I also copied (with -p) formail and egrep to /etc/smrsh (procmail
needs to be
there too). The proclog contains that:
<--snip-->
procmail: Assigning "LOGABSTRACT=all"
procmail: Assigning "USER=foo.bar.com"
procmail: Assigning "DEFAULT=/mail/users/foo.bar.com"
procmail: Assigning "BLACKSND=/mail/blacklists/sender"
procmail: Assigning "BLACKSUB=/mail/blacklists/subject"
procmail: Assigning "BLACKBDY=/mail/blacklists/body"
procmail: Executing "formail -x"Subject:" | expand | sed -e 's/^[ ]*//g' -e
s/[ ]*$//g'"
procmail: Assigning "SUBJECT=This account is currently not available."
# [... left out entries for other matches ...]
procmail: Executing " formail -x"Subject:" | egrep -is -f ${BLACKSUB}"
procmail: Non-zero exitcode (1) from " formail -x"Subject:" | egrep -is -f
${BLACKSUB}"
procmail: No match on " formail -x"Subject:" | egrep -is -f ${BLACKSUB}"
procmail: Locking "/mail/users/foo.bar.com.lock"
procmail: Assigning "LASTFOLDER=/mail/users/foo.bar.com"
procmail: Opening "/mail/users/foo.bar.com"
procmail: Acquiring kernel-lock
procmail: Unlocking "/mail/users/foo.bar.com.lock"
procmail: Notified comsat: "mail(_at_)379:/mail/users/foo.bar.com"
From spam(_at_)spam(_dot_)com Thu Dec 19 11:18:17 2002
Subject: bla
Folder: /mail/users/foo.bar.com
<--snap-->
However, if I add a recipie like
:0:
* test
${DEFAULT}.bla
then the mail is delivered to /mail/users/foo.bar.com.bla. So it does match
test" in the mail.
I 'm also wondering why I get "This account is currently not available" if I
extract the Subject
instead of the subject "bla".
Sorry for keeping you busy, but I think I'm about to reach my limits in my
procmail knowledge :-)
Greetz
Sven
-------Original-Nachricht-------
Von: procmail(_at_)Lists(_dot_)RWTH-Aachen(_dot_)DE
Datum: Donnerstag, 19. Dezember 2002 03:36:16
An: procmail(_at_)Lists(_dot_)RWTH-Aachen(_dot_)DE
Betreff: Re: sendmail/procmail virtusertable/aliases problem
At 01:15 2002-12-19 +0100, Sven Schmitt wrote:
The regular (passwd) accounts are still located in /var/spool/mail/.
Okay, then regular procmail use doesn't require any changes. If you were
to attempt to get it to deliver to the phantom accounts as if it were an
LDA, you'd need changes, but it is clear that you don't need to do that.
I only moved the user accounts out of there. All the mailboxes belong to
mail:mail. Teapop handles them fine and sendmail also has no probs.
Well, you're simply delivering into files - sendmail isn't doing any user
lookup. No surprise there.
If I can get sendmail to pass the email to procmail, I could extract the
To: field to specify the mailbox or something like that...
That won't really work for messages which are Bcc'd or have multiple
recipients (esp. within the locally hosted domains). Just include it as an
argument on the alias line (at that point, it's a given what account the
message is being delivered to - but the MTA is using the _ENVELOPE_
information to make that determination).
My procmailrc also uses INCLUDERC to add kill-lists which can be later
edited by the each user (via webinterface).
As long as this is written with a consideration that the procmail invoked
isn't running as an LDA ($LOGNAME and $HOME for instance won't be of much
use to you), everything should be fine.
The idea of using a pipe in the aliases file sounds quite interesting. I
have to take a look at that later at work. I think this could solve the
problem.
As indicated, this method of invocation isn't unusual - perhaps not common
for people who typically deliver to a regular mailbox, but for mailing
lists, it's common fare.
The main reason why I don't create useraccounts for every mailuser is
simply that I want to avoid filling up my /etc/passwd with lots of users.
Most of the mailservers I've tested have probs handling virtual users. But
to keep things simple and easier to maintain,
Uhm, manually editing virtuserable, aliases, AND an SQL database for each
user is "keeping things simple?" What you have is three separate things
which need to be kept in sync for mail to work (and that's aside from the
domains file)
FWIW, once you figure out the specific syntax of your aliases to invoke
procmail as you need, it would be a good idea to create (or modify an
existing) makefile for sendmail which rebuilds the sendmail
hashes/databases when the support files are changed. You could whip up a
small Perl or C++ program to query your SQL database to emit representative
chunks of alias and virtusertable entries, which you could diff against the
previous version of, and if changed, append to the "base" copy, and rebuild
the hashes. Whatever 'adduser' functionality you use for your SQL users
could enter the SQL data and then trigger the make.
alias.base (base manually edited alias file, without SQL users)
alias.sql (previous constructed)
alias.new (current constructed version)
alias.txt (alias.sql concatenated to alias.base)
An examole of the makefile code for alias.txt (you'd have something
virtually identical for the virtusertable):
aliases.sql:
@some_command_to_generate_file_from_sql > aliases.new
@if \
diff -q aliases.new aliases.sql > /dev/null
then \
rm aliases.new ; \
echo "No change in SQL aliases" ; \
else \
mv aliases.new aliases.sql ; \
echo "SQL aliases changed" ; \
fi
# construct the httpd.conf file from the component parts
aliases: aliases.base \
aliases.sql
@cp aliases.base $@
@cat aliases.sql >> $@
Arguably, your SQL query program could take the alias.new file as an
argument, and use the file timestamp of it and compare that against the
timestamp of the newest of the SQL entries -- but then you'd also need to
contend with _deletions_.
Using something like the above would allow you to programmatically generate
the aliases and virtusertable sections, and retain all of the configuration
data within the SQL database, making the process much less error prone,
most certainly if you have many users. The domains file could be similarly
managed.
[kersnip]
---
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
.
