On Mon, Oct 11, 2021 at 07:17:12PM -0400, Wietse Venema wrote:
> > If the goal is to leave a forensic trace, then it may be simpler to add
> > an optional list of trace key/value pairs to XCLIENT, which the
> > receiving MTA can choose to add to the message Received header.
> >
> >
Viktor Dukhovni:
> On Mon, Oct 11, 2021 at 08:10:05AM +, Kai KRETSCHMANN wrote:
>
> > The monitoring rspamd now has no chance to see in the latest Received
> > header in the connection was received TLS encrpyted or plain text.
>
> If the goal is to leave a forensic trace, then it may be
On Mon, Oct 11, 2021 at 08:10:05AM +, Kai KRETSCHMANN wrote:
> The monitoring rspamd now has no chance to see in the latest Received
> header in the connection was received TLS encrpyted or plain text.
If the goal is to leave a forensic trace, then it may be simpler to add
an optional list
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
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.
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