On Sun, Jan 21, 2024 at 11:35:39PM +0100, Simon Hoffmann via Postfix-users
wrote:
> > DO NOT use the deprecated "virtual_domains" parameter, it mixes
> > classification of domains with address mappings.
>
> I have read that and I thought I understood it.
Simply put, use "virtual_alias_domains" to enumerate any virtual alias
domains, and "virtual_alias_maps". DO NOT reply on the
backwards-compatible (with Postfix 1.x 20+ years ago) default value of
"virtual_alias_domains":
virtual_alias_domains = $virtual_alias_maps
Instead, set "virtual_alias_domains" explicitly, either empty or a
non-empty list of such domains.
> I have also read http://www.postfix.org/VIRTUAL_README.html and this states
> that with
> virtual alias mode I can have the same local part in an email address and
> deliver
> them to different unix users,
You're not reading on its own merit, rather letting your prior
expectations obscure the message. Try to forget everything you know
about the OpenSMTP virtual table as a model of what virtual mappings do,
all you should carry forward is an understanding of the functionality of
the individual lines that you want to translate in a suitable manner to
Postfix.
The Postfix virtual(5) table is *very* different, and to avoid
confusion, on this list, lets reserve virtual table for the Postfix
version, and your OpenSMTPd configuration file is just some file
with lines that implement various behaviours which you'll want to
match one line at a time...
Note:
0. The virtual(5) mapping applies to ALL envelope recipient addresses,
regardless of address class. The domainpart does not need to be
listed in virtual_alias_domains!
1. The virtual(5) table is a 1-to-many mapping of input rfc822 recipient
addresses to output *addresses*. Nothing you put on the RHS of
the *Postfix* virtual(5) file directly causes deliveryu to some
file or to a user, or causes a recipient to be rejected...
2. virtual(5) is JUST a one-to-many address mapping.
3. On the RHS, bare "localpart" addresses with no domain part are
implicity rewritten to "localpart@$myorigin"
4. The mapping is recursive! Each RHS value is again subject to
virtual(5) rewriting, until there's no match, or an address
maps to itself (after appening @$myorigin if necessary).
5. Input adresses with a domain part that matches "$myorigin"
that don't match as-is, are retried with just the localpart
as a lookup key, but the termination check (self-mapping) is
based on the full input address.
Sepately, Postfix supports virtual_alias_domains, which cannot hold any
directly deliverable mailboxes, instead, each address in such a domain
must be rewritten to some list of addresses in other domains.
> but i can still use local unix users.
You want to see "unix users" on the RHS of the table, but what's there
are email address localparts, that get an implicit domain when none is
explicitly specified.
> The first method on that page does not allow me to route
> localp...@domain1.com to a different user than localp...@domain2.org
This is wrong. You can map any address to some list of addresses.
With virtual(5), just write:
us...@domain1.com us...@domain.org
> (with the exact same localpart) and the third mode on that page does
> not use unix users and their home directory to store mails but just a
> directory structure, which is also not what i want.
With virtual_mailbox_domains you can indeed to deliver to logical users
that aren't tied to system accounts. You may need to get a copy of the
Postfix book by Patrick Koetter and Ralph Hildebrandt and spend a few
days reading the background topics.
You need to understand local(8) delivery, and virtual(8) delivery or
delivery via an LDA or LMTP to some appropriate mail store.
> > It is best to not use the same terminology for two different things.
> > Instead let go of the old terminology and focus on function.
>
> The file that maps an email address to a unix user or another email address
> in OpenSMTPd
> is literally stated in the config with the keyword "virtual".
This is actually a big part of the problem. You need to let go of the
diea that these serve the same function. They don't.
> > Actually to simon@$myorigin, which may or may not go to the UNIX user,
> > depending on how that's handled.
>
> With the information from http://www.postfix.org/VIRTUAL_README.html I
> understand
> that this line means that this email address is delivered to the unix user on
> the
> RHS. Why would I need to specify a domain on the RHS if i want the unix user
> simon to
> get the mail?
No. It is delivered to wherever that address happens to be routed,
which depends on the transport to which the address is resolved, which
depends on the domainpart's address class or matching data in the
transport(5) table.
> Or is specifying @$myhostname the actual (and only?) way to tell
> postfix to deliver to the local user?
You can deliver any address of your choice via local(8) by adding a
transport entry:
localpart@domain.example local
By default, domains listed in $mydestination are handed off to
$local_transport, which defaults to "local".
> With that in mind, i am using sieve rules in dovecot and require the mails to
> be
> delivered to dovecot via lmtp.
So you mostly don't need local(8) unless your users expect to be able to
take advantage of procmail, dotforward files, ...
> Upon reading the docs again just now it seems that I have to use
> virtual domains mode and virtual_mailbox_domains
You don't have to, you can instead specify "mailbox_transport" or
similar if you want to first optionally use local aliases(5), and/or
dotforward files.
You're not well prepared for the migration. You have some reading to
do... Come back once you've read the core chapters.
> virtual_mailbox_maps to be able to use virtual_transport, which in my
> understanding is the only way to hand mail off to dovecot.
It isn't.
> The site also states to add the domain to the virtal_alias_domains, by the
> way.
> Is the documentation wrong?
No, but you've left out essential context for that advice. It applies
when implementing a virtual alias domain, and not otherwise.
You need to read the book, and set up simple examples on a test machine
to test your understanding. Your experience with OpenSMTPd is more of
a hindrance than a help.
--
Viktor.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
