Adjuntos en correo desechable: tamaño máximo y seguridad

Qué llega como adjunto

Un mensaje es un árbol de partes, y solo algunas de ellas son archivos. La regla aquí es deliberadamente generosa, porque la alternativa —confiar en que el remitente etiquete las cosas correctamente— pierde en silencio adjuntos que un cliente de correo sí habría mostrado:

Cualquier cosa marcada como tal

Una parte cuyo Content-Disposition dice attachment. El caso habitual, y en el que coinciden todos los clientes de correo.

Cualquier cosa con un nombre de archivo

Una parte que lleva un filename, sea cual sea su otra etiqueta. Los remitentes etiquetan mal constantemente, y un archivo con nombre es un archivo.

Partes con nombre que no son texto

Una parte con un name cuyo tipo no es text/…. Es lo que atrapa el logotipo de una firma en HTML, así que un mensaje puede llegar con adjuntos que no esperabas y que el remitente nunca consideró adjuntos.

El número que ves es, por tanto, a menudo más alto que el que el remitente tenía en mente. Veinte es el máximo que conserva un solo mensaje; uno que trae más partes con nombre de archivo que eso conserva las primeras veinte y descarta el resto, algo que conviene saber antes de construir nada sobre ello.

Un nombre de archivo recibido por la red nunca se usa como ruta. El archivo se escribe con un nombre generado y el original se conserva junto a él como dato, de modo que un remitente no puede elegir dónde acaba su archivo poniéndole un nombre con una barra dentro.

El límite de tamaño, y dónde cae realmente

El número publicado es 5 MB, y merece la pena ser exactos sobre qué mide: el mensaje codificado completo. No el adjunto, ni la suma de los adjuntos, sino todo lo que entrega el servidor emisor, después de que la codificación MIME ya lo haya hecho más grande.

Base64 —la forma en que un binario cruza un protocolo pensado para texto— convierte cada tres bytes en cuatro. Añade los saltos de línea que necesita y un archivo llega cerca de un tercio más grande de lo que pesaba en el disco, un poco más si se cuentan esos saltos. Calculando hacia atrás desde 5 MB, eso sitúa el límite real en un archivo de unos 3,5 MB, y más bajo todavía para un mensaje con firma y una parte en HTML.

Qué se mide

Los encabezados, la parte en texto, la parte en HTML y todos los adjuntos, todo ello después de la codificación.

Adjuntos por mensaje

Veinte. En la práctica, el límite de tamaño llega antes.

Partes de texto

Se conservan hasta 2 MiB cada una después de decodificarlas. Un cuerpo más largo que eso se almacena truncado, algo a lo que ningún correo normal se acerca, aunque un informe generado automáticamente sí podría.

Qué pasa cuando un archivo es demasiado grande

Se rechaza en la puerta, durante la conversación SMTP, antes de que se almacene nada. Un servidor emisor que anuncia el tamaño por adelantado es rechazado de inmediato, y el intercambio termina más o menos así:

>>> MAIL FROM:<news@example.com> SIZE=7602176
<<< 552 5.3.4 Message size exceeds fixed limit

Eso importa más de lo que parece. Un servicio que aceptara el mensaje y lo descartara después dejaría al remitente creyendo que se había entregado, y a ti esperando algo que nunca iba a aparecer. Un rechazo en el momento SMTP es un fallo real comunicado a una persona real: el remitente recibe un rebote con el motivo dentro.

Un remitente que no anuncia el tamaño por adelantado recibe la misma respuesta, pero al final del mensaje, en cuanto el servidor de correo ha contado los bytes por su cuenta. En cualquier caso, nada llega al buzón y nada llega truncado.

Sacar un archivo del buzón

En el navegador está donde cabría esperar. Abre el mensaje y los adjuntos aparecen listados debajo, cada uno con el nombre que le dio el remitente y el tamaño que realmente llegó.

1. Abre el mensaje. La lista se actualiza sola, así que un archivo que llega mientras estás mirando el buzón aparece sin recargar.
2. Lee el nombre y el tamaño antes de hacer clic. Ambos son datos sobre lo que llegó, y son lo último que ves antes de que el archivo esté en tu equipo.
3. Haz clic en él. El archivo se descarga. Nunca se abre en el navegador, sea lo que sea que diga ser; la siguiente sección explica por qué eso es una ventaja y no una carencia.

Las imágenes remotas en el cuerpo del mensaje se bloquean hasta que las pides, y eso es distinto de un adjunto: una imagen bloqueada se descarga del propio servidor del remitente en el momento en que la permites, mientras que un adjunto llegó con el mensaje y no se descarga de nadie.

Descargar desde la API

Leer un mensaje devuelve sus adjuntos como una lista, y cada uno llega con la URL ya construida:

"attachments": [
  {
    "id":       "01JR8W2K4QATT1",
    "filename": "invoice.pdf",
    "mime":     "application/pdf",
    "size":     184320,
    "url":      "/api/v1/attachment/01JR8W2K4QATT1?mailbox=k7fq2m%40grabmail.io"
  }
]

