Re: [exim] Bug in duplicate detection?

Tony Finch wrote:
> On Tue, 18 Jan 2005, Harald Schueler wrote:
>
>>One of our users (let's call her Alice) reported that she missed _some_ mails,
>>while others from the same person arrived. She gets copies of all mails
>>adressed to "Bob <bob@newdomain>" and also of course mail addressed to her own
>>address "Alice <alice@newdomain>". But when mail was addressed to
>>"bob@newdomain, alice@newdomain" (not knowing she would already get a copy of
>>the mail to Bob) it was delivered only to Bob (while, interestingly, mail
>>addressed to "alice@newdomain bob@newdomain" was deliverd as expected.
>
> I noticed that you didn't have check_ancestor set on any of the routers.
> Perhaps you should examine section 22.5 of the spec, which describes your
> problem and how to fix it.

This is a different problem, although it is probably a good idea to set
check_ancestor in the forward router (I just did that). In the example
case it does not fix anything, because the problematic address
(usera@olddomain) is not the same as any ancestor in the forward router.

The problem here is that after 2 routing steps the generated address
list contains a duplicate address, but they are at different stages of
processing, one before the localmux router, essentially ready to go (but
still in reach of duplicate cancellation -- envelope rewriting in the
transport would avoid that, but this is also not possible), the other
one before the alias router, ready to be aliased to usera@local and to
be thrown away later. Unfortunely, in the example, Exim treats both as
equivalent and throws out the first one, while the second one will also
fail, because the oldserver router has already seen the first address,
before it was discarded.

To put it simple, it looks to me as if the first address sets up a trap
in the oldserver router, is then shot by duplicate elimination (but the
trap survives) and then the winning incarnation of the adress falls into
the trap.

Although I certainly cannot claim to have understood the details...

As I said, I tried to invent a simpler configuration with this problem,
but the ones that came to my mind were all real loops.

Harald