try using -d ${recipient}, but change the format of the username in
dovecot.conf
What i did was to set the mail attribute for each user in AD, then
perform a query for it and have dovecot group users by domain, this
way i can have user1@example.net and user1@example.com
Thanks
Romer Ventura
On May 10, 2010, at 3:56 PM, Phil Howard wrote:
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.