Bug#954192: exim4-config: prdr_enable = true breaks exim4+dkimproxy when using multiple recipients

[Marc Haber]

On Wed, Mar 18, 2020 at 06:32:05AM +0100, Niki Hammler wrote:
> This worked flawlessly until jessie (for me, from 2008 until now). However, with prdr_enable = true, exim4 hangs when looping back the message when
> using multiple recipients. It hangs with message:
> 
>   353 PRDR content analysis beginning

That happens when dkimproxy re-delivers the message back to exim? What's
the SMTP dialog before? Does exim advertise PRDR? Does the client
request it?

> I verified the issue observing the traffic transmitted to dkimproxy while sending a message to only one recipient:
> 
> # ngrep -d lo -W byline -q port 10028
> [...]
> T 127.0.0.1:10028 -> 127.0.0.1:48486 [AP]
> 250 OK id=1jEPuw-0005Cq-IJ.
> 
> T 127.0.0.1:48486 -> 127.0.0.1:10028 [AP]
> QUIT.
> 
> T 127.0.0.1:10028 -> 127.0.0.1:48486 [AP]
> 221 mail.nobaq.net closing connection.
> 
> 
> All good, just as expected.
> Now repeating the whole thing while sending the message to TWO recipients:
> 
> # ngrep -d lo -W byline -q port 10028
> [...]
> DATA.
> [...]
> T 127.0.0.1:10028 -> 127.0.0.1:48586 [AP]
> 353 PRDR content analysis beginning.

The things you have left out would have been interesting.

> Setting
> 
>   prdr_enable = false
> 
> fixes the issue. But this is far from optimal.

I am not sure, but if the value for prdr_enable is expanded at
connection-time, one could use an expression that expands to "true" in
the default case and to "false" in the "I am talking to dkimproxy" case.

Generally, having messages looped out of exim and in again is seldomly a
good idea because internal information is lost between the two exim
runs.

> At the very least, information about prdr (and implications) would be useful to prevent people from debugging for days why suddenly after
> 12 years there are weird redeliveries and mails stuck in the queue.

prdr has a (short) explanation in exim's spec.txt. I don't think that it
should be the responsibility of the packaging to explain every feature
of e-mail transport.

> Furthermore, a Debian-style control macro would be desirable that allows more flexible control without directly changing the config file
> (like MAIN_TLS_ADVERTISE_HOSTS etc).

Agreed. Can we have a documented patch please?

The dkimproxy package could also dump a configuration snippet. Allowing
this is one of the reasons we came up with split config.

> The next best solution would require exim4 changes directly in order to prevent use of PRDR in the exim<->dkimproxy loop.

How would that be done?

> And the best solution would be to fix this bug altogether but I am not completely sure why exim4 is hanging there in the first place
> and how much it is related to dkimproxy.

I do see "interesting behavior" but not yet a bug, let alone in exim.

Greetings
Marc


-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421