PROXY protocol v2 support

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

PROXY protocol v2 support

Tamás Gérczei
Hello List,

I'd like to ask if PROXY protocol v2 is supported by Postfix?

Thanks,
Tamás
Reply | Threaded
Open this post in threaded view
|

Re: PROXY protocol v2 support

Wietse Venema
Tam?s G?rczei:
> Hello List,
>
> I'd like to ask if PROXY protocol v2 is supported by Postfix?

It's not mentioned in documentation, therefore it is not supported.
Ditto for memcached v2 protocol.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: PROXY protocol v2 support

Tamás Gérczei
Thanks Wietse, this is what I thought and found out during my
experiments,That said, now knowing that only v1 is supported, may I ask
whether you have considered implementing v2 support? I'm about to
migrate to a setup where I'm behind a load balancer that only speaks v2.

Yours,
Tamás

On 12/30/19 9:38 PM, Wietse Venema wrote:
> Tam?s G?rczei:
>> Hello List,
>>
>> I'd like to ask if PROXY protocol v2 is supported by Postfix?
> It's not mentioned in documentation, therefore it is not supported.
> Ditto for memcached v2 protocol.
>
> Wietse

Reply | Threaded
Open this post in threaded view
|

Re: PROXY protocol v2 support

Willy Tarreau-3
On Tue, Dec 31, 2019 at 08:21:05AM +0100, Tamás Gérczei wrote:
> Thanks Wietse, this is what I thought and found out during my
> experiments,That said, now knowing that only v1 is supported, may I ask
> whether you have considered implementing v2 support? I'm about to
> migrate to a setup where I'm behind a load balancer that only speaks v2.

Maybe you can try to implement v2 support ? Parsing v2 when v1 is already
supported is quite easy, especially at the same level of support (i.e. no
TLV field support for TLS or whatever). You can have a look at
conn_recv_proxy() in haproxy:src/connection.c which supports the two
versions. Feel free to steal any code I wrote there, if that helps :-)

Regards,
Willy
Reply | Threaded
Open this post in threaded view
|

Re: PROXY protocol v2 support

Tamás Gérczei
Thanks Willy, I appreciate the clue and your helpful intention -
unfortunately this isn't something I can personally do owing to lack of
knowledge. I don't know whether the v1 implementation had been a
community patch or something Wietse or Viktor have done.

On 12/31/19 8:35 AM, Willy Tarreau wrote:

> On Tue, Dec 31, 2019 at 08:21:05AM +0100, Tamás Gérczei wrote:
>> Thanks Wietse, this is what I thought and found out during my
>> experiments,That said, now knowing that only v1 is supported, may I ask
>> whether you have considered implementing v2 support? I'm about to
>> migrate to a setup where I'm behind a load balancer that only speaks v2.
> Maybe you can try to implement v2 support ? Parsing v2 when v1 is already
> supported is quite easy, especially at the same level of support (i.e. no
> TLV field support for TLS or whatever). You can have a look at
> conn_recv_proxy() in haproxy:src/connection.c which supports the two
> versions. Feel free to steal any code I wrote there, if that helps :-)
>
> Regards,
> Willy

Reply | Threaded
Open this post in threaded view
|

Re: PROXY protocol v2 support

Willy Tarreau-3
On Tue, Dec 31, 2019 at 10:34:14AM +0100, Tamás Gérczei wrote:
> Thanks Willy, I appreciate the clue and your helpful intention -
> unfortunately this isn't something I can personally do owing to lack of
> knowledge. I don't know whether the v1 implementation had been a
> community patch or something Wietse or Viktor have done.

Wietse did all the hard work in 2012. Back then it was tricky to implement
v1 due to the non-atomicity of the protocol. I seem to remember that this
is what led to the design of v2. But honestly, every time someone told me
he lacked knowledge to contribute a patch, it took more time than average
but was of better quality in the end than those who think they know. C is
not difficult to read, it can only be tricky at times but I really think
that all you need is already there. Thus if you have a few hours to spend
there figuring how it's arranged, I'm pretty sure that you can figure how
to proceed to have a first roughly working version :-)

