Migrar Thunderbird de "mbox" a "IMAP" (VII): Filtrado en el servidor IMAP4 con Sieve y conversión de reglas Thunderbird

Jesús Cea Avión

2014-10-09 16:19

Como queda claro en mi artículo Migrar Thunderbird de "mbox" a "IMAP" (VI): Experiencia tras dos semanas, el siguiente paso es realizar el filtrado de correo en el propio servidor IMAP4, en vez de utilizar los propios filtros de correo de Thunderbird. Las ventajas son muchas:

Como se explica en el artículo anterior, Thunderbird se atasca más de lo razonable con muchas reglas de correo y muchos mensajes. En mi caso recibo del orden de 4.000 mensajes al día y tengo 1.800 reglas de correo. Reglas para clasificar el correo. Reglas para marcarlo con etiquetas. Reglas para darle prioridad, etc.
A medio plazo el plan es tener IMAP4 también en mi servidor de correo. Ejecutar las reglas de filtrado ahí con Sieve en vez de que el filtrado lo realice Thunderbird me permite tener el correo en el móvil de forma manejable, y no como lo tengo ahora (una cuenta separada con forwarding a la cuenta normal, porque no puedo permitirme recibir miles de mensajes en el móvil).

Además las acciones realizadas en el móvil como leer o responder un mensaje tendrían su reflejo en el portátil y viceversa.

No quiero hacer la migración de filtros Thunderbird a Sieve una vez y luego trabajar con Sieve para siempre. Me interesa seguir manejando mis filtros con Thunderbird, porque los actualizo y modifico con frecuencia. El procedimiento de conversión debe ser simple y ligero.

Y ahí empiezan mis problemas.

Migrar Thunderbird de "mbox" a "IMAP" (VI): Experiencia tras dos semanas

Jesús Cea Avión

2014-10-06 13:44

Para entender el contexto de este artículo es conveniente leer la serie entera:

Resumiendo el tema mucho, llevo dos semanas con la siguiente configuración:

Servidor IMAP4 Dovecot instalado en local, en mi propio portátil.
Alimento dicho servidor IMAP4 local usando Getmail. Mi servidor de correo sigue sirviendo POP3. Getmail descarga el correo por POP3 y lo deja en la carpeta de correo INBOX del IMAP4 de mi portátil. Getmail se ejecuta en un CRON cada minuto. La exclusión de instancias la realiza el propio servidor POP3.
Thunderbird está configurado para emplear dicho servidor IMAP4 local. El servicio POP3 no está accesible directamente, para evitar errores. Thunderbird revisa correo en el INBOX, aplica sus (!1800¡) reglas de filtrado y mueve los mensajes que han entrado a sus carpetas de correo correspondientes, los etiqueta apropiadamente, decide prioridades, etc.

Mis conclusiones tras este tiempo son las siguientes:

Migrar Thunderbird de "mbox" a "IMAP" (V): Alimentando el IMAP4 y reconfiguración de cuentas

Jesús Cea Avión

2014-09-21 02:55

Para entender el contexto de este artículo es conveniente leer la serie entera:

Para deshacernos de nuestra cuenta POP3 en el Thunderbird tenemos que encontrar otra forma de alimentar el IMAP4 local. La solución tradicional sería Fetchmail, pero es un programa complejo e inseguro. Yo voy a utilizar Getmail que, además, está programado en Python.

Migrar Thunderbird de "mbox" a "IMAP" (IV): Alimentando el IMAP4 y limpieza general

Jesús Cea Avión

2014-09-20 01:01

Hemos avanzado mucho tras el trabajo descrito en los artículos anteriores:

La situación ahora mismo es que tenemos dos árboles de carpetas de correo de unos mil elementos cada uno. Uno en la vieja estructura mbox de Thunderbird y otro en el IMAP4. Los árboles en sí son idénticos, y tenemos un procedimiento que mueve el correo de la estructura mbox de Thunderbird, alimentada por POP3, al servidor IMAP4 local.

A medida que van entrando mensajes nuevos por POP3, éstos se siguen guardando en el árbol de carpetas de correo mbox. El primer paso, por tanto, consiste en parar Thunderbird y modificar los filtros de correo para que el correo POP3 entrante ya no se guarde en el árbol mbox, sino en el IMAP4.

Con el Thunderbird parado buscamos el fichero msgFilterRules.dat. Estará en el disco duro, en el directorio raíz de nuestro árbol mbox. Se trata de un fichero de texto que podemos curiosear. Contiene las reglas de correo que se aplican a los mensajes que entran por POP3.

IMAP4 y la extensión MULTIAPPEND

Jesús Cea Avión

2014-09-17 22:29

El trabajo hecho en "fsync" y LD_PRELOAD nos aumenta el rendimiento de 4 a 22 mensajes por segundo. Es una mejora importante, aunque peligrosa y no apta para dejarla en producción. Pero como las extensiones Thunderbird que pretendíamos usar no funcionaban correctamente, incluso 22 mensajes por segundo es desesperante para moverlos a mano cuando necesitas mover un millón de mensajes. Doy detalles en Migrar Thunderbird de "mbox" a "IMAP" (III): ¡Migración!.

