W dniu 29.11.2012 22:54, Phil Pennock pisze:
> On 2012-11-29 at 17:51 +0100, Marcin Mirosław wrote:
>> W dniu 29.11.2012 16:15, Marcin Mirosław pisze:
>>> Configuration of virtual_delivery transport is defined as below:
>>> virtual_user:
>>> driver = accept
>>> domains = +local_domains
>>> condition = ${lookup pgsql{SQL_CZY_ISTNIEJE_UZYTK}}
>>> transport = virtual_delivery
>>> dsn_process
>>>
>>> SQL_CZY_ISTNIEJE_UZYTK = SELECT 1 FROM exim_users \
>>> WHERE login=lower(E'${quote_pgsql:$local_part}')
>>> AND aktywny = true AND tylko_wysylanie = false
>>>
>>
>> I've wrote and sent email too fast:/
>> Transport configuration is:
>> virtual_delivery:
>> driver = pipe
>> command = /usr/libexec/dovecot/deliver -d
>> "$local_part"
>> delivery_date_add
>> envelope_to_add
>> return_path_add
>> user = mail
>> log_output
>> temp_errors = 64 : 69 : 70: 71 : 72 : 73 : 74 : 75 : 78
>> shadow_condition=${if <{$spam_score_int}{0}}
>> shadow_transport=ham_transport_kopia
>
> Bear with me as I pick apart what's going on. I might have made a
> mistake and perhaps one of the other developers can point it out.
>
> So, when Exim creates a bounce message, it creates a child Exim process
> and generates the bounce message to feed to it on stdin. "Process
> failed (1) when writing error message" is saying that Exim process
> exited non-zero.
>
> Assuming that you have not set the "bounce_sender_authentication" main
> option, then the child Exim is invoked:
> exim -t -oem -oi -f <> -E$original_message_id
>
> This seems strange, the use of -oem with -f <>, because the point of
> -oem is that errors will be sent to the sender as a new message, which
> can't happen, and it seems that the actual cause of the complaint will
> then never get logged. Plus, -oem supposedly results in Exim always
> exiting non-zero, which means we'd always see that error message!
> Apparently, the documentation isn't write and it means that Exim always
> exits non-zero, unless the message was successfully received and parsed,
> in which case it always exits success.
>
> The receiving Exim forks again for the delivery, after receiving the
> message, and the return value from the delivery affects the exit code of
> that delivery process, but Exim doesn't care about that exit code, it's
> not looked at ever. (The delivery Exim process will have forked a third
> time, because you're using a pipe to run an external command, and _that_
> exit code will be looked at).
>
> A full flow to completion:
>
> Process 1: Exim which generates the bounce message
> Process 2: Exim which receives the bounce message
> Process 3: Exim which delivers the bounce message, much like any delivery
> Process 4: Pipe transport command used for the delivery
>
> Exit code of P4 is reported/recorded; exit code of P3 is ignored; Exit
> code of P2 is the one which causes P1 to generate the log message.
>
> Per docs, P2 should always exit non-zero, because of -oem, although the
> local_scan API docs note that child_open_exim() should normally return
> 0, despite documenting that it uses -oem. (And not documenting the -E
> for passing the original message id).
>
> The delivery status of P3 doesn't matter, and by that point, I think
> that P2 is destined to exit 0, thus we can assert that Exim is not
> getting as far as trying to deliver the bounce message, so P2 is failing
> during message reception.
>
> I wonder if this is the X-Failed-Recipients: header causing issues for
> containing unescaped non-ASCII? I'm not seeing what would cause that.
>
> I think I must have missed something here.
Hi!
On the begin I'd like to wish you all the best in 2013 year!
I've tried to follow you but I'm afraid this description is too low
level for my understanding of exim. Should I assume this is potential
bug in exim or bug in my configuration? Or maybe I can provide some
other information about it?
Thanks,
Marcin.
