On 2013-06-24 Mon 12:34 PM |, /dev/rob0 wrote: > On Mon, Jun 24, 2013 at 03:12:24PM +0100, Craig R. Skinner wrote: > > main.cf: > > myorigin = $mydomain # example.com > > mydestination = localhost, localhost.$mydomain > > Here we see that $myorigin (nor $mydomain) is listed in > $mydestination. >
Correct - refer back to earlier messages in the last few days. > > However, aliases seems to be totally ignored. > > > > When I move these from virtual_alias_maps back to aliases, > > mail to those convential aliases bounces: > > > > aliases: > > root: admin-acct > > I don't know if this was mentioned upthread or not, but you seem to > be making a common, wrong assumption about the meaning of an > unqualified address localpart, e.g., "admin-acct" in this example. > You're probably thinking that means "deliver to the Unix user > 'admin-acct'", Yes, that's my thinking of how aliases functions. (See below.) > when in fact it means "deliver to the address 'admin-acct@$myorigin'". > If $myorigin (which you set to $mydomain) is not listed in > $mydestination, local(8) delivery is not used. > That could explain it. > Likewise, aliases(5) ($alias_maps) are only consulted for addresses > where the domain is listed in $mydestination. For you, that's only > localpart@localhost.$mydomain (or "localpart@localhost" also if you > followed Jeroen's suggestion of "append_dot_mydomain=no".) > > OTOH virtual(5) ($virtual_alias_maps) mapping is applied to all > addresses, regardless of class. > > Generally I'd say it's a best practice to always specify > fully-qualified addresses on the RHS of $alias_maps The default aliases file does not indicate that;- "The aliases(5) table provides a system-wide mechanism to redirect mail for LOCAL recipients." "Users can control delivery of their own mail by setting up .forward files in their home directory." Which seems to mean that addresses on the RHS are often Unix accounts. # The format of the alias database input file is as follows: # # o An alias definition has the form # # name: value1, value2, ... # # The name is a local address (no domain part). # # The value contains one or more of the following: # # address # Mail is forwarded to address, which is compatible # with the RFC 822 standard. Which to my reading means the RHS does not require the domain when it is a local Unix account. i.e. mail from Unix user56 to root is aliased. > > $ uptime | mail -s uptime root > > Here you have deliberately used an unqualified localpart as if it was > an email address. > Naturally. Cron, mutt, sendmail, etc must work too. Hence the local Unix accounts as opposed to a vmail setup. > > Jun 24 14:37:25 server1 postfix/pickup[29745]: C15E367DC: uid=7432 > > from=<admin-acct> > > Jun 24 14:37:25 server1 postfix/cleanup[20891]: C15E367DC: > > message-id=<20130624133725.c15e36...@server1.example.com> > > Jun 24 14:37:25 server1 postfix/qmgr[32379]: C15E367DC: > > from=<server.ad...@example.com>, size=389, nrcpt=1 (queue active) > > (Inconsistent munging, or the sender was rewritten from > admin-acct@$myorigin to server.ad...@example.com.) > No. This is entirely consistent when using sender_canonical_maps, that behaviour is expected. > > Jun 24 14:37:25 server1 postfix/error[22953]: C15E367DC: > > to=<r...@example.com>, orig_to=<root>, relay=none, delay=0.26, > > delays=0.14/0.06/0/0.06, dsn=5.0.0, status=bounced (User unknown in virtual > > alias table) > > Postfix has appended @$myorigin as documented. example.com is in > $virtual_alias_domains (as you showed), but r...@example.com either: > 1. is not listed in $virtual_alias_maps Correct, I moved root (& others) out of $virtual_alias_maps back to aliases to test if aliases was being evaluated at all. > 2. does not resolve to an address which is NOT in > $virtual_alias_domains > $virtual_alias_domains is essentially $mydomain > As mentioned above, since example.com is NOT in $mydestination (and > you must not list the same domain in more than one address class > definition), $alias_maps are not consulted. > > > From what I'm still seeing, aliases is not referenced when the > > machine's domain name is virtual. Is this significant? > > Um, yes, that's more or less what I have been saying. :) > Thanks Rob, & various people proudly promoting postfix. Previously, the pair of primary postfix developers posted remarkably similar proposed configs, with a virtual $mydomain not listed plainly in $mydestination, and both including references to aliases evaluation. But that is not my experience - as logs show in my last mail. I'll continue reading, experimenting & testing. Thanks, -- Craig Skinner | http://twitter.com/Craig_Skinner | http://linkd.in/yGqkv7
