Hi Hum ... this conversation has alerted me to the possibility that virtual_alias_maps has two different roles ... I am/have_been confused on this despite spending weeks pondering the documentation. Is the following summary correct and complete? If so, then the proposed additions to postconf.5 and and changes to virtual(5) would have made this newbie's life easier.
On Mo, 2016-10-31, at 23:17, Viktor Dukhovni <postfix-us...@dukhovni.org<mailto:postfix-us...@dukhovni.org>> wrote: On Oct 31, 2016, at 10:49 PM, Bill Cole <postfixlists-070...@billmail.scconsult.com<mailto:postfixlists-070...@billmail.scconsult.com>> wrote: So: on what basis would you expect virusal...@covisp.net<mailto:virusal...@covisp.net> to be mapped as a virtual alias? You've told Postfix that covisp.netis a local domain and that only kreme.com<http://kreme.com> addresses should be mapped via virtual aliases. I don't see how this can ever work... Bill, you're quite wrong there. The virtual(5) alias rewriting applies across all address classes, as is evident from some of the logs the OP posted. SUMMARY: 'virtual_alias_maps' applies only to 'envelope recipient' addresses providing: 1) rewriting for all address classes and all submission methods. 2) validation for only 'virtual_alias_domains' for only submission via smtpd 3) disabled validation for 'virtual_alias_domains' if set to null (relevant for smtpd_proxy_filter) 4) the only parameter that can hook in virtual(5) tables This implies it: 5) is not used to validate any other address class except the virtual_alias class 6) does no validation for submission methods other than via smtpd 7) does no validation or rewriting of 'envelope from' or message headers. QUESTION: Is this both correct and complete? (3 is likely incorrect) DOCUMENTATION SUGGESTIONS: As feed back to the postfix project, in most cases postconf.5 seems to be the goto for a complete enumeration of the purpose of a parameter sometimes with useful links to more details and nuances. Sometime however ... In the present case I never picked up on the fact that virtual_alias_maps had two different roles with very different scopes of application. At best I'd have said two different roles with the same (narrow) scope similar to Bill's comment. My life as a newbie would have been much easier if ... : A) ... [postconf.5 virtual_alias_maps] had clearly stated points 1, 2, 3 & 4 above. Currently it only sort of mentions (1-rewrite), in what I now might interpret as pre-address class language. It did not provide my early understanding enough traction to get started. Part of that was because I was sort of aware that there were validation and rewrite roles but they were never laid out together on the same screen so it never clicked as being the same parameter rather than different parameters. My experience has been that I've needed to scan all of the postfix documentation, find the scattered relevant pieces, figure out their relation and deduce from them what is key, which has been hard since I don't yet have a full gestalt of how postfix works. Discovering that 3 & 4 were even topics was almost by luck. My colleagues here at work have declined to put in that level of effort. This proposed documentation change would have made that level of effort unnecessary. B) ... [virtual(5) Description] had stated both 1 & 2 in its first sentence. Currently it states (1-rewriting) very clearly and nicely. And while it does eventually mention (2-validation), that is only near the bottom of that document in the middle of describing the detailed format of a virtual table. My experience has been, some time later after my first read through, I'd say 'I've seen something about that somewhere ...' and go looking and not find because I was expecting the key points to be at the top of the document, or at least before the document started going in to details, so I'd skim the top, conclude (incorrectly) it was not there, and move on, missing it. C) ... [virtual(5) Configuration Parameters] had clearly stated 4 Regards, Todd Olson Cornell University
