David Touzeau:
> Dear
>
> We are facing an problem that we cannot resolve...
> Our main goal is to implement a load-balancer in front of Postfix (HaProxy).
> We have made a discuss with HaProxy founder in order to implement the
> XCLIENT protcol but this is difficult for him to implement such protocol.
FYI nginx implements XCLIENT (and more). But it does not matter,
since postscreen has no proxy support.
> In other way it seems that PostScreen is not really compatible with the
> proxy protocol.
First, there needs to be a configuration parameter that tells
postscreen what kind of proxy command will be prepended to the
client's SMTP stream.
/etc/postfix/main.cf:
# Is there a better name than "proxy protocol"?
postscreen_proxy_protocol = whatever
With this, postscreen will drop connections that fail to conform
to the configured protocol.
Regardless of command format details, if the proxy prepends a command
to the client's SMTP stream, then postscreen must use unbuffered
I/O to read that command. If buffering were turned on, the buffering
layer could read past the proxy's <CR><LF> and eat up part of the
client input kind-of like CVE-2011-0411.
A rough estimate of what this requires:
- A new main.cf parameter and documentation.
- A way to turn off buffering on VSTREAMs. Alternative: use low-level
read system calls and re-invent VSTREAM timeout/etc. error handling.
Either this may take a dozen or so lines of code.
- A new postscreen code module with generic hook to prepend proxies.
- An event-driven loop that reads the proxy command one character
at a time until <CR><LF>, length exceeded, EOF, time limit, or
other error. Another dozen lines.
- A proxy command parser that does all the necessary sanity checks
(valid address syntax, numerical TCP ports in the range 1..65535),
no missing or extra fields. Another dozen lines.
- Reuse the existing postscreen data structures that are now filled
with endpoint information from getpeername() and getsockname().
Wietse
