Re: XCLIENT enhancement needed
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.
Re: XCLIENT enhancement needed
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 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
Re: XCLIENT enhancement needed
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 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. -- Viktor.
Re: XCLIENT enhancement needed
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" 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 >
Re: XCLIENT enhancement needed
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? 11. Oktober 2021 14:10, "Wietse Venema" 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
Re: XCLIENT enhancement needed
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. >
