Viktor Dukhovni via Postfix-users wrote:

> On Sun, Jan 21, 2024 at 07:21:26PM +0100, Simon Hoffmann via Postfix-users 
> wrote:
> 
> > The old virtual_domains file just lists all domains (one per line), and can 
> > directly be used in
> > virtual_alias_domains.
> 
> You're going about this the wrong way, by tryign to translate low-level
> artefacts from one system to somewhat related, but different low-level
> artefacts in Postfix.  Instead you need to implement a functional at a
> higher layer.
> 
> Postfix support virtual alias rewriting (for all envelope recipient
> addresses), and virtual alias domains (which make rewriting mandatory,
> since there are no actual mailbox recipients in the domain, just aliases
> to mailboxes in *other* domains).
> 
> You need to read and understand:
> 
>     - ADDRESS_CLASS_README
>     - ADDRESS_REWRITING_README
>     - The virtual(5) manpage
>     - The postconf(5) descriptions of:
>         * virtual_alias_domains
>         * virtual_alias_maps
> 
> 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.

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, but i can still use local unix users.
The first method on that page does not allow me to route [email protected] 
to a
different user than [email protected] (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.


> 
> > However, in my virtual aliases table on OpenSMTPd, I have the following 
> > line-types
> 
> 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".



> 
> > [email protected]         simon
> >
> > The first line is obvious. Mail addressed to the email address is delivered 
> > to the
> > UNIX user.
> 
> This is an address mapping, best practice is to also specify a domain on
> the RHS, which by default gets qualified with "@$myorigin", but if you
> have a specific domain in mind, specify it here.
> 
> 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?

Or is specifying @$myhostname the actual (and only?)  way to tell postfix to 
deliver to the local
user?


<added at the end of composing this email>
With that in mind, i am using sieve rules in dovecot and require the mails to be
delivered to dovecot via lmtp. Upon reading the docs again just now it seems 
that i
have to use virtual domains mode and virtual_mailbox_domains and 
virtual_mailbox_maps
to be able to use virtual_transport, which in my understanding is the only way 
to
hand mail off to dovecot. 
I think i just broke my brain and need to pause for a few weeks before trying to
understand the config again ^^
</end>



The site also states to add the domain to the virtal_alias_domains, by the way.
Is the documentation wrong?


> 
> > @list.simonhoffmann.net         simon
> >
> > The second line is also obvious, as this is a catchall for a domain. In 
> > Postfix this
> > has also the lowest priority so I don't break my current alias file.
> 
> Catchalls are best avoided.  If you have a specific list of valid
> addresses, best to specify each one.


Well for one i am lazy and dont want to edit my map all the time. :)
Secondly, aside from getting more spam (which i can live with), why is it best 
to
avoid a catchall?


> 
> > simon                           simon
> 
> > For the third line, the documenation under 
> > http://www.postfix.org/virtual.5.html
> > specifies
> 
> You're looking at the wrong documentation, that line from OpenSMTPD,

What would be the right documentation? Above you asked me to read virtual(5)...



> what is supposed to achieve?  Then figure out whether it is needed,
> and how to get equivalent *functionality* (not syntax) from Postfix.
> 
> > So I am not sure if this would work and the third line would be an accepted 
> > line or
> > if I need to replace this line with a user@domain line for every virtual 
> > domain.
> 
> What is the "simon" entry supposed to achieve?  How does it augment the
> functionality of the first line?


on OpenSMPTd, this line translates to simon@ALL_DOMAINS deliver to unix user 
simon.

I actually use this for myself, hostmaster, postmaster, webmaster, abuse, ...
addresses in my config file so that these addresses always get accepted and i 
dont
need to remember to add a domain specific entry for these addresses if a add a 
new
domain to the server.


> 
> > [email protected]       /dev/null
> > The fourth line in the old alias file silently discard a mail.
> 
> Postfix virtual(5) aliases are (rfc822) address-to-address mappings.
> You cannot use "/dev/null" or similar here.  That's a feature of local
> aliases(5).  But far better:
> 
>     valias:
>         [email protected]       [email protected]
> 
>     transport:
>         discard.invalid                 discard:silently
>     
>     master.cf
>         # Should already have a "discard" transport

ah okay, i see the pattern here, thanks.


> 
> > [email protected]          error:550 no spam here!
> >
> > Lastly, the fifth line bounces the email with the given error code and
> > the given message. I have used this to disable specific address on an
> > otherwise catch all domain. The spam example above is only an example,
> > I have used this for address that were previously used but are not any
> > longer and I would like the sender to know that this address is no
> > longer in use. Is something like this possible as well?
> 
> This goes in the transport(5) file, better as:
> 
>     [email protected]          error:5.1.1 Mailbox unavailable

yeah now that i saw the pattern from the line above, i figured as much :)


> 
> and/or an access(5) table with "check_recipient_access":
> 
>     main.cf:
>         indexed = ${default_database_type}:${config_directory}/
>         transport_maps = ${indexed}transport
>         smtpd_recipient_restrictions =
>             check_recipient_access ${indexed}rcpt-access,
>             permit_mynetworks,
>             reject_unauth_destination,
>             ...
> 
>     rcpt-access:
>         [email protected]  REJECT 5.1.1 Mailbox unavailable

oh yeah right, thanks

> 
> > And then I have read the following in the documentation:
> > 
> > /etc/postfix/virtual:
> >            virtual-alias.domain    anything (right-hand content does not 
> > matter)
> 
> That's backwards compatibilty with the legacy "virtual_domains"
> parameter, which you won't use. :-)

interesting, because in the docs this is directly under 
/etc/postfix/main.cf:
           virtual_alias_maps = hash:/etc/postfix/virtual

which i interpret as "the docs first show me the main.cf part, then the content 
of
the file referenced in main.cf" which for me means i need this because the line 
above
the main.cf part says "Support for a virtual alias domain looks like:" and from
VIRTUAL_README i have learned that i want virtual alias domains.

So either I am to stupid to read the documentation (which is interesting 
because i
have several postfix servers running in virtual mailbox mode with an sql 
backend that
holds user accounts and aliases) or the documentation is out of date (i doubt) 
or the
documentation is not as intuitive as hoped :)


Thanks!

Cheers, 

Simon

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to