[exim-dev] [Bug 2693] pipelining: exim messes up order of re…

Pàgina inicial
Delete this message
Reply to this message
Autor: admin
Data:  
A: exim-dev
Assumpte: [exim-dev] [Bug 2693] pipelining: exim messes up order of replies to RCPT TO
https://bugs.exim.org/show_bug.cgi?id=2693

Simon Arlott <bugzilla.exim.simon@???> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1359|0                           |1
        is obsolete|                            |


--- Comment #13 from Simon Arlott <bugzilla.exim.simon@???> ---
Created attachment 1361
--> https://bugs.exim.org/attachment.cgi?id=1361&action=edit
Pipelining test case

I've now reproduced this; Exim has special behaviour for 452 responses and
something is going wrong.

In this example, C and D were deferred but Exim thinks E and F were deferred:

1999-03-02 09:44:33 10HmaX-0005vi-00 <= CALLER@??? U=CALLER P=local
S=sss
1999-03-02 09:44:33 10HmaX-0005vi-00 => a@??? <A@???> R=client
T=send_to_server H=127.0.0.1 [127.0.0.1] L C="250 OK id=10HmaY-0005vi-00"
1999-03-02 09:44:33 10HmaX-0005vi-00 => b@??? <B@???> R=client
T=send_to_server H=127.0.0.1 [127.0.0.1] L C="250 OK id=10HmaZ-0005vi-00"
1999-03-02 09:44:33 10HmaX-0005vi-00 -> c@??? <C@???> R=client
T=send_to_server H=127.0.0.1 [127.0.0.1] L C="250 OK id=10HmaZ-0005vi-00"
1999-03-02 09:44:33 10HmaX-0005vi-00 -> d@??? <D@???> R=client
T=send_to_server H=127.0.0.1 [127.0.0.1] L C="250 OK id=10HmaZ-0005vi-00"
1999-03-02 09:44:33 10HmaX-0005vi-00 == e@??? <E@???> R=client
T=send_to_server defer (0)
1999-03-02 09:44:33 10HmaX-0005vi-00 == f@??? <F@???> R=client
T=send_to_server defer (0)

1999-03-02 09:44:33 10HmaX-0005vi-00 => e@??? <E@???> R=client
T=send_to_server H=127.0.0.1 [127.0.0.1] L C="250 OK id=10HmbA-0005vi-00"
1999-03-02 09:44:33 10HmaX-0005vi-00 -> f@??? <F@???> R=client
T=send_to_server H=127.0.0.1 [127.0.0.1] L C="250 OK id=10HmbA-0005vi-00"
1999-03-02 09:44:33 10HmaX-0005vi-00 Completed

It's also sending to A twice too, partly because the test case is invoking a
delivery 3 times when it now only requires 2 attempts:

1999-03-02 09:44:33 10HmaY-0005vi-00 => a@??? <A@???> R=client
T=send_to_server H=127.0.0.1 [127.0.0.1] L C="250 OK id=10HmbB-0005vi-00"
1999-03-02 09:44:33 10HmaY-0005vi-00 Completed

--
You are receiving this mail because:
You are on the CC list for the bug.