Now host name resolved from client address is validated to only contain the characters specified in RFC 1034, Section 3.5. The validation allows to avoid injections when using the resolved host name in auth_http and smtp proxy. Reported by Asim Viladi Oglu Manizada, Colin Warren, Xiao Liu (Yunnan University), Yuan Tan (UC Riverside), and Bird Liu (Lanzhou University).
They might be reused in a session if an SMTP client proceeded unauthenticated after previous invalid authentication attempts. This could confuse an authentication server when passing stale credentials along with "Auth-Method: none". The condition to send the "Auth-Salt" header is similarly refined.
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.
As long as a read event is blocked (ignored), ngx_handle_read_event() needs to be called to make sure no further notifications will be triggered when using level-triggered event methods, such as select() or poll().
When using SMTP with SSL and resolver, read events might be enabled during address resolving, leading to duplicate ngx_mail_ssl_handshake_handler() calls if something arrives from the client, and duplicate session initialization - including starting another resolving. This can lead to a segmentation fault if the session is closed after first resolving finished. Fix is to block read events while resolving. Reported by Robert Norris, http://mailman.nginx.org/pipermail/nginx/2019-July/058204.html.
This is needed to allow TLS client certificate auth to work. With ssl_verify_client configured, the auth daemon can choose to allow the connection to proceed based on the certificate data. This has been tested with Thunderbird for IMAP only. I've not yet found a client that will do client certificate auth for POP3 or SMTP, and the method is not really documented anywhere that I can find. That said, its simple enough that the way I've done is probably right.
The bug had appeared in nginx 1.5.6 (04e43d03e153). Reported by Chris Boulton.
Missed during introduction of the SMTP pipelining support (04e43d03e153, 1.5.6). Previously, the check wasn't needed as s->buffer was used directly and the number of arguments didn't matter. Reported by Svyatoslav Nikolsky.