OK, I finally dissected the cradle and found out the following:
- On the back of th cradle, there are 4 metal pieces that hold the thread for the screws that attach the cradle to the car-windshield-holder. One of the screws was loose (probably due to the constant rattling the craddle takes when attached to the windshielt), and the respective metal bit had detached itself from its plastic socket and fallen into the device, probably causing a short-circuit.
- There’s a fuse soldered to the PCB, and its blown. I short circuited it and found both the cradle’s and the GPS mouse’s LED to light up when bringing power to the system.
In short: There’s a good chance that my GPS mouse and cradle are still fully functional but I can’t say for sure given that my PDA is still dead. (Anybody got an rz1710 that they’d be willing to sacrifice for a test? ;) ) In either case: If you’ve got a similar GPS system, check the screws on the back from time to time and make sure they’re all safely attached (that way, the metal counterpart inside wouldn’t have been able to fall into mine).
I also tried to open the PDA, but alas it is riddled with those @^$ ultra-tiny torx screws which I just can’t get to budge. Anyway, I doubt I could fix whatever is damaged in there, and as you probably know, I’ve got a new one on order as well.
… but I did not touch the registry. OK, enough with the singing, my server doesn’t have a registry anyway! (at least not the one known from a certain operating system)
I DID however manage to mess up the configuration of my SMTP daemon. Sure, you might say that that is not a first, as I managed to inadvertedly disable TLS support a few months ago, but this time it was actually serious enough to be able to cause mail loss on my end. I noticed it this morning as I received a ‘delayed’ delivery alert from my MTA telling me that it had trouble delivering a reminder I had sent to myself. Looking a little further, I found the server trying to look up the domain in DNS and subsequently attempting to contact my outside/Internet IP address which eventually failed as my router doesn’t do forwarding on requests coming from the inside. Not realizing my mistake, I started digging around to actually try and forward the port, until it dawned upon me that the MTA shouldn’t even try to deliver the message through the network in its normal configuration. Sure enough, the test mail that I subsequently sent from outside bounced back in my face with a big “Error 550: relay not permitted” and I recalled recently editing the config files as I hurried to open my text editor.
The bottom line: While melding in updates from the default config file, I had managed to overwrite the line defining the server’s local domains, causing it to omit the ones I had manually added later. I’ve now changed this configuration and moved my local definitions out of the config file (and into the locally imported config that’s provided by my distro for these kind of things), that way, future modifications to the default/global config file shouldn’t affect this setting again.
P.S. I also did a quick scan through the logs and it looks as if I was lucky: the affected domains have a very low traffic volume and apart from spam, no other mail delivery attempts came in while the server was misconfigured. Phew.