Kai KRETSCHMANN:
> Hi postfix experts,
>
> I think I (and others) might need an enhancement to the parameters the
> XCLIENT command currently
> accepts.
>
> The usecase is like this:
>
> I'm running a MailU installation which receives SMTP 25/tcp connections via a
> TLS terminating nginx proxy.
> That proxy now proxies the connection to a locally running postfix daemon in
> another docker
> container.
> The monitoring rspamd now has no chance to see in the latest Received header
> in the connection was
> received TLS encrpyted or plain text.
>
> I think if there was an additional optional parameter for XCLIENT like
> ENCRYPTION=... with various
> (TBD) values, that could be interpreted by postfix then to add that
> information to the Received
> line, as it would do with directly received connections via TLS/STARTLTS.
>
> If that can be implemented, then nginx has to use it in the next step.
The Postfix SMTP daemon has code that receives a TLS_SESS_STATE
object from a tlsproxy process. This code is #ifdef USE_TLSPROXY
and has been used only for testing sofar. But it shows that it is
possible to receive TLS state from a different process.
The code has obvious limitations: the Postfix SMTP daemon cannot
ask for the TLS client certificate, and it cannot control any TLS
property such as the ciphers or protocols that may be used. Many
Postfix parameters would need additional disclaimers that they do
not work with XCLIENT.
TLS_SESS_STATE has multiple fields, and receiving this via XCLIENT
could be non-trivial. Depending on what subset XCLIENT can provide
there will have to be extra code in the Postfix SMTP daemon to avoid
core dumps and other bugs because information does not exist.
Wietse
> How about that way to solve things? Or is there already any ongoing action to
> solve similar
> problems?
> If needed to keep the mailing list discussion free, feel free to write
> personally and I can provide
> some discourse space for it.
>
