Dovecot + SpamAssassin through dovecot-antispam
Hello,
I am new to the list. /Waving at everyone/
I got a basic SpamAssassin working on a Debian setup (w/ debian-spamd user), running as a Postfix transport.
I am currently trying to switch it to a dovecot plugin in order to make it interactively work with the email storage (react to mail classification, being able to train it from already received emails, aso.) My problem is now making it able to access my emails.
Here is my setup: userdb { driver = static args = uid=<fixed> gid=<fixed> home=/var/mail/vhosts/%d/%n }
passdb { driver = passwd-file args = <path to passwords file> }
mail_location = maildir:~/mail:LAYOUT=fs mail_privileged_group = vmail
Translating into this on the FS: drwxrwsr-x root mail /var/mail/ drwxrws--- root vmail /var/mail/vhosts drwx--S--- vmail vmail /var/mail/vhosts/domain1 drwx--S--- vmail vmail /var/mail/vhosts/domain1/user1 drwx--S--- vmail vmail /var/mail/vhosts/domain1/user2 drwx--S--- vmail vmail /var/mail/vhosts/domain2 drwx--S--- vmail vmail /var/mail/vhosts/domain2/user1
The drwx--S--- access rights are propagated into lower branches/leafs.
I am having a hard time understanding what to do, reading http://wiki2.dovecot.org/SharedMailboxes/Permissions, to make all the folders and subsequent files readable by the vmail group too. Based on this documentation, the way dovecot propagate permissions from parent folders is a bit cryptic to me. What needs to be done to achieve that?
The idea would be that even if I decided to allocated per-virtual-user a system user for stored files, all the files would still be stored and accessible with the same system group. I understand this would be done with the help of mail_access_groups = vmail, right?
FWIW, I am getting inspiration from the following explanations: https://www.christianroessler.net/tech/2015/spamassassin-dovecot-postfix.htm... If I understand correctly, the guy is bypassing the authentication completely with allow_all_users=yes, right? I do not want to do that anyway.
I hope what I am trying to achieve is clear enough and that I provided information enough. Would you help me?
Bernard
No help there?
Bernard
On 01/03/2017 11:27, Bernard wrote:
Hello,
I am new to the list. /Waving at everyone/
I got a basic SpamAssassin working on a Debian setup (w/ debian-spamd user), running as a Postfix transport.
I am currently trying to switch it to a dovecot plugin in order to make it interactively work with the email storage (react to mail classification, being able to train it from already received emails, aso.) My problem is now making it able to access my emails.
Here is my setup: userdb { driver = static args = uid=<fixed> gid=<fixed> home=/var/mail/vhosts/%d/%n }
passdb { driver = passwd-file args = <path to passwords file> }
mail_location = maildir:~/mail:LAYOUT=fs mail_privileged_group = vmail
Translating into this on the FS: drwxrwsr-x root mail /var/mail/ drwxrws--- root vmail /var/mail/vhosts drwx--S--- vmail vmail /var/mail/vhosts/domain1 drwx--S--- vmail vmail /var/mail/vhosts/domain1/user1 drwx--S--- vmail vmail /var/mail/vhosts/domain1/user2 drwx--S--- vmail vmail /var/mail/vhosts/domain2 drwx--S--- vmail vmail /var/mail/vhosts/domain2/user1
The drwx--S--- access rights are propagated into lower branches/leafs.
I am having a hard time understanding what to do, reading http://wiki2.dovecot.org/SharedMailboxes/Permissions, to make all the folders and subsequent files readable by the vmail group too. Based on this documentation, the way dovecot propagate permissions from parent folders is a bit cryptic to me. What needs to be done to achieve that?
The idea would be that even if I decided to allocated per-virtual-user a system user for stored files, all the files would still be stored and accessible with the same system group. I understand this would be done with the help of mail_access_groups = vmail, right?
FWIW, I am getting inspiration from the following explanations: https://www.christianroessler.net/tech/2015/spamassassin-dovecot-postfix.htm... If I understand correctly, the guy is bypassing the authentication completely with allow_all_users=yes, right? I do not want to do that anyway.
I hope what I am trying to achieve is clear enough and that I provided information enough. Would you help me?
Bernard
On 2017-03-03 10:26, Bernard wrote:
No help there?
Bernard
On 01/03/2017 11:27, Bernard wrote:
Hello,
I am new to the list. /Waving at everyone/
I got a basic SpamAssassin working on a Debian setup (w/ debian-spamd user), running as a Postfix transport.
I am currently trying to switch it to a dovecot plugin in order to make it interactively work with the email storage (react to mail classification, being able to train it from already received emails, aso.) My problem is now making it able to access my emails.
Here is my setup: userdb { driver = static args = uid=<fixed> gid=<fixed> home=/var/mail/vhosts/%d/%n }
passdb { driver = passwd-file args = <path to passwords file> }
mail_location = maildir:~/mail:LAYOUT=fs mail_privileged_group = vmail
Translating into this on the FS: drwxrwsr-x root mail /var/mail/ drwxrws--- root vmail /var/mail/vhosts drwx--S--- vmail vmail /var/mail/vhosts/domain1 drwx--S--- vmail vmail /var/mail/vhosts/domain1/user1 drwx--S--- vmail vmail /var/mail/vhosts/domain1/user2 drwx--S--- vmail vmail /var/mail/vhosts/domain2 drwx--S--- vmail vmail /var/mail/vhosts/domain2/user1
The drwx--S--- access rights are propagated into lower branches/leafs.
I am having a hard time understanding what to do, reading http://wiki2.dovecot.org/SharedMailboxes/Permissions, to make all the folders and subsequent files readable by the vmail group too. Based on this documentation, the way dovecot propagate permissions from parent folders is a bit cryptic to me. What needs to be done to achieve that?
The idea would be that even if I decided to allocated per-virtual-user a system user for stored files, all the files would still be stored and accessible with the same system group. I understand this would be done with the help of mail_access_groups = vmail, right?
FWIW, I am getting inspiration from the following explanations: https://www.christianroessler.net/tech/2015/spamassassin-dovecot-postfix.htm... If I understand correctly, the guy is bypassing the authentication completely with allow_all_users=yes, right? I do not want to do that anyway.
I hope what I am trying to achieve is clear enough and that I provided information enough. Would you help me?
Bernard Hi!
https://wiki2.dovecot.org/HowTo/AntispamWithSieve
maybe this would help you?
Aki
i recently had this problem. i am using centos 7. maybe these links will help you i reverted to the old antispam plugin as a package from https://copr.fedorainfracloud.org/coprs/cottsay/dovecot-antispam/ plus this to help configure http://www.iredmail.org/forum/topic8169-iredmail-support-antispam-via-doveco...
On 03/03/2017 12:26, Aki Tuomi wrote:
On 2017-03-03 10:26, Bernard wrote:
No help there?
Bernard
On 01/03/2017 11:27, Bernard wrote:
Hello,
I am new to the list. /Waving at everyone/
I got a basic SpamAssassin working on a Debian setup (w/ debian-spamd user), running as a Postfix transport.
I am currently trying to switch it to a dovecot plugin in order to make it interactively work with the email storage (react to mail classification, being able to train it from already received emails, aso.) My problem is now making it able to access my emails.
Here is my setup: userdb { driver = static args = uid=<fixed> gid=<fixed> home=/var/mail/vhosts/%d/%n }
passdb { driver = passwd-file args = <path to passwords file> }
mail_location = maildir:~/mail:LAYOUT=fs mail_privileged_group = vmail
Translating into this on the FS: drwxrwsr-x root mail /var/mail/ drwxrws--- root vmail /var/mail/vhosts drwx--S--- vmail vmail /var/mail/vhosts/domain1 drwx--S--- vmail vmail /var/mail/vhosts/domain1/user1 drwx--S--- vmail vmail /var/mail/vhosts/domain1/user2 drwx--S--- vmail vmail /var/mail/vhosts/domain2 drwx--S--- vmail vmail /var/mail/vhosts/domain2/user1
The drwx--S--- access rights are propagated into lower branches/leafs.
I am having a hard time understanding what to do, reading http://wiki2.dovecot.org/SharedMailboxes/Permissions, to make all the folders and subsequent files readable by the vmail group too. Based on this documentation, the way dovecot propagate permissions from parent folders is a bit cryptic to me. What needs to be done to achieve that?
The idea would be that even if I decided to allocated per-virtual-user a system user for stored files, all the files would still be stored and accessible with the same system group. I understand this would be done with the help of mail_access_groups = vmail, right?
FWIW, I am getting inspiration from the following explanations: https://www.christianroessler.net/tech/2015/spamassassin-dovecot-postfix.htm...
If I understand correctly, the guy is bypassing the authentication completely with allow_all_users=yes, right? I do not want to do that anyway.
I hope what I am trying to achieve is clear enough and that I provided information enough. Would you help me?
Bernard Hi!
https://wiki2.dovecot.org/HowTo/AntispamWithSieve
maybe this would help you?
Aki
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 3 Mar 2017, Bernard wrote:
On 01/03/2017 11:27, Bernard wrote:
Hello,
I am new to the list. /Waving at everyone/
I got a basic SpamAssassin working on a Debian setup (w/ debian-spamd user), running as a Postfix transport.
I am currently trying to switch it to a dovecot plugin in order to make it interactively work with the email storage (react to mail classification, being able to train it from already received emails, aso.) My problem is now making it able to access my emails.
if you followed the steps of both links, the spam checker is using vmail:vmail, so it has access to the messages.
Here is my setup: userdb { driver = static args = uid=<fixed> gid=<fixed> home=/var/mail/vhosts/%d/%n }
passdb { driver = passwd-file args = <path to passwords file> }
mail_location = maildir:~/mail:LAYOUT=fs mail_privileged_group = vmail
Translating into this on the FS: drwxrwsr-x root mail /var/mail/ drwxrws--- root vmail /var/mail/vhosts drwx--S--- vmail vmail /var/mail/vhosts/domain1 drwx--S--- vmail vmail /var/mail/vhosts/domain1/user1 drwx--S--- vmail vmail /var/mail/vhosts/domain1/user2 drwx--S--- vmail vmail /var/mail/vhosts/domain2 drwx--S--- vmail vmail /var/mail/vhosts/domain2/user1
The drwx--S--- access rights are propagated into lower branches/leafs.
I am having a hard time understanding what to do, reading http://wiki2.dovecot.org/SharedMailboxes/Permissions, to make all the folders and subsequent files readable by the vmail group too. Based on this documentation, the way dovecot propagate permissions from parent folders is a bit cryptic to me. What needs to be done to achieve that?
Your output matches the example in section "Permissions to new /domain/user directories" exactly. The portions about to propagate permissions apply to mailboxes and files therein only.
Also note: Permissions to new user home directories (v2.2+)
When mail_location begins with %h or ~/, its permissions are copied from the first existing parent directory if it has setgid-bit set. This isn't done when the path contains any other %variables.
So, do you use Dovecot v2.2 ?
The idea would be that even if I decided to allocated per-virtual-user a system user for stored files, all the files would still be stored and accessible with the same system group. I understand this would be done with the help of mail_access_groups = vmail, right?
FWIW, I am getting inspiration from the following explanations: https://www.christianroessler.net/tech/2015/spamassassin-dovecot-postfix.htm... If I understand correctly, the guy is bypassing the authentication completely with allow_all_users=yes, right? I do not want to do that anyway.
I hope what I am trying to achieve is clear enough and that I provided information enough. Would you help me?
Bernard
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1
iQEVAwUBWLlnmHz1H7kL/d9rAQKOWwgAi0CcrS1KRgvOusCHx/vSsGFv+HFTQsoR gODzxmmJkJKGQAi+lmd26reGRHmlbuuO9EF7nCIcYh0FtYoEJBrV9QstWz/pNj7t khabQune0BI4j+TSHVSR4VTTyaPG4MngmFTQhfljRv22i0Dfkz/Zy0i/E5ppsB5i NyeJse908L0CT6sQQSET5z44nJjSx0txv8mXYq0Q6ViGEOVe4r6hd6360UmhEP4M 6CuAoMo0Oar3R7raURrCXEFt6uvtEeBLgDyGUylJ7+TtM/qL8OlGsR6Fvhd4aw8j Xf92+a54QKgbZXkweReWCKIZmemN1Fe809yUiRSK1hvOr4Z3cbr8IQ== =86QE -----END PGP SIGNATURE-----
Hello Steffen,
Dovecot version: v2.2.13
It seems there is no problem on mail reception step when piped through dovecot.
However, running it afterwards is another story. SpamAssassin is run as debian-spamd and thus has its information stored in its own environment (isolation). As an exemple, if you read the end of the tutorial, you will notice sa-learn is then used to train SpamAssassin or to run it on stored messages again.
It is that step which bothers me. Even though I could add SpamAssassin debian-spamd user to the vmail group, in the current state that won't help.
The idea would be to configure dovecot in such a way that the vmail group has read access to the whole mail tree, even on creation of new mailboxes. Typically I would like the permissions to be ***:vmail, 770 (d) / 660 (f). /As stated, for now I am using a single vmail user for everyone as I only understood how to make dovecot running like that when setting up my mail system. Ultimately, I'd like to add a per-virtual-mailbox (or per-domain?) system user in order to ensure mail privacy system-wise, if possible./
I am having a hard time understanding how dovecot behaves and why, as well as what configuration directives impact what I want to do and which are unrelated.
... hence this call for help on the ML.
Bernard
On 03/03/2017 13:54, Steffen Kaiser wrote:
On Fri, 3 Mar 2017, Bernard wrote:
On 01/03/2017 11:27, Bernard wrote:
Hello,
I am new to the list. /Waving at everyone/
I got a basic SpamAssassin working on a Debian setup (w/ debian-spamd user), running as a Postfix transport.
I am currently trying to switch it to a dovecot plugin in order to make it interactively work with the email storage (react to mail classification, being able to train it from already received emails, aso.) My problem is now making it able to access my emails.
if you followed the steps of both links, the spam checker is using vmail:vmail, so it has access to the messages.
Here is my setup: userdb { driver = static args = uid=<fixed> gid=<fixed> home=/var/mail/vhosts/%d/%n }
passdb { driver = passwd-file args = <path to passwords file> }
mail_location = maildir:~/mail:LAYOUT=fs mail_privileged_group = vmail
Translating into this on the FS: drwxrwsr-x root mail /var/mail/ drwxrws--- root vmail /var/mail/vhosts drwx--S--- vmail vmail /var/mail/vhosts/domain1 drwx--S--- vmail vmail /var/mail/vhosts/domain1/user1 drwx--S--- vmail vmail /var/mail/vhosts/domain1/user2 drwx--S--- vmail vmail /var/mail/vhosts/domain2 drwx--S--- vmail vmail /var/mail/vhosts/domain2/user1
The drwx--S--- access rights are propagated into lower branches/leafs.
I am having a hard time understanding what to do, reading http://wiki2.dovecot.org/SharedMailboxes/Permissions, to make all the folders and subsequent files readable by the vmail group too. Based on this documentation, the way dovecot propagate permissions from parent folders is a bit cryptic to me. What needs to be done to achieve that?
Your output matches the example in section "Permissions to new /domain/user directories" exactly. The portions about to propagate permissions apply to mailboxes and files therein only.
Also note: Permissions to new user home directories (v2.2+)
When mail_location begins with %h or ~/, its permissions are copied from the first existing parent directory if it has setgid-bit set. This isn't done when the path contains any other %variables.
So, do you use Dovecot v2.2 ?
The idea would be that even if I decided to allocated per-virtual-user a system user for stored files, all the files would still be stored and accessible with the same system group. I understand this would be done with the help of mail_access_groups = vmail, right?
FWIW, I am getting inspiration from the following explanations:
If I understand correctly, the guy is bypassing the authentication completely with allow_all_users=yes, right? I do not want to do
https://www.christianroessler.net/tech/2015/spamassassin-dovecot-postfix.htm... that anyway.
I hope what I am trying to achieve is clear enough and that I provided information enough. Would you help me?
Bernard
-- Steffen Kaiser
participants (4)
-
Aki Tuomi
-
Bernard
-
Matthew Broadhead
-
Steffen Kaiser