Wietse Venema:
> Wietse Venema:
> > Victor Duchovni:
> > > On Thu, Sep 23, 2010 at 07:26:59PM -0400, Wietse Venema wrote:
> > >
> > > > More sensibly, it seems safe to skip the RESET_OWNER_ATTR() operation.
> > > > That code is a remnant of a very early attempt to attribute bounces
> > > > very accurately, and may be creating more problems than it solves.
...
> > RESET_OWNER_ATTR() is more destructive - it will remove the owner
> > attribute when a sub-alias has no owner-alias. This is really old
> > code and I don't remember the fine details of what led me to this
> > some 12 years ago.
>
> Found it. Immediately before the code that decides to save recipients
> to a new queue file depending on the owner attribute value is this
> comment:
>
> * The code below must not trigger on mail sent to an alias that has no
> * owner- companion, so that mail for an alias first.last->username is
> * delivered directly, instead of going through username->first.last
> * canonical mappings in the cleanup service. The downside of this
> * approach is that recipients in the expansion of an alias without
> * owner- won't have separate delivery queue file status records, because
> * for them, the message won't be resubmitted as a new queue file.
>
> The idea here is that we have the equivalent of:
>
> /etc/aliases:
> # Note: no owner- alias.
> first.lastname: unixlogin
>
> /etc/postfix/canonical:
> unixlogin first.lastname
>
> Even then, when a mailing list does the equivalent of:
>
> /etc/aliases:
> listname: first.lastname, ...
> owner-listname: whatever
>
> what happens is that first.lastname is put into a new queue file,
> and when that queue file is delivered, the first.lastname->unixlogin
> alias expands without any mailing list owner attribute around, so
> this will not loop even when I remove the RESET_OWNER_ATTR()
> operation for an owner-less "first.lastname" alias.
As a follow-up, I ran a few checks with .forward files that contain
the recipient itself or a local alias for that recipient. This also
delivers properly without the the RESET_OWNER_ATTR() operation,
both with direct mail to the recipient, and with mail through an
alias with or without an owner- alias.
At this point I think I know why Postfix used RESET_OWNER_ATTR()
for an owner-less local alias (i.e. to avoid writing recipients to
a new queue file and going into a loop). There is also evidence
that this step is not needed even when the recipient was a member
of a mailing list alias with a proper owner- alias, because the
new queue file effectively stripped the mailing list owner attribute.
I will mull over this for a week and then add a compatibility switch
between the old behavior (off by default) and what appears to be
the more desirable behavior (on by default). This would be similar
to the Postfix 2.3 frozen_delivered_to option which should be safe
to remove five years after its introduction.
Wietse
