Dirección de correo

El formato de correo electrónico Maildir es una forma común de almacenar mensajes de correo electrónico en un sistema de archivos , en lugar de en una base de datos. A cada mensaje se le asigna un archivo con un nombre único, y cada carpeta de correo es un directorio del sistema de archivos que contiene estos archivos. Maildir fue diseñado por Daniel J. Bernstein alrededor de 1995, con el objetivo principal de eliminar la necesidad de código de programa para gestionar el bloqueo y desbloqueo de archivos mediante el uso del sistema de archivos local. ^{[ 1 ]} El diseño de Maildir refleja el hecho de que las únicas operaciones válidas para un mensaje de correo electrónico son su creación, eliminación o el cambio de su estado.

Un directorio Maildir (a menudo llamado Maildir) suele tener tres subdirectorios llamados tmp, new, y cur. ^{[ 2 ]}

• Este tmpsubdirectorio almacena temporalmente los mensajes de correo electrónico que están en proceso de entrega. También puede almacenar otros tipos de archivos temporales.
• El newsubdirectorio almacena los mensajes que se han entregado, pero que aún no han sido vistos por ninguna aplicación de correo electrónico.
• El cursubdirectorio almacena los mensajes que ya han sido vistos por las aplicaciones de correo. ^{[ 3 ]}

Un agente de entrega de correo es un programa que entrega un mensaje de correo electrónico en un Maildir. El agente de entrega de correo crea un nuevo archivo con un nombre de archivo único en el tmpdirectorio. ^{[ 5 ] [ 6 ] [ 3 ]} En el momento de su invención, garantizar nombres de archivo únicos de manera eficiente era difícil. El algoritmo original de qmail ^{[ 1 ]} para nombres únicos era:

1. leer la hora actual de Unix
2. leer el identificador del proceso actual (PID)
3. leer el nombre de host actual
4. Concatena los tres valores anteriores en una cadena separada por el carácter de punto ; este es el nuevo nombre de archivo.
5. Si stat()informa que el nombre del archivo existe, espere dos segundos.
6. Vaya al paso anterior hasta que el nombre del archivo no exista.
7. crea un archivo con un nombre de archivo único y escribe el contenido del mensaje en el nuevo archivo.

En el año 2000, el autor de qmail recomendó en una especificación actualizada ^{[ 5 ]} agregar el valor de un contador por proceso al PID, cuyo valor debería incrementarse después de cada entrega. Se eliminó la recomendación de limitar la velocidad de "esperar dos segundos".

Para 2003, las recomendaciones se habían modificado aún más para exigir que, en lugar del PID y el contador, la parte central del nombre del archivo se creara "concatenando suficientes cadenas siguientes para garantizar la unicidad" incluso ante múltiples entregas simultáneas al mismo directorio de correo desde uno o más procesos: ^{[ 7 ]}

• # n , donde n es (en hexadecimal) la salida de la unix_sequencenumber()llamada al sistema del sistema operativo, que devuelve un número que aumenta en 1 cada vez que se llama, comenzando desde 0 después del reinicio.
• X n , donde n es (en hexadecimal) la salida de la llamada al sistema del sistema operativo unix_bootnumber(), que informa el número de veces que se ha iniciado el sistema. Junto con #, esto garantiza la unicidad; desafortunadamente, la mayoría de los sistemas operativos no admiten unix_sequencenumber()y unix_bootnumber().
• R n , donde n es (en hexadecimal) la salida de la unix_cryptorandomnumber()llamada al sistema del sistema operativo o una fuente equivalente, como /dev/urandom. Desafortunadamente, algunos sistemas operativos no incluyen generadores criptográficos de números aleatorios.
• En n , donde n es (en hexadecimal) el número de inodo UNIX de este archivo. Desafortunadamente, los números de inodo no siempre están disponibles a través de NFS .
• V n , donde n es (en hexadecimal) el número de dispositivo UNIX de este archivo. Desafortunadamente, los números de dispositivo no siempre están disponibles a través de NFS. (Los números de dispositivo tampoco son útiles con el sistema de archivos UNIX estándar: un directorio de correo debe estar dentro de un único dispositivo UNIX para link()que rename()funcione).
• M n , donde n es (en decimal) el contador de microsegundos del mismo gettimeofday()utilizado para la parte izquierda del nombre único.
• P n , donde n es (en decimal) el ID del proceso.
• Q n , donde n es (en decimal) el número de entregas realizadas por este proceso.

