Migrar Thunderbird de "mbox" a "IMAP" (I): Consideraciones

Thunderbird es un buen cliente de correo electrónico. Te permite algo que considero fundamental: descargar el correo en tu ordenador y poder trabajar con él en local, sin tener siquiera una conexión a Internet. Esto es muy importante como backup, para poder trabajar desconectado (por ejemplo, mientras viajas) y para poder almacenar un histórico de todo el correo electrónico independientemente de la capacidad que nos de nuestro servidor.

Pero Thunderbird tiene algunos problemas serios. En el contexto de este artículo, me centraré en uno: el formato nativo de almacenamiento de mensajes de Thunderbird es mbox. Este formato tiene muchas ventajas, como que se puede abrir con un simple editor de texto y que es compatible con casi todo. Pero tiene varios problemas:

1. Yo tengo en torno a un millar de carpetas, entre correo normal y RSS. En este momento mis carpetas ocupan unos 20 gigabytes.

2. Cada vez que se modifica una carpeta en alguna manera (entra un mensaje nuevo, se borra algún mensaje, algún mensaje se marca como leído, etc), toda la carpeta se marca como dirty y es necesario hacer backup de ella. El problema es que tengo carpetas que miden entre 500 MB y 2GB.

   Incluso usando estrategias diferenciales y combinaciones de ZFS, RSYNC y in-place como se describen en mi artículo Backups con RSYNC y ZFS, comparar dos archivos de 2GB para descubrir que solo se ha marcado como borrado un mensaje de 7Kbytes en medio es bastante pesado en términos de tiempo y ancho de banda de disco.

3. En mbox los mensajes borrados no se borran, sino que se marcan como borrados en el fichero, pero siguen ahí. Es decir, los ficheros mbox van creciendo y creciendo. De vez en cuando hay que hacer una compactación de carpetas. Básicamente, se lee una carpeta mbox y se van copiando los mensajes vivos a otro fichero, saltándonos los mensajes borrados. Luego se borra el fichero mbox original y se renombra el nuevo.

   Esto tiene varias consecuencias importantes:

   1. La compactación de 20GB de correo es un proceso pesado. Si se ha borrado un mensaje en un mbox de 2 GB, hay que copiar 2GB de un lado para otro.

      Thunderbird no nos dejará hacer nada hasta que termine la compactación.

   2. Durante la compactación necesitaremos tener espacio libre en disco para el fichero mbox más grande que tengamos. Esto es un problema cuando el motivo habitual para hacer una compactación es que nos hemos quedado sin espacio en la partición de correo.

   3. Como estamos creando ficheros mbox nuevos, la efectividad de los snapshots ZFS para ahorrar espacio en disco no es que sea baja, es que resulta negativa (ZFS conservaría las versiones anteriores de los ficheros mbox, multiplicando el espacio en disco)

   4. Aunque usemos una tecnología como la descrita en mi artículo Backups con RSYNC y ZFS para las copias de seguridad, una compactación mbox supone el cambio de desplazamiento u offset de los mensajes dentro del fichero original. Por tanto los snapshots ZFS tampoco serán muy efectivos para ahorrar espacio en el disco de backup.

   5. Si Thunderbird falla por algún motivo, los metadatos cacheados de los mbox pueden quedar corruptos. El efecto habitual es que Thunderbird se niega a meter correo en ese mbox mediante las reglas de correo automáticas. En este caso basta con seleccionar la carpeta en cuestión en el entorno gráfico de Thunderbird para que detecte que los metadatos cacheados están mal y los recalcule de nuevo. Pero cuando tienes mil carpetas, lleva un rato encontrar la correcta. Además, se pierde información relevante sobre esa carpeta, como las columnas que deben mostrarse, si los mensajes deben visualizarse el modo "threading" o no, el orden de visualización, hilos marcados como "watch" o "ignore", etc. Es decir, un coñazo.

   6. Mbox no está pensado para acceso concurrente y, si otros programas modifican un mbox mientras Thunderbird está funcionando, los resultados son imprevisibles. Incluyendo la corrupción del fichero.

      Se pueden tener accesos de lectura concurrentes (en Unix), pero hay que tener en cuenta que Thunderbird puede realizar cambios en el mbox: nuevo correo, correo antiguo marcado como ya leído, etc. O, el caso límite, una compactación de la carpeta, que crea un fichero mbox nuevo.

      Es factible, pero no es trivial.

   7. Thunderbird impone un límite de 2 o 4 Gigabytes en los mbox. [1]

      [1]	Limits - Folder and messages.

