Viktor Dukhovni:
> On Mon, Oct 11, 2021 at 08:10:05AM +0000, 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 of trace key/value pairs to XCLIENT, which the
> receiving MTA can choose to add to the message Received header.
> 
>     https://www.rfc-editor.org/rfc/rfc8314.html#section-7.4
> 
> While I'd have preferred a slightly different definition of
> these elements, they're probably sufficient for the needs above.

That would certainly be possible.

How about: 

    XCLIENT ... ATTR=key=value ...

where key and value are xtext encoded as per RFC 1891, meaning that
they cannot contact '=' (or '+').

Does it make sense to specify a list of key names that Postfix will
accept in this manner?

If the client can send arbitrary keys, how many distinct keys will
Postfix accept before it rejects further input? XCLIENT is forbidden
by default, so we can have a generous default limit.

        Wietse

Reply via email to