We have been issued and installed new SSL certificates to correct the problems with the previous certificates caused by the issuer.
We use a site-wide SSL certificate for our web and mail servers which we purchased from RAPIDSSL.
About two years ago, they were bought out by an outfit called SECTIGO, and asses apparently decided to shut off the intermediate certificate server even though they still had acquired customers using those certificates and without providing ANY warning to those customers (US), at least this is the explanation I’ve gotten from Integraserver, the dealer I bought the certificate through. SSLShopper’s SSL checker tells me the intermediate server expired a day ago.
Consequently you will get a message when you connect to our mail server saying unable to verify the authenticity. The web server is still working because Apache allows us to configure the intermediate servers into it so it doesn’t rely on their servers but there is no such option with the mail servers.
I am having the certificates re-issued to reflect the current intermediate servers and will install as soon as I receive it.
Reboots are completed, all NFS mounts and NIS bindings are checked. As near as I can tell everything is operational again.
Tonight I have to reboot physical hosts which various virtual machines and NFS file system hosts that hosts things like your mail spool and home directories. I expect to start this around 12AM and the reboots should be completed by about 12:30 but it will take a few more hours to check all the client machines to be sure NFS properly remounted and NIS properly rebinds to the NIS servers.
A couple of days ago a customers account here was compromised about two PM and used to send about 40,000 spams out before I shut it down. I managed to delete the majority of them from queue before they were processed but some got through.
In response, Comcast black listed out entire domain rather than the one customer all the spam came from.
I’ve already talked to Comcast Security and have been told it will take them 24-72 hours to remove the block. The ticket number is #NA250519982.
CentOS8 has been out for approximately a half year and in that time no Desktop interface has been completely ported. And at this time the current release is 8.1, however, Centos folks seem bent on abandoning Centos 8 and replacing it with a rolling release called Centos Stream similar to Fedora and that seems to be where all the development effort is going these days. So I am planning on deleting the Centos8 server and replacing it with a Centos Stream server in the near future.
Good news for those of you who liked the old Gnome environment on Centos6, Gnome is now available on Centos7 and Scientific Linux 7. It has been, up to this point, unavailable because of the unavailability of gnome-flashback, necessary for remote Gnome Desktop access, but I found an “unofficial repository” that contained it so it is now installed.
Also newly installed is the “KDE Plasma Workspaces” desktop. Part of KDE was previously available but now there is a group and the full group is installed. There is also a group for Mate now which makes it a more complete install than it previously was.
And one more Desktop, LXQT, a fairly light Desktop similar to LXDE except using the QT graphical interface, is now also installed.
When I ‘fixed’ some DKIM issues a couple of days ago, I used the same file name for two different functions accidentally and this broke the configuration in ways that affected mail lists. That has been corrected.
In addition, I misconfigured the client mail server in a way that permitted open relaying and that got abused this afternoon about the same time a customers account had been compromised and also abused. And so around 1:30PM today Pacific Time I had to stop the client outgoing server for a short while in order to fix the configuration error and delete 40,000+ spam messages from queue. Fortunately I caught the majority of them before they were sent.
I found and fixed two issues with spam filtering that closed a couple of holes, hopefully didn’t break anything in the process, but if so please use Support->Tickets to report the issue.
First thing I found broken was opendkim checking was not working owing to key retrieval. It appears that opendkim does not use the system resolver by default, it is necessary to define name servers in it’s conf file. I had not done this, key retrieval was failing, so opendkim was not rejecting sites forging as it should have been though most still would have been caught by spf. But this together with spf will also make opendmarc work so should further reduce spam.
The second thing was I had not configured recipient_checks in mail.eskimo.com’s postfix main.cf file and as a result the recipients_check file was completely ignored. This server is intended for outgoing mail, but by addressing to email@example.com AND ignoring MX records and directly attaching to this server spam could be sent. I was able to catch this because I happen to be perusing the logs for errors and happened to see one such spam come through which lead me to investigate the configuration to find out why it was not rejecting it.
The server with the mail spool spontaneously rebooted around 19:05 PM. Because NFS re-binding after a crash is less than reliable, some shell servers may not have properly remounted their file systems. It may take me several hours to check these. If you run into a server that hangs when you login, hit ‘df’, or try to retrieve e-mail please generate a support ticket: https://www.eskimo.com/support/osTicket/