Source: https://once-email.com/fr/blog/safe-email-test-evidence Tests et ingénierie · 2 août 2026Mis à jour 9 août 2026 # Comment enregistrer les preuves de test de courrier électronique sans exposer les secrets Créez des captures d'écran, des en-têtes et des rapports de bogues utiles tout en supprimant les codes de vérification, réinitialisez les jetons, les adresses e-mail, les identifiants et les données personnelles non liées. [Rédaction Once Email, Once Email author Rédaction Once Email]() Relu par Rédaction spécialisée Once Email Ce que ce guide vous aide à faire Les lecteurs peuvent produire des captures d'écran, des en-têtes et des rapports de bogues utiles tout en supprimant les informations d'identification, les identifiants et le contexte en direct qui ne prennent pas en charge le diagnostic. Guide de l’article Pourquoi cet article mérite votre attention **Analyse originale** Nous travaillons à rebours à partir de la question des défauts pour minimiser les preuves collectées, en séparant les preuves nécessaires à la reproduction des secrets et des données personnelles sans rapport. **Contexte des tendances** Les outils de suivi des problèmes dans le cloud et les équipes distribuées facilitent le partage des preuves et sont plus difficiles à retirer, augmentant ainsi la valeur des échantillons de révocation, de recadrage et de synthèse. **Valeur pratique** Les lecteurs peuvent produire des captures d'écran, des en-têtes et des rapports de bogues utiles tout en supprimant les informations d'identification, les identifiants et le contexte en direct qui ne prennent pas en charge le diagnostic. Une capture d'écran peut prouver qu'un e-mail s'est mal affiché, mais elle peut également publier un lien de réinitialisation fonctionnel. Un en-tête copié peut expliquer un chemin de livraison tout en exposant une adresse, un ID de message, un hôte interne ou une valeur de corrélation de test. Une bonne preuve préserve le fait nécessaire pour reproduire un défaut et supprime tout ce qui ne supporte pas ce fait. Traitez les codes de vérification, les liens magiques et les URL de réinitialisation de mot de passe comme des informations d'identification tant qu'ils sont valides. La rédaction ne remplace pas l'expiration ou la révocation : si un véritable secret a déjà été partagé, invalidez-le ou faites-le d'abord pivoter. Les directives officielles de GitHub sur la [suppression des données sensibles d'un référentiel]() recommandent également de révoquer ou de faire pivoter un mot de passe, un jeton ou un identifiant exposé avant de tenter de nettoyer le référentiel. ## [Commencez par la question à laquelle les preuves doivent répondre]() Écrivez une phrase avant de collecter quoi que ce soit : « Cette preuve doit montrer que… » Les exemples incluent « la ligne d'objet du mobile chevauche l'horodatage », « le message de réinitialisation est arrivé après sa période de validité indiquée » ou « le lien pointe vers l'hôte intermédiaire ». Cette phrase limite la collecte. Un défaut de mise en page peut nécessiter une capture d'écran et une largeur de fenêtre recadrées, et non le message brut. Un défaut de livraison retardée peut nécessiter des horodatages UTC et une valeur de corrélation anonymisée, et non le corps du message. Un défaut d'analyse d'en-tête peut nécessiter un petit échantillon d'en-tête synthétique, et non le message original d'un client. Préférez les preuves créées avec des comptes de test dédiés et des données fictives. N'utilisez pas la boîte de réception d'un vrai client simplement parce qu'elle démontre déjà le problème. ## [Savoir quoi supprimer]() Examinez les données visibles et cachées. Les éléments sensibles courants comprennent : - adresses complètes de l'expéditeur et du destinataire ; - codes de vérification, mots de passe à usage unique et liens magiques ; - chaque URL de réinitialisation, y compris sa chaîne de requête et son fragment ; - mots de passe, clés API, cookies, champs d'autorisation et identifiants de session ; - ` Message-ID `, ID de file d'attente du fournisseur et ID de corrélation d'application ; - noms d'hôtes internes, adresses IP privées et URL d'environnement non publiques ; - les noms, numéros de téléphone, emplacements, détails de la commande et contenu des messages sans rapport ; - les onglets du navigateur, les signets, les notifications et les noms de fichiers du bureau capturés autour d'une capture d'écran ; - les métadonnées de l'image lorsque l'outil de collecte les conserve. La [RFC 5322]() définit ` Message-ID ` comme un identifiant unique lisible par machine pour une version particulière d'un message. Il est utile pour une corrélation contrôlée des logs, mais le caractère unique est également la raison pour laquelle un rapport public a généralement besoin d'un espace réservé stable plutôt que de la valeur d'origine. N'oubliez pas les URL derrière les boutons. Une capture d'écran peut masquer la destination, tandis que le code HTML copié ou une info-bulle de survol révèle le jeton complet. À l’inverse, peindre sur du texte visible dans une image ne supprime pas un secret du HTML sous-jacent, de la couche PDF, de la description du problème ou du nom de la pièce jointe. ## [Choisissez le plus petit format de preuve sûr]() Utilisez une capture d'écran recadrée pour la position visuelle, l'habillage, le contraste ou la mise en page réactive. Utilisez un court extrait de texte pour les caractères exacts ou l'analyse. Utilisez un calendrier structuré pour les retards de livraison. Utilisez un message synthétique pour un test d'analyseur reproductible. Évitez de joindre une exportation complète de boîte aux lettres lorsque trois lignes prouvent le défaut. Ne téléchargez pas par défaut les fichiers ` .eml ` bruts vers un système de suivi des problèmes largement visible : ils peuvent contenir le corps complet, tous les champs d'en-tête, les URL des ressources distantes et les pièces jointes. Once Email affiche les messages reçus mais ne fournit pas de garantie d'exportation de preuves ou de rédaction. Son [analyseur d'en-tête d'e-mail]() traite le texte d'en-tête collé localement dans le navigateur et peut aider à identifier les champs, mais vous restez responsable de décider de ce qui peut être partagé. ## [Rédigez des captures d'écran en toute sécurité]() Faites une copie et conservez tout original non expurgé uniquement dans un endroit approuvé et dont l'accès est contrôlé. Recadrez d'abord le composant concerné. Remplacez ensuite les régions sensibles par des blocs opaques ; ne comptez pas sur le flou, la pixellisation, la mise en évidence translucide ou le placement d'une forme mobile sur un contenu modifiable. Exportez le résultat rédigé sous forme d’image aplatie. Rouvrez ce fichier exporté, effectuez un zoom avant et vérifiez que le secret ne peut pas être récupéré en masquant un calque, en copiant du texte ou en augmentant le contraste. Vérifiez les bords de l'image et le chrome du navigateur environnant pour les adresses, les onglets et les notifications. Utilisez des espaces réservés significatifs lorsque le contexte est important : ``` [TEST_RECIPIENT] [VERIFICATION_CODE_REMOVED] https://staging.example/reset?[TOKEN_REMOVED] Message-ID: <[MESSAGE_ID_REMOVED]> ``` Conservez le même espace réservé pour les occurrences répétées uniquement lorsqu’il est nécessaire de montrer que deux valeurs correspondent. Sinon, évitez de créer un pseudonyme stable qui permet aux lecteurs de corréler des rapports sans rapport. ## [Rédigez les en-têtes et les liens sans détruire le bug]() Copiez le minimum de champs pertinents dans un nouveau fichier texte. Remplacer les valeurs sensibles ; ne modifiez pas la seule preuve originale. Conservez les noms de champs, les replis et les délimiteurs si le défaut concerne l'analyse. En cas de problème d'ordre de livraison, un échantillon anonymisé peut conserver les horodatages ` Received ` tout en remplaçant les hôtes, les adresses et les ID de file d'attente. Pour un problème d'affichage d'authentification, conservez les mots-clés de résultat tels que ` spf=pass ` tout en remplaçant les domaines par des exemples réservés comme ` sender.example `. Expliquez chaque substitution dans le rapport. Si une URL de réinitialisation indique un nom d'hôte incorrect, conservez uniquement le schéma et l'hôte nettoyé, puis remplacez le chemin complet, la requête et le fragment, sauf si ces composants constituent le défaut. Ne conservez jamais un jeton réel partiel : les formats secrets peuvent contenir des identifiants de compte ou rester utilisables après que seulement quelques caractères soient masqués. ## [Séparez le rapport public des preuves restreintes]() Le numéro principal doit contenir les étapes reproductibles, le résultat attendu, le résultat réel, l'environnement, la construction et les preuves nettoyées. Si un évaluateur autorisé en matière de sécurité ou de confidentialité a réellement besoin de l'original, placez-le sur le canal restreint approuvé de l'organisation avec un propriétaire et une date de suppression. Ne l'attachez pas avec désinvolture au chat. Enregistrez qui peut accéder à la copie restreinte et pourquoi. Supprimez-le lorsque l’enquête se termine ou que la période de conservation expire. Une archive de longue durée de messages de vérification temporaires crée un risque sans améliorer un défaut résolu. ## [Vérifiez avant le téléchargement]() Utilisez une révision en deux passes. Tout d’abord, le journaliste vérifie chaque valeur visible, cible du lien, nom de fichier et champ de métadonnées. Deuxièmement, une autre personne autorisée vérifie l’artefact exporté comme le verrait un destinataire. Ouvrez le fichier exact qui sera téléchargé, pas la source modifiable. Confirmez que : 1. il ne reste aucun code, lien, cookie ou identifiant valide ; 2. les adresses et les données personnelles sont supprimées sauf si cela est strictement nécessaire et approuvé ; 3. les identifiants sont des espaces réservés ou stockés uniquement dans un canal restreint ; 4. les preuves prouvent toujours le résultat réel déclaré ; 5. les étapes de reproduction utilisent des données de test et un environnement autorisé ; 6. la visibilité du problème correspond à la sensibilité restante ; 7. Il existe une décision de conservation ou de suppression pour les originaux restreints. ## [Si un secret a déjà été publié]() Arrêtez de partager le lien et contactez le propriétaire du système. Faites expirer ou alternez les informations d'identification, invalidez les sessions concernées le cas échéant, restreignez le rapport et suivez la procédure de nettoyage du référentiel ou du système de problèmes. La suppression de la dernière capture d'écran ou du dernier commit peut ne pas supprimer les copies en cache, les notifications, les forks ou l'historique. Après le confinement, remplacez l'artefact par une version expurgée vérifiée et documentez l'exposition via le processus d'incident de l'organisation. Le but n’est pas de rendre l’histoire propre ; il s'agit de rendre le secret inutilisable, d'en limiter l'accès et de conserver suffisamment de preuves sûres pour corriger le défaut sous-jacent. Pour le flux de travail fonctionnel complet qui produit ces preuves, utilisez la [liste de contrôle des tests de courrier électronique des développeurs]() . Ensemble, les deux pratiques maintiennent un défaut de flux de courrier reproductible sans transformer son rapport en un deuxième incident de sécurité. ## Guides associés Liste de contrôle des tests d'e-mails pour les développeurs : de la demande à l'expiration Une liste de contrôle pratique et autorisée pour tester les flux de courrier électronique d'inscription, de vérification et de réinitialisation de mot de passe sans masquer les défauts de livraison ni affaiblir les contrôles de sécurité. [Liste de contrôle des tests d'e-mails pour les développeurs : de la demande à l'expiration]() Comment utiliser une API de messagerie temporaire sans créer de tests instables Une conception pratique pour les tests d'API de messagerie temporaire : isolez chaque exécution, interrogez avec interruption, identifiez le bon message, protégez les secrets et faites toujours le ménage. [Comment utiliser une API de messagerie temporaire sans créer de tests instables]() Postfix vs Dovecot : rôles différents dans la réception des e-mails Situez Postfix, Dovecot, LMTP, la file et IMAP dans le trajet entrant, puis localisez une panne à partir de preuves. [Postfix vs Dovecot : rôles différents dans la réception des e-mails]() ## Outils e-mail axés sur la confidentialité Générateur SHA-256 et SHA-512 Générez des empreintes texte localement avec Web Crypto. Générateur SHA-256 et SHA-512 [Liste de contrôle des tests d'e-mails pour les développeurs : de la demande à l'expiration Une liste de contrôle pratique et autorisée pour tester les flux de courrier électronique d'inscription, de vérification et de réinitialisation de mot de passe sans masquer les défauts de livraison ni affaiblir les contrôles de sécurité.]() [Alias ​​de messagerie, boîte de réception temporaire ou adresse permanente : laquelle devriez-vous utiliser ? Comparez les alias de transfert, les boîtes de réception temporaires réservées uniquement aux réceptions et les comptes de messagerie permanents en fonction de la récupération, de la confidentialité, des réponses, de la tenue des dossiers et de la politique du site Web.]()