SMTP banner mismatch with multiple MX records

Solution 1:

On best practices: have two MX servers

The best option is to have two servers i.e. configure another Exchange (or alternatively an opensource based SMTP server, e.g. Postfix) as a backup/secondary MX server. In most cases the server itself may cause more downtime than the Internet connectivity. As the banner mismatch is only an issue on outbound mail, this server could perfectly fine be the mail2.example.com in your current configuration.

A single server with two Internet connections

Configuration for outbound mail

Second approach would be to have both connections configured with the same hostname, as it in fact is the same host with to different IP addresses and routes. That could be achieved with a round-robin DNS configuration + matching PTR records & SMTP banner e.g.

mail.example.com. A 198.51.100.30
mail.example.com. A 203.0.113.40
40.113.0.203.in-addr.arpa. PTR mail.example.com.
30.100.51.198.in-addr.arpa. PTR mail.example.com.

Do not forget to add an SPF record allowing both IP address to send mail, e.g.

example.com. IN TXT "v=spf1 +ip4:198.51.100.30/32 +ip4:203.0.113.40/32 -all"

Configuration for inbound mail

If you want to prefer the first ISP over the secondary on inbound mail (for example if it has better bandwidth), you could separate your MX configuration from this e.g. by adding

mx1.example.com. A 198.51.100.30
mx2.example.com. A 203.0.113.40
example.com. MX 10 mx1.example.com.
example.com. MX 20 mx2.example.com.

The banner mismatch is not a problem for inbound mail, so this would be perfectly fine.

Certificate

To keep the certificate valid for both configurations it should now have SANs for all mail.example.com, mx1.example.com and mx2.example.com. Generally this doesn't matter so much, as mail server certificates are only seldom actually valitated, and most mail systems would still allow falling back to unencrypted connections.

Instead of CA based certificate validation, DNS-based Authentication of Named Entities (DANE, RFC 6698) is a proposed alternative, allowing verification of self-signed certificates, too. For backwards compatibility it's not possible to configure an SMTP server to only allow encrypted connections, which leaves a hole for MitM attacks for connections that could be established over TLS. With DANE it's possible to declare that TLS should be used for the connection and only certificates published in the DNS zone should be allowed.

Solution 2:

You only need to worry about what the banner name is when mail2 is used to send an outgoing mail. And in that case, it should still match the reverse DNS for the IP it is using. About the only thing left to check is that the proper name is used in any SSL certs (all 3 names need to match for each server - banner/helo name, name in SSL cert, and reverse lookup) and that the backup server is listed in any SPF records, etc. As far as that goes, my SPF records simply list "all MXs for this domain".

So yes, as far as I can tell with what you've posted you should be good to go.

Solution 3:

You are right with your gut feeling that this is not an actual issue because of two things:

MX records govern where you want to receive incoming email messages for your email.
Your backup MX record is not intended to be used to send mail, only to receive incoming mail.

Receiving email is easy: Although some senders may have have slightly more strict checks on for instance the contents of a TLS certificate for backwards compatibility almost all senders will simply deliver mail to your MX records as long as something is both listening on TCP port 25, responds correctly to SMTP protocol messages and is returning a "250 Requested mail action completed successfully" response after accepting mail for delivery to you.

(It is only sending email reliably that definitely requires much more careful configuration and protocol adherence.)

The incoming SMTP server does not need to identify itself at all. It only has to accept messages it wants to receive and reject any it does not. (Only the sender is required to identify itself.)

As far as I know only the actual SMTP response return code number in almost all server messages is relevant for the protocol itself. The text following the SMTP server response code not only in the banner message, but also in error and most other messages is only interesting for debugging purposes / human interaction and not relevant at all from a SMTP protocol perspective (and mostly ignored). Please note that is only for server messages, to combat spam SMTP servers themselves are much more strict on what they require when receiving messages from clients/other mail servers.

From RFC 5321 :

SMTP server implementations MAY include identification of their software and version information in the connection greeting reply after the 220 code, a practice that permits more efficient isolation and repair of any problems. Implementations MAY make provision for SMTP servers to disable the software and version announcement where it causes security concerns

