Using your example, the hostname that should return is the one mapped to the IP address regardless of whether it’s the one you queried.
Having it return any other domain is what would get you blacklisted.
So hypothetically if “microsoft.com” email were hosted by Google, you can expect the server to respond with a Google hostname.
Though in querying an email server in the above example, you’d know it was a Google server since after doing an MX lookup, you’d see a Google server is responsible for the domain. This is then the hostname you’d actually query.
But that is exactly what IS happening! ALL of the domains on the box are returning only the hostname which is someone else’s domain (which just so happens to be hosted on the same box)
So the solution of it returning a blank smtpd_banner remains the only solution
We already discussed what happened with you. At some point, YOU set the incorrect domain on your server. At the time from what I read, you thought this was a good practice.
Now you just need to adjust the hostname of your system and subsequently postfix (and potentially other software) to the correct one.
However, when you host multiple domains on a system, there is only ever one hostname that will respond to a telnet or even a dig request for the IP address which is how it’s supposed to work.
If you require assistance adjusting things, drop me a PM and I can help you get things squared away.
So. I set the hostname back to any one of the valid domains on this box and then let it get displayed by the smtp_banner for ALL the domains on the box? Oh and expect the flood gates to be open to millions of pings.
No, it’s showing the hostname of the server, which should be bound to the IP and reverse back to this domain. It’s very simple indeed and this is how it’s supposed to work. What you are proposing is wrong and shouldn’t work.
the dig -x my IP address produced some surprising results, so much so I doubt if this is being used by this particular validator under the hood.
It did point to an answer of
;; ANSWER SECTION:
101.81.56.45.-in-addr-arpa. 0 IN PTR usa.myhostname.tld
101.81.56.45.-in-addr-arpa. 0 IN PTR usa.
That does not make sense to me.
If I do a reverse lookup on the my IP using a tool like DNS Checker it exposes the VPS (Linode) box!
and not my domain name or my hostname.
So my suggestion of making the smtpd_banner blank will not result in blacklisting? and neither would the suggestion of somehow setting it to the appropriate domain name.
coz that is what the PTR is set to … some VPS providers do not allow you to edit that … or will only change it on your request … my old supplier did not allow me to change this value so it always returned their default (in my case the vps name) … my current supplier allows me to change it so for me this is not much of an issue but there is nothing wrong with the vps name being the reverse dns address … just set your hostname to the same
As suspected earlier, your VPS actually was assigned “usa.myhostname.tld” at one point.
So, assuming you’ve adjusted the “hostname” for your VPS within your VPS, now it’s time to talk with your provider and ask them to change the “PTR” record for which “they” manage since it’s “their” IP address.
*** You can manage the “forward (A)” but the provider manages the “reverse (PTR)” record ***
You keep using the word “exposed” as though any of this is sensitive or secret information. These are public records. They are not secrets that can be “exposed”. There is no security element to this conversation. Nothing is being exposed. These public records are being served out, as expected, and as needed, for fundamental services to work.
The PTR record is managed by the owner of the IP. That would presumably be Linode in this case. Some providers allow you to change the PTR record for the IPs of the hosts you’re managing. You should do that, if you’re concerned about it being “exposed” that you host your websites at a…hosting provider. But, it doesn’t matter.
Any PTR record is fine, as long as it exists and as long as the record points to a name that resolves back to the IP address. Literally anything is fine. Whatever default your host provides is fine. If they allow you to change it, and you change it to suit your tastes (i.e. some name you host on the server), that’s also fine. There can only be one for each IP, though…so, it can never be the same as every domain you send mail for. It’s literally not possible, if you send mail for more than one domain.
If the PTR (reverse) record points to a non-existant A (forward) record, then the server may get blacklisted by certain email providers who check this. It’s something our email server looks up, since spammers are known for impersonating other servers to do their evil deeds.
@Joe I’m sorry about the use of the word “exposed” but it was correct for when it was originally applied to the information in the smtp_banner as it had nothing to do withe the domain it was being applied to and was showing “Postfix and OS” that has been solved by making it blank.
I have already said that I have no problem with the domain name or the IP address being public - I don’t really care about it being a Linode box and thanks everyone it seems Linode do things different to my DO boxes where the rDNS lookup PTR records seem to be set correctly as a matter of course.
However, as it has been pointed out this might be a blacklisting issue, I will raise a ticket with them.
I have changed the hostname to be the same as the rDNS (which is now too long for my ease of use) and am giving serious consideration to moving all domains on this box to a new box on DO AND setting it up correctly from scratch The other boxes there do not have this PTR issue but they do have this same “exposure” problem with the smtpd_banner and I now know how to resolve this.
It is only a blacklist issue if the name the PTR record provides does not resolve back to the IP. The name does not need to match any name you’re sending mail from. It doesn’t matter what the name is as long as it resolves in both directions.
But surely if the PTR record resolves back to a domain that is nothing to do with the domain that is sending the email then it must raise a flag somewhere.
I am now convinced that the best course is to kill this box and go back to DO where I have a box happily running Virtualmin, do a clean install on a new box and to transfer the domains and sites over. A lot of extra work but
At least the primary issue here - the smtpd_banner - has been resolved.
It’s literally impossible for it to resolve to every domain on a system hosting mail for more than one domain, because there should only be one PTR record for an IP.
It is not, at all, a red flag for a PTR record to have no relation to the domains it sends mail for. It must exist, it must resolve to a name that resolves back to the same IP. That’s it. Any mail server that considers the name not matching mail a spammy trait is a misconfigured mail server that will throw away a significant portion of legitimate mail, including those from many of the largest mail services. When you use Google with domain support, it sends mail with an IP that has a PTR record that does not match your domain. Same with Mailchimp or whatever. It is entirely unreasonable to expect PTR record match the domains it sends mail on behalf of.
DKIM and SPF provide assurance that the server is allowed to send mail on behalf of domain. PTR does nothing of the sort, and literally cannot do anything of the sort.
adding to Joe’s comment there is one ptr record per IP so the only way of doing what you want is to place each domain on it’s own IP and set the PTR to match … in the real world there is no need to do that … if you are having mail deliverability problems for sure it will not be this
