NGiNX does not pass SMTP AUTH command to server?

Dear all,

I am by no means an experienced nginx user, but I have nginx working for
HTTP & IMAP and am now trying to add SMTP to the mix.

I require authentication for the SMTP server and am experiencing a
problem in that the first AUTH command that comes from the client does
not get passed through to the server by nginx; only the second one does.
Here is a telnet session to illustrate (an email client like Thunderbird
would of course not send the second AUTH command):

telnet aurichvm04 465
Trying 192.168.1.154…
Connected to aurichvm04.ostfriesland.
Escape character is ‘^]’.
220 aurichvm04 ESMTP ready
AUTH PLAIN <base64 encoded user & password>
235 2.0.0 OK
AUTH PLAIN <base64 encoded user & password>
235 2.7.0 Authentication successful

According to wireshark, rather than sending the AUTH command the first
time, nginx just sends a HELO command. The second time the AUTH command
is issued by the client, nginx passes it through (as I would expect it
to do the first time round).

I include my nginx.conf and sites-availabe/default below. I am using the
current Debian unstable package (0.7.65-1). My server is Postfix.

I few notes on the config:

  • I am using a trivial authentication server.
  • I have turned ssl off for test purposes.
  • I have turned xclient off because Postfix does not accept the xclient
    login attribute. (I don’t believe it is required?)

If you could help that would be great!

Thanks a lot & best regards,
Andree

–8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<–
nginx.conf:

user www-data;
worker_processes 1;

error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;

events {
worker_connections 1024;
}