Regards,
Willy
Reply | Threaded
Open this post in threaded view
|

Re: PROXY protocol v2 support

Wietse Venema
In reply to this post by Willy Tarreau-3
Willy Tarreau:

> On Tue, Dec 31, 2019 at 08:21:05AM +0100, Tam?s G?rczei wrote:
> > Thanks Wietse, this is what I thought and found out during my
> > experiments,That said, now knowing that only v1 is supported, may I ask
> > whether you have considered implementing v2 support? I'm about to
> > migrate to a setup where I'm behind a load balancer that only speaks v2.
>
> Maybe you can try to implement v2 support ? Parsing v2 when v1 is already
> supported is quite easy, especially at the same level of support (i.e. no
> TLV field support for TLS or whatever). You can have a look at
> conn_recv_proxy() in haproxy:src/connection.c which supports the two
> versions. Feel free to steal any code I wrote there, if that helps :-)

I'm looking into this, and a Postfix-quality implementation including
tests(!) is going to take more than a few hours. Primarily, because
v2 uses a binary protocol, which complicates everything. I'll put a
few hours in today.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: PROXY protocol v2 support

Tamás Gérczei
Many thanks in advance for all your efforts in this regard, Wietse!

On 12/31/19 5:08 PM, Wietse Venema wrote:

> Willy Tarreau:
>> On Tue, Dec 31, 2019 at 08:21:05AM +0100, Tam?s G?rczei wrote:
>>> Thanks Wietse, this is what I thought and found out during my
>>> experiments,That said, now knowing that only v1 is supported, may I ask
>>> whether you have considered implementing v2 support? I'm about to
>>> migrate to a setup where I'm behind a load balancer that only speaks v2.
>> Maybe you can try to implement v2 support ? Parsing v2 when v1 is already
>> supported is quite easy, especially at the same level of support (i.e. no
>> TLV field support for TLS or whatever). You can have a look at
>> conn_recv_proxy() in haproxy:src/connection.c which supports the two
>> versions. Feel free to steal any code I wrote there, if that helps :-)
> I'm looking into this, and a Postfix-quality implementation including
> tests(!) is going to take more than a few hours. Primarily, because
> v2 uses a binary protocol, which complicates everything. I'll put a
> few hours in today.
>
> Wietse

Reply | Threaded
Open this post in threaded view
|

Re: PROXY protocol v2 support

Wietse Venema
In reply to this post by Willy Tarreau-3
I have a question about the v2 protocol spec.

  - \x0 : LOCAL : the connection was established on purpose by the proxy
    without being relayed. The connection endpoints are the sender and the
    receiver. Such connections exist when the proxy sends health-checks to the
    server. The receiver must accept this connection as valid and must use the
    real connection endpoints and discard the protocol block including the
    family which is ignored.

Real connection == the endpoints of the TCP connection from proxy to Postfix?

  - 0x0 : AF_UNSPEC : the connection is forwarded for an unknown, unspecified
    or unsupported protocol. The sender should use this family when sending
    LOCAL commands or when dealing with unsupported protocol families. The
    receiver is free to accept the connection anyway and use the real endpoint
    addresses or to reject it. The receiver should ignore address information.

What does 'reject' mean in this context? If it means closing the
connection, what is the point of rejecting a connection that was
made for the purpose of a health check?

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: PROXY protocol v2 support

Viktor Dukhovni
On Tue, Dec 31, 2019 at 11:38:06AM -0500, Wietse Venema wrote:

> I have a question about the v2 protocol spec.
>
>   - \x0 : LOCAL : the connection was established on purpose by the
>     proxy without being relayed. The connection endpoints are the
>     sender and the receiver. Such connections exist when the proxy
>     sends health-checks to the server. The receiver must accept this
>     connection as valid and must use the real connection endpoints and
>     discard the protocol block including the family which is ignored.
>
> Real connection == the endpoints of the TCP connection from proxy to
> Postfix?

