[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
On Mon, May 08, 2023 at 12:33:31PM +1000, Sean Gallagher via Postfix-users wrote: > > [ Yes, one could also craft "classless" access(5) tables, ... and rely > >only on explicit transport(5) table entries, opting out of all the > >taxonomy that makes it easier to reason about Postfix mail routing, > >but this is not a good idea, and users advanced enough to do that > >aren't the audience for the README tutorials. ] > > With all due respect, there is no "advanced user" documentation, the > advanced users are reading the READMEs just like everyone else - or the > source code. The "advanced users" are doing OK between the README tutorials, the postconf(5) parameter docs and the source code. There's also the book by Patrick and Ralf as well as the O'Reilly book. One thing that's under-documented from an advanced user perspective is: - String, hostname and address match lists. - Which parameters are match lists and of which type. The description of match lists could be in DATABASE_README, with references from the various parameters as appropriate. Care to contribute some text? -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
Viktor Dukhovni via Postfix-users writes: > (...) > [ Yes, one could also craft "classless" access(5) tables, ... and rely > only on explicit transport(5) table entries, opting out of all the > taxonomy that makes it easier to reason about Postfix mail routing, > but this is not a good idea, and users advanced enough to do that > aren't the audience for the README tutorials. ] Hellow Viktor, I strongly agree with you, thanks! Sincerely, Byung-Hee from South Korea -- ^고맙습니다 _布德天下_ 감사합니다_^))// ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
On 5/05/2023 11:52 am, Sean Gallagher via Postfix-users wrote: While Wietse has his word processor open, I'd like to share a few of my greatest misdirects in my evolving understanding of Postfix. To quote a like minded individual I simply want to help others avoid my points of confusion, in the belief I am not a uniquirely incapable or unintelligent reader. 1) virtual_alias_maps is not only applied to virtual_alias_domains, but to _all_ domains that Pf receives mail for. http://www.postfix.org/ADDRESS_CLASS_README.html is very misleading in this respect. I really wish I had understood this earlier, it would have saved a lot of time. 2) macros in main.cf. There is a comment in the default master.cf https://github.com/vdukhovni/postfix/blob/master/postfix/conf/master.cf: # specify "smtpd__restrictions=$mua__restrictions" # here, and specify mua__restrictions in main.cf (where # "" is "client", "helo", "sender", "relay", or "recipient"). # Instead of specifying complex smtpd__restrictions here, It took too long to realize that these mua__restrictions are not builtin names but macro names, invented as required. This ability to create macros in main.cf should be documented. At the start of the http://www.postfix.org/postconf.5.html man page is a section on file syntax. That would seem an appropriate place to document this functionality. Sean. This list has become too much of a distraction for me. It seems well intentioned feedback on how to improve is not really welcomed here. I joined this list to report a bug, which has now been fixed. Many thanks Wietse. So now I am done. I thank the Postfix developers for a great product and apologize to those whose time I have wasted with my misguided posts. Warmest regards to All. Sean. -- This email has been checked for viruses by AVG antivirus software. www.avg.com___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
[ Yes, one could also craft "classless" access(5) tables, ... and rely only on explicit transport(5) table entries, opting out of all the taxonomy that makes it easier to reason about Postfix mail routing, but this is not a good idea, and users advanced enough to do that aren't the audience for the README tutorials. ] With all due respect, there is no "advanced user" documentation, the advanced users are reading the READMEs just like everyone else - or the source code. -- This email has been checked for viruses by AVG antivirus software. www.avg.com ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
On Mon, May 08, 2023 at 11:00:55AM +1000, Sean Gallagher via Postfix-users wrote: > check_rcpt_maps() in smtpd_check.c first looks for the recipient in > rcpt_canon_mapsand virt_alias_maps, that's the class-less part. Then it > classifies the recipient domain and checks the relevant recipient table > - that's the class-full part. One could also turn off recipient validation entirely, and Postfix would still have meaninful address classes, because these are the basis of transport resolution and relay control. Adding a recipient to virtual_alias_maps DOES NOT make Postfix accept mail for the recipient from untrusted senders, for that the domain would have to be listed in one of the address classes matched by permit_auth_destination. [ Yes, one could also craft "classless" access(5) tables, ... and rely only on explicit transport(5) table entries, opting out of all the taxonomy that makes it easier to reason about Postfix mail routing, but this is not a good idea, and users advanced enough to do that aren't the audience for the README tutorials. ] -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
On 8/05/2023 10:19 am, Wietse Venema via Postfix-users wrote: Sean Gallagher via Postfix-users: ADDRESS_CLASS_README: The most misleading place for me was the ADDRESS_CLASS_README For "The virtual alias domain class" it says: "Valid recipient addresses are listed with the virtual_alias_maps parameter" which is of course true, but there is nothing special about the virtual alias domain class in that respect. After reading that readme, one could be forgiven for thinking that the virtual_alias_maps would not be applied to the other domain classes. The virtual_alias_maps parameter should at least be mentioned in the recipient address text of the other domain class explanations. Perhaps another less confusing way to document it would be to describe a "class-less" mode of operation that uses just the virtual_alias_maps and transport_maps, and go on to say that class-full and class-less routing can co-exist. sorry, that class-less idea ignores the REQUIREMENT for recipient address validation. The Postfix SMTP server MUST accept only recipient addresses match the recipient table for their address class. I'm not suggesting any new functionality. I'm only describing how Pf currently works, to the best of my knowledge. check_rcpt_maps() in smtpd_check.c first looks for the recipient in rcpt_canon_mapsand virt_alias_maps, that's the class-less part. Then it classifies the recipient domain and checks the relevant recipient table - that's the class-full part. You _could_ (not saying it's a good idea) configure Pf with $mydestination, $virtual_alias_domains, $virtual_mailbox_domains and $relay_domains all empty and rely only on $virtual_alias_maps and $transport_maps and have a perfectly functional and secure system. i.e. the fully class-less path. Anyway, it was just an idea - not meant to be provocative. Sean. -- This email has been checked for viruses by AVG antivirus software. www.avg.com___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
On Mon, May 08, 2023 at 09:55:28AM +1000, Sean Gallagher via Postfix-users
wrote:
> Q: how would an entry in virtual_alias_maps like
> localpart@$virtual_alias_domains localpart@$virtual_alias_domains be
> handled?
> A: It would stay in $virtual_alias_domains and be handed to
> {$transport_maps, $default_transport} ???
No. It is handed to the "error" transport, which will bounce the
recipient.
--
Viktor.
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
Sean Gallagher via Postfix-users:
> ADDRESS_CLASS_README:
>
> The most misleading place for me was the ADDRESS_CLASS_README
>
> For "The virtual alias domain class" it says:
> "Valid recipient addresses are listed with the virtual_alias_maps
> parameter"
> which is of course true, but there is nothing special about the virtual
> alias domain class in that respect. After reading that readme, one could
> be forgiven for thinking that the virtual_alias_maps would not be
> applied to the other domain classes.
>
> The virtual_alias_maps parameter should at least be mentioned in the
> recipient address text of the other domain class explanations.
>
> Perhaps another less confusing way to document it would be to describe a
> "class-less" mode of operation that uses just the virtual_alias_maps and
> transport_maps, and go on to say that class-full and class-less routing
> can co-exist.
sorry, that class-less idea ignores the REQUIREMENT for recipient
address validation. The Postfix SMTP server MUST accept only
recipient addresses match the recipient table for their address
class.
> ADDRESS_REWRITING_README:
> Resolve address to section
>
> I think the virtual_alias_domain should be in both tables.
Sorry, that is wrong. At this point in message processing, there
are NO RECIPIENTS in a virtual alias domain.
By definition, all valid recipients in a virtual alias domain are
rewritten to a different domain class. Any addresses that are still
in a virtual alias domain are returned as 'user unknown'.
> Q: how would an entry in virtual_alias_maps like
> localpart@$virtual_alias_domains localpart@$virtual_alias_domains be
> handled? A: It would stay in $virtual_alias_domains and be handed to
> {$transport_maps, $default_transport} ???
No, absolutely not. Again, at this point there are NO recipients
in a virtual alias domain.
By definition, all valid recipients in a virtual alias domain are
rewritten to a different domain class. Any addresses that are still
in a virtual alias domain are returned as 'user unknown'.
I'll stop here.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
ADDRESS_CLASS_README:
The most misleading place for me was the ADDRESS_CLASS_README
For "The virtual alias domain class" it says:
"Valid recipient addresses are listed with the virtual_alias_maps
parameter"
which is of course true, but there is nothing special about the virtual
alias domain class in that respect. After reading that readme, one could
be forgiven for thinking that the virtual_alias_maps would not be
applied to the other domain classes.
The virtual_alias_maps parameter should at least be mentioned in the
recipient address text of the other domain class explanations.
Perhaps another less confusing way to document it would be to describe a
"class-less" mode of operation that uses just the virtual_alias_maps and
transport_maps, and go on to say that class-full and class-less routing
can co-exist.
ADDRESS_REWRITING_README:
Resolve address to section
I think the virtual_alias_domain should be in both tables.
The first to show that this is a Postfix 2.0 feature and also to link to
the virtual_alias_domains parameter and to exhaustively document the
possible input domains. The delivery method for Virtual alias can be
stated as "Not Applicable".
Q: how would an entry in virtual_alias_maps like
localpart@$virtual_alias_domains localpart@$virtual_alias_domains be
handled? A: It would stay in $virtual_alias_domains and be handed to
{$transport_maps, $default_transport} ???
The second table should include Virtual Alias to again, exhaustively
document the possible inputs. Transport sources and next hop sources are
the same as Default domain class ???.
As far as I can tell, the only difference between virtual_alias_domains
and the default domain class, is that virtual_alias_domains will bounce
recipients not in virtual_alias_maps or canonical_maps? Please correct me.
Sean.
On 8/05/2023 12:38 am, Wietse Venema via Postfix-users wrote:
Matus UHLAR - fantomas via Postfix-users:
I looked at docs (*README) and haven't found any.
I'd still prefer to explicitly note that virtual_alias_maps are applied
even for non-local e-mail
...you use "all email deliveries", I wonder if something like
"all emails processed (even non-local deliveries)" wouldn't be better.
Whether that helps depends on the reader's point of view. Som readers
e might be helped more with:
...all email deliveries (even local)...
Better, the virtual(5) text says
...all local, all virtual, and all remote...
which helps readers with all points of view.
I'll make this similar in virtual(5), aliases(5), 2x in postconf(5),
and 2x in ADDRESS_REWRITING_README.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
--
This email has been checked for viruses by AVG antivirus software.
www.avg.com
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
Matus UHLAR - fantomas via Postfix-users: > I looked at docs (*README) and haven't found any. > > I'd still prefer to explicitly note that virtual_alias_maps are applied > even for non-local e-mail > ...you use "all email deliveries", I wonder if something like > "all emails processed (even non-local deliveries)" wouldn't be better. Whether that helps depends on the reader's point of view. Som readers e might be helped more with: ...all email deliveries (even local)... Better, the virtual(5) text says ...all local, all virtual, and all remote... which helps readers with all points of view. I'll make this similar in virtual(5), aliases(5), 2x in postconf(5), and 2x in ADDRESS_REWRITING_README. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
On 05.05.23 11:52, Sean Gallagher via Postfix-users wrote: >While Wietse has his word processor open, I'd like to share a few of >my greatest misdirects in my evolving understanding of Postfix. > >To quote a like minded individual > >I simply want to help others avoid my points of confusion, in the belief I >am not a uniquirely incapable or unintelligent reader. > >1) virtual_alias_maps is not only applied to virtual_alias_domains, >but to _all_ domains that Pf receives mail for. >http://www.postfix.org/ADDRESS_CLASS_README.html is very misleading in >this respect. I really wish I had understood this earlier, it would >have saved a lot of time. Matus UHLAR - fantomas via Postfix-users: I had this problem too and I think that explicitly stating something like: On 05.05.23 10:34, Wietse Venema via Postfix-users wrote: The problem is that this information exists in some places but not all places where aliasling is discussed. This should not be a problem. New text for postconf(5): virtual_alias_maps (default: $virtual_maps) Optional lookup tables with aliases that apply for all email deliveries, unlike alias_maps that apply only for local(8) delivery. [...] alias_maps (default: see "postconf -d" output) Optional lookup tables with aliases that apply only for local(8) delivery, unlike virtual_alias_maps which apply for all email deliveries. [...] New text for ADDRESS_CLASS_README: Virtual aliasing Note: virtual aliasing (virtual_alias_maps) applies for all email deliveries, unlike local aliasing (alias_maps) which applies only to local(8) delivery. Local alias database Note: local aliasing (alias_maps) applies only for local(8) delivery, unlike virtual aliasing (virtual_alias_maps) which applies for all email deliveries. Are there any other placs that need to bve updated? I looked at docs (*README) and haven't found any. I'd still prefer to explicitly note that virtual_alias_maps are applied even for non-local e-mail ...you use "all email deliveries", I wonder if something like "all emails processed (even non-local deliveries)" wouldn't be better. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Due to unexpected conditions Windows 2000 will be released in first quarter of year 1901 ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
Matus UHLAR - fantomas via Postfix-users: > On 05.05.23 11:52, Sean Gallagher via Postfix-users wrote: > >While Wietse has his word processor open, I'd like to share a few of > >my greatest misdirects in my evolving understanding of Postfix. > > > >To quote a like minded individual > > > >I simply want to help others avoid my points of confusion, in the belief I > >am not a uniquirely incapable or unintelligent reader. > > > >1) virtual_alias_maps is not only applied to virtual_alias_domains, > >but to _all_ domains that Pf receives mail for. > >http://www.postfix.org/ADDRESS_CLASS_README.html is very misleading in > >this respect. I really wish I had understood this earlier, it would > >have saved a lot of time. > > I had this problem too and I think that explicitly stating something like: The problem is that this information exists in some places but not all places where aliasling is discussed. New text for postconf(5): virtual_alias_maps (default: $virtual_maps) Optional lookup tables with aliases that apply for all email deliveries, unlike alias_maps that apply only for local(8) delivery. [...] alias_maps (default: see "postconf -d" output) Optional lookup tables with aliases that apply only for local(8) delivery, unlike virtual_alias_maps which apply for all email deliveries. [...] New text for ADDRESS_CLASS_README: Virtual aliasing Note: virtual aliasing (virtual_alias_maps) applies for all email deliveries, unlike local aliasing (alias_maps) which applies only to local(8) delivery. Local alias database Note: local aliasing (alias_maps) applies only for local(8) delivery, unlike virtual aliasing (virtual_alias_maps) which applies for all email deliveries. Are there any other placs that need to bve updated? Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
On 05.05.23 11:52, Sean Gallagher via Postfix-users wrote: While Wietse has his word processor open, I'd like to share a few of my greatest misdirects in my evolving understanding of Postfix. To quote a like minded individual I simply want to help others avoid my points of confusion, in the belief I am not a uniquirely incapable or unintelligent reader. 1) virtual_alias_maps is not only applied to virtual_alias_domains, but to _all_ domains that Pf receives mail for. http://www.postfix.org/ADDRESS_CLASS_README.html is very misleading in this respect. I really wish I had understood this earlier, it would have saved a lot of time. I had this problem too and I think that explicitly stating something like: virtual_alias_maps (if set) expansion is applied to all recipient addresses, even if they aren't local, so this way it's possible to redirect mail for remote recipients would help much. Also, mentioning the main difference between virtual_alias_maps (applied at input) and alias_maps (applied at delivery, supporting :include:, pipe and file destinations just as owner- prefix) would be nice to have. Especially since it's advised to move address expansion from aliases to virtual_alias_maps when possible to avoid double deliveries for problematic destinations. 2) macros in main.cf. There is a comment in the default master.cf https://github.com/vdukhovni/postfix/blob/master/postfix/conf/master.cf: # specify "smtpd__restrictions=$mua__restrictions" # here, and specify mua__restrictions in main.cf (where # "" is "client", "helo", "sender", "relay", or "recipient"). # Instead of specifying complex smtpd__restrictions here, It took too long to realize that these mua__restrictions are not builtin names but macro names, invented as required. This ability to create macros in main.cf should be documented. At the start of the http://www.postfix.org/postconf.5.html man page is a section on file syntax. That would seem an appropriate place to document this functionality. agree. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Quantum mechanics: The dreams stuff is made of. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
