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.
-Phil
