2010/12/17

* This is mostly for personal copy-paste reasons

Those who take the time to develop applications using UW-IMAP (or Panda IMAP) know that there are a number of callbacks that need to be defined. What follows is the simplest (do nothing) version of them.

2010/07/02

Panda-IMAP is not publicly available. Mark Crispin allows access to it to people (and organizations) that donate to the development of the project. Since I am a dedicated user of the UW-IMAP toolkit and time had passed since the last version of the “old” UW-IMAP toolkit (back in 2008) on April 23, 2010 I personally donated $100 to the project. Replacing UW-IMAP with Panda-IMAP was a piece of cake and given that we are planning to move to mix format mailboxes, I am extremely happy with the result of using Panda-IMAP so far.

2008/07/18

Note to self:

When using the UW-IMAP toolkit in restrictBox or closedBox modes, or even with local patches, it is helpful to have a “vanilla” version of the utilities around, for they may not work as expected. It took me a while to figure out why

mailutil prune `pwd`/Trash “before 18-may-2008”

was not working as expected. Our local version was linked with a c-client.a with restrictBox = -1 and a local version of getpwnam(3).

Why on earth would anyone want to lay off Mark Crispin, is a mystery to me. As a long time user of the UW-IMAP toolkit I want to thank MRC for his work and software, which solved many of my problems and preserved much of my time.

2007/12/23

When I try to write email-related code and the result fails my expectations, I use my plan B: Write it in c-client. I suppose the fact that I do not start with c-client from the beginning is a result of suffering from the “Not Invented Here Syndrome“.

The other day I was trying to decipher the semantics of Thread-Index: and Thread-Topic: since it seems that Microsoft has not placed any public information on them. Apostolos suggested that Thread-Index: takes BASE64 values, to which I replied negatively. After all, decoding

/* A new post to a folder gets a 27-byte-long thread index. (The value
* is apparently unique but meaningless.) Each reply to a post gets a
* 32-byte-long thread index whose first 27 bytes are the same as the
* parent's thread index. Each reply to any of those gets a
* 37-byte-long thread index, etc. The Thread-Index header contains a
* base64 representation of this value.
*/

The “REFERENCES” argument to mail_thread() instructs it to use jwz’s algorithm. The other option is to use “ORDEREDSUBJECT” (or as draft-ietf-imapext-sort-19.txt calls it: “poor man’s threading”). walk_thread() just prints the edges of the graph (actually it is a tree):

You may wish to use the output of the above routine (slightly modified) and feed it to dot, so that you can have an image display of the threads in the email collection that you study.

What is left to discuss a little bit more, is the THREADNODE structure: You can go from a THREADNODE to its first child via the next pointer (thr->next in the above example). If the THREADNODE has two children, then the second is a branch of the first (thr->next->branch). It if has three, the third is a branch of the second child (thr->next->branch->branch) and so on.

2006/11/01

Years ago we were faced with the following situation: We had thousands of mailboxes that were being served by a proprietary and unsupported version of email software. So we decided to move to a new architecture. While researching I selected a very good (IMHO) commercial product. But for reasons outside the scope of the post I opted for a F/OSS solution, and specifically the UW-IMAP toolkit. For those rushing to judge that price was the decisive factor I only have to reiterate Vladimir Butenko‘s words:

OK and now for the real question: How do you move thousands of mailboxes without your users noticing?

Since you do not know (and do not want to know) your users’ passwords the only thing you can do is to hack into the source code of your POP3 server (we do not offer IMAP yet). Whether it is the UW-IMAP toolkit, Cucipop, popa3d or any other server that you have access to its source, the server knows the correct password for your users when they authenticate. So when the authentication succeeds you fork(2) a program that logs into the old server and fetches the mailbox from the old server to the new one that runs the F/OSS software that you have selected. This can be fetchmail or any similar program. However I have found out that Net::POP3 is a better choice:

Where exactly in the server code you fork(2), exec(3) and wait(2) for the script depends on the source code. You need to find where in the server code the authentication procedure succeeds and patch from there, before the server actually opens the user’s mailbox.

This script basically checks whether it has already moved a user’s mailbox from the old server. If it has, then the user is found in /etc/pop3.users.db and the script exits. If not, then the mailbox is moved and the user is inserted in /etc/pop3.users.db. Simply using Net::POP3 allows you to move the old mailbox to the Unix traditional mailbox format. That is why we fork tmail, since I have chosen the mbx mailbox format to store messages (I compile UW-IMAP with CREATEPROTO=mbxproto). If your server supports a format like Maildir, then you have to customize the above script accordingly, since it is written for mbx, which means that the user’s mailbox is a single file.

postmaster: n.

The email contact and maintenance person at a site connected to the network. Often, but not always, the same as the admin. The Internet standard for electronic mail (RFC-822) requires each machine to have a ‘postmaster’ address; usually it is aliased to this person.