Month: August 2008

PMAS seems fine
Now running for quite some time, the spam filter works like before, thought there is still a lot of logging around. The only problem was a crash of one of the worker processes due to the inability to share a socket. I mentioned it to Process but there is no data in the log files to give a clue on what happened.
And: I’ve seen it before, with the 3.0 version.
Process announced a final release later this week but instalation will be deferred due to a short holiday. But that will not be a problem, assuming it will keep running like now.
MySQL as well
Switching to MySQL 5.1 pays off. The server runs for weeks now, without a problem. Does a lot of paging:

20203A8D MYSQL051_SERVER HIB      4  3957781   0 03:37:53.53    914726   4604 M 
         [MYSQL051,MYSQL051_SRV]                                        36832Kb

but that is not a surprise given the nature of the beast. I’ve seen it grow to about 60Mb of virtual memory, without any problem. Though I must admit it hasn’t had to handle a high load, so far.
Patches
DEFCON 16 paid attention of OpenVMS, from a hacker’s point of view, and some weaknesses have been found: Some in old versions of WASD (pre 8.0), the Multinet FINGER daemon and teh SMGSHR shared image. Solution to these issues are easy: Upgrade WASD to the latest versions (where these vulnerabilities have been fixed), disable FINGER if you’re using the Multinet TCPIP stack (or install the patch supplied by Process), and install the patch that HP supplied for SMGSHR.
That last one is to be done, it has been downloaded already, as well as some other patches that were released after the last update.
Today I learned that as a result, more code has been scrutenized for possible problems and some others have been found for “medium” severeness, It means that risk isn’t that big, and few systems will actually be vulnerable. Details are not disclosed, nor will be. But patches will be released to address these issues. As soon as these apear, they will be installed.

Monitoring mail
I checked at 7:30 (system time).
It’s a bit weird, but either there has been little mail last night, or PMAS is very strict in rejecting: Since I enabled PMAS yesterday, just 1 message is quarantained, 4 have been discarded, and 1 have been delivered. In the operator log I did see 7 connections handled by PMAS until midnight (on log cycle, I have no access (yet) to the current log). I wonder when PMAS counts a connection as “handled” and when SMTP sends out it’s message to OPCOM: it might be that these two have been handled by PMAS, and will be signalled when PMAS actualy delivers them to SMTP.
I’ll have to check the logs tonight to be more sure – if the files still exist 😉
UPDATE
It’s Ok. I checked the logs and PMAS is working like it should. A number of messages have been rejected because of DNS blocking. These messages are counted in the statistics database, but though the reports mention these messages, they are not extracted – yet: it’s hoped they will in the final 3.1 release.

No problem if not. The procedure is fine 🙂

Spam filter enabled again
It has been running all day but since incoming SMTP traffic wasn’t redirected, PMAS didn’t have a lot to do.
Tonight I enabled it again at 19:00 by redirecting incoming mail to it’s port. To test, I forwarded a mail held at my ISP, and it got through properly. As well as messages get quarantained and discarded, just found one of each.
Hunter can do the monitoring of the anti-spam-system (if he thinks it’s needed). I’ll keep an eye on it for a few days as well.

Demeter died?
I had to do a presentation on this year’s bootcamp tonight and because of all the trouble last weekend, I had to do so this afternoon. But when I powered up Demeter – the company laptop – it failed to read the disk. Just initiates it, but there startup stopped. Luckily I was at the office and a similar system was right available, so we swapped disks to see if it was the disk or the controller. It turned out to be the controller, the system started fine so I could make a full backup of the disk (just in case) and prepare my presentation. The laptop is to be repaired – still has to go for another six months.
So for the time, I’m stuck with a somewhat slower system, with twice as many memory.

Spam filter repaired
Hunter had trouble connecting but that was caused by a typo – wrong port …
Returning late tonight, I only had time to read mail to seen how he was doing, and learned that he finally succeeded to login, and found a cause of the problems. The main issue, as I understood, was the handling of the closing of a message: <CRLF>.<CRLF> which didn’t work. That’s what I found as well, but forgot to mention. It’s something to test if TCPIP is updated! Also, the code that has to do with the verification of the FROM: address was not behaving as intended.

Well, it’s a beta so these things are to be expected.

These flaws have been repaired now, and he showed it by the result of a telnet session to the PMAS port: pretending to be a SMTP client, he typed all code (or had a script running) to see if it was handled, and it got through.

However, it was too late to reconfigure the firewall. So one more day with spam passing: about 50 for the whole day, and counting.

The whole suite will be restarted to get the correct UIC to run in; the workers still run in Hunter’s account.

PMAS trouble
As it turned out, the big problem with this new version is that PTSMTP – the controller process – seems to have big problems. The author of the program (Hunter Goatley) has given a number of settings to see what’s going on.
The first thought was it didn’t listen to port 2525 at all, or didn’t receive anything. But with the logging enabled, it became clear immediately that it did: Each new message did trigger a worker to get to work, it gets the primary data and than passes control to the controller, and there it waits for the controller to return a result – and the worker will wait until, well, eternity.
The result is that with the next message arriving, the next worker is set to work; if it’s not there yet, it will be created, started, set to work, until the maximum is reached. That one will stop working, to make room for the next.
And so on, and so on. If that clearing takes place…
The net result is that not any message is actually handled, and the sender times out. It does not mean the worker is stopped, or that it’s signalled by the controller.

Hunter has offered to check on the system, and I set up an account, but he was not yet able to login due to a blockage somewhere on the route.

It ended, once more, in bypassing PMAS alltogether, and keep track of all spam by hand. Not a problem for a few days. Up to Sunday evening about 90 messages have been deleted.