[Dovecot] From Sendmail to Dovecot mdbox, what is missing.

Ben Morrow ben at morrow.me.uk
Tue Jan 1 18:54:11 EET 2013

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.
> >If you want to keep INBOX delivery to mboxes in /var/mail,
> 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')
> >> 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).
> 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

> 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.


More information about the dovecot mailing list