[Dovecot] From Sendmail to Dovecot mdbox, what is missing.
Sendmail 8.14.4 dovecot 2.0.9
I have sendmail working and it is sending mail to /var/mail/%u. I have dovecot working in that I can move emails into IMAP folders and I can send email through IMAP. I have set up dovecot to use mdbox based on the following: mail_location = mdbox:~/mail
However, I seem to be lacking a key piece of information.
Sendmail is sending the mail to /var/mail/%u as a mbox (single file for all emails) format.
Dovecot wants to read the mail in mdbox (Multiple messages per file, but unlike mbox multiple files per mailbox.) So the two programs are not working together.
So, I cannot get dovecot to read new emails at /var/mail/%u. So I tried changing to the following: mail_location = mdbox:~/mail:INBOX=/var/mail/%u However, dovecot complains that it is NOT a directory. That is because sendmail is sending as mbox format.
I have tried two lines of “mail_location” but that did not work. example mail_location = mdbox:~/mail ----> for dovecot mail_location = mbox:INBOX=/var/mail/%u -----> for sendmail
I have tried LMTP and dovecot-lda.
LMTP – I could not see any difference with this added or not.
Dovecot-lda – I have had issues getting it configured.
Thanks for any help!
Sendmail changes
FEATURE(local_procmail', /usr/libexec/dovecot/dovecot-lda',/usr/libexec/dovecot/dovecot-lda -d $u') MODIFY_MAILER_FLAGS(LOCAL', `-f')
MAILER(procmail)dnl
Here is dovecot configuration [root@nala mail]# dovecot -n # 2.0.9: /etc/dovecot/dovecot.conf # OS: Linux 2.6.32-279.14.1.el6.x86_64 x86_64 Scientific Linux release 6.3 (Carbon) auth_mechanisms = plain login mail_gid = mail mail_location = mdbox:~/mail mail_uid = mail mbox_write_locks = fcntl passdb { driver = pam } plugin { mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename mail_log_group_events = yes } service auth { unix_listener auth-userdb { mode = 0600 user = mail } } service lmtp { inet_listener lmtp { address = 192.168.1.185 127.0.0.1 ::1 port = 24 } user = mail } ssl_cert = </etc/pki/dovecot/certs/dovecot.pem ssl_key = </etc/pki/dovecot/private/dovecot.pem userdb { driver = passwd } protocol lda { info_log_path = /var/log/maillog log_path = /var/log/maillog postmaster_address = postmaster@torpey.org }
At 5PM -0600 on 31/12/12 you (Torpey List) wrote:
Sendmail 8.14.4 dovecot 2.0.9
I have sendmail working and it is sending mail to /var/mail/%u. I have dovecot working in that I can move emails into IMAP folders and I can send email through IMAP. I have set up dovecot to use mdbox based on the following: mail_location = mdbox:~/mail
However, I seem to be lacking a key piece of information.
Sendmail is sending the mail to /var/mail/%u as a mbox (single file for all emails) format. Dovecot wants to read the mail in mdbox (Multiple messages per file, but unlike mbox multiple files per mailbox.) So the two programs are not working together.So, I cannot get dovecot to read new emails at /var/mail/%u. So I tried changing to the following: mail_location = mdbox:~/mail:INBOX=/var/mail/%u However, dovecot complains that it is NOT a directory. That is because sendmail is sending as mbox format.
I have tried two lines of “mail_location” but that did not work. example mail_location = mdbox:~/mail ----> for dovecot mail_location = mbox:INBOX=/var/mail/%u -----> for sendmail
No, that doesn't work: in fact, the second line will completely override the first. If you run 'doveconf -n' or 'doveconf mail_location' you will see that the first line doesn't have any effect.
If you want to keep INBOX delivery to mboxes in /var/mail, you can do this using two namespaces. One points to mdbox:~/mail, and holds the users' ordinary IMAP folders in mdbox format, and the other has INBOX=/var/mail/%u and just holds the INBOX. There is an example in http://wiki2.dovecot.org/Namespaces of doing this with Maildir and mbox; adjusting it for mdbox shouldn't be hard.
You will find you need a directory for each user to hold the other folders in the INBOX namespace, since Dovecot doesn't know there won't ever be any. This directory is also used to store Dovecot's index files for that namespace, and it should *not* be the same as the mdbox directory. According to http://wiki2.dovecot.org/MailLocation/mbox , you can skip this if you use
location = mbox:/var/empty:INBOX=/var/mail/%u:INDEX=MEMORY(assuming /var/empty is a readonly root-owned empty directory), but since this tells Dovecot not to store index files on disk it may make INBOX access less efficient. If you use a real directory rather than /var/empty you may want to consider enabling the acl plugin and setting up a global ACL which prevents users from creating additional folders in the INBOX namespace.
It's probably also a good idea to set mail_location = mdbox:~/mail and omit the location parameter from the mdbox namespace, since IIRC otherwise commands like 'doveadm purge' won't work correctly.
I have tried LMTP and dovecot-lda.
If you want to deliver mail into the mdbox INBOX, and forget about /var/mail altogether, you will need to get one of these two working since Sendmail doesn't understand mdbox. This is probably the best option in the long run, unless you have other software which relies on mail being in /var/mail. If you pick this option you need to remove all references to /var/mail from dovecot.conf; with the two lines you had above Dovecot will simply carry on delivering into /var/mail just as Sendmail had been.
LMTP – I could not see any difference with this added or not.
If you had configured Dovecot to deliver into /var/mail, that's hardly surprising. Otherwise, are you sure you were delivering mail to the LMTP server? If you were you should have seen entries in Dovecot's log file, and the delivered mail should have ended up with a Received header from the LMTP server.
Dovecot-lda – I have had issues getting it configured.
What issues? If you were trying to get the LDA to deliver to /var/mail, it's possible you were running into permissions problems. The best solution is to deliver into the mdbox instead, or just leave Sendmail to deliver to /var/mail.
Sendmail changes FEATURE(
local_procmail',/usr/libexec/dovecot/dovecot-lda',/usr/libexec/dovecot/dovecot-lda -d $u') MODIFY_MAILER_FLAGS(LOCAL', `-f') MAILER(procmail)dnl
I know nothing at all about Sendmail configuration, but going by the Dovecot wiki that looks correct. Are you sure mail for the appropriate users was actually getting routed through that mailer? What did you see in the logs (you need to check both Dovecot's and Sendmail's logs, wherever they may be).
Ben
-----Original Message----- From: Ben Morrow Sent: Monday, December 31, 2012 8:52 PM To: Dovecot Mailing List Subject: Re: [Dovecot] From Sendmail to Dovecot mdbox, what is missing.
At 5PM -0600 on 31/12/12 you (Torpey List) wrote:
Sendmail 8.14.4 dovecot 2.0.9
I have sendmail working and it is sending mail to /var/mail/%u. I have dovecot working in that I can move emails into IMAP folders and I can send email through IMAP. I have set up dovecot to use mdbox based on the following: mail_location = mdbox:~/mail
However, I seem to be lacking a key piece of information. Sendmail is sending the mail to /var/mail/%u as a mbox (single file for all emails) format. Dovecot wants to read the mail in mdbox (Multiple messages per file, but unlike mbox multiple files per mailbox.) So the two programs are not working together.
So, I cannot get dovecot to read new emails at /var/mail/%u. So I tried changing to the following: mail_location = mdbox:~/mail:INBOX=/var/mail/%u However, dovecot complains that it is NOT a directory. That is because sendmail is sending as mbox format.
I have tried two lines of “mail_location” but that did not work. example mail_location = mdbox:~/mail ----> for dovecot mail_location = mbox:INBOX=/var/mail/%u -----> for sendmail
No, that doesn't work: in fact, the second line will completely override the first. If you run 'doveconf -n' or 'doveconf mail_location' you will see that the first line doesn't have any effect.
I did not expect it to work, but I was trying all that I could before posting a question.
If you want to keep INBOX delivery to mboxes in /var/mail, you can do this using two namespaces. One points to mdbox:~/mail, and holds the users' ordinary IMAP folders in mdbox format, and the other has INBOX=/var/mail/%u and just holds the INBOX. There is an example in http://wiki2.dovecot.org/Namespaces of doing this with Maildir and mbox; adjusting it for mdbox shouldn't be hard.
You will find you need a directory for each user to hold the other folders in the INBOX namespace, since Dovecot doesn't know there won't ever be any. This directory is also used to store Dovecot's index files for that namespace, and it should *not* be the same as the mdbox directory. According to http://wiki2.dovecot.org/MailLocation/mbox , you can skip this if you use
location = mbox:/var/empty:INBOX=/var/mail/%u:INDEX=MEMORY
(assuming /var/empty is a readonly root-owned empty directory), but since this tells Dovecot not to store index files on disk it may make INBOX access less efficient. If you use a real directory rather than /var/empty you may want to consider enabling the acl plugin and setting up a global ACL which prevents users from creating additional folders in the INBOX namespace.
It's probably also a good idea to set mail_location = mdbox:~/mail and omit the location parameter from the mdbox namespace, since IIRC otherwise commands like 'doveadm purge' won't work correctly.
I am going to try an option below.
I have tried LMTP and dovecot-lda.
If you want to deliver mail into the mdbox INBOX, and forget about /var/mail altogether, you will need to get one of these two working since Sendmail doesn't understand mdbox. This is probably the best option in the long run, unless you have other software which relies on mail being in /var/mail. If you pick this option you need to remove all references to /var/mail from dovecot.conf; with the two lines you had above Dovecot will simply carry on delivering into /var/mail just as Sendmail had been.
I would like to deliver new mail into the mdbox INBOX and forget about /var/mail but I did not see how to do this. I think that was the piece of information that I am missing.
LMTP – I could not see any difference with this added or not.
If you had configured Dovecot to deliver into /var/mail, that's hardly surprising. Otherwise, are you sure you were delivering mail to the LMTP server? If you were you should have seen entries in Dovecot's log file, and the delivered mail should have ended up with a Received header from the LMTP server.
I have used egrep and there is no line that has /var/mail that is uncommented in any of the config files.
Based on your comment, then no I do not believe the new mail was going through LMTP.
Dovecot-lda – I have had issues getting it configured.
What issues? If you were trying to get the LDA to deliver to /var/mail, it's possible you were running into permissions problems. The best solution is to deliver into the mdbox instead, or just leave Sendmail to deliver to /var/mail.
Sendmail changes FEATURE(
local_procmail',/usr/libexec/dovecot/dovecot-lda',/usr/libexec/dovecot/dovecot-lda -d $u') MODIFY_MAILER_FLAGS(LOCAL', `-f') MAILER(procmail)dnlI know nothing at all about Sendmail configuration, but going by the Dovecot wiki that looks correct. Are you sure mail for the appropriate users was actually getting routed through that mailer? What did you see in the logs (you need to check both Dovecot's and Sendmail's logs, wherever they may be).
Ben
Thanks for the information. The email is not being delivered by LTMP because there are no logs.
The most documentation that I have found is using dovecot-lda, but as you said there are permissions issues. The wiki implied that LTMP is the best solution but I am not understanding enough to get it set up.
Therefore, I am attempting to stick with dovecot-lda *using sudo* from the dovecot-lda wiki page. The wiki said to put /usr/bin/sudo in front of path/dovecot-lda but did not say which one or both. I could not get it to work.
The option that has gone the furthest is *Making dovecot-lda setuid-root*. However, I have errors. Here are the permissions.
-rwxr-xr-x. 1 root secmail 26512 Aug 18 2011 /usr/libexec/dovecot/dovecot-lda
srw-------. 1 mail root 0 Jan 1 08:39 /var/run/dovecot/auth-userdbErrors..... ==> /var/log/maillog <== Jan 1 08:24:02 nala sendmail[20154]: r01EO2qc020154: from=<user@yahoo.com>, size=5723, class=0, nrcpts=1, msgid=<1357050226.83142.YahooMailNeo@web120205.mail.ne1.yahoo.com>, proto=ESMTP, daemon=MTA, relay=mail.example.com [192.168.1.152] Jan 01 08:24:02 lda: Error: userdb lookup: connect(/var/run/dovecot/auth-userdb) failed: Permission denied (euid=0(root) egid=0(root) missing +r perm: /var/run/dovecot/auth-userdb, euid is dir owner) Jan 01 08:24:02 lda: Fatal: Internal error occurred. Refer to server log for more information. Jan 1 08:24:02 nala sendmail[20155]: r01EO2qc020154: to=user@example.com, delay=00:00:00, xdelay=00:00:00, mailer=local, pri=35889, dsn=4.0.0, stat=Deferred: local mailer (/usr/libexec/dovecot/dovecot-lda) exited with EX_TEMPFAIL
==> /var/log/messages <== Jan 1 08:24:02 nala kernel: type=1400 audit(1357050242.947:42): avc: denied { dac_override } for pid=20156 comm="dovecot-lda" capability=1 scontext=unconfined_u:system_r:dovecot_deliver_t:s0 tcontext=unconfined_u:system_r:dovecot_deliver_t:s0 tclass=capability Jan 1 08:24:02 nala kernel: type=1400 audit(1357050242.947:43): avc: denied { dac_override } for pid=20156 comm="dovecot-lda" capability=1 scontext=unconfined_u:system_r:dovecot_deliver_t:s0 tcontext=unconfined_u:system_r:dovecot_deliver_t:s0 tclass=capability Jan 1 08:24:02 nala kernel: type=1400 audit(1357050242.947:44): avc: denied { dac_read_search } for pid=20156 comm="dovecot-lda" capability=2 scontext=unconfined_u:system_r:dovecot_deliver_t:s0 tcontext=unconfined_u:system_r:dovecot_deliver_t:s0 tclass=capability
So, the error appears to be related to /var/run/dovecot/auth-userdb. I have made various permission and owner changes; however, restarting dovecot always returns it to the permissions above. So, even if I find a combination that works, dovecot is going to put it back.
Thanks for any help, Steve
Am 01.01.2013 um 15:44 schrieb "Torpey List" <list@torpey.org>:
==> /var/log/maillog <== Jan 1 08:24:02 nala sendmail[20154]: r01EO2qc020154: from=<user@yahoo.com>, size=5723, class=0, nrcpts=1, msgid=<1357050226.83142.YahooMailNeo@web120205.mail.ne1.yahoo.com>, proto=ESMTP, daemon=MTA, relay=mail.example.com [192.168.1.152] Jan 01 08:24:02 lda: Error: userdb lookup: connect(/var/run/dovecot/auth-userdb) failed: Permission denied (euid=0(root) egid=0(root) missing +r perm: /var/run/dovecot/auth-userdb, euid is dir owner) Jan 01 08:24:02 lda: Fatal: Internal error occurred. Refer to server log for more information.
I don't use Sendmail myself so I can't really comment on its configuration. However the issue looks like a typical mismatch of UIDs on the socket:
http://wiki2.dovecot.org/LDA/Sendmail
As per the link above you could try running 'chown mail' on the LDA. This will match the ID to the 'userdb' socket unix_listener (user = mail):
-rwxr-xr-x. 1 root secmail 26512 Aug 18 2011 /usr/libexec/dovecot/dovecot-lda srw-------. 1 mail root 0 Jan 1 08:39 /var/run/dovecot/auth-userdb
Good Luck Thomas
-----Original Message----- From: Thomas Leuxner Sent: Tuesday, January 01, 2013 9:03 AM To: Dovecot Mailing List Subject: Re: [Dovecot] From Sendmail to Dovecot mdbox, what is missing.
Am 01.01.2013 um 15:44 schrieb "Torpey List" <list@torpey.org>:
I don't use Sendmail myself so I can't really comment on its configuration. However the issue looks like a typical mismatch of UIDs on the socket:
http://wiki2.dovecot.org/LDA/Sendmail
As per the link above you could try running 'chown mail' on the LDA. This will match the ID to the 'userdb' socket unix_listener (user = mail):
-rwxr-xr-x. 1 root secmail 26512 Aug 18 2011 /usr/libexec/dovecot/dovecot-lda srw-------. 1 mail root 0 Jan 1 08:39 /var/run/dovecot/auth-userdb
Good Luck Thomas
I have changed the permissions to the following: -rwxr-xr-x. 1 mail secmail 26512 Aug 18 2011 /usr/libexec/dovecot/dovecot-lda srw-rw-rw-. 1 mail secmail 0 Jan 1 09:41 /var/run/dovecot/auth-userdb
Then I get this error (steve is who the email is addressed to):
Jan 01 09:43:47 lda(steve): Fatal: setgid(501(steve)) failed with euid=0(root), gid=0(root), egid=0(root): Operation not permitted (This binary should probably be called with process group set to 501(steve) instead of 0(root))
Thanks, Steve
-----Original Message----- From: Torpey List Sent: Tuesday, January 01, 2013 9:50 AM To: Dovecot Mailing List Subject: Re: [Dovecot] From Sendmail to Dovecot mdbox, what is missing.
-----Original Message----- From: Thomas Leuxner Sent: Tuesday, January 01, 2013 9:03 AM To: Dovecot Mailing List Subject: Re: [Dovecot] From Sendmail to Dovecot mdbox, what is missing.
Am 01.01.2013 um 15:44 schrieb "Torpey List" <list@torpey.org>:
I don't use Sendmail myself so I can't really comment on its configuration. However the issue looks like a typical mismatch of UIDs on the socket:
http://wiki2.dovecot.org/LDA/Sendmail
As per the link above you could try running 'chown mail' on the LDA. This will match the ID to the 'userdb' socket unix_listener (user = mail):
-rwxr-xr-x. 1 root secmail 26512 Aug 18 2011 /usr/libexec/dovecot/dovecot-lda srw-------. 1 mail root 0 Jan 1 08:39 /var/run/dovecot/auth-userdb
Good Luck Thomas
I have changed the permissions to the following: -rwxr-xr-x. 1 mail secmail 26512 Aug 18 2011 /usr/libexec/dovecot/dovecot-lda srw-rw-rw-. 1 mail secmail 0 Jan 1 09:41 /var/run/dovecot/auth-userdb
Then I get this error (steve is who the email is addressed to):
Jan 01 09:43:47 lda(steve): Fatal: setgid(501(steve)) failed with euid=0(root), gid=0(root), egid=0(root): Operation not permitted (This binary should probably be called with process group set to 501(steve) instead of 0(root))
Thanks, Steve
I was rereading man dovecot-lda and specifically the option "-d username". it said that it is used typically with virutal users, but not necessarily with system users. I am doing system users; therefore I removed it from the sendmail feature, but then I get the following error in maillog:
Jan 1 10:28:39 nala sendmail[23041]: r01GScR4023040: smtpquit: mailer local exited with exit value 64
I googled, but did not find what value 64 meant. Anyone have a list or a clue what this error means?
Thanks, Steve
At 10AM -0600 on 1/01/13 you (Torpey List) wrote:
I was rereading man dovecot-lda and specifically the option "-d username". it said that it is used typically with virutal users, but not necessarily with system users. I am doing system users; therefore I removed it from the sendmail feature, but then I get the following error in maillog:
Jan 1 10:28:39 nala sendmail[23041]: r01GScR4023040: smtpquit: mailer local exited with exit value 64
I googled, but did not find what value 64 meant. Anyone have a list or a clue what this error means?
/usr/include/sysexits.h:
#define EX_USAGE 64 /* command line usage error */Sendmail (and therefore other mail-processing software) is one of the few traditional Unix programs to use these exit codes consistently, and expect other programs to use them.
Ben
At 8AM -0600 on 1/01/13 you (Torpey List) wrote:
-----Original Message----- From: Ben Morrow Sent: Monday, December 31, 2012 8:52 PM To: Dovecot Mailing List Subject: Re: [Dovecot] From Sendmail to Dovecot mdbox, what is missing.
At 5PM -0600 on 31/12/12 you (Torpey List) wrote:
Sendmail 8.14.4 dovecot 2.0.9
I have sendmail working and it is sending mail to /var/mail/%u. I have dovecot working in that I can move emails into IMAP folders and I can send email through IMAP. I have set up dovecot to use mdbox based on the following: mail_location = mdbox:~/mail
However, I seem to be lacking a key piece of information. <snip>
If you want to keep INBOX delivery to mboxes in /var/mail, <snip>
I am going to try an option below.
OK. That's probably best.
LMTP – I could not see any difference with this added or not.
If you had configured Dovecot to deliver into /var/mail, that's hardly surprising. Otherwise, are you sure you were delivering mail to the LMTP server? If you were you should have seen entries in Dovecot's log file, and the delivered mail should have ended up with a Received header from the LMTP server.
I have used egrep and there is no line that has /var/mail that is uncommented in any of the config files.
Based on your comment, then no I do not believe the new mail was going through LMTP.
OK. That sounds likely, since you haven't mentioned any LMTP-related Sendmail configuration.
Dovecot-lda – I have had issues getting it configured.
What issues? If you were trying to get the LDA to deliver to /var/mail, it's possible you were running into permissions problems. The best solution is to deliver into the mdbox instead, or just leave Sendmail to deliver to /var/mail.
Sendmail changes FEATURE(
local_procmail',/usr/libexec/dovecot/dovecot-lda',/usr/libexec/dovecot/dovecot-lda -d $u') MODIFY_MAILER_FLAGS(LOCAL', `-f') MAILER(procmail)dnlI know nothing at all about Sendmail configuration, but going by the Dovecot wiki that looks correct. Are you sure mail for the appropriate users was actually getting routed through that mailer? What did you see in the logs (you need to check both Dovecot's and Sendmail's logs, wherever they may be).
The email is not being delivered by LTMP because there are no logs.
The most documentation that I have found is using dovecot-lda, but as you said there are permissions issues. The wiki implied that LTMP is the best solution but I am not understanding enough to get it set up.
The most important part, which I can't help you with, is finding out how to turn on Sendmail's LMTP client (assuming it has one). For that you would need to read the Sendmail documentation, or ask on a Sendmail list.
Therefore, I am attempting to stick with dovecot-lda *using sudo* from the dovecot-lda wiki page. The wiki said to put /usr/bin/sudo in front of path/dovecot-lda but did not say which one or both. I could not get it to work.
The option that has gone the furthest is *Making dovecot-lda setuid-root*. However, I have errors. Here are the permissions.
-rwxr-xr-x. 1 root secmail 26512 Aug 18 2011 /usr/libexec/dovecot/dovecot-lda
That is not setuid root. If it were, it would be *extremely* dangerous, since you haven't removed the other-execute bit.
Making programs setuid root is a very very bad idea. You should not do it unless you have absolutely no alternative. Pretty-much the same applies to using sudo to do the same thing, although that is a little safer since sudo makes an effort to clean the environment.
How does Sendmail invoke the LDA? Is it already running as the right user for the delivery? Are you using system or virtual users?
==> /var/log/maillog <== Jan 01 08:24:02 lda: Error: userdb lookup: connect(/var/run/dovecot/auth-userdb) failed: Permission denied (euid=0(root) egid=0(root) missing +r perm: /var/run/dovecot/auth-userdb, euid is dir owner)
==> /var/log/messages <== Jan 1 08:24:02 nala kernel: type=1400 audit(1357050242.947:42): avc: denied { dac_override } for pid=20156 comm="dovecot-lda" capability=1 scontext=unconfined_u:system_r:dovecot_deliver_t:s0 tcontext=unconfined_u:system_r:dovecot_deliver_t:s0 tclass=capability
OK, these two suggest to me you are using an SELinux system, and that the system is placing unexpected limitations on the abilities of root. While that's irritating, it isn't a problem since you shouldn't be running the LDA as root anyway.
If you are using system users, make sure Sendmail invokes dovecot-lda as the appropriate user, and don't pass the -d option. (This assumes your Dovecot homedirs are the same as your /etc/passwd homedirs, and you aren't doing anything tricky in the userdb.)
If you are using virtual users with a single uid, make Sendmail invoke dovecot-lda as that uid, pass the -d option, and make sure the auth-userdb socket is accessible to that user.
If you are doing something more complicated, you will need to explain, but probably your best option is to get LMTP working.
Ben
On 01/01/2013 03:44 PM, Torpey List wrote:
[...] Thanks for the information. The email is not being delivered by LTMP because there are no logs.
The most documentation that I have found is using dovecot-lda, but as you said there are permissions issues. The wiki implied that LTMP is the best solution but I am not understanding enough to get it set up. [...]
The quick fix for a few system accounts may be use users' ~/.forward file to execute dovecot-lda.
You may execute as root the test command below to trace (eventual) problems: sendmail -d44.4 -d 27.2 -bv user
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 1 Jan 2013, Torpey List wrote:
Dovecot-lda – I have had issues getting it configured.
What issues? If you were trying to get the LDA to deliver to /var/mail, it's possible you were running into permissions problems. The best solution is to deliver into the mdbox instead, or just leave Sendmail to deliver to /var/mail.
Sendmail changes FEATURE(
local_procmail',/usr/libexec/dovecot/dovecot-lda',/usr/libexec/dovecot/dovecot-lda -d $u') MODIFY_MAILER_FLAGS(LOCAL', `-f') MAILER(procmail)dnl
I do use:
FEATURE(local_procmail', /etc/mail/smrsh/dovecot-deliver',
`/etc/mail/smrsh/dovecot-deliver -f $g -d $u -m $h')dnl
Note, you need a symlink in your "smrsh"-directory anyway.
The option that has gone the furthest is *Making dovecot-lda setuid-root*.
I don't use a setuid-root LDA.
However, I have errors. Here are the permissions.
-rwxr-xr-x. 1 root secmail 26512 Aug 18 2011 /usr/libexec/dovecot/dovecot-lda
Your LDA is not setuid-root ;-)
srw-------. 1 mail root 0 Jan 1 08:39 /var/run/dovecot/auth-userdb
Do you need to protect /var/run/dovecot/auth-userdb that tight? I mean, is this server used by users via ssh or something? Otherwise make the Unix permission of that socket so, that any system user can read from it (aka 0666). Maybe, put all mail users into the same group and use 0660. Change group of auth-userdb to mail ... .
Errors..... ==> /var/log/maillog <== Jan 1 08:24:02 nala sendmail[20154]: r01EO2qc020154: from=<user@yahoo.com>, size=5723, class=0, nrcpts=1, msgid=<1357050226.83142.YahooMailNeo@web120205.mail.ne1.yahoo.com>, proto=ESMTP, daemon=MTA, relay=mail.example.com [192.168.1.152] Jan 01 08:24:02 lda: Error: userdb lookup: connect(/var/run/dovecot/auth-userdb) failed: Permission denied (euid=0(root) egid=0(root) missing +r perm: /var/run/dovecot/auth-userdb, euid is dir owner) Jan 01 08:24:02 lda: Fatal: Internal error occurred. Refer to server log for more information.
That error seems to indicate a Dovecot permission check failure, but IMHO root is allowed to connect always. You could try to chmod +x /var/run/dovecot/auth-userdb, the x-perm disables the check of Dovecot.
Jan 1 08:24:02 nala sendmail[20155]: r01EO2qc020154: to=user@example.com, delay=00:00:00, xdelay=00:00:00, mailer=local, pri=35889, dsn=4.0.0, stat=Deferred: local mailer (/usr/libexec/dovecot/dovecot-lda) exited with EX_TEMPFAIL
==> /var/log/messages <== Jan 1 08:24:02 nala kernel: type=1400 audit(1357050242.947:42): avc: denied { dac_override } for pid=20156 comm="dovecot-lda" capability=1 scontext=unconfined_u:system_r:dovecot_deliver_t:s0 tcontext=unconfined_u:system_r:dovecot_deliver_t:s0 tclass=capability Jan 1 08:24:02 nala kernel: type=1400 audit(1357050242.947:43): avc: denied { dac_override } for pid=20156 comm="dovecot-lda" capability=1 scontext=unconfined_u:system_r:dovecot_deliver_t:s0 tcontext=unconfined_u:system_r:dovecot_deliver_t:s0 tclass=capability Jan 1 08:24:02 nala kernel: type=1400 audit(1357050242.947:44): avc: denied { dac_read_search } for pid=20156 comm="dovecot-lda" capability=2 scontext=unconfined_u:system_r:dovecot_deliver_t:s0 tcontext=unconfined_u:system_r:dovecot_deliver_t:s0 tclass=capability
This is a AppArmor / SELinux entry?? Did you configured your policy? Security policies would overrule Unix and Dovecot permission checks.
So, the error appears to be related to /var/run/dovecot/auth-userdb. I have made various permission and owner changes; however, restarting dovecot always returns it to the permissions above. So, even if I find a combination that works, dovecot is going to put it back.
You can change the default permission and ownership in the config file.
Regards,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBUOUtBmoxLS8a3A9mAQKpMwgAsZ1UmJAMcmjWul1fx8MsMZk4TEHeOT8E Ns7HaVnizwooYiDy1bY2jGrhG8xegCXzC7fpWqCXloji7qmVoe5prqLhZsTIpusc wpXf9VAnQ38Fbm4hRj+75zPBIxUYBO7/ulIZsLPkZhRII9WK+QGNNrJnP6ycNcqn +4supaV0AR3KC8uLntfBsrgBWz+2/ZNJu+yZUFpyZpGJHKBkqsaEk7cDnhgHQCzE lhk05MNP+w13QKFb9ZPi9/tv3bhEkBr4R9yA4/xp+Nk7JnrY8ry8Oy2guMXda0a8 Iym6Qgt9XfUFAQ+Urujbu1OlI5KiRIcJV+EyRdM4uVcmAmVZAtI3ow== =K9zr -----END PGP SIGNATURE-----
-----Original Message----- From: Steffen Kaiser Sent: Thursday, January 03, 2013 1:02 AM To: Dovecot Mailing List Cc: Torpey List Subject: Re: [Dovecot] From Sendmail to Dovecot mdbox, what is missing.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 1 Jan 2013, Torpey List wrote:
Dovecot-lda – I have had issues getting it configured.
What issues? If you were trying to get the LDA to deliver to /var/mail, it's possible you were running into permissions problems. The best solution is to deliver into the mdbox instead, or just leave Sendmail to deliver to /var/mail.
Sendmail changes FEATURE(
local_procmail',/usr/libexec/dovecot/dovecot-lda',/usr/libexec/dovecot/dovecot-lda -d $u') MODIFY_MAILER_FLAGS(LOCAL', `-f') MAILER(procmail)dnlI do use: FEATURE(
local_procmail',/etc/mail/smrsh/dovecot-deliver', `/etc/mail/smrsh/dovecot-deliver -f $g -d $u -m $h')dnlNote, you need a symlink in your "smrsh"-directory anyway.
This appears to have been my road block. Mail has started moving, so now I need to do testing to make sure everything else is working.
I knew that I was missing a detail.
Thank you so much, Steve
SOLVED. It turns out it was SELinux that was causing this error (as well as others): Jan 26 17:32:58 nala kernel: type=1400 audit(1359243178.285:5768): avc: denied { setgid } for pid=30558 comm="dovecot-lda" capability=6 scontext=unconfined_u:system_r:dovecot_deliver_t:s0 tcontext=unconfined_u:system_r:dovecot_deliver_t:s0 tclass=capability
The errors were combined into err.txt using the following command. grep audit /var/log/messages |grep dovecot-lda >> err.txt
Then a SELinux was generated using: audit2allow -i err.txt -M dovecot-lda
which made a file dovecot-lda.te that contained the following: module dovecot-lda 2.1;
require { type var_log_t; type dovecot_deliver_t; type etc_runtime_t; class capability { setuid dac_read_search setgid dac_override }; class file append; class dir write; }
#============= dovecot_deliver_t ============== allow dovecot_deliver_t etc_runtime_t:file append; #!!!! This avc is allowed in the current policy
allow dovecot_deliver_t self:capability setgid; allow dovecot_deliver_t self:capability { setuid dac_read_search dac_override }; #!!!! The source type 'dovecot_deliver_t' can write to a 'dir' of the following types: # user_home_t, dovecot_deliver_tmp_t, user_home_dir_t, tmp_t, mail_spool_t, nfs_t
allow dovecot_deliver_t var_log_t:dir write;
If you make any changes to dovecot-lda.te, like the version number because you have already tried to get it into SELinux then you have to do the following command: make
Finally, to get it incorporated into SELinux: semodule -i dovecot-lda.pp
This has been driving me crazy for a month, I am surprised that I could not find straight solution. I have to give credit to the following bugzilla that helped me use the audit2allow in an automated way that provided the necessary detail to generate dovecot-lda.te listed above. https://bugzilla.redhat.com/show_bug.cgi?id=667579
My mail is flowing from tests, now I need to have a larger stream make it work.
Thanks, Steve
-----Original Message----- From: Steffen Kaiser Sent: Thursday, January 03, 2013 1:02 AM To: Dovecot Mailing List Cc: Torpey List Subject: Re: [Dovecot] From Sendmail to Dovecot mdbox, what is missing.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, 1 Jan 2013, Torpey List wrote:
Dovecot-lda – I have had issues getting it configured.
What issues? If you were trying to get the LDA to deliver to /var/mail, it's possible you were running into permissions problems. The best solution is to deliver into the mdbox instead, or just leave Sendmail to deliver to /var/mail.
Sendmail changes FEATURE(
local_procmail',/usr/libexec/dovecot/dovecot-lda',/usr/libexec/dovecot/dovecot-lda -d $u') MODIFY_MAILER_FLAGS(LOCAL', `-f') MAILER(procmail)dnl
I do use:
FEATURE(local_procmail', /etc/mail/smrsh/dovecot-deliver',
`/etc/mail/smrsh/dovecot-deliver -f $g -d $u -m $h')dnl
Note, you need a symlink in your "smrsh"-directory anyway.
The option that has gone the furthest is *Making dovecot-lda setuid-root*.
I don't use a setuid-root LDA.
However, I have errors. Here are the permissions.
-rwxr-xr-x. 1 root secmail 26512 Aug 18 2011 /usr/libexec/dovecot/dovecot-lda
Your LDA is not setuid-root ;-)
srw-------. 1 mail root 0 Jan 1 08:39 /var/run/dovecot/auth-userdb
Do you need to protect /var/run/dovecot/auth-userdb that tight? I mean, is this server used by users via ssh or something? Otherwise make the Unix permission of that socket so, that any system user can read from it (aka 0666). Maybe, put all mail users into the same group and use 0660. Change group of auth-userdb to mail ... .
Errors..... ==> /var/log/maillog <== Jan 1 08:24:02 nala sendmail[20154]: r01EO2qc020154: from=<user@yahoo.com>, size=5723, class=0, nrcpts=1, msgid=<1357050226.83142.YahooMailNeo@web120205.mail.ne1.yahoo.com>, proto=ESMTP, daemon=MTA, relay=mail.example.com [192.168.1.152] Jan 01 08:24:02 lda: Error: userdb lookup: connect(/var/run/dovecot/auth-userdb) failed: Permission denied (euid=0(root) egid=0(root) missing +r perm: /var/run/dovecot/auth-userdb, euid is dir owner) Jan 01 08:24:02 lda: Fatal: Internal error occurred. Refer to server log for more information.
That error seems to indicate a Dovecot permission check failure, but IMHO root is allowed to connect always. You could try to chmod +x /var/run/dovecot/auth-userdb, the x-perm disables the check of Dovecot.
Jan 1 08:24:02 nala sendmail[20155]: r01EO2qc020154: to=user@example.com, delay=00:00:00, xdelay=00:00:00, mailer=local, pri=35889, dsn=4.0.0, stat=Deferred: local mailer (/usr/libexec/dovecot/dovecot-lda) exited with EX_TEMPFAIL
==> /var/log/messages <== Jan 1 08:24:02 nala kernel: type=1400 audit(1357050242.947:42): avc: denied { dac_override } for pid=20156 comm="dovecot-lda" capability=1 scontext=unconfined_u:system_r:dovecot_deliver_t:s0 tcontext=unconfined_u:system_r:dovecot_deliver_t:s0 tclass=capability Jan 1 08:24:02 nala kernel: type=1400 audit(1357050242.947:43): avc: denied { dac_override } for pid=20156 comm="dovecot-lda" capability=1 scontext=unconfined_u:system_r:dovecot_deliver_t:s0 tcontext=unconfined_u:system_r:dovecot_deliver_t:s0 tclass=capability Jan 1 08:24:02 nala kernel: type=1400 audit(1357050242.947:44): avc: denied { dac_read_search } for pid=20156 comm="dovecot-lda" capability=2 scontext=unconfined_u:system_r:dovecot_deliver_t:s0 tcontext=unconfined_u:system_r:dovecot_deliver_t:s0 tclass=capability
This is a AppArmor / SELinux entry?? Did you configured your policy? Security policies would overrule Unix and Dovecot permission checks.
So, the error appears to be related to /var/run/dovecot/auth-userdb. I have made various permission and owner changes; however, restarting dovecot always returns it to the permissions above. So, even if I find a combination that works, dovecot is going to put it back.
You can change the default permission and ownership in the config file.
Regards,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux)
iQEVAwUBUOUtBmoxLS8a3A9mAQKpMwgAsZ1UmJAMcmjWul1fx8MsMZk4TEHeOT8E Ns7HaVnizwooYiDy1bY2jGrhG8xegCXzC7fpWqCXloji7qmVoe5prqLhZsTIpusc wpXf9VAnQ38Fbm4hRj+75zPBIxUYBO7/ulIZsLPkZhRII9WK+QGNNrJnP6ycNcqn +4supaV0AR3KC8uLntfBsrgBWz+2/ZNJu+yZUFpyZpGJHKBkqsaEk7cDnhgHQCzE lhk05MNP+w13QKFb9ZPi9/tv3bhEkBr4R9yA4/xp+Nk7JnrY8ry8Oy2guMXda0a8 Iym6Qgt9XfUFAQ+Urujbu1OlI5KiRIcJV+EyRdM4uVcmAmVZAtI3ow== =K9zr -----END PGP SIGNATURE-----
participants (5)
-
Andrzej A. Filip
-
Ben Morrow
-
Steffen Kaiser
-
Thomas Leuxner
-
Torpey List