Uno de los grandes fastidios de Thunderbird es que Mozilla ya no lo considera un proyecto prioritario. Es un buen producto, pero languidece y no está adoptando extensiones IMAP4 modernas. Y algunas de ellas son muy importantes, como NOTIFY.

Thunderbird está enviando a Dovecot un mensaje y no hace nada hasta que Dovecot le da el OK. Esto es claramente poco óptimo. Al ocurrir escrituras síncronas en realidad la CPU está aburrida y podemos aumentar la velocidad considerablemente simplemente abriendo varias conexiones IMAP4 en paralelo a diferentes carpetas. Los experimentos en mi portátil, con dos cores, muestran que se puede duplicar el rendimiento trabajando simultaneamente con cuatro buzones a la vez, en paralelo.

Sería perfecto si IMAP4 tuviese una extensión que permitiese indicar que un mensaje determinado no es importante y que no importa si se pierde. Eso no existe :-). Pero sí existe una extensión interesante: MULTIAPPEND.

"fsync" y LD_PRELOAD

Jesús Cea Avión

2014-09-15 17:50

Como comento en Migrar Thunderbird de "mbox" a "IMAP" (III): ¡Migración!, estoy moviendo cuatro mensajes por segundo. No es mala velocidad en abstracto, pero sí lo es si pensamos que para mover un millón de mensajes necesito 70 horas ininterrumpidas.

Una vez que quedó claro que las extensiones de Thunderbird y el propio programa no estaban a la altura de las circunstancias, la migración manual copiando carpeta a carpeta empezó a ser una opción válida, si bien poco deseable. Tengo carpetas como Python-DEV con 80.000 mensajes. Mi propio Inbox tiene 42.000 mensajes. Carpetas de correo privado con 8.000 mensajes, etc. Copiar a mano es un coñazo y es fácil meter la pata. Y a 4 mensajes por segundo tambien es una tortura lenta y dolorosa.

¿Por qué 4 mensajes por segundo?. El correo electrónico es una aplicación atípica. Una de las máximas de todos los sistemas de correo electrónico serios es que un mensaje no debe perderse nunca. Si un sistema acepta un mensaje es responsable del mismo y no debe perderlo por causas pueriles como un disco duro lleno o que se vaya la luz en mal momento. Y ahí está el problema.

Mucha gente piensa que leer de un disco duro es rápido y escribir en él es lento. Al contrario, leer de un disco es lento porque mientras no tengamos la información el programa no puede continuar. En cambio cuando un programa escribe, sus escrituras se almacenan en la caché del sistema operativo y el programa continua inmediatamente, sin ninguna pausa. El sistema operativo acumula cambios en RAM y los vuelca todos a disco en una larga ráfaga en un momento futuro. Se trata de escrituras asíncronas.

Pero a veces necesitamos que un dato se grabe en el disco AHORA. Por ejemplo, cuando entra un mensaje de correo electrónico y debemos asegurarnos de que se ha grabado en disco duro de verdad antes de darle el OK al servidor que nos lo manda.

Todo esto lo explico muy bien en un artículo anterior: ZFS y SSD's. Lee ese artículo y luego continua aquí.

¿Ya?

¿De verdad?

Vale, seguimos.

Migrar Thunderbird de "mbox" a "IMAP" (III): ¡Migración!

Jesús Cea Avión

2014-09-13 15:28

Tras lo descrito en los artículos Migrar Thunderbird de "mbox" a "IMAP" (I): Consideraciones y Migrar Thunderbird de "mbox" a "IMAP" (II): Prueba de concepto tenemos la suficiente confianza en el sistema para decidirnos hacer la migración.

Lo primero que hay que decir es que en mis pruebas veo que, sin complicarme la vida, puedo mover al IMAP4 cuatro mensajes por segundo. Parece rápido, pero con un millón de mensajes necesitaré 70 horas ininterrumpidas. Es mucho tiempo, pero no es un problema siempre que pueda seguir usando el Thunderbird mientras tanto y siempre que pueda continuar la migración sin problemas en caso de fallo o de que apague el ordenador. Es decir, no importa el tiempo si puedo seguir trabajando con normalidad mientras tanto. Ese era el plan. ¡Qué equivocado estaba!.

Pero no adelantemos acontecimientos.

El primer paso de la migración consiste en replicar la estructura del árbol de carpetas de correo y mover todos los mensajes al servidor IMAP4. Debemos copiar la estructura y mover los datos, pero mantener la estructura original en su sitio. Con mil carpetas, esto no es trivial.

Mi primera idea fue escribirme un pequeño programa en Python que recorra las carpetas de correo mbox y transfiera su contenido a Dovecot a través de IMAP4. Este enfoque tiene varios inconvenientes:

Hay que escribirlo y depurarlo. Lleva tiempo y hay riesgo de perder correo.
Me interesa conservar todos los atributos de los mensajes: leído o no, respondido, se ha hecho forward, el mensaje tiene etiquetas, etc.

