Hi Viktor,
On Mon, 6 May 2019, Viktor Dukhovni wrote:
In most cases virtual(5) is superior to aliases(5), but you still
need it for mailman and pipes, so you'd rewrite those to localhost
(or some suitable domain listed in mydestination).
Right. Good point. Something to keep in mind.
To paraphrase my understanding than:
If a domain is not listed in any other class, it needs to be listed in
virtual_alias_domains. virtual_alias_maps rewrites are being applied to
incoming mail regardless of the class however.
Well, it needs to be listed if you want to accept inbound mail and
your only choice is rewriting to some underlying domain. Yes,
rewriting happens either way.
Thanks for confirming. And of course, I'd eventually would like to accept
mail at some point after the rewriting. :-)
I was hoping to get away from the rewrites. Especially as I'd like people
to be able to login to the imap server with their email-address, e.g.
u...@example.org. That prevents a lot of confusion on the user side...
.invalid would probably make things weird...
The recipient envelope has nothing to do with how users log in, or
which mailbox they see. Mapping of users to mailboxes is up to the
IMAP server. In some cases, you can also rewrite back to the original
address via smtp_generic_maps, but it is often not needed, since the
IMAP server can perform the relevant mappings.
You are correct. Let me rephrase:
Ideally I'd like to be able to receive mail and use the same address as an
LMTP destination and have delivery work. That way the logic is very simple
and people only have to add one entry somewhere rather than multiple
entries to keep rewriting in mind.
I do believe that is possible... I need to do some tests though with my
setup... Preferably on a copy of that mailserver...
If a domain has at least one virtual_mailbox user, add it to the
virtual_mailbox_domains list and remove it from virtual_alias_domains or
relay_domains.
And also mydestination.
Right. I forgot about that part. That would mean moving my users from
local to virtual mailbox delivery should happen first.
Add all virtual_mailbox users under the mydestinations domain to the
local_recipient_maps for now.
At which point, no need for local_recipient_maps for that domain.
That's only for domains where all the users are local or aliased.
True, once everyone is moved to virtual mailbox, that makes a lot of
sense.
If I stay with local delivery, I'd probably still need that though. But it
seems to me that moving to virtual mailboxes is the right approach
actually.
In that setup transport_maps would still be consulted, right?
Always consulted, unless the final recipient is in a virtual alias
domain, in which case the recipient is bounced.
Thanks for clarifying. That is already taken into account in my current
setup I believe.
So the plan now is:
1. Take care of the pipe delivery in /etc/aliases and ensure that they
will get mail in the future under e.g. u...@hostname.example.com. Use
virtual_alias_maps for that.
2. Migrate the dovecot users currently on local to virtual mailbox
delivery. Remove example.com from mydestinations and move it to
virtual_mailbox_domains.
3. Migrate other domains with at least one virtual_mailbox user from
the current virtual_alias_domains to virtual_mailbox_domains.
I think this should work. Thanks a lot for being my sounding board. That
was very helpful.
There's one thing I noticed though in my setup which would probably be
affecting the move from local to virtual mailbox delivery:
Right now I have a bunch of mailroutes in the form of either foo -> bar
which work fine as example.com is part of mydestinations so mail to
f...@example.com gets correctly rewritten to bar and sent onwards to the
LMTP socket as b...@host.example.com as append_at_myorigin is set to yes.
Due to a configuration error on my part on the Dovecot side that worked
fine. I have all users in an SQL database and my SQL query would always
return u...@example.com regardless of the input. e.g.
u...@host.example.com as a lookup key would return u...@example.com as the
dovecot user due to me getting the SQL query wrong...
Once I fixed the query I was getting errors about unknown users, because
of course u...@host.example.com was an invalid user. u...@example.com
would have been the right field.
I see multiple ways of fixing that problem:
1. Change the SQL query on the dovecot side to also consider
host.example.com a valid domain part.
2. Change append_at_myorigin to no and set append_dot_mydomain to yes.
3. Change my virtual_alias_maps to not use bare usernames (e.g. user) but
always fully qualified ones including domain names (e.g.
u...@example.com).
What would be your preferred solution? 1. would be the easy fix. 2. seems
cleaner but I am not sure about any side effects. 3. would be the most
work but I fear this might be necessary anyway for moving from local to
virtual mailboxes for my main domain...
Any suggestions?
cheers,
Andreas
