mxtoolsbox SuperTool Test 1 Reverse DNS name mismatch

[jpduyx]

when i used https://mxtoolbox.com/SuperTool.aspx to test my new docker-mailserver based installation I got a warning that my reverse DNS name doesn't match with the announced name of the docker mailserver and that this increases the SPAM points in some cases. Postfix was announcing the hostname as .mydomain ... but this randomly generated docker name is nowhere in my DNS nor in the Reverse DNS PTR of my ISP level (which i can't control like probably many others also can't control)

I found a fix, by manually setting the docker hostname to the reverse dns name of my host ... (myhostname.ISPNNAME). mxtoolbox test all became green. I was happy.

Then next day my ISP contacted me and said i was "spamming" them.
my mailserver was sending the logwatch reports to

postmaster@ispname ... instead of to [email protected]
(this is also written in the mailserver.env example I see now after I became a spammer)

Could postfix be configured to announces the "correct Reverse DNS name" automagically without any user intervention? The docker generated host name is nowhere to be found in any DNS and things seam to work. So if that works ... the announcing servername could perhaps also be the Reverse DNS name ... this could be configured at container creation by obtaining the reverse DNS?

Or would that break other stuff?

[polarathene]

but this randomly generated docker name

You shouldn't have the default container ID if you set hostname for the container as our docs instruct you to do?

Then next day my ISP contacted me and said i was "spamming" them.
my mailserver was sending the logwatch reports to

Yes, the hostname is used for various services / features in DMS. It's assumed that you are in control of it.

Or would that break other stuff?

Not sure, but you really shouldn't be configuring for domains you don't actually own. (EDIT: I just noticed the example you gave is tailored to your host, not as generic as I thought when I responded)

You can also have:

• Multiple domains that point to a single IP.
• Multiple IP that have rDNS to a single domain.

You're not always going to get a perfect match there, I don't think you'll find many real services being that strict. They should just check that your EHLO resolves to an IP that rDNS domain resolves back to the same IP. That is what Postfix supports as a check, but it can perform a more relaxed one too.

Consider that you're perhaps just chasing a score here that isn't that important.

If you're really concerned about delivery reputation / success, you should relay through a service like SendGrid. They're better established at avoiding the problems you're concerned about.

---

Could postfix be configured to announces the "correct Reverse DNS name" automagically without any user intervention?

If you really insist on this, Postfix has smtp_helo_name, you can add that with our postfix-main.cf to send a different hostname FQDN.

Perhaps you can contact your ISP to change the rDNS to point to your actual domain for DMS hostname.

[polarathene]

I think when you send mail to another MTA, and it fails the bounce is sent back to your MTA (which if necessary may be sent back elsewhere if it's not an address DMS manages). I can't quite recall where that information is from, but I think it might have been the HELO/EHLO.

You can inspect the raw mail message by sending a mail to another MTA like Gmail, and it should mention in the return-path header IIRC. It should be to the MTA rather than the sender, at least I recall some failures related to Mailgun service when some DNS records weren't sent, and the logs indicated that mail was sent back to the sending MTA rather than the sender domain.

If that's the case, then using that rDNS to fool the scoring system is not doing you many favours when something goes wrong. It'd try deliver to an MTA with that rDNS name you provided I think, which wouldn't be your DMS instance and probably cause similar complaints from the ISP allowing you to send mail?

[jpduyx]

#You shouldn't have the default container ID if you set hostname for the container as our docs instruct you to do?

Thanks I re-read the example / instructions and found it too... Not sure anymore how it got missing from my config. I tried a lot to make it work behind Caddy (certificates) and with a webmail server ... Now I have put the hostname in my docker-compose config and I'm probably not spamming anymore since I found the logwatch report in my own mailbox...

#Consider that you're perhaps just chasing a score here that isn't that important.
Most probably I am. Since my old mailserver has been running fine with the out of the box exim announcement ... like :

reverse.DNS.name ESMTP Exim VERSION Tue, 13 Feb 2024 10:49:11 +0100

For me it seams that the announced name of the mailserver is just a name. But announcing the rDNS makes at least the mxtoolbox test and perhaps some spamfilters happier?

I was just wondering would it be wrong to configure the mailserver announcement name at creation time of a container to be the rDNS name (which at least exists somewhere and can be reached, is probably also known to the owner of the server and means something in the real world) instead of the randomly generated docker container name, in cases like mine where by mistake no hostname was configured)

I was meaning to ask my question in general based on my n=1 experience as I think not everybody owns or can easily (ask to) change the rDNS ... and perhaps make DMS a bit more fool proof for fools like me that somehow lost the hostname in their configuration.

[polarathene]

