<div dir="ltr">Thanks for quick response. See my comment below:<div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 3, 2016 at 10:13 AM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<span class=""><br>
On Thu, Nov 03, 2016 at 09:41:03AM -0700, Maxim Vladimirsky wrote:<br>
<br>
> Hi Folks,<br>
><br>
> I was not sure if you would be interested in this, but decided to run it by<br>
> you anyway.<br>
><br>
> We need to run Nginx as an SMTP proxy sitting behind ELB in AWS, but we<br>
> also want the upstream SMTP server to get the real client ip, so Nginx is<br>
> configured to provide it via an XCLIENT command. However the stock version<br>
> of Nginx provides ELB's ip instead, because it does not recognize the Proxy<br>
> Protocol header (<a href="http://docs.aws.amazon.com/elasticloadbalancing/latest/" rel="noreferrer" target="_blank">http://docs.aws.amazon.com/<wbr>elasticloadbalancing/latest/</a><br>
> classic/enable-proxy-protocol.<wbr>html#proxy-protocol) sent to it by ELB.<br>
<br>
</span>Seems to be perfectly valid use case.<br>
<span class=""><br>
> The following patch updates the mail module so that it can be configured to<br>
> expect Proxy Protocol header by setting `proxy_protocol on`. In that case<br>
> Proxy Protocol header is parsed, a client IP is retrieved and passed to an<br>
> SMTP upstream in an XCLIENT command.<br>
<br>
</span>The "proxy_protocol on" is expected to configure sending PROXY<br>
protocol to an upstream server, similar to how it already works in<br>
the stream module:<br>
<br>
<a href="http://nginx.org/en/docs/stream/ngx_stream_proxy_module.html#proxy_protocol" rel="noreferrer" target="_blank">http://nginx.org/en/docs/<wbr>stream/ngx_stream_proxy_<wbr>module.html#proxy_protocol</a><br>
<br>
Accepting PROXY protocol from clients is expected to be enabled<br>
using a listening socket option instead, similar to what we have<br>
in http and stream modules:<br>
<br>
<a href="http://nginx.org/en/docs/http/ngx_http_core_module.html#listen" rel="noreferrer" target="_blank">http://nginx.org/en/docs/http/<wbr>ngx_http_core_module.html#<wbr>listen</a><br>
<a href="http://nginx.org/en/docs/stream/ngx_stream_core_module.html#listen" rel="noreferrer" target="_blank">http://nginx.org/en/docs/<wbr>stream/ngx_stream_core_module.<wbr>html#listen</a></blockquote><div><br></div><div>I will fix that.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Open question is how it should work though.  I.e., if it should<br>
just unconditionally set provided address as a client one, similar<br>
to how<br>
<br>
    listen 80 proxy_protocol;<br>
    real_ip_header proxy_protocol;<br>
    set_real_ip_from <a href="http://0.0.0.0/0" rel="noreferrer" target="_blank">0.0.0.0/0</a>;<br>
<br>
works in stream / http, or there should be some advanced control<br>
like the realip module in stream / http.<br></blockquote><div><br></div><div>Taking ip from Proxy Protocol header and passing in via XCLIENT is really all we need, and I cannot even think of a scenario where we would need any kind of fine tuning of this logic. So this is probably a question to a broader audience.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/" rel="noreferrer" target="_blank">http://nginx.org/</a><br>
<br>
______________________________<wbr>_________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx-devel</a><br>
</font></span></blockquote></div><br></div></div>