Re: [exim-dev] XCLIENT patch to Exim; Cambridge

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Wietse Venema
Fecha:  
A: exim-dev
Cc: Wietse Venema
Asunto: Re: [exim-dev] XCLIENT patch to Exim; Cambridge
Viktor Dukhovni:
> On Fri, Jan 16, 2015 at 12:52:46AM +0000, 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.


Specifically, this was added for nginx.

> > Is that Postfix page the sole definition of the ESMTP option?


There is an IETF draft for XFORWARD but that solves a different
problem (logging instead of impersonation). I am not aware of a
similar effort with respect to XCLIENT. Either way, if there is an
IETF spec then I'll update Postfix where needed.

Postfix accepts XCLIENT without EHLO. That is OK because XCLIENT
is meant for settings where ESMTP negotiation is unnecessary. Some
in-the-field implementations may rely on this optimization.

    Wietse


> 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_NAME            "NAME"          /* client name */
>     #define XCLIENT_REVERSE_NAME    "REVERSE_NAME"  /* reverse client name */
>     #define XCLIENT_ADDR            "ADDR"          /* client address */
>     #define XCLIENT_PORT            "PORT"          /* client port */
>     #define XCLIENT_PROTO           "PROTO"         /* client protocol */
>     #define XCLIENT_HELO            "HELO"          /* 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.