[Dovecot] dovecot/deliver ... Can't open log file /var/log/dovecot/error.log: Permission denied

[Noel Butler]

On Tue, 2010-05-11 at 16:17 -0400, Phil Howard wrote:

> On Tue, May 11, 2010 at 14:38, Bradley Giesbrecht <
> bradley.giesbrecht at gmail.com> wrote:
> 
> >
> > On May 11, 2010, at 11:26 AM, Phil Howard wrote:
> >
> >  On Tue, May 11, 2010 at 12:59, Gerard Seibert <dovecot.user at seibercom.net
> >> >wrote:
> >>
> >>  Virtual documentaion: http://www.postfix.org/virtual.8.html
> >>>
> >>>
> >> This seems to be a delivery agent of its own.  I don't want Postfix to do
> >> the delivery.  I want Dovecot to do the delivery so it can create the
> >> additional cache/index files (whatever they were ... Dovecot documentation
> >> encourages this).  So that means handing it off to the
> >> /usr/lib/dovecot/deliver program.
> >>
> >
> > Basically postfix just needs to know that a username/email address is local
> > and how to deliver.
> >
> 
> And it did seem to do that already.  Mail was sent to dovecot/deliver.  It
> included the domain name.  But deliver just didn't construct the
> mail_location correctly due to %d being empty.  The resulting path with the
> empty space where the domain name should have been was used to actually
> deliver the mail.  I read that file and the domain name was also in the
> headers.  The domain was there, but %d didn't get it.
> 
> 

interesting...

%d is derived from the right hand side of a username, dovecot's deliver
couldn't care less about verifying the domain, since that is the MTA's
job.






> > If you are using virtual users in main.cf this works for me.
> > virtual_transport                    = dovecot
> 
> 
> > In master.cf this works for me.
> >
> > dovecot          unix    -    n    n    -    -    pipe
> >    flags=DRhu user=_vmail:_vmail argv=/opt/local/libexec/dovecot/deliver -d
> > ${recipient}
> >
> 

Brad et al, you'd also might want to consider adding in -e as well,
before  -d to handle tempfails nicer


> I tried it, but effectively, nothing happened.  Maybe the other virtual_*
> stuff also needs to be configured.  I've used that virtual_* stuff before


it certainly does



> 
> I'm using "passwd-file" to authenticate, and mail_location = to compose a
> pattern of where each maildir will be found.  I won't be using a backend
> database (that's the last thing I want to do).
> 


why not? it simplifies virtual users, you're trying to use a method
primarily designed for system accounts, as demonstrated over the past
several days you are only giving yourself pain for no reason.



> 
> I got the log file working.  I had to tell Postfix to run dovecot/deliver as
> user:group vmail:vmail and that did it.  It WAS running dovecot/deliver as
> some user whose name just happened to match (even though the mail didn't
> belong to the person who had that system account).
> 
> I'm looking over the Postfix virtual_* stuff again.  Maybe there's new stuff
> since I last did Postfix about 6 years ago or so.
> 
> Summary of what I want to accomplish:
> 


and it would be all solved using MySQL in 15 minutes (OK, maybe an hour
if you don't know what your doing) but here you are days later and no
further, even if it takes you 4 hours converting users and moving mail
etc, it has to be better use of your time then you are getting now.

It takes only a few minutes to write a perl script to read a passwd file
and insert into a backend DB. I did one a couple years ago to convert a
qmail/vpopmail ystem, using CDB filees, to postfix/dovecot/mysql, the
biggest time consumer was copying all of the mail to its new structured
location.

I hope you are your own employer, because if you worked for someone
else , they should be demanding an explanation for all the time wasting,
that's not a personal attack, it is pure reality.