← Todas las funciones

Importación y exportación de correo

Por Lucas Flores, IT Systeme Flores UG. Última actualización: 2026-10-29

Restow lee archivos de correo, por ejemplo los restos de un buzón que ya no existe pero que hay que conservar, y los convierte en un buzón heredado que usted puede explorar y restaurar. Además, vuelve a sacar el correo como archivos: desde copias de seguridad, desde buzones importados y desde el archivo. Está disponible en todas las ediciones, desde la 0.1.0, e indica lo que no puede hacer junto a lo que sí puede. La misma página trata el archivo en el que puede acabar el correo importado, si usted lo decide, las vías por las que el correo llega a él desde los propios buzones (Business y Service Provider, desde la 0.4.4) y la capa que se apoya en él y está diseñada para un uso conforme a GoBD.

Qué se puede importar

• EML: archivos sueltos, carpetas o un ZIP.
• MSG (Outlook): archivos sueltos, carpetas o un ZIP. Solo mensajes de correo; los eventos, contactos y tareas guardados como MSG se notifican como "no es correo" y no se importan.
• MBOX: Thunderbird (incluidas sus carpetas .sbd), Apple Mail, exportaciones de Dovecot y Postfix, y Google Takeout.
• ZIP: la estructura de carpetas dentro del archivo pasa a ser la estructura de carpetas del buzón, con EML, MSG y MBOX en su interior.
• MailStore: una exportación como árbol de carpetas EML o MSG, o un ZIP con él. El formato de archivo interno de MailStore no se puede leer; en MailStore, exporte el correo al sistema de archivos como EML o MSG.

Cómo entran los archivos

Puede cargar archivos en el navegador. La carga se hace por fragmentos y se puede reanudar, hasta 10 GiB por archivo por defecto, y cada fragmento lleva una suma de comprobación SHA-256. Cada fragmento se sella con la clave del inquilino en cuanto llega, desde el primer byte, y se guarda en su destino de almacenamiento, de modo que no se escribe ninguna copia en texto claro del archivo en un disco. El tipo de archivo se reconoce por su contenido, nunca por la extensión.

La alternativa es una carpeta de importación en el servidor, montada en solo lectura, con una subcarpeta por inquilino. El administrador deja allí archivos o árboles de carpetas enteros, por ejemplo una exportación de MailStore, y los selecciona en la interfaz. Restow nunca escribe en esa carpeta ni la vacía, y comprueba que cada ruta permanezca dentro de la subcarpeta del propio inquilino.

Qué obtiene

Una importación crea una fuente propia (Imported mail files) con un buzón heredado que conserva la estructura de carpetas. Aparece en el explorador de restauración como cualquier otro buzón, marcado como importado. Puede explorarlo, buscar en él, ver e imprimir mensajes, descargarlos y restaurarlos en una cuenta IMAP existente o en un buzón de Microsoft 365 (en una carpeta de restauración nueva; los elementos existentes nunca se sustituyen). No existe "restaurar en el original", porque no hay original. Cada importación añade una instantánea nueva que contiene todo lo anterior más el correo nuevo, de modo que se puede construir un buzón heredado a partir de varios archivos, uno tras otro.

• EML y MBOX se guardan byte a byte. Un archivo MSG no contiene un correo ya hecho, así que Restow reconstruye un EML a partir de las propiedades guardadas (cabeceras, si Outlook las guardó, texto, HTML, adjuntos y mensajes incrustados). El informe cuenta esos mensajes como reconstruidos a partir de MSG.
• Un mensaje con el mismo Message-ID y el mismo SHA-256 en la misma carpeta es un duplicado: no se vuelve a guardar, pero se cuenta y se enumera. Importar dos veces el mismo archivo da como resultado "nada nuevo" y ninguna instantánea.
• Cada elemento ilegible o dañado figura con su motivo en el informe de importación, y lo inofensivo, como los archivos vacíos, figura como omitido. Nada desaparece en silencio.
• Si el proceso de importación se reinicia, continúa donde se quedó y nunca lee un mensaje dos veces.

Opcionalmente puede incorporar el correo importado al archivo (la opción de archivar a la vez, disponible en todas las ediciones): cada mensaje nuevo pasa a ser un objeto de archivo con sus bytes originales, cadena de hashes, los ajustes de retención del archivo y búsqueda por asunto, direcciones y texto del mensaje (el contenido de los adjuntos no se busca). El plazo de retención empieza en la fecha de importación, no en la fecha del mensaje, y el archivo es de solo anexado y con detección de manipulaciones (cadena de hashes) desde la incorporación. Qué impide un cambio es una cuestión del repositorio: véase «Inmutabilidad y el archivo» más abajo.

El archivo

