[exim] Re: Bug in exim

Página Inicial
Delete this message
Reply to this message
Autor: Russell Stuart
Data:  
Para: exim-users
Assunto: [exim] Re: Bug in exim
On Wed, 2005-02-09 at 21:28, Russell Stuart wrote:
> Exim Version: 4.43 + exiscan
> OS:           Debian Sarge
> Config files: http://www.lubemobile.com.au/ras/exim4


This is what is happening. I am a little too tired to figure
out what to do about it.

Lets assume we have a single incoming email sent to:
x@???.

1. So, at this point we have:

      deliver.c/addr_route = x@???


2.  The problem is triggered by the "archive" router in my
    config file.  The "archive" router is a redirect router.
    It unconditionally sends all incoming mail to:
      email-archive@???
    and marks the email as "unseen".


    Internally, the redirect router handles this by adding 
    email-archive as a new address, and marks x@??? as
    successfully processed.  So we have:


      deliver.c/addr_succeed = x@???
      deliver.c/addr_new = email-archive@...


3.  My "archive" router marks x@??? as unseen, so a duplicate
    of it is created in route.c, and we eventually get:


      deliver.c/addr_succeed = x@???
      deliver.c/addr_route = x@???, email-archive@...


    This is the final output of the routing phase.


4.  If email gets delivered at this point things work as you
    might expect: x@??? and email-achive@... each get their
    copy of the email.  But in my case, things go wrong, and
    the transport returns DEFER.


    So the message must be written out to the queue, ie to a -H
    file.  The addresses get written in two chunks: those in the
    addr_succeed queue get written to the initial "delivery has
    been completed" section.  And all addresses get written to
    the next section.  So we end up with a -H file looking like
    this:


       1CzaC1-00064l-3S-H
       root 0 0
         :
         :
       -acl 14 2
       no
       -body_linecount 1
       -spam_score_int -25
       NN x@???
       2
       x@???
       email-archive@???  0,0#1


5.  Which of course says ... the delivery to x@??? has been made,
    when in fact no deliveries have taken place.


In my original bug report I rabbited on about Kaspersky and
LMTP. They were irrelevant. It boils down to this: if you
mark an address as unseen in the archive router, and then
the message gets deferred, a recipient marked as "unseen"
will be dropped.

My first thought was that if a router has the "unseen" flag
set it should not put the original address on addr_succeed.
Routing has after all not succeeded - the address still has
to be processed. But I am tired and need to get some sleep,
so there are probably a 1000 good and obvious reasons why
that won't work.

I really need to get this fixed. I would like to beg,
borrow or steal a quick hack to get around this until a
decent solution comes along. Can one of you who actually
knows the internals of Exim help?