[exim-dev] XCLIENT patch to Exim; Cambridge
FreeBSD is carrying a local patch to Exim, adding XCLIENT support. The ticket requesting its addition is at: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=133891 and there's no indication given there about why this was aimed directly at one OS's packaging, rather than at upstream. The feature documentation is: http://www.postfix.org/XCLIENT_README.html The patch can be found at: https://github.com/freebsd/freebsd-ports/blob/master/mail/exim/files/extra-patch-xclient This should probably be considered as a parallel to the proxy protocol support which we have. Aside from security review, the biggest issue is likely to be that the patch wasn't given to us and is currently a standalone work without a license statement, so we'd need to chase down the original author and ask about permission to include as part of Exim, under GPL. In 2008 there was discussion on exim-users, subject XCLIENT supported by exim?; Nigel summarized the state as zero previous discussion, no patches, so no apparent interest. The tone of the response I see was generally oh that's a Postfix thing, we just connect Exim directly to the Internet without anything in front of it. One of the last posts referenced an existing patch by Vsevolod Stakhov: http://cebka.pp.ru/blog/2007/12/xclient-exim.html http://cebka.pp.ru/blog/patch-exim-xclient but there's no longer any DNS for that host; however, the initial report in the FreeBSD PR #133891 referenced http://cebka.pp.ru/blog/2009/01/-eximxclient.html so it seems that the history of this patch in FreeBSD traces back to then, even though the FreeBSD patch has been maintained as it's patched for more recent Exim releases. I think that the biggest problem is that most postmaster folks back then didn't see the benefit of siting an Exim behind a front-end proxy, especially since this was presented as a security proxy adding features, where all the features _could_ be done in Exim already. Since then, with the widening spread of protocol-generic front-end loadbalancers, we've seen the haproxy Proxy Protocol take off, the approach of setting normally-from-getsockopt vars based upon remote data _if_ the connecting host passes an ACL has been validated and seen not to be a security issue (well, unless someone allows the extension from the open Internet, instead of just from the local trusted proxies) and I think that this is _much_ less controversial. It looks like the Vsevolod Stakhov from the original report is probably the gentleman by that name now at the University of Cambridge (oh, it's the same guy who did the cool libucl config library stuff, that's why the name was familiar :) ). On this basis, I'm going to explicitly CC Tony, also at UoC who could perhaps chat with Vsevolod, and the address found on https://github.com/vstakhov. Guys, okay to pull this patch into Exim? -Phil -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [exim-dev] XCLIENT patch to Exim; Cambridge
On Thu, Jan 15, 2015 at 07:00:48PM +, Phil Pennock wrote: FreeBSD is carrying a local patch to Exim, adding XCLIENT support. If you adopt this, at some point it might make sense to write up an informational I-D describing an experimental SMTP protocol extension. This makes it less Postfix-specific. It by now likely implemented in various other SMTP cleint and/or server stacks, and perhaps we could skip directly to a standards-track I-D. -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [exim-dev] XCLIENT patch to Exim; Cambridge
On 15/01/15 19:00, Phil Pennock wrote: FreeBSD is carrying a local patch to Exim, adding XCLIENT support. [...] Guys, okay to pull this patch into Exim? If you think there's enough value / interest, yup. The three justifications for it on the Postfix page are, I think, irrelevant to use with Exim, leaving only your loadbalancer case. We need, I think: - project sponsor -- delivery positioning (experimental?) -- legal chasing - coder/architect -- builds, testcases, documentation -- security review (coding, operational constraints, logging) -- feature-incompatibility (proxy-protocol? TLS? X509 certs?) -- coding standards -- feature spinoffs (xcode string expansions?) [ I'm hoping you're setting yourself up for both roles... ] Most of the attributes look ok for us to support. I'm dubious about the LOGIN one though; this feels like a protocol level violation. OTOH, nginx (according to https://www.ruby-forum.com/topic/205086 ) does indeed violate in that way. Echhh. If we did support it I would argue strong for a separate configuration control on it. I think we'd want to know what features are actually used by existing proxy front-ends. Is that Postfix page the sole definition of the ESMTP option? I note it doesn't specify the format of an IP address (there is an example of an IPv4 one). Swaks supports it, and mentions another (undocumented!) attribute: REVERSE_NAME ... ( http://www.jetmore.org/john/code/vmail/latest/doc/ref.txt ) -- Cheers, Jeremy -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
Re: [exim-dev] XCLIENT patch to Exim; Cambridge
On Fri, Jan 16, 2015 at 12:52:46AM +, Jeremy Harris wrote: Most of the attributes look ok for us to support. I'm dubious about the LOGIN one though; this feels like a protocol level violation. In Postfix this allows proxying of SASL logins. A proxy might handle SASL auth in front of the MTA. The MTA receives the SASL login name as determined by the proxy and applies access control decisions accordingly. Is that Postfix page the sole definition of the ESMTP option? I think so, that's why it is perhaps time for an IETF draft, the feature seems to have caught on far beyond Postfix. Not sure whether the I-D should be informational or standards-track. XCLIENT is a local matter between various load-balancer systems and the MTA behind them, and is not generally a concern across indepedently operated systems. So informational might be less work, and still get the job done. I note it doesn't specify the format of an IP address (there is an example of an IPv4 one). Quoting XCLIENT_README: The ADDR attribute specifies an SMTP client numerical IPv4 network address, an IPv6 address prefixed with IPV6:, or [UNAVAILABLE] when the address information is unavailable. Address information is not enclosed with []. Thus one of the three forms: 192.0.2.1 IPv6:2001:db8::1 [UNAVAILABLE] Swaks supports it, and mentions another (undocumented!) attribute: REVERSE_NAME ... ( http://www.jetmore.org/john/code/vmail/latest/doc/ref.txt ) It does looks like XCLIENT_README omits that attribute which was added more recently. The full list is: #define XCLIENT_NAMENAME /* client name */ #define XCLIENT_REVERSE_NAMEREVERSE_NAME /* reverse client name */ #define XCLIENT_ADDRADDR /* client address */ #define XCLIENT_PORTPORT /* client port */ #define XCLIENT_PROTO PROTO /* client protocol */ #define XCLIENT_HELOHELO /* client helo */ #define XCLIENT_LOGIN LOGIN /* SASL login name */ The REVERSE_NAME is the unverified result of of a PTR lookup. While NAME is the FCrDNS. These are of course not always available to the proxy. -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