That would be my reading of that text, most likely a health-check or
other proxy-initiated connection.

>   - 0x0 : AF_UNSPEC : the connection is forwarded for an unknown,
>     unspecified or unsupported protocol. The sender should use this
>     family when sending LOCAL commands or when dealing with
>     unsupported protocol families. The receiver is free to accept the
>     connection anyway and use the real endpoint addresses or to reject
>     it. The receiver should ignore address information.
>
> What does 'reject' mean in this context? If it means closing the
> connection, what is the point of rejecting a connection that was
> made for the purpose of a health check?

Yes, reject == close, but presumably only if the connection was not
proxy-originated, i.e. not LOCAL.  For Postfix, if the proxy cannot
provide any address information, for a forwarded connection (should
"never" happen in practice) we probably should close the connection.

--
    Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: PROXY protocol v2 support

Wietse Venema
In reply to this post by Wietse Venema
Wietse Venema:

> Willy Tarreau:
> > On Tue, Dec 31, 2019 at 08:21:05AM +0100, Tam?s G?rczei wrote:
> > > Thanks Wietse, this is what I thought and found out during my
> > > experiments,That said, now knowing that only v1 is supported, may I ask
> > > whether you have considered implementing v2 support? I'm about to
> > > migrate to a setup where I'm behind a load balancer that only speaks v2.
> >
> > Maybe you can try to implement v2 support ? Parsing v2 when v1 is already
> > supported is quite easy, especially at the same level of support (i.e. no
> > TLV field support for TLS or whatever). You can have a look at
> > conn_recv_proxy() in haproxy:src/connection.c which supports the two
> > versions. Feel free to steal any code I wrote there, if that helps :-)
>
> I'm looking into this, and a Postfix-quality implementation including
> tests(!) is going to take more than a few hours. Primarily, because
> v2 uses a binary protocol, which complicates everything. I'll put a
> few hours in today.

I found that I first have to refactor the existing Postfix
implementation, because of a change in the haproxy message format.
The "diff -u" output is about 750 lines -- and that is refactoring
before adding v2 support.

The existing Postfix code completely separates the haproxy message
reader from the haproxy message parser. The v1 haproxy message has
a unique message terminator, and the haproxy message reader can
pull the entire message from the input queue before handing it off
to the haproxy message parser.

With the new protocol, there is no unique message terminator.
Instead, message length information is embedded in the message, and
the reader has to pull the message from the input queue after the
parser has figured out the message length. It's not super complicated,
but this back-and-forth between reading and parsing is complicating
the event-driven postscreen code a bit.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: PROXY protocol v2 support

Wietse Venema
> > > Maybe you can try to implement v2 support ? Parsing v2 when v1 is already
> > > supported is quite easy, especially at the same level of support (i.e. no
> > > TLV field support for TLS or whatever). You can have a look at
> > > conn_recv_proxy() in haproxy:src/connection.c which supports the two
> > > versions. Feel free to steal any code I wrote there, if that helps :-)
> >
> > I'm looking into this, and a Postfix-quality implementation including
> > tests(!) is going to take more than a few hours. Primarily, because
> > v2 uses a binary protocol, which complicates everything. I'll put a
> > few hours in today.
>
> I found that I first have to refactor the existing Postfix
> implementation, because of a change in the haproxy message format.
> The "diff -u" output is about 750 lines -- and that is refactoring
> before adding v2 support.
>
> The existing Postfix code completely separates the haproxy message
> reader from the haproxy message parser. The v1 haproxy message has
> a unique message terminator, and the haproxy message reader can
> pull the entire message from the input queue before handing it off
> to the haproxy message parser.

The refactor is done (postfix-3.5-20200101-nonprod), and I verified
that version 1 protocol still support works as before.

It took a littie over 200 lines to add version 2 protocol support.
That code will need some testing before I can share it.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: PROXY protocol v2 support

