Re: [exim-dev] [exim-cvs] Proxy Protocol - Server support

Top Pagina
Delete this message
Reply to this message
Auteur: Phil Pennock
Datum:  
Aan: Todd Lyons
CC: exim-dev
Onderwerp: Re: [exim-dev] [exim-cvs] Proxy Protocol - Server support
On 2013-12-02 at 08:25 -0800, Todd Lyons wrote:
> What would a control variable do for us? Once it gets to the ACL
> processing, the proxy negotiation has already failed. Is your
> contention that limiting to only the QUIT command is short sighted?


I didn't check the relative position of acl_smtp_connect and the current
logic, but it seemed reasonable that someone might use various checks in
a connect-time ACL to decide whether or not the source host is a proxy
and toggle on the state then, much as is done for `control =
submission`.

It's not worth worrying about if that's not practical.

> The spec very clearly spells out that a connection must be configured
> to be a proxy connection, or a regular connection, and not do any kind
> of auto-detection. I followed that thought process to come to the
> conclusion that for a proxy configured host, it must pass, or no smtp
> commands are to be allowed. I welcome better suggestions.


acl_smtp_connect is at connect time, before the first SMTP command.
It's more of an "acl_tcp_connection_received" ACL check, but named with
"smtp" presumably to keep the SMTP/non-SMTP distinction isolated (and
because there was no reason to consider receiving non-SMTP over TCP).

> It does seem easier to just make log_extra_selector a 64 bit int.


Be aware that the only usage of 64-bit right now (that I recall) is as
the default size for int_eximarith_t and can be overriden on a per-OS
basis. However, it doesn't look like any OS actually does so.

I'll post to exim-users asking for notice from anyone building Exim on a
platform which doesn't support 64-bit integers.

> I used the declaration and code from the spec. I didn't consider that
> alignment might be off.


Okay. I think a compiler would be insane to do so, but compilers seem
to do insane things sometimes.

> > That flushes to the end of the next \n line. Is that really what is
> > wanted at this point?
>
> It there a better way to remove everything from the input buffer until
> the newline?


It was more "there's corrupt data, why stop at a newline?".

-Phil