Victor Duchovni: > On Tue, Nov 17, 2009 at 01:12:26PM -0500, Wietse Venema wrote: > > > > > Apparently, owner-foo works for email addresses but not commands. > > > > That would be a bug. > > > > > > It is not easy to solve, since bounces are not sent by local(8), so > > > we would need new a queue-file with "owner-test" as the new sender, > > > but there is no secure mechanism to record a command as the recipient > > > in the queue file. > > > > What about using the bounce_one() approach? local(8) already > > solved the notification problem with mail delivery loops that way. > > It would be nice to avoid synchronous single-recipient bounces whenever > possible. With "Delivered-To:", we expect at most one such bounce per > current queue file, because the header in question is a message property. > With failure reasons other than "Delivered-To:" loops, I would prefer > to stick to indirect bounces.
You may stick to indirect bounces. Generally, I think it is a better trade-off if the mail system can solve a problem without exposing it to the user. Fewer mistakes will be made, and the current case is not a "hot" code path. Wietse > So perhaps we can avoid this code-path when the command is the *sole* > (unowned) expansion of the original queue-file recipient address. Not > sure how expensive it would to keep track of this. > > I am not a big fan of Sendmail-compatible alias semantics. Whenever > possible I arrange for *all* alias expansion to be indirect, by making > sure that $myorigin is not a local domain, and only suitably *rewritten* > (in virtual(5)) mail is handed to the local transport. > > Command expansion poses a special problem in this respect, and the > "solution" is typically to wrap-up the command in its own alias, and > use its "external" (non-local) address when delivering mail to the > command and other recipients. > > I do the same for non-command recipients also. So local(8) delivery is > always indirect at non-leaf nodes, and most lists are managed on input > via virtual alias expansion. > > -- > Viktor. > > Disclaimer: off-list followups get on-list replies or get ignored. > Please do not ignore the "Reply-To" header. > > To unsubscribe from the postfix-users list, visit > http://www.postfix.org/lists.html or click the link below: > <mailto:majord...@postfix.org?body=unsubscribe%20postfix-users> > > If my response solves your problem, the best way to thank me is to not > send an "it worked, thanks" follow-up. If you must respond, please put > "It worked, thanks" in the "Subject" so I can delete these quickly. > >