Issue My entire server is getting blacklisted: what to do?

[ramasaig]

Server operating system version

Ubuntu 20.04.4 LTS

Plesk version and microupdate number

Plesk Obsidian 18.0.44 Update #3

My entire server is getting blacklisted, allegedly because someone is using one of the domains to send spam. I very much doubt if any of my clients is doing this, so it's probably some other organisation.

To counteract whatever is going on I have edited the SPF records for every domain to 'v=spf1 ip4:77.68.113.147 -all' except the offending domain, where it's set to 'v=spf1 -all' in the hope of not authorising any e-mails at all (which may be overkill?).

I have also set up DKIM on all domains. Plesk seems to have made this easier than I expected (or I didn't understand!)

And I've started with DMARC as 'v=DMARC1; p=none'. I'm aware that sets no policy, but I've read that it's prudent to start there and go to 'p=quarantine' or 'p=Reject' later. However, 'p=none' generates a 'not enabled' response from Mxtoolbox.

I have lso limited the number of e-mails that can be sent to ten per hour, which I hope is low enough to make spamming not worthwhile.

Then there's the matter of 'Reverse DNS'. I've seen apparently adverse comment that the reverse DNS is not consistent, or doesn't properly reflect the sending domain. Isn't that inevitable with several domains on one server? The reverse DNS goes back to the server, not the individual domain.
I'm unclear whether one should explicitly set Reverse DNS in Plesk, or whether it will be generated automatically.

There may be specific issues surrounding contact forms, but I think that's best kept for another post.

What more could I be doing in regard to DNS?

 

[Bobbbb]

Couple of questions...

Blacklisted by who or which blacklist?

You are correct, the reverse DNS should point to the primary FQDN of the server. Any IP addresses configured for your server should all have the same reverse DNS which should be the FQDN (fully qualified domain name) of your server. You can check your IP addresses here to make sure the reverse DNS looks good...

Reverse DNS Check - Debouncer

In your previous thread you asked about viewing mail logs. Generally, that is done over SSH, however, you can install the Plesk "Mail Log Browser" extension, from the extension catalog, which will let you view the mail logs through the Plesk GUI.

However, if the spam is being sent via a PHP script hosted on one of your subscriptions, you will likely need to use the root SSH login to determine which subscription and script is being used, so you can remove the offending script, or secure it, depending on the situation. The support article linked below may be helpful...

https://support.plesk.com/hc/en-us/...these-scripts-are-running-if-Postfix-is-used-

-Bob

 

[Bobbbb]

I'm fairly sure which domain/script is being used by someone to send spam becasue Cloudmark have told me. The problem is to stop it and get my server off the blacklist.

If you know which script it is, then remove it (back it up, first), update it to a secure version, or configure it such that it can't be used to send spam. Is it some sort of formmail script? Which one and which version?

 

[ramasaig]

Thanks, Bob
The reverse DNS was reported by Mxtoolbox as: 'idrigill2.riabhach.co.uk'. That makes sens to me as at some point I named this server 'idrigill2' (my cPanel/WHM on a different server was 'idrigill'). As already agreed, all domains on this server will give the same result. The Debouncer gives me:
FCrDNS test result:
77.68.113.147 resolved to idrigill2.riabhach.co.uk;
idrigill2.riabhach.co.uk unresolved;
rDNS is NOT forward confirmed.

Generic PTR record test result:
idrigill2.riabhach.co.uk not looks like generic.

I'm aware which script is allegedly causing the problem because Cloudmark told me. I'd not met Cloudmark until yesterday but they appear to be another e-mail monitoring service like Mxtoolbox. I have already removed the entire 'contact' form and substituted a 'mailto' so people can still reach us. Some say a mailto is just another invitation to spammers, but I need to maintain contact...

The script is one I wrote myself. I've used it for years without known problems. It contains a Honeypot which is intended to spot spam bots which often leave names blank (or have first and last names the same). It also detects key words in the message to weed out undesirable stuff (or at least some of it). The honeypot should send an e-mail to me as '[email protected]'. The subject line contains the word 'Spam'. It is this subject line that Cloudmark have told me they're seeing in this spam. I'm not getting any of this spam myself so it's hard to judge. I could remove the entire honeypot and see if that improves matters.

Here's an aside that is slowing me down at present: Earlier today running a test with Mxtoolbox for the offending domain it told me that there was no DNS entry (in Plesk) for ns3 even though at my registrar's there are ns1, ns2, ns3. So thinking to correct that I added an ns3 record in Plesk (two records to be precise, following the format for ns1 & ns2). Rather to my surprise Plesk then decided the domain no longer resolved. There was no immediate effect, but subsequently my browser has decided it can't find the site, so I've deleted the ns3 entries, and must presumably wait for the change to propagate. All very mysterious.

 

[Bobbbb]

Are you a Fasthosts customer? They may be able to offer some support.

It does look like you have some DNS issues. It looks like NS1 and NS2 are OK. Something is wrong with NS3. But since they all point to the same IP, there is no purpose in having an NS3. I'd just remove NS3 from the registrar's glue records and Plesk, and stick with NS1 and NS2.

Is "riabhach.co.uk" your domain name? If so, you should add a DNS "A" record for "drigill2.riabhach.co.uk" so it points to "77.68.113.147". That should make the FCrDNS test pass.

Once you have resolved the FCrDNS issue, so that test passes, make sure that Plesk is set to "Send from domain IP addresses" under Tools & Settings > Mail Server Settings.

Be aware that if this is a new server it will take some time for the server (and IP address) to build up a positive mail sending reputation. Until then, keep the outgoing mail volume to a minimum and make sure any outgoing messages are such that they won't be reported as spam.

Send a test message, from a subscription on the server, to the Newsletters spam test by mail-tester.com service and see if it reports any significant issues.

-Bob

Additional references:

An IP address of a Plesk mail server got blacklisted. How to troubleshoot?

How to disable PHP mail() function for a spamming domain on Plesk for Linux server?

Willmaster PHP Feedback Form

 

[ramasaig]

Thanks for your response.
Yes, I'm a Fasthosts customer. I have been 'talking' to them, and they have been helpful, but I felt I needed a wider view.

A test on Mxtoolbox yesterday showed that there was an NS3 entry at my registrar but not at 'local' (i.e. Plesk). So I thought it would be useful to create one there. This turned out to have been a mistake. I'm reasonably sure I got the syntax right, but Plesk took immediate exception saying the domain didn't resolve. I thought it might need time for propagation, so I left it. Things didn't improve, so I removed the pair of NS3 records from Plesk after about eight hours. I didn't do anything at the registrar. Today 'mull-bed-and-breakfast.co.uk' still isn't resolving. I can't think of any obvious reason for that. Do I just wait and see, or is there some action I should take?

It may not be a factor, but my registrar is a bit opaque on 'Glue Records', and I don't fully understand them myself. I moved the registration of riabhach.co.uk to Fasthosts simply because I couldn't get any sense out of my normal registrar. The other domains seem to have been working OK without specific glue records, until this problem with 'mull-bed-and-breakfast.co.uk' (and even now I don't know that the problem is glue records or lack thereof).

'riabhach.co.uk' is indeed my domain name' (Gaelic, pronounced 'reevach', 'ch' as in 'loch') I have created an 'A' record for 'idrigill2.riabhach.co.uk' as you suggest.
The FCrDNS test now resolves, though I do not understand the meaning of the last line: 'idrigill2.riabhach.co.uk not looks like generic' Why the 'not'? Or is it just bad grammar and should be 'idrigill2.riabhach.co.uk does not look like generic' ?

Plesk is set to 'Send from domain IP addresses' (and always has been). Outgoing mail volume is limited to 10 per hour from each domain (100 from server). I made this change a couple of days ago. I'm sure this is an adequate limit for now.

I have sent two test messages to mail-test.com. The first, from my private e-mail address, had no problems (10/10). It even came back and said 'Not Black-listed'. The second from 'mull-bed-and-breakfast.co.uk' predicatably said I wasn't allowed to use that domain (SPF fail). I expected that as SPF is currently set to 'v=spf1 -all'. It too said 'Not black-listed'. Though in neither case did the list of 24 Blacklists include the one that have been causing my the problem. Mxtoolbox still says the IP address is blacklisted by 'UCEPROTECTL3'.

I'm happy to let a little time pass and see if matters improve. Above all else now I need 'mull-bed-and-breakfast.co.uk' to resolve.

 

[ramasaig]

I have discovered that there was an 'A' record missing for 'mull-bed-and-breakfast.co.uk'. (Whether I inadvertently deleted it when I created or deleted the NS3 pair I do not know). Plesk is no longer complaining about it not resolving and I can open the web site in my browser. So that issue's gone away.

 

[Bobbbb]

NS3, name servers and glue...

DNS is not my area of expertise, however, I think the following is correct. If Fasthosts, or someone more knowledgeable, says something else, they may be correct.

I believe you only need the glue record for ns1, ns2, and ns3, and those would be at the registrar for "riabhach.co.uk" (is that Fasthosts?). I believe that is the only place you'll need glue records. All of your other hosted domains would just point DNS to ns1.riabhach.co.uk, ns2, ns3, and should work fine. See...

Creating your own nameservers with glue records

I see now that you may have listed ns1, ns2, AND ns3 as the DNS servers for your hosted domains. In that case, I would suggest getting ns3 working again (or remove ns3 from the registrar DNS settings for each hosted domain name). Make sure ns3 is also listed in the glue records for "riabhach.co.uk" at the registrar.

Then, make sure you have an "A" record for ns1, ns2, and "ns3.riabhach.co.uk", on your Plesk, that points to "77.68.113.147" and also "NS" records, on your Plesk, for ns1, ns2, and "ns3.riabhach.co.uk".

FCrDNS...

though I do not understand the meaning of the last line: 'idrigill2.riabhach.co.uk not looks like generic' Why the 'not'? Or is it just bad grammar and should be 'idrigill2.riabhach.co.uk does not look like generic' ?

You are correct, it is just bad grammar. You have resolved the FCrDNS issue which should help with outgoing mail being accepted. My servers, for example, will not accept mail that does not pass the FCrDNS test.

UCEPROTECTL3...

It is unlikely you will be able to resolve the UCEPROTECTL3 listing. They are over aggressive and have listed your provider's (Fasthosts) entire network. Most email providers will not be blocking mail just based on a UCEPROTECTL3 listing, due to the blocking of legit mail. However, you can open a ticket with Fasthosts, showing them the blocklisting, and they may be able to do something, or provide a more detailed explanation. Also see...

UCEPROTECTL3 - BLACKLIST

I do not see your IP addresses listed on any major blocklists at the moment.

-Bob

 

[Bobbbb]

Also, go ahead and set your SPF records on your hosted domains to something reasonable. SPF records won't keep you from being blocklisted of spam is being sent, but it will help to protect your email users' recipients from email spoofing, and may help with deliverability to email servers using score based spam filters. A passed SPF and/or DKIM check would likely push the spam score closer to good (ham) vs. spam.

SPF Wizard - SPF Generator DNS tool

 

[ramasaig]

Thank your for your response. It has all been very helpful.

I agree with you about Glue records etc. 'riabhach.co.uk' is registered with Fasthosts because my normal registrar is a bit vague when it comes to glue records. All I can change on their website is nameservers, which of course I've done long ago. I will take a look at the glue records for 'riabhach.co.uk' as you suggest. All the other domains are fine with just NS1 and NS2 in their DNS settings. I'm inclined to leave well alone as my attempt yesterday to add an NS3 record was such a disaster..

I will ease the SPF seeing for 'mull-bed-and-breakfast.co.uk to the same as all the others, viz: 'v=spf1 ip4:77.68.113.147 -all'

I think UCEPROTECTL3 had my previous server (also with Fasthosts) black-listed too, and it didn't seem to matter what I did. Much of this kicked off when e-mails to one of my web site clients started getting bounced back to me. She has an address on 'plus.com' (part of plusnet, I assume) and it's used on her web site for visitor messages to her, so it's important that it works. I sent her a message about 10 minutes ago. So far it hasn't come back, which is hopeful.

I am hoping that's going to wrap this up. I'm still looking at the Willmaster form for which you sent me a link. I'm well used to forms, but I haven't worked out the finer points of this one yet.

Thank you for all your help.

 

[Bobbbb]

Glad to hear it all seems sorted. Here's another useful tool I stumbled across some time ago, in case the email forms don't work out...

SpamSpan - An unobtrusive anti-spam solution for accessible email obfuscation

-Bob

 

[mow]

I believe you only need the glue record for ns1, ns2, and ns3, and those would be at the registrar for "riabhach.co.uk" (is that Fasthosts?). I believe that is the only place you'll need glue records. All of your other hosted domains would just point DNS to ns1.riabhach.co.uk, ns2, ns3, and should work fine. See...

You only need glue records for the nameservers if all of them are inside their own domain because there would be no way to get their IP otherwise. If you use nameservers residing in another domain, you don't need glue records (but that other domain will).