NGINX Mailproxy

[Maxim Dounin]

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 at domain.tld {8}
> mails>+ go ahead
> nginx>PASSWORD
> mails>BAD UNKNOWN Command
> 
> nginx>3 LOGIN {17}
> mails> + OK
> nginx> user at 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/