Authenticating SMTP Proxy

Question

I have acquired a number of mail users, and I'm wanting to transition them away from their current mail server and onto mine. I've set up perdition as a proxy which will allow me to proxy IMAP and POP connections - and I have control of the DNS used to direct them to the appropriate mail server. I do not have access to the old mail server.

The mail proxy server is running Linux

Unfortunately I suspect a lot of people are using the same server for POP3 and SMTP.

I am wanting to set up an SMTP proxy so I can seemlessly provide SMTP services to the customers during the transition - without an open mail relay. It does not appear that Perdition offers this solution natively.

Is anyone aware of a solution which either proxies SMTP requests (including AUTH requests) - ideally with the ability to map which requests go to which backend ? [ I've not tried an IPTables DNAT rule - I suspect this might work, but I loose the ability to do authentication to different servers on a per domain / client basis, which makes migration substantially harder ].

EDIT

I have tried configuring Dovecot as a director / proxy in place of Perdition. This works fine for IMAP and POP, but not for SMTP - Specifically it will authenticate based on username or domain name - it does not check the actual credentials against the SMTP server.

Answer 1

For Postfix, see Andy Beverley's article SMTP Authentication and Postfix.

START=yes
MECHANISMS="rimap"
MECH_OPTIONS="imap.example.com"

I would also configure postfix to route directly to your new SMTP Server as a relay. Add the IP of your new server to 'my networks' and set relayhost to the new smtp server.

Point it to the perdition proxy for dovecot where the imap server is, it's plain auth between the saslauthd system and imap so you'll need to use the perdition proxy as non-secure to localhost (or just block external access to 143 pending your setup details)

Answer 2

Is anyone aware of  a solution which … proxies SMTP requests (including AUTH requests) – ideally with the ability to map which requests go to which backend

Since Nginx 1.19.4, the Nginx mail module can fulfill all these requirements.

Instructions

1. Follow the official "Configuring NGINX as a Mail Proxy Server". But only create one server { … } entry, for SMTP proxy.

2. Enable proxying the authentication by adding directive proxy_smtp_auth on; to your server block (manual, related answer). This is the functionality that appeared first in Nginx version 1.19.4. (Check with nginx -v. Ubuntu 20.04 still has 1.18.0, for example.)

3. Run an Nginx HTTP Authentication Server. This is a small server speaking a special Nginx-defined HTTP based protocol, which can be used both for authentication and for mapping requests to different SMTP backend servers.

HTTP Authentication server options

• Custom server script. Examples are available in Python, PHP, or Perl. Best suited for simple cases, esp. when you need the authentication server only to select the backend, while outsourcing authentication to that backend via proxy_smtp_auth on.

• Server and SQL database. For more advanced use cases, there is the Nginx Mail Auth HTTP Server, written in Go. It can do both authentication and backend selection based on data in a SQL database.

• Nginx config for single backend referral. In the simplest case, you want to refer each client to the same backend server. This can be done with Nginx itself (see). (While this may work, I found it difficult to debug.)

• Nginx config for authentication and single backend referral. If you only need authentication and referral to a single backend server, you still can do that with Nginx itself. This uses HTTP Basic Auth, with usernames and hashed passwords stored in a file. (While this may work, I found it difficult to debug.)

Example

A complete Nginx config example would look like this (not tested, probably not fully functional yet):

mail {
    server_name smtp.example.com;

    # Configure host and port of your Nginx HTTP Authentication server.
    auth_http localhost:8278;

    proxy_pass_error_message on;

    starttls on;
    ssl_certificate     /data/cert/fullchain.pem;
    ssl_certificate_key /data/cert/privkey.pem;

    server {
        listen           25;
        listen           587;
        listen           465 ssl;
        protocol         smtp;
        smtp_auth        login plain cram-md5;
        proxy_smtp_auth  on;
    }
}

Answer 3

A Stackoverflow user had the same issue, and created their own solution for this scenario: go-smtpproxy. From the README:

The purpose of this is to provide functions that act as a server to receive SMTP messages from your downstream client. These SMTP messages are relayed through to an upstream server.

The command / response exchanges are passed on transparently.