Esa URL es un simple GET con el buzón como parámetro de consulta, y en los dominios públicos no necesita nada más: ni clave, ni sesión, ni cuenta:

curl -OJ "https://grabmail.io/api/v1/attachment/01JR8W2K4QATT1?mailbox=k7fq2m%40grabmail.io"

-OJ le dice a curl que guarde el archivo con el nombre que envía el servidor en vez de con el id. El endpoint responde una de tres cosas: el archivo, un 404 si no existe tal adjunto en ese buzón o ha caducado, o un 429 si preguntas más de una vez por segundo.

El id de un adjunto está ligado a su buzón, así que un id de una dirección es un 404 en otra. No hay ningún endpoint que liste adjuntos por sí solos: llegan con su mensaje y se leen a partir de él. La referencia de la API tiene la forma completa de la respuesta de un mensaje.

Por qué todo archivo se descarga como binario

Sea lo que sea que el remitente dijera que era su archivo, vuelve como application/octet-stream y se descarga en lugar de abrirse. Eso no es descuido con los tipos de contenido: es la única respuesta segura cuando el archivo viene de un desconocido.

El tipo del remitente nunca se repite de vuelta

Quien etiqueta su archivo como text/html y consigue que se renderice en nuestro origen está ejecutando su página como si fuéramos nosotros, en tu sesión, con todo lo que eso le permite alcanzar. Así que la etiqueta se descarta y quien lo pide decide qué es el archivo a partir de los metadatos que lo acompañan.

Siempre descarga, nunca vista

Content-Disposition: attachment en cada respuesta, así que nada se renderiza en el sitio, sea cual sea su etiqueta.

Sin detección automática, y nada puede ejecutarse

X-Content-Type-Options: nosniff impide que el navegador intente adivinar un tipo, y una Content-Security-Policy de default-src 'none'; sandbox significa que, aunque algo llegara a renderizarse, no podría cargar nada ni ejecutar nada.

El nombre de archivo no puede convertirse en cabecera

El nombre se codifica en lugar de pegarse directamente en la respuesta, así que un archivo con un salto de línea en su nombre no puede añadir una cabecera de su elección.

El archivo en sí no se toca: byte a byte, lo que envió el remitente. Lo que es deliberadamente aburrido es todo lo que lo rodea. También se almacena fuera de la raíz web, así que adivinar una ruta no sirve de nada: el buzón tiene que resolverse y autorizarse antes de que se lea el archivo.

Nada aquí analiza el archivo

No hay antivirus, ni detonación en sandbox, ni comprobación de reputación. Es un límite declarado, no un descuido, y cambia lo que puedes hacer con seguridad con lo que llega:

• Cualquiera puede enviar a una dirección pública. No necesita conocerte a ti, necesita conocer la dirección, y las cortas se adivinan. Un archivo en un buzón público tiene, por defecto, un autor desconocido.
• Los ejecutables y los scripts son aquí exactamente igual de peligrosos que en cualquier otro sitio. Nada se filtra por extensión, y nada mira dentro de un archivo comprimido para ver qué contiene.
• Los documentos capaces de ejecutar cosas son el caso habitual. Los archivos ofimáticos con macros y los PDF con acciones incrustadas son la vía más común, no los ejecutables evidentes.
• El nombre no te dice nada. Un archivo llamado invoice.pdf es lo que digan sus bytes que es, y la extensión la eligió quien lo envió.

Los archivos se van cuando se va el mensaje

Un adjunto no tiene vida propia. Pertenece a su mensaje, y se va cuando se va el mensaje:

Después de 5 días

Se elimina con el mensaje, leído o no, con un reloj que empezó a contar en el momento de la llegada. No hay archivo ni exportación.

Cuando eliminas el mensaje

De inmediato, y la URL pasa a ser un 404. Es la misma acción tanto si eliminas desde el buzón como desde la API.

No hay vuelta atrás

No hay forma de recuperarlo, ni periodo de gracia, ni un buzón de soporte al que preguntar. Todo lo que vayas a necesitar mañana hay que descargarlo hoy.

Cuando el correo no es la vía adecuada

Parte de lo que la gente intenta hacer aquí con los adjuntos no es un límite que sortear: es la herramienta equivocada para el trabajo:

• Un archivo por encima del límite. Nada lo sube. Envía un enlace en su lugar.
• Algo que vas a necesitar el mes que viene. 5 días es un límite estricto que aplica un proceso automático, no un ajuste. Descárgalo ahora, o usa un buzón real.
• Cualquier cosa que te importaría que leyera un desconocido. En un dominio público, la dirección es el único candado de la puerta, y es uno corto.

Un dominio propio cambia el tercero de esos casos y ninguno de los dos primeros: el límite y la retención son exactamente los mismos, pero la dirección vive en un nombre que no aparece en ninguna parte de este sitio, así que nadie le envía archivos por casualidad. Un registro MX basta:

Registro MX para tu dominio10 smtp.grabmail.ioCopiar

Aquí está la guía completa paso a paso — el registro, qué demuestra publicarlo, y los límites reales de un buzón sin contraseña.

Preguntas