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.
> >
> > 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 '+').
Yes, that's basically it. Perhaps rather than "ATTR" it could be
"CLAUSE" (to match the RFC terminology) or some other bikeshed colour.
> Does it make sense to specify a list of key names that Postfix will
> accept in this manner?
That may be a reasonable setting if the the XCLIENT software is not
easily configurable and generates more tags than one wants to import.
> 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.
Well, we're probably not going to extend the SMTP command length limit
for XCLIENT, so only a modest number per line, but IIRC XCLIENT is
cumulative, so I guess we should limit the XCLIENT command count to at
most a dozen or so. The client can pack multiple clauses per command
(which won't cost us enough to care about), but should not be sending a
large number of commands.
Since XCLIENT is for trusted clients only, I don't see a pressing need
for fancy controls or very large attribute counts.
The main cost for us would be new code to fold the Received header given
a variable set of clauses. Right now we have a fairly static layout IIRC.
--
Viktor.