Sin duda, algunos de los problemas que indico son debidos a mi forma de trabajar con el correo. Es cierto. Pero también lo es que esta forma de trabajar es el fruto de más de 20 años experiencia y al manejo de un volumen de correo brutal (más de 4.000 mensaje al día). Me resulta imprescindible automatizar al máximo y que mi software esté a la altura. Que yo me tenga que adaptar a las limitaciones de un programa no es aceptable. El software, la informática, debe adaptarse a mí.

Mozilla, los creadores de Thunderbird, son conscientes de estos y otros problemas, y han estado trabajando en un nuevo sistema de almacenamiento de mensajes basado en Maildir (pero no 100% compatible). Lamentablemente el desarrollo en esta área parece haberse detenido, sin fecha de entrega. De hecho Thunderbird ya no es un producto prioritario de Mozilla, así que no es inteligente esperar mejoras profundas (aunque siempre hay esperanzas :).

Se impone, pues, buscar alternativas.

Una opción relativamente simple es la siguiente: Thunderbird es un gestor de correo electrónico que permite el acceso a los buzones tanto por POP3 como por IMAP4. ¿Qué pasa si almacenamos nuestro correo electrónico en un servidor IMAP4 en nuestro propio ordenador, en vez de en el servidor?. IMAP4 nos independiza del sistema de almacenamiento de Thunderbird. Nos permite acceso concurrente, incluso de escritura. Y seguimos teniendo el correo electrónico en local.

Tras pensar mucho el tema (hay más factores importantes que no estoy reflejando en este artículo, pero que espero escribir en el futuro) y ver las opciones software disponibles, opté por Dovecot. Posiblemente el servidor IMAP4 Open Source más popular del mundo.

Dovecot soporta cuatro sistemas de almacenamiento de correo: mbox, Maildir y dos sistemas propietarios llamados sdbox y mdbox.

Sobre mbox ya hemos hablado.

Maildir es un formato interesante, pero en mi contexto tiene varios problemas:

1. Maildir almacena cada mensaje en un fichero separado. En mi caso eso supone un millón de ficheros, más o menos. Solo ver si ha habido cambios respecto al backup lleva tiempo y ancho de banda de disco.
2. Los atributos como "mensaje leído" o tags se almacenan en el propio nombre del fichero. Es decir, el nombre cambia. Para que el backup sea efectivo habría que seguir esos cambios también en el backup. Habría que desarrollar código para ello.
3. Copiar o mover un mensaje entre carpetas de correo supone mover el fichero físico, seguramente cambiándole el nombre en el proceso. Esto interfiere con el rendimiento de los backup. Habría que desarrollar código para seguir esos cambios y propagarlos al backup de forma eficiente.
4. Los ficheros mbox se comprimen muy bien porque son ficheros grandes que contienen varios mensajes, por ejemplo, de una misma lista de correo. Los mensajes tienen el mismo vocabulario, la misma temática y las cabeceras son muy parecidas. El sueño húmedo de un compresor de datos. En cambio con Maildir cada mensaje es un fichero separado y pequeño, por lo que esta redundancia no se ve y no se puede explotar.

Los formatos sdbox y mdbox separan los mensajes en sí de sus metadatos y de la carpeta en la que se encuentran. El backup no sufre por mover o etiquetar mensajes. Además, los documentos adjuntos a los mensajes se almacenan de forma separada, permitiendo deduplicación y reduciendo el coste de la compactación. También permiten "archivar" correo fuera del spool principal.

En sdbox cada mensaje se almacena en un fichero separado, como Maildir. En cambio mdbox almacena varios mensajes por fichero físico. Pero, comparado con mbox, en un mismo fichero se pueden almacenar mensajes de varias carpetas de correo y una misma carpeta de correo se almacenará en varios ficheros separados. Esto es bueno y malo a la vez, y estoy evaluando la conveniencia de escribir un nuevo backend para ocuparme de ello, ajustado a mis necesidades. Ya veremos.

En resumen, mi elección es mdbox.

Actualización 20140911: Puedes leer la segunda parte en Migrar Thunderbird de "mbox" a "IMAP" (II): Prueba de concepto.