Hi people. First time I'm posting at spamcop forums.
I have an issue where I'm trying to send email to another mail server which blocks me because I don't have a reverse DNS lookup for my server's IP (not that its wrong or anyhing - simply there is no DNS configured for reverse lookups on that IP block. I can't even do anything about it, because I'm co-located and have no control over this).
I've contacted the mail administrator for that domain, and I'm trying to convince him that that behavior is broken and should be fixed, but I'm having little luck getting to him - he keeps waving at "an RFC that's out there" that supposedly dictate that this is valid but refuses to point out exact details.
My questions:
*) Is it ok to block mail from IP addresses that cannot be reverse resolved (in my case the name in the EHLO command is valid and resolved, but the IP that it resolves to then fails to reverse resolve) ?
*) If its not - can someone point me at the standard that says that it cannot, as I've read several dozens RFC in the last few days and none mention that.
*) If it is indeed a valid situation and the mentioned domain is indeed broken - who can I complain too besides the mail administrator for that domain that would make a difference (something like SpamCop that deals with SMTP standard compliance instead of SPAM) ?
Also: what is the relation between this site and spamcom.com ?
TIA
Full Version: Problems with reluctant mail server admin
Blocking mail from a server with no PTR record is a good way to block spam originating from zombied machines, and is VERY common practice among larger ISPs.
As far as RFCs, I don't recall ever reading anything in an RFC that REQUIRES a PTR record for a mail server, and strictly speaking, it is not necessary. I have a similar problem on a small exchange server that I run at home on a dynamic IP address (using tzo for DNS resolution).
My solution there was simply to configure it to forward through a smarthost instead of doing direct delivery. In most cases you would be able to forward through your ISPs smarthosts, although some ISPs (like roadrunner) won't deliver mail that is "From" a non-roadrunner address. In cases like that, you may have to find someone with a mail server that trusts you enough to allow you to relay through your server.
If your mailserver sits on a static IP address, then your ISP should be able to insert the PTR record on their DNS servers for you. I've never had an ISP complain about doing this on a static IP business account, although its been my experience that you have to go to about Tier 3 support before anyone knows what a PTR record is.
As far as RFCs, I don't recall ever reading anything in an RFC that REQUIRES a PTR record for a mail server, and strictly speaking, it is not necessary. I have a similar problem on a small exchange server that I run at home on a dynamic IP address (using tzo for DNS resolution).
My solution there was simply to configure it to forward through a smarthost instead of doing direct delivery. In most cases you would be able to forward through your ISPs smarthosts, although some ISPs (like roadrunner) won't deliver mail that is "From" a non-roadrunner address. In cases like that, you may have to find someone with a mail server that trusts you enough to allow you to relay through your server.
If your mailserver sits on a static IP address, then your ISP should be able to insert the PTR record on their DNS servers for you. I've never had an ISP complain about doing this on a static IP business account, although its been my experience that you have to go to about Tier 3 support before anyone knows what a PTR record is.
I don't really see how blocking mail from IPs that can't reverse resolve prevent SPAM delivery from zombied hosts - most (if not all) dynamic IP ranges I have encountered have reverse lookups from their owners. It resolves to something like xx-xx-xx.pop.dsl.provider.com, but it will resolve. If you don't want zombies to deliver mail then you need to block dynamic ip ranges, in which case my server which is on a static IP would be allowed in.
At the moment relaying through the ISP's mail host is not an option as I'm not using an ISP - the server is co-located on a private server farm that leases bandwidth from several ISPs: I'm not sure which ISP's mail relay to use, whether it will always work or even if it will work at all as the IP range where the server is located isn't really owned by an ISP.
I already asked the server farm administrator to set up PTR records for my server, but he says that it will take a couple of week at the least (or a couple of month on the outside) because RIPE (the IP registrar) needs to set it up on their side first.
At the moment relaying through the ISP's mail host is not an option as I'm not using an ISP - the server is co-located on a private server farm that leases bandwidth from several ISPs: I'm not sure which ISP's mail relay to use, whether it will always work or even if it will work at all as the IP range where the server is located isn't really owned by an ISP.
I already asked the server farm administrator to set up PTR records for my server, but he says that it will take a couple of week at the least (or a couple of month on the outside) because RIPE (the IP registrar) needs to set it up on their side first.
QUOTE(guss77 @ Mar 7 2006, 04:59 AM)
Hi people. First time I'm posting at spamcop forums.
Hi, and welcome!QUOTE(guss77 @ Mar 7 2006, 04:59 AM)
I have an issue where I'm trying to send email to another mail server which blocks me because I don't have a reverse DNS lookup for my server's IP (not that its wrong or anyhing - simply there is no DNS configured for reverse lookups on that IP block. I can't even do anything about it, because I'm co-located and have no control over this).
I've contacted the mail administrator for that domain, and I'm trying to convince him that that behavior is broken and should be fixed, but I'm having little luck getting to him - he keeps waving at "an RFC that's out there" that supposedly dictate that this is valid but refuses to point out exact details.
Please see http://forum.spamcop.net/forums/index.php?...027&#entry36027 for details on that.I've contacted the mail administrator for that domain, and I'm trying to convince him that that behavior is broken and should be fixed, but I'm having little luck getting to him - he keeps waving at "an RFC that's out there" that supposedly dictate that this is valid but refuses to point out exact details.
QUOTE(guss77 @ Mar 7 2006, 04:59 AM)
My questions:
*) Is it ok to block mail from IP addresses that cannot be reverse resolved (in my case the name in the EHLO command is valid and resolved, but the IP that it resolves to then fails to reverse resolve) ?
Yes, I think it is ok. Doing so does not violate any RFC I know of, and complies with the "My server, my rules" concept.*) Is it ok to block mail from IP addresses that cannot be reverse resolved (in my case the name in the EHLO command is valid and resolved, but the IP that it resolves to then fails to reverse resolve) ?
QUOTE(guss77 @ Mar 7 2006, 04:59 AM)
*) If its not - can someone point me at the standard that says that it cannot, as I've read several dozens RFC in the last few days and none mention that.
*) If it is indeed a valid situation and the mentioned domain is indeed broken - who can I complain too besides the mail administrator for that domain that would make a difference (something like SpamCop that deals with SMTP standard compliance instead of SPAM) ?
You can complain to the DNS Administrator for that IP Block (per its SOA Record), the people responsible for that IP Block (per IP WHOIS), your server farm administrator, and the people you are paying (perhaps all the same people). You are paying for professional service and you are getting amateur service.*) If it is indeed a valid situation and the mentioned domain is indeed broken - who can I complain too besides the mail administrator for that domain that would make a difference (something like SpamCop that deals with SMTP standard compliance instead of SPAM) ?
QUOTE(guss77 @ Mar 7 2006, 04:59 AM)
Also: what is the relation between this site and spamcom.com ?
This website helps to support users of www.spamcop.net and other hosts in the spamcop.net domain. It appears that Julian Haight (founder of SpamCop.net) registered spamcom.com on September 18th, 2000 because so many people were misspelling spamcop.net. He doesn't appear to be using it for anything meaningful. Julian appears to have sold it to IronPort with SpamCop.net in mid-2003. If you meant spamcop.com, that was usurped by a domain squatter on August 9th, 2000.
QUOTE(guss77 @ Mar 7 2006, 12:37 PM)
I already asked the server farm administrator to set up PTR records for my server, but he says that it will take a couple of week at the least (or a couple of month on the outside) because RIPE (the IP registrar) needs to set it up on their side first.
I think your server farm administrator is shining you on, and doesn't know the difference between PTR Records, reverse DNS, IN-ADDR records, and IP WHOIS. What IP Address (or range of them) is he administering? Thanks!
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.