Dynamic reverse dns rule problem

[diadem.support]

Hello,

We have recently installed magic spam but various clients are complaining that there mails are not getting thorough to our server.While checking the log we found something like:

2009-11-04 18:27:44 magicspam-plesk[12400]: SPAM[check_dynamic_reverse_dns]: mua=0,ip=[122.182.6.129:dsl-mum-static-ilp-129.6.182.122.airtelbroadband.in],helo=<mail2.ambitpte.com>,from=<VishalRandive@ambitcapital.com>,rcpt=<vikram@tcg-advisory.com>

Here it is blocked by the rule check_dynamic_reverse_dns, but the client is using a static IP provided by their ISP Airtel to run their mail server. Can you explain why this is happening?

Regards,
Diadem Technologies Pvt. Ltd.

[magicspam]

Hello,

The rule 'check_dynamic_reverse_dns' is based on ensuring that an email server operator follow the best practices methodology of proper DNS naming conventions.

While the IP address itself is static, it is still set to a 'dynamic' style naming convention, commonly associated with various IP pools as provided by an internet service provider and as such has not been set in association with any identity specific to the email server and/or domain itself. For the example listed, we would expect that 122.182.6.129 would have a reverse DNS entry configured similar to the HELO:

mail2.abitpte.com

Those emails that were blocked should have received an extended 550 rejection notice pointing them to this page:

http://www.linuxmagic.com/best_practice ... e_dns.html

which covers in full detail what the nature of the policy is along with the origins.

You do of course have a couple of options available. You, as the recipient email service, can opt to take the high road and enforce the policy - pointing out to those operators affected that as part of best practices they *should* be contacting their ISP to have the reverse DNS for said IP addresses set properly (this is normally a free service from most ISPs).

You also have the following options available:

* Disable the rule check_dynamic_reverse_dns (NOT recommended. This particular rule is responsible for catching an extremely large portion of infected home PC spam)
* Adding a white list entry for either those server IP's that you know can be trusted, or adding white list entries for 'from' email addresses / domains.
* Adding a 'fake' DNS entry in the /etc/hosts file on your server.

We hope this information helps.