Este algoritmo de 2003 fue criticado ^{[ 8 ]} en 2006 por ser innecesariamente complejo por Timo Sirainen , el creador de Dovecot .

Hasta noviembre de 2023, el autor de qmail, Daniel Bernstein, no había realizado más cambios a las recomendaciones de generación de nombres de archivo de 2003. ^{[ 9 ]} En los sistemas POSIX modernos, los archivos temporales se pueden crear de forma segura con la mkstempfunción de la biblioteca C.

El proceso de entrega almacena el mensaje en el maildir creando y escribiendo en , y luego moviendo este archivo a . El movimiento se puede hacer usando , que es atómico en muchos sistemas. ^{[ 10 ]} Alternativamente, se puede hacer creando un enlace duro del archivo a y luego desvinculando el archivo de . Cualquier archivo restante se eliminará eventualmente. Esta secuencia garantiza que un programa que lea el maildir no verá un mensaje escrito parcialmente. Puede haber varios programas leyendo un maildir al mismo tiempo. Estos van desde agentes de usuario de correo (MUA), que acceden al sistema de archivos del servidor directamente, a través de servidores de Protocolo de acceso a mensajes de Internet o Protocolo de oficina de correos que actúan en nombre de MUA remotos, hasta utilidades como biff y rsync , que pueden o no conocer la estructura del maildir. Los lectores nunca deben mirar en .tmp/uniquefilenamenew/uniquefilenamerenamenewtmptmp

Cuando un proceso de lectura de maildir consciente (ya sea un servidor POP o IMAPnew , o un agente de usuario de correo que actúa localmente) encuentra mensajes en el directorio, debe moverlos a cur. Es solo un medio para notificar al usuario "tiene X mensajes nuevos". ^{[ 11 ]} Este movimiento debe hacerse utilizando el sistema de archivos atómico rename(), ya que la técnica alternativa de vincular y luego desvincular no es atómica y puede resultar en mensajes duplicados. Se agrega un sufijo informativo a los nombres de archivo en esta etapa. Consiste en dos puntos (para separar la parte única del nombre de archivo de la información real), un "2", una coma y varias banderas . El "2" especifica la versión de la información que sigue a la coma. "2" es la única versión especificada oficialmente en la actualidad, siendo "1" una versión experimental. La especificación define indicadores que muestran si el mensaje ha sido leído, eliminado, etc.: la letra inicial (mayúscula) de "Passed", "Replied", "Seen", "Trashed", "Draft" y "Flagged". ^{[ 7 ]} Las aplicaciones a menudo optan por complementar este conjunto muy limitado de indicadores, por ejemplo, notmuch ^{[ 12 ]} ofrece sincronización de indicadores además de indicadores arbitrarios definidos por el usuario, ^{[ 13 ]} mientras que Dovecot utiliza letras minúsculas para coincidir con 26 palabras clave IMAP, ^{[ 6 ]} que pueden incluir palabras clave como $ MDNSent o indicadores definidos por el usuario.

Aunque Maildir fue diseñado para permitir el uso sin bloqueo, en la práctica algunos programas que utilizan Maildir también utilizan bloqueos, como Dovecot. ^{[ 14 ]}

El estándar Maildir solo se puede implementar en sistemas que aceptan dos puntos en los nombres de archivo. ^{[ 15 ]}

Los sistemas que no permiten dos puntos en los nombres de archivo (esto incluye Microsoft Windows y algunas configuraciones de Novell Storage Services ) pueden usar un separador alternativo no estándar, como ";" o "-". A menudo es sencillo modificar el software libre y de código abierto para que utilice un separador diferente. ^{[ 16 ]}

Dado que actualmente no existe un consenso sobre qué carácter debería tener este separador alternativo, pueden surgir dificultades de interoperabilidad entre los distintos programas compatibles con Maildir en estos sistemas. Sin embargo, no todo el software relacionado con Maildir necesita conocer el carácter separador, ya que no todo el software relacionado con Maildir necesita poder leer o modificar los indicadores de un mensaje ("leído", "respondido", etc.); el software que simplemente entrega mensajes a Maildir o archiva mensajes antiguos basándose únicamente en la fecha, debería funcionar independientemente del separador utilizado. Si solo el cliente de correo (MUA) necesita leer o modificar los indicadores de los mensajes, y solo se utiliza un MUA, entonces se pueden usar separadores alternativos no estándar sin problemas de interoperabilidad.

• mbox
• Sistema de gestión de mensajes MH
• MEZCLA (correo electrónico)

• Página del manual para Maildir
• Especificaciones de Maildir