Tamás Gérczei
Amazing. Thank you!

On 1/2/20 1:41 AM, Wietse Venema wrote:

>>>> Maybe you can try to implement v2 support ? Parsing v2 when v1 is already
>>>> supported is quite easy, especially at the same level of support (i.e. no
>>>> TLV field support for TLS or whatever). You can have a look at
>>>> conn_recv_proxy() in haproxy:src/connection.c which supports the two
>>>> versions. Feel free to steal any code I wrote there, if that helps :-)
>>> I'm looking into this, and a Postfix-quality implementation including
>>> tests(!) is going to take more than a few hours. Primarily, because
>>> v2 uses a binary protocol, which complicates everything. I'll put a
>>> few hours in today.
>> I found that I first have to refactor the existing Postfix
>> implementation, because of a change in the haproxy message format.
>> The "diff -u" output is about 750 lines -- and that is refactoring
>> before adding v2 support.
>>
>> The existing Postfix code completely separates the haproxy message
>> reader from the haproxy message parser. The v1 haproxy message has
>> a unique message terminator, and the haproxy message reader can
>> pull the entire message from the input queue before handing it off
>> to the haproxy message parser.
> The refactor is done (postfix-3.5-20200101-nonprod), and I verified
> that version 1 protocol still support works as before.
>
> It took a littie over 200 lines to add version 2 protocol support.
> That code will need some testing before I can share it.
>
> Wietse

Reply | Threaded
Open this post in threaded view
|

Ready: PROXY protocol v2 support

Wietse Venema
In reply to this post by Wietse Venema
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
Reply | Threaded
Open this post in threaded view
|

Re: Ready: PROXY protocol v2 support

Tamás Gérczei
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

Reply | Threaded
Open this post in threaded view
|

Re: Ready: PROXY protocol v2 support

Tamás Gérczei
In reply to this post by Wietse Venema
I've just tested it by spinning up an instance of this version behind an
AWS NLB and connecting to the load balancer from the outside - it worked
well, nevertheless I'd encourage others to test as well. Log snippets
follow:

# with smtpd_upstream_proxy_protocol defaulted to empty
postfix-test-7cbd54cdfc-twv79 postfix Jan 07 10:50:55 mail
postfix/master[1]: daemon started -- version 3.5-20200105-nonprod,
configuration /postfix/config-live
postfix-test-7cbd54cdfc-twv79 postfix Jan 07 10:51:19 mail
postfix/smtpd[76]: connect from
ip-10-36-0-0.eu-central-1.compute.internal[10.36.0.0]
postfix-test-7cbd54cdfc-twv79 postfix Jan 07 10:51:19 mail
postfix/smtpd[76]: improper command pipelining after QUIT from
ip-10-36-0-0.eu-central-1.compute.internal[10.36.0.0]:
!\021\000T\2620\030\265\254\024\000\272\260\273\000\031\003\000\004\206n\304Q\004\000>\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000\000

# with smtpd_upstream_proxy_protocol = haproxy
postfix-test-7cbd54cdfc-65x22 postfix Jan 07 10:52:24 mail
postfix/master[1]: daemon started -- version 3.5-20200105-nonprod,
configuration /postfix/config-live
postfix-test-7cbd54cdfc-65x22 postfix Jan 07 10:52:28 mail
postfix/smtpd[76]: connect from fejezd.be[178.48.24.181]

Again: thanks Wietse!

T.

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

Reply | Threaded
Open this post in threaded view
|

broken haproxy crc32 support

Wietse Venema
In reply to this post by Willy Tarreau-3
I found a portability bug in haproxy's CRC32 implementation, while
adding adding CRC32 support to Postfix's haproxy2 code. The haproxy
code produces incorrect results on ix86. Which just happens to work
as long as everyone is using ix86.

The same bug appears to exist in other hash functions in
haproxy/src/hash.c.

My proposed solution: introduce a NEW type of TLV for checksums
that are generated with a more portable CRC32 implementation.

