procmail
[Top] [All Lists]

Re: sendmail/procmail virtusertable/aliases problem

2002-12-18 19:45:29
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