Pièces jointes sur adresse jetable : limites et sécurité

Ce qui arrive comme pièce jointe

Un message est un arbre de parties, et seules certaines d’entre elles sont des fichiers. La règle ici est volontairement généreuse, car l’alternative — faire confiance à l’expéditeur pour bien étiqueter ses parties — perd silencieusement des pièces jointes qu’un client de messagerie aurait pourtant affichées :

Tout ce qui est marqué comme telle

Une partie dont le Content-Disposition indique attachment. Le cas ordinaire, celui sur lequel tous les clients de messagerie s’accordent.

Tout ce qui porte un nom de fichier

Une partie portant un filename, quelle que soit par ailleurs son étiquette. Les expéditeurs se trompent d’étiquette en permanence, et un fichier qui porte un nom est un fichier.

Les parties nommées qui ne sont pas du texte

Une partie portant un name dont le type n’est pas text/…. C’est ce qui capture le logo d’une signature HTML — un message peut donc arriver avec des pièces jointes auxquelles vous ne vous attendiez pas, et que l’expéditeur lui-même n’a jamais considérées comme telles.

Le nombre que vous voyez est donc souvent plus élevé que celui auquel pensait l’expéditeur. Vingt est le maximum que garde un même message ; un message qui porte plus de parties nommées que cela ne conserve que les vingt premières et abandonne le reste, ce qui vaut la peine d’être su avant de construire quoi que ce soit là-dessus.

Un nom de fichier reçu sur le fil n’est jamais utilisé comme chemin. Le fichier est écrit sous un nom généré, et le nom d’origine est conservé à côté comme simple donnée — un expéditeur ne peut donc pas choisir où atterrit son fichier en y glissant une barre oblique.

Le plafond de taille, et où il tombe réellement

Le chiffre annoncé est 5 MB, et il vaut la peine d’être précis sur ce qu’il mesure : le message encodé dans son intégralité. Pas la pièce jointe, pas la somme des pièces jointes — tout ce que le serveur expéditeur transmet, une fois que l’encodage MIME l’a déjà fait grossir.

Le Base64 — la façon dont un binaire traverse un protocole conçu pour du texte — transforme chaque groupe de trois octets en quatre. Ajoutez les sauts de ligne qu’il exige, et un fichier arrive environ un tiers plus lourd qu’il ne l’était sur le disque, un peu plus une fois ceux-ci comptés. En partant de 5 MB et en remontant, cela place la limite réelle autour de 3,5 Mo pour un fichier — moins encore pour un message avec une signature et une partie HTML.

Ce qui est mesuré

Les en-têtes, la partie texte, la partie HTML et chaque pièce jointe, le tout après encodage.

Pièces jointes par message

Vingt. En pratique, c’est le plafond de taille qui arrive en premier.

Parties texte

Conservées jusqu’à 2 Mio chacune après décodage. Un corps plus long que cela est stocké tronqué — ce dont aucun message ordinaire n’approche, même si un rapport généré automatiquement le pourrait.

Ce qui se passe quand un fichier est trop volumineux

Il est refusé à la porte, pendant la conversation SMTP, avant que quoi que ce soit ne soit stocké. Un serveur expéditeur qui annonce la taille à l’avance est repoussé immédiatement, et l’échange se termine à peu près ainsi :

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

Cela compte plus qu’il n’y paraît. Un service qui accepterait le message pour l’abandonner ensuite laisserait l’expéditeur croire qu’il a été livré, et vous à attendre quelque chose qui n’allait jamais arriver. Un refus au moment du SMTP est un véritable échec signalé à une véritable personne : l’expéditeur reçoit un message de rejet qui en indique la raison.

Un expéditeur qui n’annonce pas la taille à l’avance reçoit la même réponse, mais à la fin du message, une fois que le serveur de messagerie a compté les octets lui-même. Dans les deux cas, rien n’atterrit dans la boîte et rien n’arrive tronqué.

Récupérer un fichier depuis la boîte

Dans le navigateur, c’est là où on l’attend. Ouvrez le message, et les pièces jointes sont listées en dessous, chacune avec le nom donné par l’expéditeur et la taille réellement arrivée.

1. Ouvrez le message. La liste se rafraîchit toute seule, donc un fichier qui arrive pendant que vous regardez la boîte apparaît sans recharger la page.
2. Lisez le nom et la taille avant de cliquer. Ce sont deux faits sur ce qui est arrivé, et c’est la dernière chose que vous voyez avant que le fichier ne soit sur votre machine.
3. Cliquez dessus. Le fichier se télécharge. Il ne s’ouvre jamais dans le navigateur, quoi qu’il prétende être — la section suivante explique pourquoi c’est une garantie plutôt qu’un manque.

Les images distantes dans le corps du message sont bloquées tant que vous ne les autorisez pas, et c’est différent d’une pièce jointe : une image bloquée est récupérée depuis le serveur de l’expéditeur au moment où vous l’autorisez, alors qu’une pièce jointe est arrivée avec le message et n’est récupérée nulle part.

Télécharger depuis l’API

Lire un message renvoie ses pièces jointes sous forme de liste, chacune avec son URL déjà construite :

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

Cette URL est un simple GET avec la boîte comme paramètre de requête, et sur les domaines publics elle ne demande rien d’autre — ni clé, ni session, ni compte :

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

