Monthly maintenance – with a twist
The automated job works fine. Nothing weird or unexpected found. Even in mail:
PMAS statistics for June
Total messages : 2451 = 100.0 o/o
DNS Blacklisted : 0 = .0 o/o (Files: 0)
Relay attempts : 266 = 10.8 o/o (Files: 30)
Accepted by PMAS : 2185 = 89.1 o/o (Files: 30)
Handled by explicit rule
Rejected : 1589 = 72.7 o/o (processed), 64.8 o/o (all)
Accepted : 204 = 9.3 o/o (processed), 8.3 o/o (all)
Handled by content
Discarded : 153 = 7.0 o/o (processed), 6.2 o/o (all)
Quarantained : 197 = 9.0 o/o (processed), 8.0 o/o (all)
Delivered : 42 = 1.9 o/o (processed), 1.7 o/o (all)
Since DNSBlacklisting hasn’t been re-enabled yet, the number of messages is zero – obviously. Given the number of messages there is no real need at the moment, and I want to monitor it closely, so it might be done in a weekend or so.
Relay attempts were concentrated on the last few days, but the amounts are not that big.
There are quite a log of debug log files; needed to investigate some things, but I’m way to busy with other stuff ….
This month’s twist is the mail access trouble. Since HP’s POP doesn’t seem to work properly, I have now installed another program: Ruslan Laishev’s Starlet POP server (SPOP3). It has been developed as a service running on the TCPWARE stack, or as a detached process. Since I don’t use TCPWARE, I would like to have it running as a normal TCPIP-service. But as it turned out, this is not possible: appearently, there are problems accessing the sockets, according Ruslan; Attempting to connect to a socket crashes the program with a DUPLNAM error.
But it works as a detached process so I left it that way. It does the job, although a bit different: where HP’s POP process copies files to the WASTEBASKET folder in VMSMAil, SPOP3 actually deletes read messages. This is an alteration I may add.
The second mail access protocol;: IMAP, is also running, I use it for my phones and tablets – in stead of POP because mail is accessed where it resides. But for some reason, it seems the IMAP process stalls for some reason, the logs do not give a clue on what may have caused it. This was the case for a day or two; and tonight I found multiple TCPIP$IMAP processed on the system, both HIB but not responding – I gor network errors on my Android devices. All went fine after they were restarted.
01-Apr-2014
More of the same
The end-of-month processing shows no surprises:
PMAS statistics for March
Total messages : 2569 = 100.0 o/o
DNS Blacklisted : 0 = .0 o/o (Files: 0)
Relay attempts : 495 = 19.2 o/o (Files: 31)
Accepted by PMAS : 2074 = 80.7 o/o (Files: 31)
Handled by explicit rule
Rejected : 1538 = 74.1 o/o (processed), 59.8 o/o (all)
Accepted : 176 = 8.4 o/o (processed), 6.8 o/o (all)
Handled by content
Discarded : 136 = 6.5 o/o (processed), 5.2 o/o (all)
Quarantained : 197 = 9.4 o/o (processed), 7.6 o/o (all)
Delivered : 27 = 1.3 o/o (processed), 1.0 o/o (all)
It may seem weird that there are no mails rejected because of the sender being blacklisted, but that is because I had to disable this….But it seems the rules are strict enough, blocking almost 75% of what remaind. Nevertheless: it might stil be a good idea to re-enable it again, and be at hand if there still is a failure..
There is, however. a very different problem, with VoiP.
The router facilitates VoiP using standard, analog phones. Works fine, except that at times, connections are dropped, and calling us is at times impossible. The Dect phone I used did have a problem with power – the adaptor had a bad connection and the batteries were too old, so the unit ran out of power fairly quicky.
Now we have a new set, and at first, it didn’t show this behaviour. It did, however, show something else – perferrably in the middle of the night, for two nights in a row: it rang a few times, displaying a small number – 2,to 5 digits where 10 is normal. then quit the connection. This happened a few times i a minute, and al of a sudden it stopped.
Today, connection was, once again, dropped after a few minutes…
The big problem to solve it, is that it cannot be reproduced at will. Plus that I will have to reinstall the Fritzbox for the test – something I would try to avoid due to it’s restrictions…
03-Feb-2014
NTP issue – update
From several sides I got information on the NTP problems; John Santos (via OpenVMS SIG) suggested a test for checking whether time was updated, using ntpq (it did) , and Stephen Hoffman showed me where NTPDC is located; but I found that already, and disabled monlist as was suggested – by editing TCPIP$NTP.CONF. Now monlist doesn’t work anymore – not even on localhost (directly), nor does ntpq – runs into a timeout. The router log doesn’t show any more incoming NTP traffic either – what used to be the case when monlist was not disabled. time to dig into the manuals – if available….Enabling monlist – just to be able to do some synchronization – might be a possibility – now incoming traffic to port 123 is disabled….We’ll see.
For the rest, no real surprises:
PMAS statistics for January
Total messages : 1414 = 100.0 o/o
DNS Blacklisted : 0 = .0 o/o (Files: 0)
Relay attempts : 338 = 23.9 o/o (Files: 31)
Accepted by PMAS : 1076 = 76.0 o/o (Files: 31)
Handled by explicit rule
Rejected : 445 = 41.3 o/o (processed), 31.4 o/o (all)
Accepted : 288 = 26.7 o/o (processed), 20.3 o/o (all)
Handled by content
Discarded : 137 = 12.7 o/o (processed), 9.6 o/o (all)
Quarantained : 163 = 15.1 o/o (processed), 11.5 o/o (all)
Delivered : 43 = 3.9 o/o (processed), 3.0 o/o (all)
There have been relay attempts on a few days- on 13-Jan-2014 there were about 100 from one address. Of course these failed.
02-Nov-2012
Monthly maintenance
Nothing strange:
PMAS statistics for October
Total messages : 8043 = 100.0 o/o
DNS Blacklisted : 3228 = 40.1 o/o (Files: 31)
Relay attempts : 199 = 2.4 o/o (Files: 26)
Accepted by PMAS : 4616 = 57.3 o/o (Files: 31)
Handled by explicit rule
Rejected : 3984 = 86.3 o/o (processed), 49.5 o/o (all)
Accepted : 243 = 5.2 o/o (processed), 3.0 o/o (all)
Handled by content
Discarded : 133 = 2.8 o/o (processed), 1.6 o/o (all)
Quarantained : 208 = 4.5 o/o (processed), 2.5 o/o (all)
Delivered : 48 = 1.0 o/o (processed), .5 o/o (all)
Two files of relay attempts: one of 40 blocks (147 lines): every 10 minutes am attempt from address 66.231.174.114, during a whole day; the next day, it went on (from the same address) until about 05:00. Probably it has started before but in too lttle amounts.
This address refers to the internal mail server of Centennialpr.com, a subsidiary of AT&T. This seems to be an ISP or similar, in Puerto Rico. Weird… Has this server been hacked?