Hello!

On Mon, Feb 17, 2020 at 11:40:45AM +0100, Fabian Joël Flückiger wrote:

> I am trying to use nginx as reverse-mailproxy for multiple
> mailservers.Whenever I have a client which connects to the
> nginx-mailproxy via STARTLS or SSL, the NGINX passes a malformed
> LOGIN packets to the backend mailserver, per example:
> (nginx = nginx, mails = backend mailserver, in the first case
> MailEnable, in the second case Dovecot)
>
> nginx>5 LOGIN {18}
> mails>+ go ahead
> nginx>user@domain.tld {8}
> mails>+ go ahead
> nginx>PASSWORD
> mails>BAD UNKNOWN Command
>
> nginx>3 LOGIN {17}
> mails> + OK
> nginx> user@domain.tld {8}
> mails> + OK
> nginx>PASSWORD
> mails>3 NO [AUTHENTICATIONFAILED] Authentication failed.
>
>
> As you can see, nginx adds a suffix to the username, which lets
> the backendserver fail. Wireshark displays this additional data
> as {number}, I can also provide the hex variant of the packets.
> NGINX also adds this suffix, if the username is passed via NGX
> auth header.
> I've tested this with the nginx-full binary from the ubuntu
> repositories, as well as a self-compiled binary.

The "{18}" part is a part of the IMAP literal syntax, see here:

https://tools.ietf.org/html/rfc3501#section-4.3

It is certainly recognized by both backends used in the examples
above. While MailEnable response looks incorrect (it should start
with tag "5" followed by a space), this is probably an artifact of
manual translation of packets into the message. Dovecot's one is
perfectly correct and clearly says that authentication failed.

Most likely the problem is that LOGIN authentication is disabled
on your backends, or it requires SSL or STARTTLS to work (and it
does not work, since nginx uses plaintext connections to the
backends). Check the configuration and logs of your backends to
find out the exact reason.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx