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.
> 
> 

Reply via email to