El formato interno de Thunderbird está aceptablemente documentado, pero la gestión de estos flags en IMAP4 complica bastante el código: al mover los mensajes hay que limpiar las cabeceras propietarias de Thunderbird y luego hay que poner los flags correspondientes en el IMAP4. El mapeo de un lado a otro no está documentado y habría que hacer experimentos. Bugs, tiempo, riesgo...
Los mensajes movidos al IMAP4 hay que borrarlos de las carpetas de correo origen. Thunderbird no tiene un API para que programas externos interactúen con sus carpetas de correo (este es otro motivo para migrar a IMAP4). Esto nos deja dos alternativas:
- El programa de migración debe funcionar con el Thunderbird cerrado. Cuando termina de mover una carpeta de correo a IMAP4 debe truncar el fichero mbox original o bien modificar las banderas de los mensajes para marcarlos como borrados.
  
  Cuando abrimos el Thunderbird detectará que sus ficheros de metadatos tienen una fecha anterior a la última modificación de las carpetas de correo y se reconstruirán con los mensajes borrados.
  
  Esto es simple pero requiere tener el Thunderbird cerrado mientras se hace la migración. Y la migración lleva días.
- Otra posibilidad es que el programa de migración vaya guardando, por ejemplo, el hash o el Message-ID de los mensajes que se han movido al IMAP4. Podemos ejecutar el programa de migración varias veces, y que ignore los mensajes que ya ha movido. Esto nos permite seguir trabajando con el Thunderbird, pero hay muchas complicaciones con mensajes que cambian: un mensaje que se marca como leído, otro que se mueve a otra carpeta de correo...
  
  Podemos ser disciplinados y no tocar en el Thunderbird las carpetas que estamos moviendo en este momento. Pero resulta complejo. Frágil.

En resumen: elaborar un programa propio para migrar es complicado y nos obliga a dejar de usar el Thunderbird mientras dura la migración, que puede llevar días. O bien debemos tener mucho cuidado coordinando nuestro uso de Thunderbird con el proceso de migración. Es fácil meter la pata.

¿Qué más opciones tenemos?.

Migrar Thunderbird de "mbox" a "IMAP" (II): Prueba de concepto

Jesús Cea Avión

2014-09-11 00:59

Tras valorar lo que describo en mi artículo Migrar Thunderbird de "mbox" a "IMAP" (I): Consideraciones decido montar una prueba de concepto. Algo de este estilo:

Instalo Dovecot en mi portátil y lo configuro para usar mdbox como tecnología de almacenamiento de correo.
Creo una nueva cuenta en Thunderbird y la configuro para usar IMAP4 en la máquina local (la IP 127.0.0.1).
Elijo algunas carpetas de correo de mi Thunderbird, con alta actividad, y las recreo (manteniendo la estructura del árbol) en la nueva cuenta IMAP4.
Muevo los mensajes contenidos en esas carpetas de correo al IMAP4 y actualizo las reglas de filtrado automático de Thunderbird para que deposite los nuevos mensajes que vayan entrando para ellas en la nueva localización.

A partir de ahora opero con Thunderbird con normalidad. Sigo recibiendo el correo por POP3 y las reglas automáticas mueven los mensajes relevantes al IMAP4 interno. Hago numerosas pruebas etiquetando mensajes, copiándolos entre carpetas, rendimiento, búsquedas en los mensajes, mensajes con adjuntos, etc., y todo parece funcionar con normalidad. Funcionan incluso, para mi sorpresa, las Saved Searches cubriendo simultaneamente carpetas de correo tradicionales y carpetas IMAP4.

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

Jesús Cea Avión

2014-09-10 16:30

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:

Yo tengo en torno a un millar de carpetas, entre correo normal y RSS. En este momento mis carpetas ocupan unos 20 gigabytes.
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.
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 :).

¿Cómo monto mis páginas web de viajes?

Jesús Cea Avión

2014-08-20 16:45

Algunos lectores me han preguntado cómo elaboro mis páginas de viajes, con sus tracks GPS y sus fotos geolocalizadas. Un ejemplo.

Lo primero que tengo que decir es que cuando viajo me llevo un data logger. Se trata de una pequeña unidad autónoma que va grabando mi posición todo el tiempo, cada par de segundos, y lo almacena en una memoria interna. Hoy en día eso se podría hacer con un teléfono, si no fuera por los problemas de la multitarea de iOS y, sobre todo, por el enorme consumo de batería que ello supone. Mi unidad autónoma tiene muy poca capacidad (2MB) pero la batería le dura 14 horas y puedo configurarlo de diferentes maneras.

Lo segundo que hay que decir es que mi iPhone está configurado para que incluya la posición GPS en las fotografías, lo que simplifica el problema bastante. Pero cuando viajo con más gente que desactiva esa funcionalidad por privacidad o consumo de batería o uso fotografías tomadas por cámaras tradicionales, tener datos GPS en paralelo resulta muy útil. Además te permite almacenar datos detallados de posición aunque no saques fotos constantemente.

Lo tercero es que mucha de la tecnología que uso es propia, fundamentalmente disponible a través de mi proyecto PyTrek. Parece un proyecto abandonado, pero no :-). El repositorio está vivo :-).