El archivo es un almacén de solo anexado para correo, con una cadena de hashes SHA-256, en todas las ediciones. El correo entra mediante la importación de correo con archivado, como se describe arriba, y, en Business y Service Provider, desde los propios buzones (véase «Cómo entra el correo en el archivo» más abajo). El archivo se activa por trabajo de correo. La búsqueda abarca asunto, direcciones y el texto del mensaje (no los adjuntos), pagina sus resultados y filtra por remitente, fecha y buzón. Cada resultado nombra la vía que capturó el correo, y un correo que capturaron varias vías las muestra todas.

• La verificación de la cadena comprueba cada eslabón de la cadena de hashes, los anclajes diarios (escritos cada noche) y, si usted quiere, una muestra del contenido de los mensajes.
• Los mensajes archivados se pueden leer en Restow y descargar como .eml.
• Un aviso explica cómo protege el almacenamiento el correo archivado.
• El archivo se puede exportar como un buzón, véase más abajo. La exportación de una búsqueda deja fuera las capturas que sustituyó una vía más fuerte, igual que la propia búsqueda.

Cómo entra el correo en el archivo

Desde la 0.4.4 el archivo tiene más vías de entrada que el journaling. El editor de trabajos de correo pregunta «Cómo llega el correo al archivo» (en la interfaz en inglés, «How mail reaches the archive») y ofrece, para cada tipo de buzón del trabajo, solo las vías que le corresponden (Microsoft 365, IMAP, Google Workspace por IMAP; para las cuentas IMAP en un host de Microsoft sugiere conectar en su lugar una fuente de Microsoft 365). Cada vía se marca como «En el transporte» («At transport») o «Cercana al momento» («Near-time»), se exige al menos una por tipo y las vías se pueden combinar. Los valores por defecto de un trabajo nuevo son Graph para Microsoft 365 y la sincronización IMAP para IMAP y Google Workspace. Todo esto forma parte de Business y Service Provider; la compilación Community deja inactiva la captura.

• Microsoft Graph (Microsoft 365, cercana al momento). Restow se suscribe a las notificaciones de cambios de Graph de cada buzón archivado y obtiene cada correo nuevo en pocos minutos tras la entrega. No necesita ningún permiso nuevo de Microsoft, ni el puerto 25, ni una regla de journaling. Graph avisa a Restow de un correo nuevo solo si la URL pública de la instalación es https en el puerto 443 y Microsoft puede alcanzarla; si no, Restow consulta cada buzón, por defecto cada 15 minutos, y la página del archivo dice por qué.
• Journaling de Exchange (Microsoft 365, en el transporte). Exchange Online envía un informe de journaling de cada correo mientras está en transporte, así que la copia existe antes de que ningún usuario pueda tocar el correo, incluidos los destinatarios en copia oculta y el correo que se elimina de inmediato. Sigue siendo la prueba más fuerte. Necesita el receptor de journaling con un certificado TLS propio y el puerto 25. La página del archivo genera ahora los comandos de PowerShell de Exchange Online (conector, buzón para informes de journaling no entregables, regla de journaling) para copiarlos y espera el primer informe.
• Sincronización IMAP con IDLE (IMAP y Google Workspace, cercana al momento). Restow mantiene la cuenta sincronizada y archiva cada correo nuevo en cuanto está en el buzón: con IMAP IDLE donde el servidor lo ofrece (una conexión abierta por cuenta), y si no, comprobando a intervalos, a lo que también se puede ajustar una fuente para proveedores con un límite de conexiones ajustado. Se leen todas las carpetas salvo Borradores; en Gmail y Google Workspace solo Todos los mensajes, Spam y Papelera, que contienen cada correo una sola vez. Desde la 0.4.7, un mensaje que el servidor rechaza o no entrega ya no retiene su carpeta ni toda la pasada (la captura lo abandona tras tres pasadas y solo lo nombra en el registro del worker), las carpetas que una pasada no alcanzó conservan su estado, y una vigilancia que el servidor rechaza con un NO en EXAMINE o en IDLE se reintenta al cabo de minutos, en lugar de tomar el servidor por uno sin IDLE durante un día.
• Copias reenviadas (IMAP y Google Workspace, en el transporte). El proveedor de correo envía a Restow una copia de cada correo entrante y saliente mientras el correo está en su transporte: una regla BCC en Postfix o mailcow, una regla de Sieve o la regla de enrutamiento «Añadir más destinatarios» de Google Workspace. Cada cuenta IMAP puede tener una dirección de archivo propia, de modo que la copia se asigna exactamente a esa cuenta; una copia enviada a la dirección de journaling del inquilino se asigna por sus cabeceras. La página del archivo muestra cómo configurar la regla y si llegan copias. Una copia así no tiene sobre de journaling: los destinatarios en copia oculta solo aparecen si el proveedor los escribe en una cabecera, y una copia de Sieve cubre solo el correo entrante.
• Importación de correo con archivado (todas las ediciones, a posteriori). Como se describe arriba; el plazo de retención empieza en la fecha de importación.

