The problem was: an alias expands into multiple addresses; one of
them needs to be deferred; all addresses receive another copy of
the mail.

There is no need to drag into the discussion aliases that
invoke other aliases.

        Wietse

Matthias Andree:
> wietseporcupine.org (Wietse Venema) writes:
>
> > I will not repeat myself again. End of discussion.
>
> I have a different suggestions from those I had before, would you
> consider that to reduce the impact of the bug without (as I believe)
> violating your requirements?
>
> Question on the work flow: Assume this aliases
>
> s: t1 t2
> t1: a b c
> t2: x y z
>
> Will the expansion be expanding the entire right hand side at once (s
> -turn-> t1 t2 -turn-> a b c x y z) or will it rather recurse each
> expansion immediately): s -resolve-t1-> a b c -> resolve-t2-> x y z?

Expansion "at once" requires unbounded amounts of memory, therefore
it violates requirement number 3.

> AFAICS from the source, Postfix does the equivalent of "sort|uniq" to
> eliminate immediate duplicates - right after this step, Postfix will
> determine if it has "immediate delivery expansions" := { file, command,
> include }.

Postfix does not the equivalent of sort|uniq. That requires unbounded
amounts of memory, therefore it violates requirement number 3.

> If there was a counter or flag "current queue item had immediate
> delivery expansions" or, even better (if possible), "current queue item
> had unsuccessful immediate delivery expansions", Postfix could determine
> if
>
> 1. it had to retry the entire delivery (i. e. one expansion returned 75
> -> push the original recipient, "s" here, into the defer queue) or
>
> 2. if it was sufficiently safe to just push the failed recipients back
> to the defer queue, dropping the "s". It's safe if the current mail has
> not seen command expansions.

One message can have multiple destinations. Therefore one flag is
not useful.

Pushing failed recipients to the defer queue means writing TODO
destinations to queue file. This violates requirement number 4.

        Wietse

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]