No likes? Stuck at 93? You didn’t like the Spring make-over? Can’t remain winter forever you know!
The Bayesian filtering database was corrupted causing the SpamAssassin failures. In order to resolve this I had to initialize the database so all spam / ham training history is gone.
Please help us train the filters again by bouncing spam to: email@example.com
It is also necessary for the filters to have examples of non-spam in order to be able to differentiate between the two.
Please help us train the filters by sending examples of non-spam e-mail to: firstname.lastname@example.org
Again: spam goes to email@example.com and non-spam to firstname.lastname@example.org.
Thank you for your patience.
Still problems with SpamAssassin. Disk space increased, doesn’t appear to be a resource issue:
Plenty of disk space:
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/vda3 27016320 5755716 19907756 23% /
Plenty of memory:
total used free shared buffers cached
Mem: 4053548 1504976 2548572 6136 46200 595264
-/+ buffers/cache: 863512 3190036
Swap: 2097148 0 2097148
Plenty of CPU:
14:45:14 up 3 min, 2 users, load average: 0.63, 0.62, 0.28
I am back to researching this. Any suggestions most appreciated.
I am still getting messages that are getting past spamassassin. SpamAssassin is called from system procmail rules. Procmail provides an error that says program failed with an exit code of -25. A Google search reveals that many people are experiencing these and suggests a possible resource shortage.
These machines are short on disk space at this point so I am going to enlarge the virtual disks to see if this resolves the issue.
If anyone else has any information about this error, please e-mail email@example.com.
Mx1 is restored with spamassassin. It appears an update failed to complete properly, probably because I had left a test-updates repository enabled and it grabbed an update that was broken.
This has been fixed, the server is restored to service and now spamassassin is operational on both mx1 and mx2.
I am in the process of replacing these servers because spammers have adapted to old versions and can often sneak by. Working on new servers based upon the latest and greatest so it will at least slow them down until they adapt again.
On mx1, spamassassin not only is not running but trashed itself to the point where it won’t start. I’ve taken mx1 out of service and am restoring it from a backup image. I did store the postfix spool first so no mail will be lost. Incoming mail can still be processed by mx2 while this is being restored so there is no loss in functionality and traffic right now is low enough that capacity shouldn’t be an issue.
SpamAssasin’s daemon, spamd, died at some point on mx2 allowing a lot more spam than would normally make it through. It has been restarted.
I am in the process of replacing the existing mail servers with new servers with newer anti-spam measures. The existing servers are three years old now and spammers have adapted to get past the old measures. The new servers will rely more heavily on Bayesian filtering (which is adaptive) with a much improved back end capable of holding a lot more sample data thus enabling more accurate filtering.
I have removed outages-list and eskimo-announce. This news section replaces both of them. Neither have been used for years legitimately but spammers have been forging source addresses against them in order to cause the bounce to deliver to the forged address. Since this could potentially get our services black listed for back scatter, I’ve removed them entirely.
If you wish to have this information delivered to you via e-mail you can use the subscribe function on this page. Since submissions are by web only using authentication, back scatter can not be generated the way they could with the previous mail lists.
While I am still working on new mail servers, I’ve updated postfix on the current incoming servers, mx1 and mx2, and client server mail, to the latest version which is postfix 3.0.1.
The primary reason for doing this is that it added settings for how long mail could be kept in queue before being rejected. This was necessary because of people sending mail to domains which had MX records but non-functional or non-existent servers at the IP addresses those records resolved to. It was also necessary because of sites like Yahoo and Google which sometimes won’t accept e-mail as fast as our servers are trying to send it and, if this goes on too long, causes a backlog in our mail queue.
Still working on new mail servers for better spam control and over-all functionality. Working with Ubuntu 14.04 LTS rather than Fedora and so far it’s going much more smoothly. Ubuntu builds low latency kernels as part of the distribution so don’t have to do that by hand, synaptic is far better than any of the package installers provided with Fedora.
I’ve got most of the necessary pieces installed on one new server, now just have to configure everything. Once I get one setup, it should be easy to clone the new configuration.