Re: Ready: PROXY protocol v2 support
Thank you Wietse, I will test this week and let you know. On 1/6/20 12:42 AM, Wietse Venema wrote: > You can test haproxy v2 protocol support in postfix-3.5-20200105-nonprod > (http://ftp.porcupine.org/mirrors/postfix-release/index.html). I > have done all the testing that I can do. It would be great is someone > can test it against some real haproxy client. > > Haproxy v2 protocol support is limited to TCP over IPv4 and TCP > over IPv6. It supports non-proxied connections (typically used for > heartbeats). > > This will be part of the Postfix 3.5 stable release early this year. > > Wietse
Ready: PROXY protocol v2 support
You can test haproxy v2 protocol support in postfix-3.5-20200105-nonprod (http://ftp.porcupine.org/mirrors/postfix-release/index.html). I have done all the testing that I can do. It would be great is someone can test it against some real haproxy client. Haproxy v2 protocol support is limited to TCP over IPv4 and TCP over IPv6. It supports non-proxied connections (typically used for heartbeats). This will be part of the Postfix 3.5 stable release early this year. Wietse
Re: New functionality proposal
> On Jan 4, 2020, at 1:14 PM, Thierry Fournier wrote: > > Hi list, > > For my own usage I wrote a new DNS filter which is executed by smtp / lmtp > client > before executing DNS request. > > It allow to force response on MX requests without performing DNS request, or > force "domain not found” response. > > - For example, I can build MX response to force an email to be routed on my > own > servers in place of the real destination serveur. This is useful for tests. > > - Other example is an easy way to integrate relay on Internet in front of > existing > couple of MTA without changing any configuration and keeping the high > availability > provided by the DNS multiple MX records. (the “relay" transport doesn’t > seem to > allow multiple target). > > - Next example is blacklisting specific domain before performing the DNS > request. > > > Are you interested by the patch which integrate this functionality in main > postfix branch ? IMHO, all of this can be done in a local (unbound, BIND, ...) resolver. A Postfix MTA connected to the public Internet, *should* run a local resolver. Queries to a local resolver are fast enough. -- Viktor.
