Thanks for the reply- information regarding the protocols can be found here: https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
But to save time, they switched to a non-text format, as you said. If I could code it I would :( 2.1. Human-readable header format (Version 1) This is the format specified in version 1 of the protocol. It consists in one line of US-ASCII text matching exactly the following block, sent immediately and at once upon the connection establishment and prepended before any data flowing from the sender to the receiver 2.2. Binary header format (version 2) Producing human-readable IPv6 addresses and parsing them is very inefficient, due to the multiple possible representation formats and the handling of compact address format. It was also not possible to specify address families outside IPv4/IPv6 nor non-TCP protocols. Another drawback of the human-readable format is the fact that implementations need to parse all characters to find the trailing CRLF, which makes it harder to read only the exact bytes count. Last, the UNKNOWN address type has not always been accepted by servers as a valid protocol because of its imprecise meaning. On 12/07/18 22:44, Wietse Venema wrote: > cvandesa...@opendmz.com: >> I've been successfully using Postfix 3.3.1 behind an Haproxy for a few >> weeks now, and while this is a minor complaint, I just wondered if it >> was known. >> >> I have dual-stack ipv4/v6 support enabled and as a result most of my >> mail that comes from Google comes from an ipv6 address. >> >> The IP address is not parsed properly I think in the haproxy protocol, >> and I suspect that was fixed in send-proxy-v2 which I believe Postfix >> doesn't support. If this is the case, are their plans to support the >> haproxy v2 version of the proxy protocol? > If someone has time to contribute code, I will consider it. Note > that there are two Postfix haproxy handlers: a blocking handler > for smtpd, and a non-blocking handler for postscreen. > > The Postfix haproxy handlers will accept both IPv4 and IPv6. I have > no idea what send-proxy-v2 looks like, but if they did not complicate > things by switching to some non-text format, then it should be easy > to reuse most of that code for send-proxy-v2. > > Wietse