Solution 4:

One of the ways to configure Postfix in situation like yours is to define two outgoing smtp transport interfaces in master.conf:

mail.example.com-out  unix -       -       n       -       -       smtp
   -o smtp_bind_address=198.51.100.30
   -o smtp_helo_name=mail.example.com
   -o syslog_name=postfix-mail.example.com

mail2.example.com-out  unix -       -       n       -       -       smtp
   -o smtp_bind_address=203.0.113.40
   -o smtp_helo_name=mail2.example.com
   -o syslog_name=postfix-mail2.example.com

Then define 'default_transport' parameter in your main.cf:

default_transport = mail.example.com-out

Finally, create a shell script that checks your ISP connections regularly by cronjob and switches Postfix transport on the fly. Here is an example of such bash script (assuming your two ISPs connected to eth0 and eth1 interfaces. Alternatively, use -S switch for ping command below defining source ip address: ping -S 198.51.100.30 -c 2 $SERVERIP... - particular way depends on your configuration of two gateway interfaces/routing table), it shoud be run under root:

#!/bin/bash
SERVERIP=8.8.8.8

ping -I eth0 -c 2 $SERVERIP > /dev/null 2>&1
if [ $? -ne 0 ]
then
    echo "ISP1 is down"
    ping -I eth1 -c 2 $SERVERIP > /dev/null 2>&1
    if [ $? -ne 0 ]
        echo "ISP2 is also down"
    else
        echo "Switching to ISP2"  
        sed -i 's/mail.example.com-out/mail2.example.com-out/g' /etc/postfix/main.cf
        systemctl reload postfix
    fi  
else
   echo "ISP1 reachable"
   if grep -q 'mail2.example.com-out' /etc/postfix/main.cf; then
      echo "Switching back to ISP1"
      sed -i 's/mail2.example.com-out/mail.example.com-out/g' /etc/postfix/main.cf
      systemctl reload postfix
   fi
fi

Root's crontab (run 'crontab -e' under root to edit) example to run the script once in every 2 minutes:

*/2 * * * * /path/to/your/script.sh 2>&1 | ts | tee -a /var/log/check_postfix_transport.log

Rationale:

SMTP banner is defined only for the smtp daemon (server) receiving the incoming connection from the smtp client. With the SMTP banner server identifies itself for the connecting client during session initiation. It is optional, however.

From RFC 5321:

3.1 Session Initiation

An SMTP session is initiated when a client opens a connection to a server and the server responds with an opening message.

SMTP server implementations MAY include identification of their software and version information in the connection greeting reply after the 220 code.

Client (for example another server that wants to deliver email to the incoming server) never sends SMTP banner to receiving server. What is sends to server is EHLO/HELO host name and this is the very thing that is checked by servers against PTR mismatch with regard to spam, etc.

From RFC 5321:

3.2 Client Initiation

Once the server has sent the welcoming message and the client has received it, the client normally sends the EHLO command to the server, indicating the client's identity.

Based on EHLO/HELO the server may check PTR (if SMTP sending party's ip resolves back to its host name) and/or spf and finally decides if it really wants to receive or relay the email message originating from the SMTP client.

Based on this, what you should do in general is to care about EHLO commands that your SMTP server sends to other servers when it wants to send email messages to them (and acts as an SMTP client during these connections). You should ensure that your SMTP server uses proper source ip address and sends proper EHLO host name that resolves back to that ip used for connection. And you may basically ignore SMTP banner simply because it is about receiving email, not sending.

I guess that mxtoolbox also mixes up SMTP Reverse DNS Mismatch and SMTP Banner Mismatch and checks the latter for no reason, and its wording about SMTP banner with that regard is partially incorrect. SMTP rDNS Mismatch does matter, SMTP Banner Mismatch does not. Again, SMTP banner is sent by the recieving server (that is why it is defined in Postfix in 'smtpd_banner' parameter, not in 'smtp_banner') and not by the sending/relaying client. Thus it has nothing to do with spam, etc.

In this sense the SMTP banner serves the same purpose that certificates do to identify the receiving server, though without the third party chain of trust.