Nick Howitt wrote:
AKAIK it does go through spamassassin, but none of the RBL lists will work as they all look up the ClearSDN server IP's.
Nick, I figured out something that might help others. (Perhaps this is also stupid rule as other valid senders might use this, but I haven't found any using this form in the past month's logs.)
I put the following in the Spamassassin blacklist and now i'm spam free from those people stuffing the MX backup. I noticed that they always have the same form in the logs:
Following put in the Spamassassin blacklist:
So far in the past 3 days, it's caught and gotten rid of 1200+ spam. It's a shame for the wasted processing and bandwidth but my email client is clean for the first time in weeks.
Maybe this should be cross posted to the forum dealing with Spamassassin?
Out of curiousity, is there way to run email from the MX backup through spamassassin before putting into the mailbox? Or perhaps have postfix check MX email coming in through those same checks? I already have postfix checking rbl lists and in spamassassin it is checking URIBL.
Thanks again for your help.
Here is the maillog lines.
It does look like they pushed the spam to the backup. The first few lines shows the clearsdn.com server delivering the spam message. Since each spam message comes from a different domain, it will come through from an OK from the clearsdn.com IP address. :-(
I never would have checked this despite seeing the clearsdn.com in the maillog.
Unbelievable. So probably the firewall was working OK.
Now to figure out how to stop this.
That is very interesting and might be what's going on. Yes, I've been using Clear mail MX as backup.
I read about this over the weekend and changing some settings in either Spamassassin or Postfix but I can't remember which. I flew over my head as I didn't even thing about the Clear MX. It was along the lines of making sure that email only came in via the lower MX records. But that screws up if the server goes down for a while. Then all the email go into the black hole.
I'll collect the maillog info this evening and post.
Thanks in advance for having a look.
I had 22.214.171.124/24 originally in the firewall local but then I removed that since it didn't appear to work. So I put individual lines. Those appear to work. But I'd rather just block the IP range. I do have IP ranges in the list from before, and I assume those work but I can't tell at the moment.
This morning I got a bunch of spam from:
126.96.36.199 > in list
188.8.131.52 > new
184.108.40.206 > new
220.127.116.11 > new
18.104.22.168 > new
22.214.171.124 > new
126.96.36.199 > new
I'm going to add the new in a moment but first here is the list of INPUT DROPs.
Thank you Nick.
I am running ClearOS mail server.
I am assuming the IPs aren't connected as the spam is intermittent. So when the reconnect would happen it should block but it doesn't.
Is there a way that I can check?
I'll look into the ipset. I'm always looking for ways to be more efficient. Thanks again for your help.
Over the past few weeks the number of spam messages has been growing and I've been trying to block the offending IP ranges.
I've been adding the IP ranges into the /etc/clearos/firewall.d/local but it doesn't appear to work.
Example: I put in
But then I still get many spam messages from 188.8.131.52; 184.108.40.206; 220.127.116.11 etc. etc.
When I do the command I can see that 18.104.22.168/24 is included in the INPUT with DROP command.
Since it didn't seem to be working properly, I have now blocked the individual IP addresses. That appears to work however it is somewhat time consuming adding each IP address manually. The subnet notation would be so much more efficient.
Have I done something wrong in the subnet statement in the local file that it doesn't work?
Nick Howitt wrote:
For LE, it is in the documentation for LE - https://documentation.clearos.com/content:en_us:7_ug_lets_encrypt#replace_the_self-signed_certificate_for_webconfig. The setting is not backed up, as you say. I wonder if it can be safely but the restore program would need extra functionality to restart the webconfig.
For e-mail, if you use cyrus-imapd, all mail is under /var/spool/imap and /var/lib/imap. The raw mails are under /var/spool/imap and there is a database and other stuff under /var/lib/imap. These can be copied/rsync'd/tar'd across, but it will do everyone at the state of the last mails. If your e-mails have moved on since then, you have a bit of a pickle. You can possibly copy any new e-mails for the user as a backup, can copy in all the old e-mails under /var/spool/imap, but they will all appear as unread and you won't see any where you have replied. Then the new ones you've backed up can probably then be copied in as well, but make sure the files don't duplicate. Be careful manipulating files as the naming is odd as they all end with a . and things don't always go as expected. I think if you edit them you initially lose the trailing ".". Make sure you also copy in the cyrus.* files in each folder or you will have to run "reconstruct" on the mailbox.
I wanted to close this adventure off for now. I change the self signed cert as per the link provided. No more messages! Thanks for the link! I'm not sure why I didn't find it myself!
I gave up on the cyrus email extract and told the individual in question that the email was lost. It's a bit of a cop-out but I ran out of patience.
As always, thanks for all your help, Nick. Much appreciated!!
Nick Howitt wrote:Thanks Nick.
I have successfully moved a disk between servers. It is how I did my 7.x installation, but note that all your network interfaces may (will) change so check the files you will need to review in the Config Backup docs. The other thing is the two servers will have to boot the same way, either UEFI or BIOS.
Note, if doing a disk recovery, best practice says always do it on a clone of the disk and never on the disk itself
I have reinstalled on the new drive and restored all the settings via "Configuration Backup and Restore". It was mostly OK. There were issues with the Let's Encrypt certificates, flexshare, fail2ban, mounting our nas and virtual websites. I think those are fixed now.
I have two outstanding issues.
The reinstall seems to buggered up the certificate for the webconsole. It is now a localhost.localdomain. It should be using my server Let's Encrypt certificate. I can't figure out where to change this. It doesn't appear to be in the HowTo unless I missed it.
Second is not unexpected but frustrating ... Even after I told everyone to download their email, one family member didn't. So the second questions, is what would you use as search terms to figure out how to rescue the left over mail that are on the old server disk?
Nick Howitt wrote:
There should be no reason that I can think of that getting the chroot line wrong would stop you being able to boot again from USB/DVD.
The initramfs message could be interesting. There are plenty of references for generating a new one. Google "generate initramfs centos 7". This looks interesting.
I don't think /boot is in the LVM. I think it is a native partition in its own right. I am not sure you can copy a /boot from one drive to another as it has the drive partition references in it, but I am not sure.
Otherwise, especially if you have a significant user set up or OpenVPN certificates deployed, I'd go for option 2 over 3, but note that after you do a system restore, I'd delete and recreate websites and flexshares as a restore on its own does not generate the folders or the bind mounts in /etc/fstab. If you can still mount your old disk you may be able to recover those and the rest of your data. They should be fast to copy over if you have both disks mounted in the same machine. From /etc/fstab, don't copy over the whole file or you will really mess things up, just copy the bind mount settings.
Thank you Nick.
You are correct. The /boot is an ext2/3/4 partition and is not in the LVM.
The second partition on the hard drive is the LVM volume. It appears that the cloned /boot has defective sectors or corrupted file(s). I suspect that is why it won't boot up properly.
I've read the info about initramfs and will give that a try but I think I need to try a two pronged approach.
I still have my old server box with similar hardware but one generation older. The new server is build the same just with a newer CPU and more RAM. Everything else is essentially the same.
Would the following work?
Could I install the current COS version onto my old server, do the restore of settings and if everything runs OK, just swap the hard drive to the new server? This way I wouldn't touch the existing server hard drive again until I do the swap out. I think I reduce the risk that sectors used on the hard drive sector fail in start-up before I've got a rebuilt server.
Is that advisable or are the auto identification of hardware in COS going to have a problem with the switch?
Thanks again for all the advice!