On Wed, May 25, 2016 at 10:00:55PM +0200, Dirk wrote:

> Which user to what maildir is definend in.
> virtual_mailbox_maps = hash:/etc/postfix/vmaps
> 
> The second (sub)domain has not fixed user assignment. The users must
> match an regex defined as well in
> virtual_mailbox_maps = regexp:/etc/postfix/vmaps-regex

Presumably, you have:

    virtual_mailbox_maps =
        hash:/etc/postfix/vmaps,
        regexp:/etc/postfix/vmaps-regex

to accomplish both.  Right?

What kind of mappings happen in that regexp table?  Sure you can
the mail delivered to some maildir or other, but how are users able
to read the mail?  Presumably dovecot still needs to know about
the mailboxes created by virtual(8) so it can grant access to them
to suitably authenticated users via IMAP.

> But now I would like to use sieve with dovecot.

For both domains?  Or just one of them?

> Therefore I would have to enable
> #virtual_transport = lmtp:unix:private/dovecot-lmtp

Fine, now the LMTP recipient needs to be a recipient name known to
dovecot, but that's not much different from the requirement that
dovecot be able to associated users with mailboxes for IMAP.

So you've not explained your problem in sufficient detail.

> [private/dovecot-lmtp] said: 550 5.1.1 <test.d...@x.domain1.com> User doesn't 
> exist: test.d...@x.domain1.com (in reply to RCPT TO command)

Well dovecot does not know about that mailbox.  Deliver to a mailbox
that dovecot does know about.  You'd typically use virtual_alias_maps
for that.

> It would maybe solve my probelm if I could enable the virtual_transport
> only for domain1.com not x.domain1.com.

You can certainly use the transport(5) table to direct either domain
to a different transport, but it is not clear that this is the right
approach.

        http://www.postfix.org/ADDRESS_REWRITING_README.html
        http://www.postfix.org/ADDRESS_CLASS_README.html
        http://www.postfix.org/virtual.5.html
        http://www.postfix.org/postconf.5.html#virtual_alias_maps
        http://www.postfix.org/postconf.5.html#transport_maps

-- 
        Viktor.

Reply via email to