tigeremailimapthunderbird
I just finished a journey through my e-mail configuration and while it was mostly frustrating, I thought others might find some parts of it of interest.
It all began innocently enough. I received my copy of MacOSX Tiger on April 29th. One of the first things I noticed after the upgrade was the new Mail application. The new UI is awful. I start to feel depressed by the colors in the new UI. (For folks who are interested in changing the UI, two programs I've heard about are Mail Fixer and Cage Fighter.
But, for me, even worse than the UI was the fact that Mail now refused to show me when I had new mail in my mailboxes. I mean what's the point of an e-mail program if you have to click on each mailbox to find out if there's a new message?
Before I continue, I should say a little bit more about my setup. I have a few Macs and a few PC's around the house. Since I never wanted to lock myself down to having to read e-mail at any specific machine, I long ago setup a machine (FreeBSD) to act as an IMAP server.
Rather than sort my email into mailboxes at the client, I sort my mail on the server using procmail. This makes sure that no matter what machine I'm using to read my email, I can have the same sort of sorting going on regardless of the platform and mail reader.
So here's where Mail has a problem. It's not just my INBOX that needs to be checked for new messages. New mail may get sorted into many different folders on the IMAP server. Sadly, and for reasons I cannot begin to fathom, Mail only checks the INBOX when it checks for new mail.
Now, this problem isn't new. It's existed on the Mac before. In face, I used to use an AppleScript I found on the net as a workaround. Unfortunately, with Tiger, this workaround no longer works. It doesn't force the Mail app to recalculate the number of unread messages in each mailbox.
I don't know why exactly, I was surprised by this. I guess, I just assumed that my configuration cannot be that uncommon and that surely someone at Apple would do the Right Thing (tm) and fix Mail so it worked properly with IMAP clients. Well, you know what happens when you assume.
After I noticed that Mail wasn't working the way I wanted it to, I managed to convince myself that I must be doing something wrong. So I thought I'd better check things out by making sure my IMAP server was up to date. I was running a copy of the UW-IMAP server from 2003. I installed the latest version from the FreeBSD ports collection which was the 2004a version. It's not quite the latest, but I didn't see anything in the UW-IMAP release notes about updating unread message count so I figured it would be safe.
Anyway, after getting the new server going, it didn't change Mail's behavior at all as I mentioned above. However, I did learn a little more about the UW-IMAP server in my travels. I came across this document about mailbox formats. It seems that by default the server is built to handle old-style UNIX mbox mail formats. I've always thought this was a great thing since the mail messages are stored in plain ASCII, but I have definitely been noticing that my larger mailboxes take longer to load in my mail programs.
After reading that document, it seemed that UW-IMAP was optimized more for their own mbx format. And, it turns out that the UW-IMAP distribution provides a handy little tool called mailutil which allows you copy your existing mailboxes into mbx format. For example, this command will copy the mailbox "foo" which is mbox format into a new "foo_mbx" folder in the mbx format:
mailutil copy '{localhost/novalidate-cert}Mailboxes/foo' '{localhost/novalidate-cert}#driver.mbx/Mailboxes/foo_mbx'
The novalidate-cert is necessary since I have a self-signed certificate on my IMAP server to do SSL connections. Without that option the command failed. I didn't do any benchmarks, but in my opinion, Mail seemed to be able to open the mailboxes much more quickly once they were converted to mbx format. Looks like someone else did do some benchmarks.
So, after spending all this time tinkering with the server, I found myself no better off than before I started. I was still stuck with the ugly new Mail 2 application which wouldn't tell me when I got new mail.
I thought about Thunderbird a few times and decided that even though it updated the unread count, I couldn't switch to it because I was addicted to being able to use Apple's Address Book.
But, wait...
I noticed that in the "General" tab of the preference panel of the Mail application there's a preference called "Default Mail Reader" You can specify any application you want and it will become the default application to handle mailto: URL's. Specifically, the following gets written into the com.apple.LaunchServices portion of the defaults database:
{LSHandlerRoleAll = "org.mozilla.thunderbird"; LSHandlerURLScheme = mailto; }
Now, I can go the Address Book, select a person's card and when I try to send mail to them, it open's in Thunderbird. It works well enough for now.
So, for a while now I've been getting e-mail like this from my Sonicwall firewall:
From:
Date: Wed Dec 10, 2003 1:50:19 PM America/New_York
To:
Subject: *** Alert from SonicWALL *** [0040100CF2DA]
12/10/2003 13:48:54.672 - IP spoof detected - Source:172.208.217.243, 138, LAN - Destination:172.208.255.255, 138, WAN - MAC address: 00.30.65.A9.15.36 -
I had always assumed that it coincided with times when I ran the AOL client on my G4 Cube.
Today I realized that it was sending messages when I wasn't using the computer.
Puzzled, I ran "netstat -W" and found these:
udp4 0 0 acd0d9f3.ipt.aol.com.netbios-dgm *.*
udp4 0 0 acd0d9f3.ipt.aol.com.netbios-ns *.*
And of course, acd0d9f3.ipt.aol.com is 172.208.217.243 according to nslookup. So, why do I have this connection running from my machine to the universe ? What app has that connection ?
[paris:~/Desktop/Web Downloads] rob% lsof -i
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
iCal 430 rob 11u inet 0x03309a4c 0t0 TCP localhost:55578->localhost:ipp (CLOSE_WAIT)
iCal 430 rob 14u inet 0x02c737bc 0t0 TCP localhost:55557->localhost:ipp (CLOSE_WAIT)
Safari 1559 rob 14u inet 0x03321a2c 0t0 TCP localhost:57864->localhost:ipp (CLOSE_WAIT)
Safari 1559 rob 23u inet 0x033094ec 0t0 TCP localhost:57854->localhost:ipp (CLOSE_WAIT)
Safari 1559 rob 28u inet 0x033101dc 0t0 TCP paris.balboa1321.bogus:59959->216.239.37.99:http (ESTABLISHED)
Safari 1559 rob 38u inet 0x02c73a6c 0t0 TCP paris.balboa1321.bogus:59960->nurse.csi.cam.ac.uk:http (CLOSE_WAIT)
Mail 2672 rob 9u inet 0x033084cc 0t0 TCP paris.balboa1321.bogus:59396->montauk.balboa1321.bogus:imaps (ESTABLISHED)
Mail 2672 rob 12u inet 0x032c1a0c 0t0 TCP paris.balboa1321.bogus:58072->montauk.balboa1321.bogus:imaps (ESTABLISHED)
Mail 2672 rob 16u inet 0x033214cc 0t0 TCP paris.balboa1321.bogus:57884->montauk.balboa1321.bogus:imaps (CLOSE_WAIT)
Mail 2672 rob 17u inet 0t0 TCP no PCB, CANTSENDMORE, CANTRCVMORE
Mail 2672 rob 18u inet 0t0 TCP no PCB, CANTSENDMORE, CANTRCVMORE
Mail 2672 rob 19u inet 0x0331073c 0t0 TCP paris.balboa1321.bogus:59835->montauk.balboa1321.bogus:imaps (ESTABLISHED)
ssh 3648 rob 3u inet 0x0330923c 0t0 TCP paris.balboa1321.bogus:59769->montauk.balboa1321.bogus:ssh (ESTABLISHED)
I'm pretty confused at this point. I tried killing processes until I could get the netstat to show that the AOL netbios ports were gone. They seemed to go away when I killed nmbd. I thought that maybe somehow they were being created when I ran AOL client like AOL itself or an AIM client like iChat, but I just tried that and the connections were not recreated.
Mysterious...