-OJ indique à curl d’enregistrer le fichier sous le nom envoyé par le serveur plutôt que sous l’identifiant. L’endpoint répond l’une de ces trois choses : le fichier, un 404 si aucune pièce jointe de ce nom n’existe dans cette boîte ou qu’elle a expiré, ou un 429 si vous demandez plus d’une fois par seconde.

L’identifiant d’une pièce jointe est propre à sa boîte, donc l’identifiant d’une adresse renvoie un 404 chez une autre. Il n’existe aucun endpoint qui liste les pièces jointes à part : elles arrivent avec leur message et se lisent à partir de lui. La référence de l’API détaille la forme complète d’une réponse de message.

Pourquoi chaque fichier se télécharge comme un binaire

Quel que soit le type annoncé par l’expéditeur, le fichier revient en application/octet-stream et se télécharge au lieu de s’ouvrir. Ce n’est pas de la négligence sur les types de contenu — c’est la seule réponse sûre quand le fichier vient d’un inconnu.

Le type annoncé par l’expéditeur n’est jamais renvoyé tel quel

Quelqu’un qui étiquette son fichier text/html et parvient à le faire afficher sur notre origine fait tourner sa page comme si c’était nous, dans votre session, avec tout ce que cela permet d’atteindre. L’étiquette est donc écartée, et c’est à l’appelant de décider ce qu’est le fichier à partir des métadonnées qui l’accompagnent.

Toujours un téléchargement, jamais un affichage

Content-Disposition: attachment sur chaque réponse, de sorte que rien ne s’affiche sur place, quelle que soit l’étiquette.

Aucune détection automatique, et rien ne peut s’exécuter

X-Content-Type-Options: nosniff empêche le navigateur de deviner un type, et une Content-Security-Policy de default-src 'none'; sandbox fait que même si quelque chose s’affichait, rien ne pourrait être chargé ni exécuté.

Le nom de fichier ne peut pas devenir un en-tête

Le nom est encodé plutôt que collé tel quel dans la réponse, si bien qu’un fichier nommé avec un saut de ligne ne peut pas ajouter un en-tête de son choix.

Le fichier lui-même n’est pas modifié — octet pour octet ce que l’expéditeur a envoyé. C’est l’habillage autour qui est volontairement sans surprise. Il est aussi stocké en dehors de la racine web, donc deviner un chemin ne mène nulle part : la boîte doit être résolue et autorisée avant même que le fichier ne soit lu.

Rien ici n’analyse le fichier

Il n’y a ni antivirus, ni détonation en bac à sable, ni vérification de réputation. C’est une limite assumée plutôt qu’un oubli, et cela change ce que vous pouvez faire sans risque avec ce qui arrive :

• N’importe qui peut écrire à une adresse publique. Il n’a pas besoin de vous connaître — seulement de connaître l’adresse, et les courtes se devinent. Un fichier dans une boîte publique a par défaut un auteur inconnu.
• Les exécutables et les scripts sont exactement aussi dangereux ici qu’ailleurs. Rien n’est filtré par extension, et rien ne regarde à l’intérieur d’une archive pour voir ce qu’elle contient.
• Les documents capables d’exécuter quelque chose sont le cas le plus courant. Les fichiers bureautiques avec macros et les PDF à actions intégrées sont la vraie porte d’entrée, bien plus que les exécutables évidents.
• Le nom ne dit rien. Un fichier appelé invoice.pdf est ce que disent ses octets, pas ce que dit son extension — et l’extension a été choisie par celui qui l’a envoyé.

Les fichiers partent quand le message part

Une pièce jointe n’a pas de vie propre. Elle appartient à son message, et s’en va quand il s’en va :

Après 5 jours

Supprimée avec le message, lu ou non, sur une horloge qui démarre à l’arrivée. Il n’y a ni archive ni export.

Quand vous supprimez le message

Immédiatement, et l’URL devient un 404. C’est le même appel, que vous supprimiez depuis la boîte ou via l’API.

Il n’y a pas de retour en arrière

Pas d’annulation, pas de délai de grâce, pas de boîte support à qui demander. Tout ce dont vous aurez besoin demain doit être téléchargé aujourd’hui.

Quand l’e-mail n’est pas le bon tuyau

Une partie de ce que les gens essaient de faire ici avec des pièces jointes n’est pas une limite à contourner — c’est le mauvais outil pour la tâche :

• Un fichier au-dessus du plafond. Rien ne le relève. Envoyez un lien à la place.
• Quelque chose dont vous aurez besoin le mois prochain. 5 jours est une limite stricte imposée par une tâche automatisée, pas un réglage. Récupérez-le maintenant, ou utilisez une vraie boîte mail.
• Tout ce que vous n’aimeriez pas voir lu par un inconnu. Sur un domaine public, l’adresse est le seul verrou de la boîte, et il est court.

Un domaine qui vous appartient change ce troisième point, mais ni l’un ni l’autre des deux premiers : le plafond et la rétention restent exactement les mêmes, mais l’adresse repose sur un nom qui n’apparaît nulle part sur ce site, donc personne ne lui envoie de fichiers au hasard. Un seul enregistrement MX suffit :

Enregistrement MX pour votre domaine10 smtp.grabmail.ioCopier

Le guide complet se trouve ici — l’enregistrement, ce que sa publication prouve, et les limites honnêtes d’une boîte sans mot de passe.

Questions