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