http {
include /etc/nginx/mime.types;

 access_log         /var/log/nginx/access.log;

 sendfile           on;

 keepalive_timeout  65;
 tcp_nodelay        on;

 gzip               on;
 gzip_disable       "MSIE [1-6]\.(?!.*SV1)";

 include            /etc/nginx/conf.d/*.conf;
 include            /etc/nginx/sites-enabled/*;

}

mail {
ssl off;

ssl_certificate
/etc/ssl/certs/aurichvm04.ostfriesland_cert.pem;

ssl_certificate_key
/etc/ssl/private/aurichvm04.ostfriesland_key.pem;
ssl_session_timeout 5m;

 server {
        listen              aurichvm04.ostfriesland:993;
        protocol            imap;

        imap_capabilities   "IMAP4rev1" "SORT" "THREAD=REFERENCES"

“MULTIAPPEND” “UNSELECT” “LITERAL+” “IDLE” “CHILDREN” “NAMESPACE”

        proxy               on;
        auth_http           127.0.0.1:9000/auth-imap/;
        }

 server {
        listen              aurichvm04.ostfriesland:465;
        protocol            smtp;

        smtp_capabilities   "SIZE 10240000" "VRFY" "ETRN"

“ENHANCEDSTATUSCODES” “8BITMIME” “DSN” “AUTH PLAIN LOGIN”

        proxy               on;
        xclient             off;
        auth_http           127.0.0.1:9000/auth-smtp/;
        }

}

–8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<–
sites-available/default:

server {
listen localhost:9000;

   access_log       /var/log/nginx/localhost_AUTH.access.log;

   location = /auth-imap/ {
            add_header Auth-Status OK;
            add_header Auth-Server 192.168.1.152;
            add_header Auth-Port 143;

            empty_gif;
   }

   location = /auth-smtp/ {
            add_header Auth-Status OK;
            add_header Auth-Server 192.168.1.152;
            add_header Auth-Port 25;

            empty_gif;
   }

}

server {
listen 443;
server_name aurichvm04.ostfriesland;

   ssl                      on;

ssl_certificate
/etc/ssl/certs/aurichvm04.ostfriesland_cert.pem;

ssl_certificate_key
/etc/ssl/private/aurichvm04.ostfriesland_key.pem;
ssl_session_timeout 5m;

access_log
/var/log/nginx/aurichvm04.ostfriesland_HTTPS.access.log;

   location / {
            proxy_pass              http://emden3:8080;
            proxy_redirect          off;
            proxy_set_header        Host $host;
            proxy_set_header        X-Real-IP $remote_addr;
            proxy_set_header        X-Forwarded-For

$proxy_add_x_forwarded_for;
}
}

Hello!

On Sun, Feb 28, 2010 at 08:02:19PM +1100, Andree Leidenfrost wrote:

[…]

According to wireshark, rather than sending the AUTH command the first
time, nginx just sends a HELO command. The second time the AUTH command

Yes, nginx doesn’t pass AUTH command to backend for SMTP. You
should configure backend to accept mail from nginx without
authentication.

[…]

I few notes on the config:

  • I am using a trivial authentication server.
  • I have turned ssl off for test purposes.
  • I have turned xclient off because Postfix does not accept the xclient
    login attribute. (I don’t believe it is required?)

You need postfix patched to work with nginx’s xclient on.
Patch is here:

http://citrin.ru/nginx:xclient-login-patch

Maxim D.

Hi Maxim,

Thank you for your turbo-swift reply and your explanations!

NGiNX authenticates fine for IMAP and POP3. Is it not somewhat
inconsistent that it does not authenticate for SMTP? Especially as it
seems to work the second time??? If the SMTP server can take care of
authentication in the first place, would it not be a good thing to
utilise this rather than relying on an additional authentication
mechanism?

Has the patch you mention actually been put in front of the Postfix
people? I have no idea what RFCs may exist for this xclient stuff (and I
have not really been able to find anything definitive on this on the
internet), but changing the code of an MTA is something that would not
happen on a whim, I guess?

Thanks again & best regards,
Andree

Hello!

On Sun, Feb 28, 2010 at 10:18:59PM +1100, Andree Leidenfrost wrote:

NGiNX authenticates fine for IMAP and POP3. Is it not somewhat
inconsistent that it does not authenticate for SMTP? Especially as it
seems to work the second time??? If the SMTP server can take care of
authentication in the first place, would it not be a good thing to
utilise this rather than relying on an additional authentication
mechanism?

It is believed that there is no need to re-authenticate against
smtp backend as it doesn’t provide any additional value (unlike
POP3 and IMAP where it’s required to obtain access to specific
mailbox).

Has the patch you mention actually been put in front of the Postfix
people?

AFAIK, no. But I may be wrong, I’m not the author of the patch
in question.

I have no idea what RFCs may exist for this xclient stuff (and I
have not really been able to find anything definitive on this on the
internet),

XCLIENT was originally implemented in Postfix, and there is no
RFC. There is also patch for Exim to support it (developed by
Vsevolod Stakhov, cebka.pp.ru; the patch was made for nginx and
supports LOGIN attribute).

[…]

Maxim D.

p.s. Please do not top-post. Thank you.

Hi Maxim!

On Sun, 2010-02-28 at 15:41 +0300, Maxim D. wrote:

It is believed that there is no need to re-authenticate against
smtp backend as it doesn’t provide any additional value (unlike
POP3 and IMAP where it’s required to obtain access to specific
mailbox).

I for once would like to use the SMTP backend for authentication. :wink:
(This is why I use a static/primitive http_auth server.) NGiNX seems to
be able to pass the AUTH command through the second time, so on
principle, I suppose, this could also work the first time? (You decide
whether this is worthwhile to support by NGiNX.)

As a side note, I would really appreciate to be able to securely
communicate to any of the backends via SSL from NGiNX, be that POP3,
IMAP or SMTP or whatever - it’s letters versus postcards even within
organisations - I like the privacy of letters.

XCLIENT was originally implemented in Postfix, and there is no
RFC. There is also patch for Exim to support it (developed by
Vsevolod Stakhov, cebka.pp.ru; the patch was made for nginx and
supports LOGIN attribute).

Thank you! If this is a Postfix thing in the first place, the Postfix
people should really be talked to, I guess? Not much point having a
patch that may never make it into upstream Postfix (unless you operate
in an environment where components are hand-patched all the time)?

[…]

Maxim D.

p.s. Please do not top-post. Thank you.

Thanks a lot & best regards,
Andree