Guardar el correo en su bucket de S3: qué llega ahí y cómo llega

Llega un mensaje para usted y, aproximadamente un segundo después, hay un objeto nuevo en un bucket de su propia cuenta de nube. Ese objeto es la parte interesante del correo de almacenamiento propio (bring your own storage): qué contiene, cómo se escribió y qué puede hacer con él que ningún proveedor de correo le dejaría hacer con sus discos.

¿Qué acaba realmente en su bucket?

Blobs cifrados, más el índice que los convierte en un buzón. Cada mensaje se comprime con zstd, se cifra con una clave por buzón usando age (el formato de cifrado de ficheros basado en X25519) y se escribe bajo un prefijo blobs/ con un nombre derivado de un hash de su contenido. Bytes idénticos reciben el mismo nombre. Nada en la clave del objeto le dice a quien la lea qué guarda: ni el asunto, ni el remitente, ni a qué dirección iba dirigido.

El índice es la parte que la gente olvida cuando imagina esto funcionando. Un buzón no es un montón de blobs: algo tiene que saber qué blob es qué mensaje, a qué conversación pertenece, cuáles están sin leer, cuáles llevan etiqueta. Esa estructura se escribe en el mismo almacenamiento y se cifra igual. Por eso “mi correo está en mi bucket” es una afirmación más fuerte de lo que suena al principio: el archivo no solo se puede recuperar, se describe a sí mismo ante cualquier cosa que tenga la clave.

Una pregunta que hay que hacerle a cualquier proveedor que ofrezca esto, antes de confiarle un dominio: ¿está documentado el formato en el almacenamiento? Unos bytes que solo se pueden leer con el software de un fabricante son una forma de propiedad más débil de lo que aparentan.

¿Cómo llega un mensaje desde el remitente hasta su almacenamiento?

Cinco pasos, y lo que importa es el orden de los dos últimos.

Nuestro host MX responde a la conexión SMTP y comprueba el mensaje: SPF, DKIM y DMARC del correo entrante, reputación del remitente y listas de bloqueo, y después análisis de spam y phishing. El filtrado tiene que leer texto en claro, así que todo eso ocurre aquí, antes de que nada se cifre en reposo. Un servicio que filtra su spam ha visto su correo; quien afirme las dos cosas describe algo que no puede funcionar.

Después la dirección del destinatario se resuelve a un buzón, el mensaje se comprime y se cifra con la clave de ese buzón, y el objeto se escribe en su almacenamiento: un PUT a S3 o a un endpoint compatible con S3, a R2, a un servidor WebDAV, o un commit a un repositorio Git.

Solo cuando la escritura ha tenido éxito responde el borde 250 OK. El borde receptor no tiene estado y no mantiene cola propia, lo cual suena a limitación y en realidad es la garantía de fiabilidad: no puede confirmar un mensaje que no ha guardado. Cuando su almacenamiento está caído, el mensaje sigue en la cola del servidor remitente, que es el sitio más duradero en el que podría estar.

¿Qué puede hacer con el bucket que un proveedor nunca le permitiría?

Todo lo que ofrezca la API de almacenamiento, porque el bucket es suyo y el servicio de correo es solo un cliente con una clave.

El versionado de objetos convierte “algo borró un año de correo” en una recuperación en lugar de un incidente. Las reglas de ciclo de vida recortan la factura de un archivo que nadie lee. La replicación entre regiones o un rclone sync nocturno colocan una segunda copia en un segundo operador y en un segundo país, con la misma periodicidad que todo lo demás que respalda. Object Lock satisface una obligación de retención de la que su proveedor de correo no ha oído hablar nunca. Los registros de acceso al bucket anotan cada lectura, incluidas las nuestras. El cifrado del lado del servidor con su propia clave de KMS envuelve nuestro texto cifrado en una segunda capa cuya clave puede revocar usted de forma unilateral.

Dos de esas cosas tienen aristas. Las transiciones a capas frías vuelven lenta la recuperación, así que apúntelas a una réplica y no a los blobs que su webmail está leyendo en ese momento. Y Object Lock en modo compliance significa que nadie borra un objeto antes de su fecha de retención, usted incluido, incluida la versión de usted que fijó mal el plazo. Ese modo es una decisión, no una casilla.

La otra libertad es la ubicación. Usted elige la región y, por separado, elige quién la opera. La región no es la jurisdicción: una región europea operada por una empresa constituida en EE. UU. sigue siendo alcanzable bajo la CLOUD Act, en vigor desde 2018. Elegir las dos cosas a conciencia es casi toda la razón por la que la gente quiere este arreglo.

El coste se comporta de forma distinta a lo que las páginas de precios le enseñan a esperar. El correo son miles de objetos pequeños, así que dominan los cargos por petición y la salida de datos, no la tarifa por gigabyte. R2 no factura salida en absoluto.

¿Qué se queda en el servicio de enrutado?

Las partes que tienen que vivir en el internet público y, por defecto, las claves.

Nosotros mantenemos los registros MX, el TLS del borde, la firma DKIM y la alineación DMARC de su correo saliente, el trabajo de reputación de IP, el análisis de spam y phishing, y el cliente de webmail. Sus credenciales del bucket quedan selladas en nuestra base de datos, porque la entrega las necesita.

La custodia de las claves es el asterisco honesto. En el nivel por defecto, con custodia en el servidor, tenemos las claves por buzón, que es lo que permite dibujar y buscar el buzón en un navegador; su proveedor de almacenamiento solo ve texto cifrado, pero nosotros podemos descifrar. El nivel de custodia en el dispositivo, en beta, genera las claves en su navegador y borra nuestra copia: desde ahí el servicio puede escribir en su almacenamiento y no puede leer lo que escribió. Los dos diseños son defendibles. Solo uno de ellos es “nadie más que yo”, y la diferencia merece conocerse antes de citarla en un documento de políticas.

¿Cómo falla esto?

De tres maneras, en el orden en que ocurren de verdad.

Credenciales. Rota una clave de acceso un martes y olvida que la ruta del correo consume ese bucket. La entrega empieza a fallar y, como el borde retiene el 250 OK, no se pierde nada de inmediato: obtiene un retraso y rebotes de aviso, no un agujero en su archivo. Rote como lo haría con cualquier otro cliente: añada la clave nueva al buzón primero, revoque la vieja después.

Políticas. Una política de bucket que resulta ser pública expone texto cifrado y no mensajes, que es la diferencia entre un bochorno y una catástrofe; pero el número de objetos, los tamaños y las marcas de tiempo siguen siendo un conjunto de datos para análisis de tráfico, y un buzón que usted puso deliberadamente en claro en reposo expone exactamente lo que cabe esperar. Una regla de ciclo de vida con acción de expiración borra correo según calendario y no pregunta dos veces. Una política de clave de KMS que se olvida de quien escribe detiene la entrega en seco.

Usted. La custodia transfiere responsabilidad junto con el poder. Borrar el bucket borra el correo, y no hay ticket de soporte que restaure una copia que nunca tuvimos. Eso no es una carencia del producto. Es lo que compró.

La prueba que yo aplicaría a cualquier proveedor que ofrezca esto: ¿puede revocarle las credenciales de almacenamiento en diez segundos, y su archivo sigue siendo legible después? Si la respuesta es sí, el correo es suyo. Si la respuesta pasa por una herramienta de exportación, lo que tiene es una cuenta.