Hi Jeremy,
> Von: "Jeremy Harris via Exim-users" <exim-users@???>
> On 20/03/2020 17:09, Lukas Haase via Exim-users wrote:
> > 1.) Exim received a message to be delivered externally on a port != 10029 and router dkimproxy processes which uses transport dkimproxy_smtp to pass the message to localhost:10028
>
> I assume you mean "received, on port != 10029, a message..."
Yes. ESL ;-)
> > 2.) dkimproxy listens on localhost:10028. In parallel, it opens an SMTP connection back to exim (via localhost:10029). The purpose is to sign the message via DKIM
>
> Not sure why you're doing that; exim can dkim-sign
It's a legacy setup from 2008 when exim was not able to do that.
Maybe it's time to transition soon.
> > 3.) Since prdr_enable=true, exim advertises PRDR on port 10029
>
> If you're listening on 10029, and have not disabled the main-section
> prdr_enable option, yes.
>
> > which is further passed along to exim
>
> But you said that dkimproxy is the source for this connection. Does it
> understand and use PRDR? Where is this second exim? Are you
> implying that dkimproxy is not a full MTA, but an attempt at a
> transparent proxy?
Yes, sorry that my description was not fully clear. dkimproxy is a fully transparent proxy, NOT a full MTA!
If exim is not listening on 10029, connection to dkimproxy on 10028 failes.
Again, here's how dkimproxy works:
1.) Connection to 127.0.0.1:10028 is established (dkimproxy listens on 10028). Call it connection 1.
2.) dkimproxy immideately opens a connection to 127.0.0.1:10029 (exim listens on 10029). Call it connection 2.
3.) dkimproxy receives exim's greeting via connection 2 and passes it back via connection 1.
4.) Exim seesm the greeting and says "EHLO myself" via connection 1.
5.) dkimproxy passes it back to exim via connection 2.
6.) And so forth.
7.) Only during data command, dkimproxy generates the signature for the email and adds it to the data.
8.) Apart from that, all messages and responses are transparently relayed between connection 1 and connection 2.
> > 4.) Now exim (connected to dkimproxy via port 10028) sees that PRDR was advertised and uses it:
> > MAIL FROM:<from@???> SIZE=1000 PRDR
> > RCPT TO:<to1@???>
> > RCPT TO:<to2@???>
> > DATA
> > 5.) exim shuffled in the message, dkimproxy signs it and send it back to exim via port 10029.
> > 6.) NORMALLY, the message should arrive back here.
>
> Back where?
Back at exim on port 10029 (via connection 2 from above).
> > Due the condition
> > condition = "${if eq {$interface_port}{10029}{0}{1}}"
> > in transport "dkimproxy", the router is skipped this time and normal processing continues.
> > 7.) However, instead exim hangs: It responds to the DATA command with:
> > 353 PRDR content analysis beginning.
> > but nothing else happens. The connection is not terminated (with QUIT) and stays open.
>
> Sounds like your dkimproxy does not understand PRDR, and it not written
> to be resilient in the presence of ESMTP extensions it does not
> understand.
Well, why would need dkimproxy to understand PRDR? It just passes the messages along.
dkimproxy passes the data in the DATA command as it should and ends with a dot, as it should.
It is exim which only responds with
353 PRDR content analysis beginning.
and does nothing else.
To my understanding, the client (dkimproxy) is not supposed to do anything after that.
It just waits (and would relay back the data unchanged as described above).
> > Of course, I'd be interested how to DISABLE PRDR for a specific port (10029) or router/transport
>
> Smtp transport option hosts_try_prdr. It's in the docs.
> For your purpose, if the transport is shared for other purposes
> as well as this dkimproxy feed, use an expansion depending on the
> port.
It is not shared between anything else (it's a dedicated "dkimproxy_smtp").
Amazing! That works!!
# ngrep -d lo -W byline -q port 10028
[...]
T 127.0.0.1:10028 -> 127.0.0.1:33042 [AP]
250-mail Hello localhost [127.0.0.1].
250-SIZE 52428800.
250-8BITMIME.
250-PIPELINING.
250-PRDR.
250 HELP.
[...]
T 127.0.0.1:33042 -> 127.0.0.1:10028 [AP]
MAIL FROM:<from@???> SIZE=3923.
RCPT TO:<to1.hammler@???>.
RCPT TO:<to2@???>.
DATA.
[...]
PRDR is advertised but not used.
That really solves the main issue.
> but I'd be more interested to know what is going wrong here.
>
> I'd suggest you use Exim's dkim signing rather than this proxy.
I think that's a good point.
The dkimproxy is legacy and pretty fragile anyway.
I need to look how to do dkim with exim.
Best,
Luke
