Kai KRETSCHMANN:
> A variant to this would be to allow more values for the PROTO parameter.
> If I could say "ESMTPS" for XCLIENT then postfix should know it
> was TLS transferred. Even if I don't see the rest of meta data
> like TLS version or CN content.
> Currently the readme says only SMTP and ESMTP would be allowed.
>
> Would that seem easier to implement?
That could be the worst possible solution. It would be like having
an empty TLS_SESS_STATE object, and would maximize the amount of
change needed to code that makes decisions based on the TLS status
of an SMTP session, or that logs properties of an SMTP session.
What missing TLS_SESS_STATE fields would break existing code? It
is not every field, but I don't have time to look into that now.
Wietse
> 11. Oktober 2021 14:10, "Wietse Venema" <wie...@porcupine.org> schrieb:
>
> > 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.
>
>
> Kai Kretschmann
> Friedrichsdorf
>
