[PATCH] Add proxy_protocol option to mail listener

[Maxim Dounin]

Hello!

On Wed, Jul 12, 2017 at 02:08:31PM +0200, Kees Bos wrote:

> On di, 2017-07-11 at 18:12 +0300, Maxim Dounin wrote:
> > Hello!
> > 
> > On Fri, Jul 07, 2017 at 03:38:02PM +0200, Kees Bos wrote:
> > 
> > > 
> > > # HG changeset patch
> > > # User Kees Bos <cornelis.bos at gmail.com>
> > > # Date 1499422505 0
> > > #      Fri Jul 07 10:15:05 2017 +0000
> > > # Node ID bc79b2baf494aabb889de1e5dbe3184ff0cb9bfa
> > > # Parent  70e65bf8dfd7a8d39aae8ac3a209d426e6947735
> > > Add proxy_protocol option to mail listener
> > > 
> > > Add support for the mail handlers. This enables the use of an
> > > upstream
> > > loadbalancer/proxy (like haproxy) that connects with the proxy
> > > protocol.
> > > 
> > > The original ip (as exposed with the proxy protocol) will be used
> > > as
> > > parameter for the 'Client-IP' in the authentication call.
> > > 
> > > Example config:
> > > mail {
> > >     server_name mail.example.com;
> > >     auth_http   localhost:9000/;
> > > 
> > >     server {
> > >         listen 143 proxy_protocol;
> > >         protocol imap;
> > >     }
> > > }
> > I see at least the following problems in this patch:
> 
> Thanks for the comments. I wasn't aware of a previous attempt (just
> started to look at nginx code etc). Apparently I'm not the only one
> interested in proxy_protocol for the mail module :-)

Well, I've provided the link when you asked about it in April in 
the nginx@ mailing list:

http://mailman.nginx.org/pipermail/nginx/2017-April/053582.html

> > 1. The implementation is not complete compared to other modules 
> > (http, stream): it only tries to change the address passed as 
> > Client-IP in auth_http, but not the address used for logging 
> > and/or for XCLIENT.
> 
> I'll handle that.
> 
> > 
> > 2. It unconditionally trusts all clients who can connect to the 
> > port in question.  This doesn't look wise.
> 
> I'm not sure what you mean here.
> 
> There's no way to verify the correctness of the proxy protocol (that's
> also true so for the http/stream implementation). If a proxy protocol
> claims to originate from 1.1.1.1:1 and that the connection was
> originally to 2.2.2.2:2 the listener has no way to know that that's
> correct (or not).

Obviously enough, you can't verify the information provided.  But 
you can trust or do not trust to the particular client.  For 
example, in the ngx_http_realip_module this is done using the 
set_real_ip_from directive (http://nginx.org/r/set_real_ip_from) - 
you can explicitly configure address blocks you want to allow to 
set client's address based on the provided header or PROXY 
protocol.

The link I've provided in the previous message contains an example 
with set_real_ip_from as part of the review.

-- 
Maxim Dounin
http://nginx.org/