Pourquoi un e-mail bloque une pièce jointe .exe ou .zip : ce qui se passe réellement
Gmail, Outlook et la plupart des messageries refusent certains fichiers en pièce jointe, parfois même à l'intérieur d'une archive ZIP. Le mécanisme et les façons légitimes de contourner le blocage.
Pourquoi c’est bloqué
Gmail et Outlook refusent tous deux une liste de types de fichiers en pièce jointe pour protéger l’expéditeur et le destinataire contre les virus — pas seulement les EXE, mais aussi les BAT, CMD, JS, MSI, VBS et plusieurs dizaines d’autres extensions associées à l’exécution de code. La liste précise varie légèrement entre messageries, mais les formats exécutables Windows en constituent le cœur commun.
Ce blocage ne se limite pas à l’extension déclarée du fichier joint directement : la plupart des messageries inspectent également le contenu des archives (ZIP en tête) pour détecter un exécutable qui s’y trouverait compressé, précisément parce qu’une archive ne compresse ni n’exécute rien mais sert fréquemment de vecteur pour dissimuler un fichier autrement bloqué. Un ZIP contenant un seul .exe est ainsi rejeté même si l’extension visible du fichier joint est “.zip”.
Ce filtrage explique aussi pourquoi renommer un exécutable en changeant simplement son extension (programme.exe en programme.txt) ne trompe pas systématiquement un filtre sérieux : les messageries les plus robustes, comme un identifieur de fichier, s’appuient sur le contenu réel du fichier plutôt que sur son nom déclaré — le même principe que celui détaillé dans extension vs signature binaire.
Du côté du destinataire, un e-mail annonçant une pièce jointe qui n’apparaît jamais, ou un message d’erreur de blocage explicite, ne signale pas une pièce jointe corrompue : c’est un comportement attendu du filtre de la messagerie, à ne pas confondre avec une attaque par double extension où c’est au contraire l’absence de blocage qui pose problème (voir attaque par double extension).
Comment l’envoyer quand même, légitimement
Pour transmettre un exécutable ou un script à un destinataire de confiance (livraison d’un logiciel interne, script d’installation), trois méthodes légitimes, dans l’ordre recommandé par Gmail et Outlook eux-mêmes :
- Passer par un lien de partage plutôt que par la pièce jointe directe. Déposer le fichier sur un service de stockage cloud (Drive, OneDrive, ou tout hébergeur interne à l’entreprise) et envoyer le lien par e-mail. C’est la méthode recommandée en premier par les deux messageries : le fichier ne transite jamais par le filtre de pièce jointe.
- Compresser dans une archive protégée par mot de passe. Le chiffrement rend le contenu illisible pour le filtre automatique, qui laisse alors passer l’archive — le mot de passe se transmet séparément (jamais dans le même e-mail). Cette méthode déclenche parfois une vigilance accrue côté destinataire plutôt qu’un simple passage silencieux, ce qui est normal.
- Renommer temporairement l’extension du fichier, en accord préalable avec le destinataire (
programme.exeenvoyé enprogramme.exe.bloque, restauré après réception). La méthode la plus artisanale des trois, à réserver aux cas où les deux premières ne sont pas praticables.
Ce qu’il ne faut pas faire
Renommer l’extension sans prévenir le destinataire ne fiabilise rien : lui seul doit ensuite deviner qu’il faut restaurer .exe, ce qui revient à lui demander d’exécuter un fichier reçu par e-mail sans certitude sur son contenu réel — exactement le réflexe qu’un filtre de pièce jointe cherche à éviter.
Vérifier le vrai contenu d'un fichier avant envoi →
Formats concernés
Voir aussi
- Attaque par double extension (photo.jpg.exe) : comment la repérer avant d'ouvrir un fichier
- Extension vs signature binaire : pourquoi renommer un fichier ne change pas ce qu'il est
- EML, MSG, PST : quel format choisir pour exporter, archiver ou migrer des e-mails
Sources
Dernière mise à jour :