The XCLIENT command uses xtext encoding for attribute values, as specified in https://www.postfix.org/XCLIENT_README.html. Reported by Igor Morgenstern of Aisle Research.
In particular, an untagged CAPABILITY response as described in the interim RFC 3501 internet drafts was seen in various IMAP servers. Previously resulted in a broken connection, now an untagged response is proxied to client.
When establishing a connection to the backend, nginx blocks reading from the client with ngx_mail_proxy_block_read(). Previously, such events were lost, and in some cases this resulted in connection hangs. Notably, this affected mail_imap_ssl.t on Windows, since the test closes connections after requesting authentication, but without waiting for any responses (so the connection close events might be lost). Fix is to post an event to read from the client after connecting to the backend if there were blocked events.
Maximum size for reading the PROXY protocol header is increased to 4096 to accommodate a bigger number of TLVs, which are supported since cca4c8a715de. Maximum size for writing the PROXY protocol header is not changed since only version 1 is currently supported.
The change is mostly the same as the SMTP one (04e43d03e153 and 3f5d0af4e40a), and ensures that nginx is able to properly handle or reject multiple IMAP commands. The s->cmd field is not really used and set for consistency. Non-synchronizing literals handling in invalid/unknown commands is limited, so when a non-synchronizing literal is detected at the end of a discarded line, the connection is closed.
The change is mostly the same as the SMTP one (04e43d03e153 and 3f5d0af4e40a), and ensures that nginx is able to properly handle or reject multiple POP3 commands, as required by the PIPELINING capability (RFC 2449). The s->cmd field is not really used and set for consistency.
Previously, if there were some pipelined SMTP data in the buffer when a proxied connection with the backend was established, nginx called ngx_mail_proxy_handler() to send these data, and not tried to send the response to the last command. In most cases, this response was later sent along with the response to the pipelined command, but if for some reason client decides to wait for the response before finishing the next command this might result in a connection hang. Fix is to always call ngx_mail_proxy_handler() to send the response, and additionally post an event to send the pipelined data if needed.
Activated with the "proxy_protocol" directive. Can be combined with "listen ... proxy_protocol;" and "set_real_ip_from ...;" to pass client address provided to nginx in the PROXY protocol header.
If we need to be notified about further events, ngx_handle_read_event() needs to be called after a read event is processed. Without this, an event can be removed from the kernel and won't be reported again, notably when using oneshot event methods, such as eventport on Solaris. For consistency, existing ngx_handle_read_event() call removed from ngx_mail_read_command(), as this call only covers one of the code paths where ngx_mail_read_command() returns NGX_AGAIN. Instead, appropriate processing added to the callers, covering all code paths where NGX_AGAIN is returned.
The proxy_smtp_auth directive instructs nginx to authenticate users on backend via the AUTH command (using the PLAIN SASL mechanism), similar to what is normally done for IMAP and POP3. If xclient is enabled along with proxy_smtp_auth, the XCLIENT command won't try to send the LOGIN parameter.