Don't blame me for the fact that competent programming, as I view it as an intellectual possibility, will be too difficult for "the average programmer" — you must not fall into the trap of rejecting a surgical technique because it is beyond the capabilities of the barber in his shop around the corner. (Edsger W. Dijkstra)
It's a wonderful, wonderful opera, except that it hurts. (Joseph Campbell)
I've had email from customers saying that MXToolbox says their Kerio Connect mail server is not configured correctly. It reports that they have no PTR record configured (reverse DNS), that the banner is incorrect and that TLS is not enabled. Sounds pretty bad, doesn't it?
And yet when I check these things manually, there is not problem: everything is as it should be. So what's going on here - is MXToolbox wrong or am I?
To find out, I asked MXToolbox to check my own domain. This is the report I got back.
Let's take a look at each of those:
SOA Serial Number Format is Invalid
That's my DNS provider (Cloudflare) and it's an absolutely meaningless message. As MXToolbox itself notes:
It has become common to set your serial number with a date format to make it easier to to manage.
Indeed, that's just what Cloudflare does and it's quite silly to report that as a warning.
SOA Expire Value out of recommended range
According to their docs, MxToolBox will issue this warning if your value is less than 2 weeks or more than 4 weeks. They say those are "suggested values". Well, Cloudflare uses a default of one week - which they say is their "suggested value". It's their DNS servers that will be queried more frequently, so why does that concern MXToolbox? It shouldn't.
Reverse DNS does not match SMTP banner
Really? Actually, it does: my banner says "220 mail.aplawrence.com ESMTP ready" and the reverse DNS is mail.aplawrence.com, so that's correct. They get this wrong for the same reason they get the next two wrong.
EHLO asks that a server list its capabilities and STARTTLS is listed.
15.6662 seconds - Not good!
But actually, that's deliberate - that's the Spam Repellent setting that we do on purpose. MXToolbox even mentions that possibility:
It is also possible your server is "Tar pitting". Tar pitting is a technique used by some email servers to slow down spammers. The idea is that legitimate senders will wait longer to establish a connection than spammers will.
I suspect this is the source of the TLS and reverse banner also: they spit those commands out too early and got disconnected. To find out, I turned on SMTP debugging momentarily and had them try again. As I suspected, I saw this in the log: