Re: HAProxy and proxy protocol support

I realize there is not standard SMTP signaling for this, but neither is the
HAProxy protocol "standard." So, if OP can confirm whether they are
terminating TLS at the HAProxy layer, then it may be "simpler" (in some
sense) to support signaling either in the SMTP conversation or as an X-
header in the message. But no, I don't think this is likely to be a viable
approach. I'm just discussing it for completeness. Among other things, I
don't believe HAProxy's capabilities extend to inserting bytes into
protocols it doesn't understand natively; and SMTP isn't one of those (HTTP
is).

It sounds like you've completed the important parts of the implementation.
I would strongly advocate you base your implementation on PROXY v2, as it
allows for passing of arbitrary values in variable length fields--which
would subsequently allow the HAProxy front end to potentially signal to
features within postfix if you expand the feature e.g., providing values to
insert into X- headers, or values that can be used in filtering rules.
After all the "source IP" can be seen as just one such special case value
in a fixed special case field of the PROXY protocol.

I can't quite completely parse the last paragraph, but it sounds like your
concern is whether the header bytes are transmitted immediately by HAProxy
upon connection setup so as to not delay tcp.c's forking. It does send the
bytes immediately. PROXY is not a bidirectional protocol, and I believe the
implementation in HAProxy pushes those bytes immediately EXCEPT that there
are some configuration options which can tell HAProxy to delay adjudicating
the connection until enough bytes have been transmitted by the origin
connection so that HAProxy can extract necessary headers for itself. For
example, in order to receive the SNI. Anyway, in such cases, I believe
HAProxy would not have opened the downstream proxy connection until that
has already happened. Thus, nothing to worry about.

btw, I find HAProxy's choice of naming the protocol PROXY unfortunate. The
word is terribly overloaded already, and it becomes difficult to know if
one's talking about the protocol, the instance of HAProxy, the downstream
connection, or the politics ;)

Thanks for postfix!


On Mon, Jun 10, 2024 at 7:10 PM Sam Varshavchik <[email protected]>
wrote:

> Andrew Athan writes:
>
> > »I have direct experience with HAProxy's PROXY protocols (v1 & v2) and
> can
> > help with the implementation if you point me to where the best place to
> > implement the protocol handler would be, and how to pass the necessary
> values
> > onward. Both versions of the protocol are quite easy to handle, with v2
> > allowing for some additional parameter passing flexibility. That being
> said,
> > I believe another approach would be to make changes on the HAProxy
> side,
> > assuming there is a signaling capability somewhere in the protocols used
> in
> > the postfix conversation. I don't recall all the details of SMTP but of
> > course this alternative would only work if the conversations are not
> enclosed
> > in TLS and/or (I'm not remembering all the details of SMTP) there is an
> > opportunity to pass information prior to any SMTP level encryption
> (e.g.
> > encode them in the initial EHLO?).
>
> No, there is no standardized mechanism in SMTP for passing along the
> origin
> PI of a proxies connection. Nor there is one for IMAP or POP3, either.
>
> I did some manual testing today, I uploaded builds of courier and courier-
> imap packages to https://www.courier-mta.org/download.html, dated today.
> I
> have no way of knowing whether this would work or not with the real
> HAProxy.
>
> At the same time this removes the code for mostly deprecated and unused
> identd protocol. couriertcpd's --noidentlookup option is removed and
> replaced with -haproxy. Building and installing this version using the
> documneted update process, or building and installing updated rpm or deb
> packages will remove the TCPDOPTS setting from the esmtpd, imap, and
> pop3d
> configuration file (since --noidentlookup is a default option and it no
> longer exists) and reset it to the default one. Adding an "-haproxy"
> option
> to TCPDOPTS, per the updated documentation in the couriertcpd man page,
> enables HAProxy. All connections must either be HAProxy or not. Now that
> I
> talked this out, I'll do some more work and make it possible to
> selectively
> enable HAProxy based on the connecting IP address, so this isn't going to
> be
> the final way of enabling it, so this'll change.
>
> As far as the code changes, the relevant code is in tcpd.c which, after
> accepting each connection on the listening socket it forks, and runs the
> server.
>
> One possible complication here will be the necessity of reading the
> HAProxy
> header before forking off a new process, this means that the next
> connection
> cannot be accepted until then. This is currently unavoidable because it's
> the parent process that keeps track of each active connection and its IP
> address, to enforce rate limiting on connections from the same IP address
> or
> netblock. The parent process needs to know the connecting IP address. I
> would not expect to be any delays here, HAProxy should be prompt it
> pushing
> out the header. We'll see.
>
> _______________________________________________
> courier-users mailing list
> [email protected]
> Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
>

_______________________________________________
courier-users mailing list
[email protected]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users