Wietse Venema:
> Rik Theys:
> > Now, when I put the following in the aliases file:
> >
> > member1: user1
> > member2: user2
> > member3: user3
> > testlist: :include:/etc/postfix/testlist
> > owner-testlist: user1
> >
> > and in /etc/postfix/testlist:
> >
> > member1
> > member2
> > member3
> >
> > I touch /var/spool/mail/user2.lock to simulate a locked mailbox.
> >
> > When I now send a mail to testlist, the mail is not forwarded and resent
> > as owner-testlist. The mail is sent to user1 and then deferred. With
> > every retry of the mail, the mail gets sent again to user1 and then
> > deferred. This happens until user2.lock is removed and the mail is once
> > again sent to all addresses on the list.
>
> Sorry, don't do that. Postfix will NOT store mailing list members
> in the "new" queue file if that member is an alias.
>
> I haven't had time to fix local delivery agent logic since 1998,
> and it is unlikely to be fixed now without unexpectedly breaking
> a ton of other things, such as:
>
> - Instead of failing with a mail delivery loop, deliver mail to
> the user FOO when FOO is an alias that contains FOO (or an alias
> for FOO).
>
> - Instead of failing with a mail delivery loop, deliver mail to
> the mailbox FOO when ~FOO/.forward contains FOO (or an alias for
> FOO).
>
> And other Sendmail compatibility.
At this point the best I could do is make the alias expansion
behavior configurable with a backwards-compatible default setting.
Specifically, this would involve a switch that turns off alias
expansion once Postfix starts delivery to an alias FOO that has an
owner-FOO alias. This would solve the problem for mailing lists,
but could create mail delivery loops that currently don't exist.
Once this switch is fielded we can see if int introduces any surprises.
Wietse
