On Mon, May 10, 2010 at 15:58, Jerry dovecot.user@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@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@example.com and bob@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@example.com and fred@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@example.com and jerry@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@domainname to someothername to lookup in /etc/passwd (that would be a nightmare) or just put username@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@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.