For me it seams that the announced name of the mailserver is just a name. But announcing the rDNS makes at least the mxtoolbox test and perhaps some spamfilters happier?

It's announcing yourself to the MTA you're connecting to for delivery/relay. A common check can be to validate that there is a valid DNS entry for that name, and that it resolves to the IP the connection is made from.

Doesn't have to be rDNS that's an additional more strict test, DMS does not have that enabled when it receives mail for example.

---

I was just wondering would it be wrong to configure the mailserver announcement name at creation time of a container to be the rDNS name (which at least exists somewhere and can be reached, is probably also known to the owner of the server and means something in the real world) instead of the randomly generated docker container name, in cases like mine where by mistake no hostname was configured)

And how would you do that?

DMS container is typically in a private IP range with some ports published, or via reverse proxy (Traefik can handle TCP routers, Caddy requires a separate app Caddy-L4). This is only something that'd work with host mode networking... except that a host can have multiple interfaces, so it's not guaranteed then which one is correct either.

hostname is more correct and what should be used. We are very clear on configuring this. Far less room for error with hostname than attempting to know the rDNS name (which may not always point back to the same IP that DMS is connecting from).

I think not everybody owns or can easily (ask to) change the rDNS

Correct, and that's why you don't see it as a mandatory requirement. Even when it is met, it doesn't really establish that much trust that the MTA is any less likely to be a spammer. If that's all it took, capable spammers could favor that to appear trustworthy. It does not add much value to the less strict check of DNS lookup on EHLO FQDN, and that it resolves back to the same IP from the EHLO client connecting.

---

instead of the randomly generated docker container name, in cases like mine where by mistake no hostname was configured
make DMS a bit more fool proof for fools like me that somehow lost the hostname in their configuration.

I'm not quite sure how you got DMS to run without configuring the hostname:

$ docker run --rm -it mailserver/docker-mailserver:13

[   INF   ]  Welcome to docker-mailserver v13.3.1
[   INF   ]  Checking configuration
[  ERROR  ]  Setting hostname/domainname is required
[  ERROR  ]  Shutting down
2024-02-13 21:21:54,940 WARN received SIGTERM indicating exit request

• Even if you set a hostname, it needs to be an FQDN (example.com, not example), otherwise it'll fail to start too.
• When you use a program like swaks if connecting to DMS and the EHLO is not an FQDN DMS also rejects accepting mail.

[jpduyx]

#I'm not quite sure how you got DMS to run without configuring the hostname

docker-compose.yml without any hostname configured starts fine...
the container got random hostname + the full domain name from the host ... for example if the docker host has name x.y.z then the container got the name

<random>.x.y.z

And this .x.y.z is not in my DNS settings anywhere ... a host's reverse dns should probably always exist and can be figured out in 2 steps (perhaps there is even a reverse DNS PTR service like ifconfig.me for my ip address that can do it in 1 step?):

docker exec -ti mailserver curl ifconfig.me
121.122.123.124

docker exec -ti mailserver host     121.122.123.124
124.123.122.121.in-addr.arpa domain name pointer x.y.z.

# or oneliner using dig: 

docker exec -ti mailserver dig -x  $(curl -s ifconfig.me/ip) +short
x.y.z.

this works for me at my isp vps and my hosting community vps and also my test server in google cloud.

[polarathene]

docker-compose.yml without any hostname configured starts fine...

Since you're still using docker-compose.yml instead of compose.yaml, is it safe to assume you're on an old version of Docker Compose?

# compose.yaml
services:
  dms:
    image: mailserver/docker-mailserver:13
    container_name: dms-test

$ docker compose up

[+] Running 1/0
 ✔ Container dms-test Created                                                                                                                                                                                            0.0s
Attaching to dms-test 
dms-test | [   INF   ]  Welcome to docker-mailserver v13.3.1
dms-test | [   INF   ]  Checking configuration
dms-test | [  ERROR  ]  Setting hostname/domainname is required
dms-test | [  ERROR  ]  Shutting down
dms-test | 2024-02-14 11:54:21,243 WARN received SIGTERM indicating exit request
dms-test exited with code 0

Doesn't work for me:

• Docker Compose v2.23.3
• Docker Engine v24.0.7

It has always been a hexadecimal value without anything else appended AFAIK, I've used both Linux and WSL2. So you're presumably using macOS, a very old version of Compose / Docker, or it's something your distro is doing quite differently?

If there are no . in the generated hostname, you'll get a shutdown as shown above.

---

there is even a reverse DNS PTR service like ifconfig.me for my ip address that can do it in 1 step?

I don't think you'll get any maintainers agreeing to that approach.

Use user-patches.sh with postconf smtp_helo_name=x.y.z if you'd like that approach for yourself.