Email Me

Musings for the Week of December 3 These are my musings for the week. Pull up a keyboard or mouse, click here to read the latest ramblings, and off we go...

Sunday, December 3 - Sniffles

Yes, I have the sniffles. A cold of some sort, I think, mostly in the head and chest. Not too debilitating, but annoying.

New essay is up, follow the link and enjoy. And now, I need a refill of tea. Tomorrow, all.

Tuesday, December 5 - Creeping Crud & Galloping Email... No, Sorry, Galloping Crud and Creeping Email

Yeah, yeah, I know, I missed a day. <sheepish grin> Between fighting off this whatever-it-is (no mere cold, this must surely be a demon-spawned curse from the netherworld) and the email troubles, and of course the fact that it was Monday, trust me. You didn't want to talk to me anyway. <G>

But here I am, another day, here at work spreading cheer and cold germs. Think I've kicked the email troubles, though. Although last night, they were a real problem. Specifically, according to my email server, I didn't exist. Neat, huh? And it wasn't consistent. From most people that I've talked to - Keri, Tom, and others, there was no problem at all.

But, my mailing lists (normally a raging torrent of email; Keri's noted before that in the time it takes to drive home, I get a couple of dozen messages) slowed over the weekend. Right after changing the DNS entries for the rearviewmirror.org domain. I didn't think anything of it; a weekend in December, well, it's going to be slow. And it didn't STOP, it just slowed. Then it did stop, yesterday about noon. But I was still getting email from "real people". I started to wonder a bit, but I still wasn't really worried; obviously there was nothing wrong with Fortytwo (the web/email server) since it was merrily serving web requests and emails alike. I could send emails no problem, and emails were coming in. Where's the problem?

I quickly found a serious problem; the most important recruiter I've been speaking to couldn't send me email. When mailing lists emails don't arrive, that's a mild annoyance; I might conceivably miss something I need to know. When the recruiter handling the job I want can't send me email, it's time to hit the Master Alarm and run through some emergency procedures. First step, what kind of error are they getting? Is it possible it's on their end? No, they can send email to others. Hmm. OK, are they just not seeing the server? No, they can see the web site. Double hmm. Well, OK, when the messages bounce, what's the error message? "User unknown". Uh - excuse me?

There are two reasons why that shouldn't be possible. One, I *know* matt@rearviewmirror.org works; I'm happily sending mail with it (they're even receiving it) and other people are emailing me at it. Two, even if the user DIDN'T exist I'd still get the email. Communigate is configured such that if an email arrives for an unknown user, it accepts it and routes it to the postmaster account (for those without a scorecard - me). This allows the handy party/business trick of simply telling people to send you email at theirname@domain.tld. (For example, John Doe could send me email at jdoe@rearviewmirror.org and I'd get it.) Amazing how the little things impress people so much. <G>

OK. So we have here an impossibility. But it's really happening, so forget "impossibles" and figure out what the heck is going on. Number one, what's changed? Well, DNS has - but not the MX (mail exchange) records, only the www record. That can't be it. Tom reminded me of something, though; DNS is wierd. No, it shouldn't affect email in the slightest, since that record was unchanged, but it would appear that it has. Most likely, sitting back and letting things settle out for a few days would fix the problem.

But what kind of Daynotes Gang member would I be if I didn't do silly things that later prove to be pointless? Isn't that our motto? <G> So, let's start playing with the configuration and see what we get. First step, let's really take a look at the message process and see what's happening. How does one go about that? Fire up telnet.

First, just for review, let's check messages on my account. Step one, open a session to the POP3 mail server, on port 110.

$ telnet 192.168.1.100 110

That uses telnet to open a connection to port 110 on server 192.168.1.100. You would of course use some other address. (And people say telnet isn't good for anything anymore!) Assuming the connection is established, you'll see something like this:

Trying 192.168.1.100...
Connected to 192.168.1.100.
+OK CommuniGate Pro POP3 Server 3.4b6 ready <4812.976037153@rearviewmirror.org>

So now you need to log in. You do that by first identifying yourself (note; commands are case-insensitive. USER is the same as user is the same as UsEr.

USER matt

To which the server responds:

+OK Please send the PASS

And you respond with the password. Please note that the password is sent in plaintext which means anyone who set their mind to it could discover your email password if you're communicating over the internet or any public network. Watch those passwords, people!

PASS whatever

No, that's not really it. The server responds with (if you got it right)

+OK 6 messages in queue

There are other commands I would now use to check and download messages; LIST displays the number and size (but nothing else) of all the messages, TOP msg n lists n lines of message number msg and so on. For my purposes, though, I'm done; the mailbox works, which is all I wanted to check. So I'll quit now. (Do NOT simply close the telnet session by escaping out or closing the telnet client; that leaves the connection thread hanging, which can in some circumstances crash the mail server or at least your mailbox. Prevent that simply by saying

QUIT
+OK CommuniGate Pro POP3 Server connection closed
Connection closed by foreign host.

$

So. The user is definitely there, the mailbox is working. Now let's see what happens when I send mail to that user.

Once again, telnet to the rescue:

telnet 192.168.1.100 25

Port 25 is SMTP, Simple Mail Transfer Protocol. Just think of it as the "outbox" to the port 110 "inbox". You should see something like this:

Trying 192.168.1.100...
Connected to 192.168.1.100.
220 rearviewmirror.org ESMTP CommuniGate Pro 3.4b6

Now, you have to say who you are - what domain you're from. How do you tell it your domain? Why, you say HELLO of course! Or, more correctly, HELO...

HELO athena.rearviewmirror.org

Now then, let's send a message.

MAIL FROM:test@rearviewmirror.org
250 test@rearviewmirror.org sender accepted

That "sender accepted" stuff means that sender is allowed for this mail server. The spammers have made it so that you have to authenticate to send email from the server; in the "good ol' days" any server would do to send email from. Not anymore. Anyway, now we tell it who we send the message to:

RCPT TO:matt@rearviewmirror.org
250 DATA Subject:Test message

Now here, you have to hit [ENTER] twice. Why? Because the RFC says so, that's why. But then you can enter your message. To send the message, go to a new line, type ".", and hit [ENTER] again. You should get

250 OK

or a variant depending on your mail server; I get

250 91680 message accepted for delivery

Which means the same thing.

And that's it. So where's the problem? Well, like all good scientists, I immediately concluded (since I got the answer I wanted) that there was no problem, and clearly the email fairies were simply in the mood to cause problems. Then the ghost of the scientific method rolled in its grave and smacked me across the head, and I recovered.

I was neglecting a crucial variable in the experiment; I was doing all of this from my living room, on the same network as the mail server, and I was doing so without using DNS to connect; I was using the straight IP. Because of the way the network is layed out, I *have* to do things that way; DNS points to the public interface of Pluto, the firewall, not to the mail server directly. Pluto then takes requests to those ports (specifically, 25, 80 (for web) and 110) filters them for "bad things", and forwards them to Fortytwo. From inside the network, you can't do that; the packets apparently can't take a turn that sharp and messily fly off into the crowd. I dunno exactly why, but it's documented that you can't do that. (I asked the guy who wrote that software why once; he started explaining, the world started spinning, and I woke up hours later with a headache and a reservation against asking people detailed questions about computer languages I don't know.)

In other words, I'm suspecting there's a DNS problem, but I just tried to test the problem without involving DNS anywhere in the test process. Well, what can I say, it was Monday.

So. How do we get DNS involved in the process? Try the whole thing again from the outside world. OK, I've got accounts on Hydras, work, and a few other places... where should I test from? Well, we know Tom can send me email. I didn't try sending email to myself from work. So, let's try that...

ssh to work, then telnet back (a very silly exercise, but what can I say... POP traffic CAN be encrypted, but it's a pain when you're using Outlook. So I don't. Yet.) and go through the same routine.

User Unknown

Well, ain't that a kick in the head...

What's different? Well, I went through DNS. I do the same routing again using the IP (24.14.247.139) instead, and it works beautifully. No troubles. I try the same thing again using a couple of domains that I have pointing to the box that aren't in use; again, works like a charm. It only happens when I send to matt.

On a hunch, I spell out the entire user; CommuniGate fills it in for you by default, but you can specify the whole thing. The message goes through.

Well now I'm very confused. It seems on the face of it to be DNS; so long as I use the IP address, everything's fine. It's only when I use DNS that it gets hosed. But then, if I simply spell out the whole username, it works. If the problem were really DNS, it should work even with the whole username. Also, it's odd that DNS works well enough to provide a connection, and THEN it fails. If it were DNS alone, it shouldn't connect to the server at all. Muttering imprecations upon the head of whoever's causing the problem, I open the CommuniGate administration page in my browser and look at the domain settings.

Suddenly, lights dawn, angels sing, and imprecations rattle off my head.

Let's back up a step... prior to last week, "rearviewmirror.org" pointed to Hydras at Tom's place. This weekend, I changed that to point to my own network. Well, CommuniGate includes a very nice webmail system, very handy indeed, but if you tried to browse to rearviewmirror.org at the right port for webmail, you got Tom's mail server, not mine. So I had a DNS A record for pluto.rearviewmirror.org, which is where all mail goes. This worked just fine for regular mail routing; the traffic was forwarded in to the mail server, the mail server simply accepted packets as they arrived; the security to prevent spamming didn't work off of where the packets where pointed to, only where they came from, so CommuniGate didn't notice that the packets were pointed to "24.14.247.139" instead of "192.168.1.100". However, to use webmail, CommuniGate DOES check what name and IP you pointed your browser to. If you were outside the firewall, and you tried 24.14.247.139, you got a polite message telling you to buzz off; although that address did somehow point to that server, it didn't provide services for that name - so go away, please. If you used pluto.rearviewmirror.org, you got the same error, because the mail server was for rearviewmirror.org, not pluto.rearviewmirror.org.

Being lazy, I solved the problem the easy way; I told CommuniGate that it would now provide services for the pluto.rearviewmirror.org domain. Point the browser to pluto.rearviewmirror.org, and when you log in, just make sure you give it the full username and domain. Since I didn't intend to actually use pluto.rearviewmirror.org email addresses, I didn't bother to do anything to the domain settings or create any accounts. In fact, I quite forgot about it. This was fine, since the mail server doesn't really care where packets are going, as I said, it simply accepts them. But, of course, the server has to look to see which domain the packets are intended for...

So what was happening was that for some people, or more precisely, some mail servers, the messages were arriving tagged for delivery to pluto.rearviewmirror.org - the DNS record for the machine - and were attempting delivery to a "matt" account under pluto.rearviewmirror.org, rather than under rearviewmirror.org. I deleted the pluto.rearviewmirror.org domain under CommuniGate (since rearviewmirror.org now pointed to this machine, I didn't need the workaround anymore), went back, and tried again. This time, it worked properly.

Now, I'm not certain WHY this caused a problem. Mail messages sent to matt@rearviewmirror.org shouldn't be going to the pluto.rearviewmirror.org domain, no matter where the TCP packets are headed. So far as the mail server software is concerned, it should be looking at the mail headers, not the packet headers. But the instant I deleted pluto.rearviewmirror.org, it started working again. I dunno.

At any rate, that seems to have solved the problem. Let's see what problems today brings...

Wednesday, December 6 - Duck!

Morning... errr... Afternoon, all!

I suppose you're wondering what the "Duck!" thing is about... well, our office building has floor-to-ceiling windows. I'm on the south side of the building, looking out over a series of landscaping ponds - these, in fact - and there is a large flock of ducks that frequent these ponds. They seem content there, rarely flying at all; mostly they walk from pond to pond, and that's about it.

Well, as anyone in an office with windows like this knows, on occaision a bird will be blinded by the reflection of sunlight off the windows, and fly into the windows. When that happens here, it's a little startling; a sudden THUMP that echoes through the very quiet office (I'm pretty much on my own back here). Usually, the bird's OK; if you look quick enough, you can see it flying - a bit wobbly - back away from the building.

Today, a duck hit the window.

Now, these ducks are not small, and they are very well fed. I didn't here a sudden THUMP, instead there was a very loud THWACK. For a second, I thought I was going to have a duck in my lap; the window bowed in far enough to disturb the venetian blind, though fortunately without cracking or breaking. I don't know if the duck was OK or not; I couldn't see it. On the other hand, I didn't see anybody running towards the area belw the window, although a few from the cafe below were looking up towards the window.

So that was my excitement for the day. You?

For the past few days, I haven't used Windows much at all; I've done everything on either IGOR, my office workstation, or the laptop formerly known as Homer, now Thoth, at home. Both are running Mandrake 7.2, KDE2.

Things have definitely improved; KDE is to the point where I think Keri or any other reasonably-knowledgable computer user could work productively, although there are still rough edges. For me, there are only a few things missing; a decent mail client, a good scheduling program and a really good Visio replacement. On email... sigh. Most of the Unix/Linux clients are extremely powerful. Rules-based filtering unmatched by anything in the Windows world, stability, compatability with almost any sort of email... but they're all crap when it comes to the interface. This is one area where I refuse to accept a shoddy interface design. Email serves a critical purpose, two-way communication, and an interface which makes that more difficult than it absolutely has to be is unacceptable. Outlook has many faults, but it has a fairly good - not perfect, but fairly good - interface. It's decades ahead of the various Linux interfaces, though. (Yes, Tom, I did try Mulberry; can't stand the multiple-windows thing. For some applications, that's perfect, but not for my email. One window, please, preferably with customizable frames to show different things.)

Right now, I'm using Kmail. It works, I guess, although some things about the folder layout and interface drive me nuts; for example, a message arrives from a mailing list and is filtered into that mailing list's folder. Great, that's what I want. One problem - there's absolutely no indication that that folder has new messages in it. If I open that folder, the messages that are unread are a different color, but there's nothing on the folder itself.

CORRECTION: I just finished upgrading to KDE 2.0.1, and now the folder names are bolded when there are unread messages, with a red number next to the folder name to indicate how many there are. In addition, top-level folders (all the mailing lists are under a top-level folder named Lists, for example) are bolded whenever a folder under them has unread messages. That's much better.

Kmail does integrate well with both PGP and GPG however, which is good. I use PGP, which seems to work much better when switching from Windows to Unix and back. Once I got PGP installed and my keys imported, Kmail took 30 seconds to configure its use. I just noticed something odd, though; PGP is automatically set to sign all messages. That's not really a bad thing, but it's unusual; I hadn't noticed until now, because Kmail doesn't display the usualy boxed "PGP Signed Message" headers and footer. Instead, it puts a little line of text in the formatted header box that says "Message PGP signed by" and the user. Interesting, and more good then bad, I think.

Anyway, what that means for me is that I could do away with Windows on the desktop for all but a few tasks. I don't think I will, though. In another year... who knows?

Friday, December 8 - Grand Piffle

Yes, that's right. Grand Piffle indeed. What's going on? Well, let's see...

Scooter the Wonder ThinkPad is living up to the IBM ThinkPad nickname of Stinkpad, and it's NOT because of Windows. It crashed yesterday, about 2 PM, shortly after I finished writing a post for the day, but before I'd transferred it to the server. BSOD (Windows 2000's BSOD is a different shade, have you noticed??) and rebooted.

Now, this is a part of life with Windows, we all know this. But generally, it's associated with Windows 95/98, not Windows 2000. I can count on the fingers of one hand the number of times Keri's Anya has crashed. Most of my other Windows 2000 workstations are much the same, although a couple are a bit more finicky. But Scooter... he's been crashing a LOT lately. I'd been thinking about YANW2KI'ing it, but I hadn't gotten around to it yet. Then, yesterday happened. Scooter wouldn't reboot.

I mean literally. Not that it froze up again while loading windows. Not that it couldn't find the MBR. I couldn't even get the stupid "IBM" logo to come up while it loaded the BIOS. Hit the power button, watch the lights flash on, then off, while the power light stayed on - normal. Watch the battery indicator change from "AC" to "AC Charging - Full Charge" - stupid, but normal. Wait for the LCD to light up and IBM's grandiose advertisement to appear.

Wait some more.

This is not normal.

This is not good, either.

This is bad. I am... displeased. And the computers know what happens when I am displeased. (You know, sometimes I wonder why I'm all alone on one side of the office while everyone else is on the other side...)

I spent about two hours alternately cursing, lecturing Scooter on proper computer-SysAdmin relationships, and hunting for a florist and chocolate shop (Hey, it works when Keri stops talking to me...) and hitting the power button. Finally, in disgust, I went back to my Linux workstation and left Scooter to sulk. This morning, it booted up - but it went to the machine BIOS instead of loading the OS, with the oh-so-helpful helpful message that it detected failed boot attempts. I checked over the settings, told it to reboot, held my breath, and hit that Fine power button again.

No boot.

Dirty words, spit, snot, lawyers, and other unholy things. Try again. Scooter came up, and I hit F12 to select another boot device (guessing correctly that I could avoid the BIOS that way. Either that, or it wasn't going to do it this time.) Tell it to boot from hard disk... windows comes up. Oh goody.

Do not pass Go, do not collect $200, make a quick backup of all data. Fortunately, that was easy - everything's in one folder. I cheated and used SSH to quick copy everything to my workstation. (note to novice SSH users; learn the "SCP" command. The "SCP" command is your friend. Except when it does the wrong thing, then it sucks.)

scp -r "C:\Documents and Settings\mbeland\My Documents\*" matt@igor:backup/