Details
=======

Haproxy CRC32 support adds a checksum to the haproxy protocol header.
This protects against random bitflips that happen before a proxy
header is written to a sender's TCP stack, and after a proxy header
is read from a receiver's TCP stack (during transport over TCP, the
proxy header is always protected by the TCP checksum).

Here's the code from haproxy/src/hash.c:

    unsigned int hash_crc32(const char *key, int len)
    {
        unsigned int hash;
        ...
        hash = ~0;
        while (len--) {
            hash ^= *key++;
            ...
        }
        ...
    }

The bug is that 'key' should be 'const unsigned char *'. Otherwise,
the result depends on the hardware and/or compiler.

Below is a small test program to illustrate these differences.

* On systems where 'char' is a signed type, *key is a signed
  8-bit value in the range -128..+127. In the code above, this is
  converted to int -128..+127, then converted to unsigned, where
  the negative integers become very large positive numbers.

  Example: the 8-bit value 0xff becomes the 32-bit value 0xffffffff.
  This breaks the CRC32 computation, due to non-portable programming.
  See test program below.

* On systems where 'char' is an unsigned type. *key is an unsigned
  8-bit value in the range 0..255. In the code above, this is
  converted to int 0..255, then converned to unsigned 0..255.

  Example: the 8-bit value 0xff becomes the 32-bit value 0xff. This
  does not break the CRC32 computation, but that is just the result
  of dumb luck. Code that is portable would always work this way.

As luck has it, with ix86 systems, 'char' is a signed type. Therefore
the CRC32 computation is screwed up (both i386 and x86_64 a.k.a. amd64).

I wrote a small test program (not included) that compares the result
from haproxy's hash_crc32() implementation and some other crc32
implementations that I found on the web, plus an implementation
that I cobbled together. All portable implementations agree on the
result. hash_crc32() only some of the time agrees with the portable
implementations.

This makes Postfix support for haproxy CRC checks pointless.  It
would have to compute two versions of CRC32: the correct one and
the one that is broken, otherwise CRC32 would only work between
similar systems.

        Wietse

#include <stdlib.h>
#include <stdio.h>

int     main(void)
{
    {
        char    c = 0xff;
        unsigned i = c;

        printf("default char 0xff -> unsigned int 0x%x\n", i);
    }
    {
        unsigned char c = 0xff;
        unsigned i = c;

        printf("unsigned char 0xff -> unsigned int 0x%x\n", i);
    }
    {
        signed char c = 0xff;
        unsigned i = c;

        printf("signed char 0xff -> unsigned int 0x%x\n", i);
    }
    exit (0);
}
Reply | Threaded
Open this post in threaded view
|

Re: broken haproxy crc32 support

Willy Tarreau-3
Hi Wietse,

[CCing haproxy ML and responding inline]

First, thanks a lot for your detailed analysis.

On Sat, Jan 11, 2020 at 09:03:19PM -0500, Wietse Venema wrote:

> I found a portability bug in haproxy's CRC32 implementation, while
> adding adding CRC32 support to Postfix's haproxy2 code. The haproxy
> code produces incorrect results on ix86. Which just happens to work
> as long as everyone is using ix86.
>
> The same bug appears to exist in other hash functions in
> haproxy/src/hash.c.
>
> My proposed solution: introduce a NEW type of TLV for checksums
> that are generated with a more portable CRC32 implementation.
>
> Details
> =======
>
> Haproxy CRC32 support adds a checksum to the haproxy protocol header.
> This protects against random bitflips that happen before a proxy
> header is written to a sender's TCP stack, and after a proxy header
> is read from a receiver's TCP stack (during transport over TCP, the
> proxy header is always protected by the TCP checksum).
>
> Here's the code from haproxy/src/hash.c:
>
>     unsigned int hash_crc32(const char *key, int len)
>     {
>         unsigned int hash;
>         ...
>         hash = ~0;
>         while (len--) {
>             hash ^= *key++;
>             ...
>         }
>         ...
>     }
>
> The bug is that 'key' should be 'const unsigned char *'. Otherwise,
> the result depends on the hardware and/or compiler.

