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.html
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.html > 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.html >> 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? >> --- >> BernardHi! 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.html >> 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-----