On Thursday 22 April 2010 15:34:40 Phil Howard wrote:
So what would local_recipient_maps look like in this case?
As the suggested setup uses virtual_mailbox_domains for the mailboxes hosted by dovecot, it would be virtual_mailbox_maps. Alternatively one could define relay_domains, relay_transport and relay_recipient_maps. local_recipient_maps is for use with mydestination and system (/etc/passwd) users only. But this aspect is indeed missing in Thomas' suggestion.
At this point, I don't understand what is happening for this. I would be expecting Postfix to be asking Dovecot if a user is valid.
This is not directly possible as there is no postfix lookup table that can query any protocol that dovecot speaks. Neither is there one for the passwd- file format.
Instead of a lookup table one could theoretically use reject_unverified_recipient as described in the Postfix ADDRESS_VERIFICATION_README but I don't know if it works with any non-SMTP transport for the destination domain. I can't tell from the first reading, and have no time to explore that.
Otherwise there's no choice but to generate a hash/btree/cdb file from the dovecot passwd-files for use in virtual_mailbox_maps.
mailbox_command = /usr/lib/dovecot/deliver
in Postfix main.cf. Is that workable instead of "virtual_transport = lmtp:unix:private/dovecot-lmtp" Or would running LMTP be a better way?
If you can't wait for Dovecot 2.0, you need to use dovecot deliver, but you should set it up as a pipe transport in master - see http://wiki.dovecot.org/LDA/Postfix for virtual users. mailbox_command again is for real system users only.
Rainer