I spent a fair amount of time sorting out how postmaster email is routed after we received a couple of reports that anyone trying to send email out to postmaster at other domains had their email snaffled and sent to our postmaster account
A look at the Exim config showed a rather confused routing for postmaster that involved rewrites and redirects to another account, back to postmaster and then finally back to the other account again for delivery. I removed all this gumph and replaced it with a single alias to route postmaster correctly. I also managed to cut our oldest mailhub, mercury, out of the loop meaning it’s days are numbered
. As usual the actual change took very little time (once I’d figured what out what on earth it was doing) but testing to make sure I hand’t knackered the config took quite a while. It’s in service now and seems to be working, which is good.
A side effect of this is that spamchecking for the Postmaster account now works, a feature requested by the people that look after it. We’re slightly unsure whether this is wise given that postmaster is a likely recipient of Freedom of Information requests. However, they claim the spam folder is checked carefully daily (though you wonder if there is a point spam checking for the account in this case…).
As a quick project I was also asked if I could find a way of checking whether certain windows computers were turned on and run this at regular intervals (this is for lecture theatre pcs). Nice and easy if you have the IP/hostname but a bit more fiddly if you only have the NETBIOS name (yuck). A bit of searching found nbtscan, which while it doesn’t do quite we I wanted does do netbios lookups incredibly quickly and is likely to be a useful tool. In the end I used nmblookup to query the WINS server to look for registrations for the computers which seems to work. If I can get IPs for all the computers I can use nbtscan which might be a bit quicker but it’s difficult to find the IPs out as the hostnames have no correlation to the netbios name. Hohum