Thanks Kees and Maxim, for the patch and the discussion. A very helpful
community!

This looks like it's working well for my use case for a tcp465/"ssl on"
mail proxy server block. My earlier issues appear to have (at least
partly) been related to STARTTLS with a tcp587/"starttls only" block
that I started my investigations with...

Once I switched over to the straight SSL block things started working a
lot better. I'll get back to my STARTTLS challenge in a little bit,
unless there's some reason you know of off-hand that it should act
differently?

The only other thing I've noticed is an inconsistency/typo in the
'set_real_ip_from' directive (as in the documentation section of the
patchset). It looks like it is actually parsed as 'set_realip_from' (no
_ in the realip part). I'm not sure which is the correct form ( :-) ),
but the feature works when I use the 'set_realip_from' form , so it does
differ from the docs...

Thanks again Kees! Wayde.



On 08/07/2017 09:25 AM, Kees Bos wrote:
> On ma, 2017-08-07 at 07:49 -0400, Wayde Nie wrote:
>> On 08/07/2017 03:44 AM, Kees Bos wrote:, and when I do set
>>>> proxy_protocol
>>>> on the listen directive I see the correct ip and port picked up and
>>>> logged in the error.log, however, then nginx stops sending the smtp
>>>> greeting... My mail client connects to my loadbalancer, the lb
>>>> connects
>>>> to nginx:587 sending the PROXY line, nginx parses and logs the PROXY
>>>> fields, then the client times out waiting for any return traffic
>>>> from
>>>> nginx... I know it's something I'm doing :-)
>>>>
>>>> I'm happy to keep poking away at it, but curious mostly, if you think
>>>> the approach is sound? (ie. use $proxy_protocol_addr, set by
>>>> proxy_protocol directive and pass in to auth_http script in auth url
>>>> as
>>>> a get param?) and if an initial patch that starts by just setting
>>>> $proxy_protocol_* variables would be a useful first step in this type
>>>> of
>>>> functionality?
>>>>> Just to get the picture right (it looks to me that your downstream smtp
>>>>> server expects the proxy protocol), what's the exact flow you're trying
>>>>> to accomplish?
>>
>> Hi Kees,
>>
>> Thanks for looking!
>>
>> In my use case I have an external hardware loadbalancer that is
>> receiving end user connections on a VIP, pre-pending proxy_protocol
>> header and loadbalancing them to small pool of nginx servers running
>> as the mail proxies. Nginx is parsing the proxy_protocol header and
>> (I hope) proxying to my upstream smtp server without passing the
>> proxy_protocol header, which my upstream smtp server doesn't support
>> (as currently implemented).
>>
>> Flow like:
>>
>> 1) Client makes connection to [external-LB-VIP:587] for email
>> submission
>> 2) [external-LB-VIP:587] --> injects proxy_protocol header -->
>> load balances to set of nginx services via TCP service pool (ie:
>> lb straight tcp, no application level inspection by loadbalancer,
>> other than prepending proxy_protocol header)
>> 3) Nginx parses proxy_protocol header, logs client ip and passes
>> client IP into auth_http script, along with username and password
>> for authn/authz
>> 4) on successful return response from auth_http; nginx proxies
>> mail submission to upstream smtp server without proxy_protocol
>> header.
>>
>>
>> So, if possible, I'd like nginx to get the client ip passed to it
>> from the external hardware load balancer, log it and then use it in
>> the auth_http script, but otherwise not pass it on to the upstream
>> smtp server...
>>
>> Is this doable?
>>
>> Thanks,Wayde.
>
> Yep. Should be.
>
> I just noticed that my mail from Jul 20 is emtpy and should contain
> the latest patch. I've just sent the patch.
>
>
> In your case, the config should probably be something like:
>
> mail {
> server_name mail.example.com;
> auth_http <auth url>;
> server {
> listen 587 proxy_protocol;
> protocol smtp;
> set_real_ip_from <external lb ip>;
> }
> }
>
>
>
>
>
>
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel

_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel