This may be OT... our server with ServePath, it is the only machine on the C-class network associated with the router, in effect our box has it's own router and the IP of the router is the IP of the box... sometimes referred to by servePath as "the transit IP" because the "real" IP's for all our domains are down stream one level. OK... Now. I've been tailing mail logs and to my dismay see that other ISP's are rejecting mail because the IP the mail comes from is not the IP of the domain sending it, but the transit IP and the transit IP had not PTR address so reverse look ups failed to find anything and we were even being classed as "zombie" by some other ISP's who rejected mail from our box... OK so I went to support and they said "ummm your box has no PTR. can you give us a full qualified domain to enter one for you." Oh boy... I don't know how long this has been going on. At any rate. Is this something that one can set inside WebMin? and if so were?
I would have thought it obvious that ServePath would set up PTR's for machines they were hosting, but then again, there's really nothing that says they should since whether I use the box for mail or not is my decision...
But if I look up PTR on the net it does appear that this record has to be entered by ServePath... any insights appreciated. This level of mail admin is a black art to me...
Howdy,
Well, PTR records, or reverse DNS, is nearly always setup by one's ISP.
It's also fairly typical that they wouldn't do anything about that until you notify them -- reverse DNS is only effective if the reverse DNS matches your server's hostname, so your ISP would need to learn from you what the entry should be.
So generally, once you setup your server, one of the first things you'd do is give your ISP a call, and say "Hey, I need a reverse DNS entry for my IP address, the name should be foo.example.com".
So when you installed Virtualmin, whatever hostname you set it up with is what you'd tell your ISP to use as the fully qualified address.
I've been threatening to write a Server HOWTO that documents all the things one needs to do in setting up a server, and this topic would be a great addition to this document :-)
-Eric
<div class='quote'>reverse DNS is only effective if the reverse DNS matches your server's hostname, so your ISP would need to learn from you what the entry should be.</div>
Actually, that's not necessary. Any reverse record will "work" from the perspective mail delivery. It just has to resolve to something, and that something has to resolve back to that IP. It doesn't have to match the forward name of the machine (and, in a virtual hosting system, which forward name should that be? there could be hundreds or thousands of names on the system).
For example, here's Virtualmin.com:
[root@www ~]# host virtualmin.com
virtualmin.com has address 70.86.4.238
[root@www ~]# host 70.86.4.238
238.4.86.70.in-addr.arpa domain name pointer ee.4.5646.static.theplanet.com.
[root@www ~]# host ee.4.5646.static.theplanet.com.
ee.4.5646.static.theplanet.com has address 70.86.4.238
Notice that the reverse is some random name from theplanet.com, where our box is located. The important thing is that a PTR exists, and that it points to a resolvable domain name.
That said, if your host doesn't provide PTR, by default, they may be just waiting for you to tell them what to make it, or ask them to delegate the zone to your server(s).
--
Check out the forum guidelines!
Actually, it is not REQUIRED to match the forward IP, but, a fair number of mail system owners, including me, tend to block email from mail servers whose reverse IP does not match. So, it depends. I think it's a good idea to set it up, personally.
<div class='quote'>a fair number of mail system owners, including me, tend to block email from mail servers whose reverse IP does not match</div>
Steve, you mean you don't want our mail? I'm hurt. ;-)
Just for reference, no major email provider blocks based on non-matching PTR, and we've never had any trouble with it. It's extremely common for legitimate mail to come from IPs that don't match the PTR name, so unless you run your own server for your own personal use, and don't have to deal with customers who expect mail to reliably arrive, it'd trigger too many false positives. Perhaps as a point or two in SpamAssassin it might be a useful indicator of spamminess (but I'm doubtful even of that, since so much legitimate mail has the same indicator).
--
Check out the forum guidelines!
Yes, I agree no MAJOR providers do, depending on what major means. We've seen some Comcast mail servers blocking mail under these conditions before. But, as you know, if your mail does not get through to someone else, that is bad. And it's so trivial to update your PTR record, so, not sure why you would not. I have to disagree for once on this one.
We find we block very very very few mail servers that are legit by doing this, and in that once or twice a year case, we simply whitelist them. But, I do admit this is for our own companies email, not, customers email on a server. i.e., we choose to do this and accept the small risk in return for clean inboxes.
So, I am not recommending people block using this technique of course, probably not wise esp. on a shared hosting server of course. However, customers are also mad if their mail does not make it to another company, EVEN IF it's "the other companies fault" too don't forget. So, we always recommend the trivial step of updating the PTR record. It takes seconds of time to request this and there is little reason to not do this, and, only benefit to doing so.
Here's a sample RDNS tutorial:
http://www.med.wayne.edu/msis/email/postmaster-baddns.asp
As for virtualmin email.... We find a lot of SPAM coming from your ISP.... Well, trying to come! But, yes, we do get your mail, despite the configuration!
<div class='quote'>As for virtualmin email.... We find a lot of SPAM coming from your ISP....</div>
We're currently hosted at The Planet, who have over 100,000 dedicated servers at their facilities. I guess there might be a spammer or two at any given time operating under their roof.
The new server where the new website resides does have a PTR record that matches, but I didn't go out of my way to make it happen. SoftLayer just seems to set it automatically for the first IP on the box.
--
Check out the forum guidelines!