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.
> >
> > I think this idea has been considered before. I (still) think this
> > makes sense. A more interesting question is what to do with:
> >
> > toplist-owner: foo
> > toplist: midlist1, midlist2
> > midlist1-owner: bar
> > midlist1: a, b, c, d, e
> > midlist2-owner: baz
> > midlist2: x, y, z, w, t
> >
> > If mail delivery to "x" fails for a message addressed to "toplist", should
> > the bounce notice go to "foo" or "baz". The latter potentially involvles
> > forking off lots of copies of the message, one for each sub-list, so
> > there is some incentive to leave the "owner" alone, if one is already set.
>
> 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.
Wietse