Graph, la sincronización IMAP y las copias reenviadas asumen, cada una una sola vez y por pasos reanudables, el correo que ya está en el buzón y lo marcan como «capturado después» («Captured afterwards»). El correo que llega al archivo por más de una vía se reconoce por su Message-ID y su contenido y se conserva una sola vez: una captura que no es más fuerte que lo que el archivo ya tiene pasa a ser una anotación de captura de ese elemento, y una más fuerte (por ejemplo una copia reenviada tras una sincronización IMAP) pasa a ser el elemento y nombra la captura anterior a la que sustituye, que queda sin cambios en la cadena. Los informes de journaling y los mensajes importados siguen siendo elementos propios. Si llega el mismo Message-ID con otro cuerpo, se conservan ambos y se marcan.

La página del archivo muestra el estado de la captura (flujos, cómo se detecta el correo, recuentos de 24 horas y 7 días, la asunción del correo existente), la captura por buzón con una puesta al día a petición, las direcciones de reenvío y los comandos del journaling de Exchange, y las alertas avisan cuando una captura se detiene: un buzón en error más de una hora, copias reenviadas que llevan 24 horas sin llegar o una dirección de journaling sin informes desde hace 24 horas.

Desde la 0.4.7 el trabajo recomendado incluye el archivo. Mientras la instalación ofrezca la captura desde el buzón (Business y Service Provider) y el inquilino tenga buzones o cuentas que un archivo pueda capturar, «Crear el trabajo recomendado» (Create recommended job) y «Proteger todo lo que no tiene trabajo» (Protect everything without a job) hacen que el nuevo trabajo de correo sobre todos los objetos copie y archive. Un trabajo de correo sobre todos los objetos que ya existe y todavía no archiva se cambia a archivar en su lugar («Activar el archivado en ...», Switch archiving on in ...): sus programaciones se conservan, el cambio queda auditado como una edición en el editor de trabajos y solo ocurre cuando un administrador aplica la recomendación. El clic usa las vías de captura por defecto que no necesitan nada más en el inquilino, Microsoft Graph para los buzones de Microsoft 365 y la sincronización IMAP para las demás cuentas; el journaling y el reenvío siguen siendo una elección en el editor. Un trabajo de correo sobre objetos seleccionados nunca se cambia, y un trabajo sobre todos los objetos cuyas vías de captura se eligieron a mano se deja como está. La lista de trabajos de correo muestra «Activar el archivado» (Switch archiving on) donde la recomendación lo activaría. Sin la captura, el trabajo recomendado se crea como antes.

Lo que la captura cercana al momento no promete

• Graph y la sincronización IMAP toman el correo del buzón poco después de la entrega, no durante el transporte. Un correo que se mueve o se elimina en ese intervalo puede perderse. En Microsoft 365, una directiva de retención o una retención por litigio (Litigation Hold) que conserve el correo eliminado cierra el intervalo para el correo eliminado. Restow no puede ver esas retenciones (Graph no ofrece forma de leerlas), así que un administrador confirma la retención por fuente, y la página del archivo muestra los comandos de solo lectura de PowerShell de Exchange Online que la comprueban. IMAP no tiene nada comparable.
• De los elementos recuperables solo se lee la carpeta de eliminaciones, así que el correo purgado antes de que Restow lo obtuviera puede faltar. Graph no puede exportar correo de más de unos 150 MB; ese correo se registra, no se archiva. Restow ve a los destinatarios en copia oculta solo en el remitente, y se pierde el correo que una aplicación envía sin copia en Elementos enviados.
• El journaling y las copias reenviadas muestran un correo tal como pasó por el servidor; la captura cercana al momento lo muestra tal como estaba en el buzón poco después. Restow marca cada captura y no afirma que las vías cercanas al momento sean completas.
• Probado contra una API de Microsoft Graph simulada, un servidor IMAP simulado, el Dovecot de la prueba de humo de la versión y el propio receptor, nunca contra un inquilino real de Microsoft 365 o Google Workspace, ni contra Postfix, mailcow o un proveedor de alojamiento reales. El receptor no comprueba el remitente (SPF). Las fuentes IMAP con OAuth2 todavía no se pueden crear, así que una cuenta de Google Workspace se reconoce por su host o su lista de carpetas.
• Los trabajos de correo que ya archivaban antes de la 0.4.4 conservan exactamente lo que hacían: solo journaling para Microsoft 365 y todavía ninguna vía para las cuentas IMAP y de Google Workspace, así que no arranca nada nuevo por sí solo. Un administrador activa Graph o el archivado IMAP en el trabajo.

Inmutabilidad y el archivo

