2

My gut feeling says "this isn't a problem and logically cannot really be fixed". I am configuring a backup ISP connection for use with our onsite exchange mail server.

This is what I have set up:

198.51.100.30 -> primary ISP
203.0.113.40 -> backup ISP

The following added to our example.com domain DNS:

mail.example.com. A 198.51.100.30
mail2.example.com. A 203.0.113.40
example.com. MX 10 mail.example.com.
example.com. MX 20 mail2.example.com.

PTR added by relevent ISPs:

198.51.100.30 mail.example.com
203.0.113.40 mail2.example.com

Now, our mail server always worked with just mail.example.com as the banner, all is well, MXToolBox is happy. However, what do I do with the banner regarding our failover MX? Obviously the failover PTR is mail2.example.com and will produce a "Reverse DNS does not match SMTP Banner" in MXToolBox.

Do I just not worry about this or have I not set something correctly?

EDIT: SSL SAN cert installed on mail server has both mail.example.com and mail2.example.com.

1
  • As a comment to my above, I could have used a DNS failover entity such as DNSMadeEasy, leave a single MX record and let the DNS failover happen via a third party (with appropriate firewall rules). However I am going to use the solution I selected as answer as this ensures that the system can use either IP regardless and there will be no chance of a mismatch between firewall sending via IP2 and the third party DNS failover still in TTL for IP1 Sep 19, 2019 at 9:15

4 Answers 4

2

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.

4
  • I'll not edit the question but yes, but I updated my SPF with the extra IP added. Since I have exchange already it possible to get another license but expensive. Since the answer seems to be "not possible without 2 servers" I am now looking at scripting. When our firewall fails over it can run a script as part of the gateway alarm, I am looking at scripting a banner change at this point. Sep 18, 2019 at 7:52
  • In my answer, 284 of 354 words are about how to do this with a single server. Please read it as carefully as I was trying to be thorough. Sep 18, 2019 at 10:38
  • TL;DR: Do not try and change the banner, but use the same hostname in both of your PTR records. The scripting adds complexity; therefore, it's more likely to fail. Sep 18, 2019 at 10:42
  • After more careful consideration, this is the solution I will be using. SSL is via letsencrypt so not a problem with added domains. I will be implementing a "3 A record solution" two 'mx A records' and a third ptr for both IP addresses (both IP addresses with the same third A record as a "round robin"). All three A records will live on the SSL cert, IPs are already on the spf so no change there. Sep 18, 2019 at 19:31
6

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.

4
  • I will edit that the SSL cert also has mail.server.co.uk and mail2.server.co.uk - it is simply the banner that will be different when primary ISP goes down. At that point all incoming mail will be via mail2.server.co.uk and outgoing mail will be mail2.server.co.uk - note that there is only one mail server so as far as I can tell I can only put one SMTP banner hence the question. Sep 17, 2019 at 18:53
  • @AngryCarrotTop now i'm confused. one box with multiple ips from different providers? Then the ISPs need to configure reverse DNS for all IPs to point to the banner name used. Your question wording sounded like you have two servers, and two connections, and the backup server kicks in when ISP one goes down. In which case my answer applies.
    – ivanivan
    Sep 17, 2019 at 19:52
  • one exchaneg server not servers. PTR (for domain listed in each MX) is registered with each ISP - i.e. mail.example.com with ISP1 and mail2.example.com with ISP2. Sep 18, 2019 at 7:39
  • @AngryCarrotTop in that case, all reverse DNS should map to the banner name used. Keep the one DNS entry for mail2 so that your backup mx delivery will work, although having an actual second server for the backup mx is better.
    – ivanivan
    Sep 18, 2019 at 12:57
1

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

  1. 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.)

  1. 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

3
  • This was my thinking but I was concerned that failover IP2 would trigger spam traps. Ironically enough Im not sure what my setup would do - I use puremessage as my spam filter so would need to look up "what does puremessage do with banner mismatches". Oddly enough, bbc.co.uk secondary mx has a banner mismatch.... Sep 18, 2019 at 19:36
  • Spam detection is based on the behavior of the sender , not of the behavior of receiving (your) mail server
    – HBruijn
    Sep 18, 2019 at 20:09
  • In this situation, however, the secondary MX is actually the same server. If ISP1 gets down, mail will be sent using the secondary IP. That's why it's problematic. Sep 19, 2019 at 3:57
1

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.

2
  • In the end this was a moot point. We migrated to office 365 and thus the email issue was a non-concern. May 7, 2021 at 7:26
  • Yes, I understand that answering that question after 1.5 year after is probably not very helpful anyway. Still I wanted to share some thoughts, especially about widely misunderstood SMTP banner meaning. May 8, 2021 at 8:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .