SpamAssasin issue with LDAP and system users


I have been having fun with ldap ( following the virtualmin ldap tutorial ). I must say, it is a great tutorial and it works pretty well.

However, I want use ldap in a slightly different way.

*** BACKGROUND / Description ***

I have 2 servers:

1) A big server (Server A) to store: normal domains + replicated domains

2) A Small Server (Server B) to store: only replicated domains.

Both servers have ldap replication currently working and tested. I mean, if I create a domain in server B (ldap master/provider) it get automatically replicated to server A. I know that is a fact because I use a ldap browser to see this in action.

Server B is configured to STORE users in LDAP with this procedure:

> Virtualmin > System Settings > Server settings > Store users and groupsĀ  = In LDAP database

So, in at the end, Server B save Users, Groups, Postfix aliases and Postfix virtual domains in LDAP as it is supposed to do.

Now, Server A is configured to STORE users in Unix files with this procedure:

> Virtualmin > System Settings > Server settings > Store users and groupsĀ  = In local files

And it does that (I see them in Users and Groups's Module and NOT in LDAP Users and Groups).

*** So, What is my problem then? ***

The issue is that for Server A, SpamAssassin is not working properly for replicated users. Let's say user: "USER1" was created in server B (as replicated user) and then his folder (something like: /home/rep/USER1) has been copied to server A along with this user details (LDAP database).

USER1 can send and receive emails from SERVER A or B with roundcube or outlook. MX is configured like:

  • USER1domain MX 5 SERVER-B
  • USER1domain MX 10 SERVER-A

If USER1 receive email on SERVER-B it pass through SpamAssassin. But if email arrives first to SERVER-A SpamAssassin rules are completely ignored. Of course, in both cases, email is then automatically copied to the other server.

I would like to make it possible to apply SpamAssassin rules to USER1 incomming emails when they first come to SERVER-A. If you note MX DNS register you will notice that USER1 emails will first try to arrive to SERVER-B (where SpamAssasin works!), so the probability that those emails arrive to SERVER-A is reduced in this way. However, I still would like to improve spam filtering by using it on SERVER-A and not only on SERVER-B.

I have searched into postfix file to see how SpamAssasin is executed and I found that postfix in fact calls a program called "procmail-wrapper" like this:

mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME

I guess "procmail-wrapper" is responsible for calling "Procmail" who then calls SpamAssasin. I am really not using Virus Filtering to keep load low, so "procmail-wrapper" and "Procmail" are only useful for SpamAssasin not Amavis. Im not expert with procmail related stuff either.

I found out there are some folders with files from SERVER-B that are missing in SERVER-A for SpamAssasin to work. These are:

  1. /etc/webmin/virtual-server/procmail
  2. /etc/webmin/virtual-server/spam

Folder #1 contains a list of files with names like "137528329632729" and the number of those files is the same as virtual servers I have in Virtualmin. These folders are both present in SERVER-A and SERVER-B. The only difference is that Im not duplicating the SERVER-B procmail & spam folders to SERVER-A. Folder #2 has a list of subfolders with the same name-fashion.

*** And My QUESTIONS? ***

I do not want to mix up things or cause a malfunction on something, so Im better consulting on this forum to try to get a good answer first. I just want to apply Spam rules to USER1's incomming mails on SERVER-A.

------>>> 1) Is there a better way to handle spamassasin for this scenario instead of using procmail/procmail-wrapper???

2) If I use procmail/procmail-wrapper what is the best way to accomplish the required goal (copy folders, just make a simple config, etc...)? <<<------

*** Any REFERENCES ***

Well, I searched the forums and I couldnt find an answer to this issue, so that's why Im posting this question.

Thank you very much.

PD: Sorry for this long post :)


  • Virtualmin: 4.04.gpl GPL
  • Theme version: 8.7
  • OpenLDAP: 2.4.28
  • Postfix version: 2.9.6
  • SpamAssassin version 3.3.2
  • OS: Ubuntu 12.04.3
  • Machine: 4GB RAM, dedicated server


Howdy -- yeah, the procmail-wrapper does indeed call procmail, which ensures that procmail is run with the permissions of the email recipient.

Each of the files in "/etc/webmin/virtual-server/procmail" represent a given domain -- those correspond with a domain ID, as found in /etc/webmin/virtual-server/domains".

The directories within "/etc/webmin/virtual-server/spam" contain SpamAssassin settings for each of your domains.

Your setup there is fairly atypical though, and a bit complex. I'm not entirely certain I understand all the issues you're running into.

Here's my suggestion -- first, since you're using Virtualmin GPL, and the area here is for Virtualmin Pro customers, my suggestion is to open a new thread in the Forums (using the Forums link above), and to post your question there.

However, here's a few things you might want to consider as you're doing that --

If you continue to use procmail, you may want to make sure that the /etc/procmailrc on both systems is correct.

In order to use procmail though, which is the system that Virtualmin is designed to use, you would need all the email-related config files that Virtualmin creates on the system that the email arrives on.

It sounds like that's not occurring in your setup.

Also, in that new Forum thread, you may want to let us know what error(s) you're seeing during email delivery. You can use /var/log/mail.log and /var/log/procmail.log to see what errors are being thrown.

You could always consider moving to a setup that doesn't use what Virtualmin configures for spam processing... you could have Postfix call SpamAssassin directly as the emails come in, or you could use a tool such as Amavis to help with that. Those setups aren't supported by Virtualmin, though they should work. Neither of those would need to use procmail.