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:[email protected]?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.
>
>