La cadena de hashes hace visible un cambio; no lo impide. Lo que lo impide es el almacenamiento, y eso es un ajuste del repositorio. Los registros de los elementos del archivo conservan su propia retención, como antes. El contenido de los mensajes se guarda en el mismo almacén de fragmentos que las copias, así que desde la 0.4.0 el ajuste de inmutabilidad de un repositorio en S3 con Object Lock (modo compliance o governance, 1 a 3650 días) bloquea también los paquetes que lo guardan. Un repositorio local o NFS recibe solo un retraso de borrado que Restow impone por sí mismo: quien tenga acceso al servidor o al recurso puede borrar los archivos igualmente, y la interfaz lo rotula «Retraso de borrado (no inmutable)». El repositorio predeterminado de la instalación no se puede hacer inmutable; dé al inquilino un repositorio propio. Los detalles, lo que no se bloquea y contra qué no protege están en la página de almacenamiento. Se probó con un S3 simulado, todavía no con un servicio S3 real con Object Lock.

La capa GoBD, desde Business

Business y Service Provider añaden sobre el archivo una capa diseñada para un uso conforme a GoBD:

• Captura desde los buzones por Graph y sincronización IMAP, y captura en el transporte mediante la recepción de informes de journaling de Exchange Online por SMTP y de copias que reenvía un proveedor de correo (el receptor necesita un certificado TLS propio). Cada informe de journaling se asigna a los buzones que nombra.
• Políticas de retención con una ejecución de eliminación obligatoria.
• Retención legal (legal hold) por inquilino o por buzón. Una retención se libera con un motivo obligatorio, y la liberación queda auditada.

Rigen los mismos límites de arriba: lo que impide un cambio es el repositorio, no la capa. Para el contexto, véase, en inglés, GoBD and e-mail archiving.

Exportación

Puede exportar buzones o carpetas de copias de seguridad (buzones de Microsoft 365 y cuentas IMAP), buzones importados y el archivo, en uno de dos formatos:

• EML en un archivo ZIP: un .eml por mensaje con la estructura de carpetas, más MANIFEST.csv y SHA256SUMS (verificable con sha256sum -c). Los bytes son los originales guardados.
• MBOX: una sola carpeta pasa a ser un archivo .mbox; varias carpetas pasan a ser un ZIP con un .mbox por carpeta, más manifiesto y sumas de comprobación.

El archivo de exportación se escribe cifrado en su destino de almacenamiento, y mientras se escribe se comprueba el SHA-256 de cada mensaje frente al manifiesto, de modo que un fragmento dañado detiene la exportación en lugar de entregar un archivo defectuoso sin aviso. El enlace de descarga es válido durante 24 horas. La solicitud y cada descarga quedan en el registro de auditoría, y las exportaciones de datos de otras personas llevan un motivo indicado. Solo se exporta correo: los eventos de calendario y los contactos se cuentan en el informe, no se exportan.

Límites indicados, no ocultos

• Los archivos PST y OST se reconocen y se rechazan con una explicación. La importación de PST, la exportación de PST y la exportación de MSG están previstas, véase la hoja de ruta. EML en un ZIP contiene los mismos mensajes en su forma original.
• Los eventos de calendario y los contactos de los archivos MSG no se importan, y el formato de archivo interno de MailStore no se puede leer.
• De MSG, un cuerpo que solo existe como RTF no se decodifica (Restow usa el cuerpo de texto), y los adjuntos que solo apuntan a un archivo se descartan. Otros tipos de archivo comprimido (gz, 7z, rar, tar) y los archivos .emlx de Apple se reconocen y se notifican como no admitidos, y los ZIP protegidos con contraseña o anidados se notifican y no se abren.
• Los archivos de correo se leen en procesos auxiliares propios con límites de memoria y de tiempo, nunca dentro del propio proceso del servidor. Un mensaje que no se puede leer dentro de esos límites se notifica como ilegible (o se importa byte a byte sin asunto, remitente ni texto) y la importación continúa. Por defecto, las cargas pendientes de importar pueden ocupar hasta 100 GiB por inquilino y los archivos de exportación no caducados hasta 50 GiB por inquilino; ambos límites se pueden cambiar.
• Un buzón importado todavía no se puede eliminar, ni tampoco la fuente de importación mientras conserve instantáneas, objetos de archivo o retenciones legales (legal hold).
• El plazo de retención del archivo para el correo incorporado empieza en la fecha de importación.

Documentación

La guía del administrador (en inglés) describe los pasos en importación y exportación de correo. El correo restaurado desde un buzón importado sigue las reglas de la página de restauración.

Preguntas frecuentes

Vea cómo funciona la restauración →

Más en Aprender: el glosario de copias de seguridad (archivo, cadena de hashes, journaling, retención legal) →

Más en Aprender: copia de seguridad y archivo, y por qué uno no sustituye al otro →