Yes, good catch. It's even why I use ARM a lot, in order to catch such
bugs, but this one managed to slip through it seems :-/

> Below is a small test program to illustrate these differences.
>
> * On systems where 'char' is a signed type, *key is a signed
>   8-bit value in the range -128..+127. In the code above, this is
>   converted to int -128..+127, then converted to unsigned, where
>   the negative integers become very large positive numbers.
>
>   Example: the 8-bit value 0xff becomes the 32-bit value 0xffffffff.
>   This breaks the CRC32 computation, due to non-portable programming.
>   See test program below.
>
> * On systems where 'char' is an unsigned type. *key is an unsigned
>   8-bit value in the range 0..255. In the code above, this is
>   converted to int 0..255, then converned to unsigned 0..255.
>
>   Example: the 8-bit value 0xff becomes the 32-bit value 0xff. This
>   does not break the CRC32 computation, but that is just the result
>   of dumb luck. Code that is portable would always work this way.
>
> As luck has it, with ix86 systems, 'char' is a signed type. Therefore
> the CRC32 computation is screwed up (both i386 and x86_64 a.k.a. amd64).
>
> I wrote a small test program (not included) that compares the result
> from haproxy's hash_crc32() implementation and some other crc32
> implementations that I found on the web, plus an implementation
> that I cobbled together. All portable implementations agree on the
> result. hash_crc32() only some of the time agrees with the portable
> implementations.
>
> This makes Postfix support for haproxy CRC checks pointless.  It
> would have to compute two versions of CRC32: the correct one and
> the one that is broken, otherwise CRC32 would only work between
> similar systems.

No, there is no reason you have to compute both. I looked at the doc
and the doc explicitly states that these hashes respect the standards,
and for CRC32C the RFC is even mentioned. What the doc claims is true
for ARM/PPC, it's wrong on x86. Even if it can break certain things,
the code is already broken as it means that haproxy will not be able
to properly interoperate between two architectures. Additionally,
someone migrating from ARM to x86 would get caught by this bug. Thus
we have to fix haproxy.

HAProxy doesn't emit the CRC32c TLV field in the proxy protocol but
it does validate it if present. This means that everyone using this
validation will compare it against an external agent provided one,
which has zero chance of using haproxy's bogus code, hence it already
does not work. In addition, the CRC validation is very recent (1.9)
so it's not much spread in versions found in distros, so even if
someone would have created their own implementation indoors, it would
be very limited because in practice I think only one distro ships such
a version.

Last, the CRC32 calculation using converters was added in 1.6 and is
wrong as well since it uses the same function. This can affect logs
and/or stick tables (which are the main locations where users will
place this). But similarly this is already wrong so it needs to be
fixed.

All this shows that neither CRC32 nor CRC32c are that much used today,
or that the usage is limited to situations not sensitive to interop
issues. So I want to see it fixed, and we'll put a prominent warning
in next releases. Do you want to propose a patch or should I do it ?

Many thanks!
Willy
Reply | Threaded
Open this post in threaded view
|

Re: broken haproxy crc32 support

Wietse Venema
Willy Tarreau:
> All this shows that neither CRC32 nor CRC32c are that much used today,
> or that the usage is limited to situations not sensitive to interop
> issues. So I want to see it fixed, and we'll put a prominent warning
> in next releases. Do you want to propose a patch or should I do it ?

I trust that you can add the word 'unsigned' to this and the other
hash functions. Additionally, I suggest that you add tests so that
a bad change won't go undetected.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Ready: PROXY protocol v2 support

Wietse Venema
In reply to this post by Tamás Gérczei
HAProxy v2 support is now part of the regular Postfix 3.5 development release.
No support for CRC32, pending a fix in the HAProxy code.

        Wietse
12