Postfix/dovecot: Configuring mail routing on a per mailbox bassis

Red Squirrel

[H]F Junkie
Joined
Nov 29, 2009
Messages
9,211
I guess this technically would go in Linux forum but I figure people here may know how to do this and this section gets more traffic.

I'm rebuilding my home email server so I can retire the old physical box that is currently responsible for it as well as update the software. It's currently running on FC9 which is super old. Current setup is as follows:

- Postfix / Dovecot using Linux accounts, so one account per mailbox, I just name them email_[something] to distinguish them from other users.
- Fetch mail gets mail from online servers and then delivers them to the respective local mailboxes.
- Each home directory has a procmailrc file which has rules for each mailbox. I have various requirements for each mailbox, such as some don't get spam filtering, some do, some have email that actually activate an external app etc...
- To access mail I just use imap and Thunderbird
- Current mailbox system is mbox format.

For the new setup, it is using virtual users and Maildir format. I have that working.

However, I'm not sure how I go about setting up per mailbox rules. I don't think procmail supports this, I read that it can but it sounded like quite the hack, such as having a master recipe file that just has conditions for each mailbox. That seems too ugly.

I tried experimenting with the virtual_alias_maps file and tried the following as an entry:

[email protected] procmail /localdata/mail/conf/procmailrules/test3_test.loc

But not sure if that is the right syntax, or if arguments are even supported. Basically this file would have an entry for each mailbox and it's respective procmail file. At least in theory, I'm not sure if there is a way to do this.

So TLDR: I want to be able to control on a per virtual mailbox basis what happens to emails, such as sending them through SA, then acting upon the result, such as putting it in another folder. Or perhaps sending the entire email through a 3rd party app. I want to be able to do this for each individual mailbox.

I'm also willing to write a program to do this, if there is nothing available. In fact that may be my fail safe, I'll just use procmail and pipe the mail through this custom program and then have it handle the rest. Though if there is actually something already available to do this that is not too complicated to setup then I rather do this.
 
Yeah found that through googling, but it does not seem to go through great detail on mailbox based rules, only user based, ex: it refers to putting a file in the home directory. But I'll try to search further and see if I can find a how-to that has more details. I guess the setup I want is probably not typical, as usually you want to setup spamassassin, maybe clamav or other such rules, and just do it globally.
 
What sort of virtual users are you using? MySQL?

The sieve files can go in the same directory as you are storing the maildirs, I have this setup and working without issue. Multiply/users/domains it works perfectly, unless you are doing something weird/hackish/plain wrong.

Although i'm not clear where you are meaning by mailbox based rules? Each mailbox is a virtual user is it not.
 
Just using file based and the Maildir format is /domain/user. So if I put the files in the user folder it will work? I'll have to experiment with that. When it talks about home directory I figured it was talking about a /home/user directory like for an actual unix account. By mailbox based rule I mean I want to be able to configure a separate set of rules for each email address. So [email protected] might run through spam assassin, and then have a rule to put it in that user's spam folder, but for [email protected] I may want to skip the SA, but perhaps filter emails based on subject and sort them, or other such rules. Basically want granular control. For the most part I just want to go through SA then have spam go in the spam folder, but there's a couple special email addresses that have different requirements.
 
Just using file based and the Maildir format is /domain/user. So if I put the files in the user folder it will work? I'll have to experiment with that. When it talks about home directory I figured it was talking about a /home/user directory like for an actual unix account. By mailbox based rule I mean I want to be able to configure a separate set of rules for each email address. So [email protected] might run through spam assassin, and then have a rule to put it in that user's spam folder, but for [email protected] I may want to skip the SA, but perhaps filter emails based on subject and sort them, or other such rules. Basically want granular control. For the most part I just want to go through SA then have spam go in the spam folder, but there's a couple special email addresses that have different requirements.
Yes that will work fine with dovecot/sieve/mda. Each mailbox is still a seperate use and referred to as such, doesn't matter that they're virtual users without differing UID/GIDs.
 
I'm working on trying to get this to work but I have two issues. First one is I'm getting errors like this when I send mail:

Code:
Oct 31 16:33:04 rohan dovecot: lda: Fatal: Internal error occurred. Refer to server log for more information.
Oct 31 16:33:04 rohan postfix/pipe[27319]: 274B7640E9E: to=<[email protected]>, relay=dovecot, delay=40563, delays=40563/0.01/0/0.43, dsn=4.3.0, status=deferred (temporary failure)
Oct 31 16:42:44 rohan dovecot: imap-login: Login: user=<[email protected]>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=27349, secured
Oct 31 16:42:44 rohan dovecot: imap([email protected]): Disconnected: Logged out bytes=79/681
Oct 31 16:52:46 rohan dovecot: imap-login: Login: user=<[email protected]>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=27379, secured
Oct 31 16:52:46 rohan dovecot: imap([email protected]): Disconnected: Logged out bytes=79/681
Oct 31 16:53:04 rohan postfix/qmgr[24846]: 658E7640E9D: from=<[email protected]>, size=517, nrcpt=1 (queue active)
Oct 31 16:53:04 rohan dovecot: lda: Error: userdb lookup: connect(/var/run/dovecot/auth-userdb) failed: Permission denied (euid=1999(vmail) egid=1999(vmail) missing +w perm: /var/run/dovecot/auth-userdb, euid is not dir owner)

Every time I try to change the permissions it just changes back on it's own and goes back to being owned as root. I'm guessing it has to be owned as vmail, but I also tried making it owned by postfix and dovecot with same result. If I chmod it 777 it works, but that's obviously a bad idea, I just did it to test.

But before I play any further with this file... what is it exactly? I already have the /etc/dovecot/passwd file that has the user accounts, so what is this auth-userdb file for? When I create a new account do I need to do anything to this file too? I'm only aware of having to edit the /etc/postfix/vmailbox and other virtual related files in there, and then the dovecot passwd for imap login.

Also in the dovecot config I never noticed till now there is also this:

Code:
userdb {
    driver = static
    args = uid=1999 gid=1999 home=/var/vmail/%d/%n allow_all_users=yes
}

What is THAT user db file for? The docs don't seem to explain what these are for other than stating that it's a userdb... I know that, but how does it differ from the passdb, which also has users?

The second issue I'm having is when I use a web client to send mail, nothing happens. No log entry, no nothing. The web client has no error either. Before I changed the the virtual_transport from virtual to dovecot, it worked fine. Is there a way to still use sieve without having to use dovecot-lda? I have not even gotten to playing with rules yet I just want to make sure I have a basic working setup first. I had it working in basic mode before I changed that setting.

Though while googling, I also discovered the mailbox_command_maps parameter. did not find much on it, but if it does what I think it does, would this allow me to have a file with a list of each account and post in a procmail command that calls a specific procmailrc file for user mailbox? Perhaps that is a simpler option if it works the way I think it would.
 
Back
Top