I have Plesk 9.2.3 on a Linux server with CentOS5 and ASL. We use qmail-scanner.

I have one client whose emails were getting through but are no longer reaching our server. They are hosted by Fasthosts. They get a failure notice when sending to us including the link http://www.spamrats.com/bl?213.171.216.175

Fasthosts say:

Spamrats say that the reverse DNS does not conform with best practice.

We do check against certain Black Lists but I was not aware qmail-scanner is checking against Spamrats.

Can anyone advise how we might get around this? The only way we've found so far is getting our client to send to us via our smart host. But if they send through the FastHosts exchange server, that is when it fails.

the best way to fix it is by telling the sender to fix their reverse dns. A mail server without reverse dns will have trouble all over the place...

This is what I do when my customers complain about some mail not getting delivered to them. And most of the senders actually are glad when I tell them their current setup isn't correct. It has actually given me a few new customers over the years, when they realize their current provider isn't up to par...

sorry, I thought I had posted a response to this ...

Thank you for your response Biggles. I agree with all your comments. I too have got additional business from pointing out things like this. I cannot this client of mine's domain as they need MS Exchange and my Linux server will not allow that.

My client's emails are coming through FastHosts who host their domain. I cannot see what is wrong with the Fasthosts server's REverse DNS.

mail.myclient.com resolves as follows:


and if I look at the reverse DNS, there is one:


but Spamrats IP checker http://www.spamrats.com/lookup.php?ip=213.171.216.66 says


So, what is actually wrong with that Reverse DNS? Because Fast Hosts are refusing to do anything and what they are saying is totally wrong. The only way we can receive from our client is if they send through our smarthost smtp.smarthost.net and those get through to us fine.

Is there any way that we can force our server to bypass Spamrats somehow? I'm not sure where that is in the qmail-scanner settings. Or can I tell it to ignore checking that particular domain when it gets to Spamrats? I do have whitelist_from *@myclient.com in my /etc/mail/spamassassin/local.cf file

I might be out on deep water here, but I think that the reverse DNS definition says something about IP-adressess not being a part of the reverse lookup.

Or maybe the reverse dns isn't correct. The mailserver is called mailserver.myclient.com and the reverse lookup answer is mail213-171-216-66.livemail.co.uk.

Thanks for the contribution Biggles. On the second point, I THINK it is OK because they are on a shared hosting platform. I checked my own mail server IP address on Spamrats and it passed, so it might be the first point of having the IP address in the Reverse DNS. I'll see if I can persuade Fast Hosts, but they are a nightmare to deal with.

They are telling my client that they have to pay a lot more and get a dedicated server to have the reverse DNS going direct to their own domain. Well, I could do that!! But hositng small numbers of Microsoft Exchange clients is expensive, unless someone can tell me how to do this most cost-effectively.

Get this response from that rubbish company Fasthosts to my client:


They cannot accept their incorrect Reverse DNS is against industry recommendations! What sort of company is that!!

Please can someone advise how we might be able to either skip checking by Spamrats, or better still simply whitelist checking from my client's domain so that their emails get through to us. Our client is the only known one we have that does not get through to us, and we are the only company that our client gets failure notices from.

I would try to use local.cf and add -100 to the domain you want to whitelist. I have had problem with whitelisting and qmail-scanner before, so this is the way I have handled whitelisting. I'm not able to check out the exact syntax right now, but some googling will hoefully help you...

Don't forget to restart spamassassin and re-confirue qmail-scanner after updating local.cf. Don't know if it really is necessary, but I made it a habit of always doing it after changing spamassassin config.

Hi Biggles,

I already have them whitelisted with that score. We did that when Fasthosts mail servers were rejecting the emails due to being Blacklisted on Spamcop and other black lists! That time, our server was rejecting it so it solved the issue.

Problem now is that our maillog is not receiving any traffic at all from Fasthosts. So this is being blocked before we can do anything to it. I'm asusming that somewhere in the qmail-scanner or spamassassin config, it is being told to check that blacklist, but it is sadly not in the local.cf file.

Does anyone else know where the Spamrats checking is dictated, and how we can overcome this?

a few things from my side:
Your server with the IP address is provided by fasthost, right?

1. Set your Reverse-DNS entry in your fasthosts hosting company control panel to match your hostname of your server (both should NOT contain the IP address)
2. Set your Postfix to greets with your hostname
3. Note that the hostname given in the SMTP greeting should have an A record pointing back to the same server
3. How do you add/use RBL's? Remove dyna.spamrats.com either through plesk or manually whereever you put it

ps: I'm a little bit confused about where what is located and from where who is filtering etc. Maybe a short list of facts would help to understand your situation better.
like.
1. my server hosting domain A
2. can't get mails from ....etc

Thanks for the help BruceLee.

1. My client's domain is NOT HOSTED BY US (because we do not have MS Exchange hosting available as yet). That is the crux of the problem. They are hosted by Fasthosts (which is not my company).
2. My own IP address/server is NOT through Fasthosts - we have our own rack space, servers etc. and all our own IPs/mail etc. are fine.
2. Emails from my client to us are not getting through. Caught by Spamrats.
3. Fasthosts say they will not resolve their reverse DNS which is causing that.
4. I thought that Spamrats was being invoked by Spamassassin. However, looked at Plesk RBLs and it is included there. I've disabled Spamrats checking and Hey Presto! it is working, so THANK YOU for pointing me there - I should have checked there first.

You are welcome. Great that it works.

Way to go Brucie!

and we've found something else which works well for us:
Remove the Spamrats checking on Plesk (we did thta before to allow the emails to get through, but lost one RBL level.
Add the Spamrats RBL to the spamassassin local.cf file and give it whatever score we want.
Whitelist the client's known domain that goes through Fasthosts
Hey Presto - we are still getting the benefit of Spamrats but bypassing the poorly configured Fastshosts mail servers!

One even better way of getting that is using spamdyke. Then you don't even have to process the e-mails, they just go away (but with an excellent logging facility in the Plesk panel, courtesy of haggybear)!

Just wanted to post here a comment on this persons issue, however we did think we made the explanations quite clear on the website. Whenever you are running an email server, the reverse DNS should never be simply nnn-nnn.upstream-provider.com, you should always have something like mail.your-domain.com, the 'your-domain.com' part is the important part. You are the responsible party for email coming from your server, not your upstream provider. This is according to most best practices documents for email operators, along with many anti-spam best policies. And frankly, most providers are signatories to these types of 'Best Practices'. Sometimes we hear, "Our upstream provider won't give us reverse DNS". Escalate this issue. Often a lower end support technician might not know what you mean. Or, you might have opted for the cheapest package that your provider offers, and they charge more for business class packages which are meant for running email servers. However, if at the end of the day, your upstream providers says you can run an email server on their IP(s) but they refuse to give you proper reverse DNS, "Run" don't walk, to a more professional provider..

The thing is, reverse DNS is one of the few things Trojans and Bots can't fake.. only real administrators and/or operators of the IP address can change, and it is an effective spam fighting technique used by many spam protection services.

In our case, once we find that your IP is responsible for spam, before you get off the list, we like to see that you are a professionally minded administrator of your email server. We have a very low false positive rate.

PS, there is always a work around, use your ISP's smart relay. Another link to Best Practices for Email operators is:

http://www.linuxmagic.com/best_practices/