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

[Phil Howard]

On Mon, May 10, 2010 at 15:58, Jerry <dovecot.user at seibercom.net> wrote:

>
> See: http://wiki.dovecot.org/LDA/Postfix
>
> Be sure to read the entire page.
>

I have a few times.  But now I'm getting a bit of a different perspective on
part of it.  The parameters are:

-d <username>: Destination username. If given, the user information is
looked up from dovecot-auth. Typically used with virtual users, but not
necessarily with system users.
-a <address>: Destination address (e.g. user+ext at domain). Default is the
same as username. (v1.1+ only)

Well, that was actually confusing. I was passing the address via -a instead
of -d because -d was described as username.  That, and I know that the first
cases of "virtual users" (in sendmail and earlier postfix) was actually just
a twisted variant of system users, where the left hand side of @ was used
alone, and it didn't support distinct domains (e.g. bob at example.com and
bob at example.net were both just bob ... even if not the same as bob in
/etc/passwd).  And that's why I didn't use -d because in my case, I do have
different domains, where fred at example.com and fred at example.net are different
people.  So they are separate mailboxes and separate IMAP and submit
logins.  Oh, and their passwords may be different, too :-)

It's easy to continue to tie in virtual users to system users when
uniqueness is only on the LHS.  So if jerry at example.com and
jerry at example.net are the same user, and likewise for all users, then
storing the password in /etc/passwd or /etc/shadow suffices (for those not
wanting to use LDAP, SQL, etc).  But when the users need to be different
across different domains, even though the LHS is the same, now we have
issues with connecting them to system users.  And I have seen people map
username at domainname to someothername to lookup in /etc/passwd (that would be
a nightmare) or just put username at domainname in /etc/passwd (not sure how
well that would work).

But there is more than one semantic for "virtual users".  I believe I have
seen at least four.  In my case it will be unrelated to system users in
/etc/passwd or the setuid() or seteuid() calls.  Security will depend on the
mail application codes, not the underlying OS, to keep one user out of
another's mailbox (or sieve scripts,etc).


> > So what is virtual_minimum_uid doing for you if virtual_uid_maps is
> > static? Or why are any of these even relevant if everything is being
> > piped to a process started via master.cf?
>
> Not really sure. I was told it has something to do with Postfix itself.
>

The description of virtual_minumum_uid seemed to suggest that it was a bound
applied to what you get from virtual_uid_maps in case something was bad in
the map.


> > And (problem I posted in a separate thread) does %d get assigned
> > correctly with the domain name for mail_location = if this method of
> > running dovecot/deliver is used?
>
> You can either try it or perhaps ask on the Postfix forum.
>

Maybe it's related to -d vs -a in dovecot/deliver.  Postfix was sending the
full user at domain to dovecot/deliver, and the %d should have been filled in
from that by dovecot/deliver.  But I was using -a and that may be wrong.
I'll try with -d instead.  Now I get a new error I didn't get before:

Error: Can't connect to auth server at /var/run/dovecot//auth-master:
Permission denied

It's not really clear how it is that worked before.