La rédaction est une transformation des preuves. Cela peut rendre la discussion d'un échantillon plus sûre tout en supprimant les informations nécessaires pour répondre à la question technique d'origine. Commencez par définir cette question : interprétation de l'en-tête, alignement de domaine, le routage, la vérification de signature ou le filtrage de contenu. Les données minimales utiles diffèrent pour chaque tâche.
Préserver l’original et identifier le dérivé
Stockez le message d'origine dans un emplacement restreint et calculez son empreinte digitale SHA-256 au niveau de l'octet. Faites une copie séparée pour la désinfection. Enregistrez le collecteur, la méthode de collecte, l'heure et le hachage original ; puis enregistrez un nouveau hachage pour le dérivé. Un hachage prend en charge les comparaisons d'intégrité ultérieures mais ne prouve pas la véracité du message ni celui qui l'a envoyé.
N'écrasez pas le seul original et n'étiquetez pas un fichier modifié comme « original brut ». En-têtes de messages peut contenir des adresses de destinataires, des hôtes internes, des informations IP publiques et privées, des URL de suivi et des identifiants. Les parties MIME et les messages joints peuvent répéter des informations sensibles absentes du corps visible. RFC 5322 décrit la structure des messages ; le flux de travail de rédaction est ici une recommandation opérationnelle et non une norme de rédaction prescrite. RFC 5322 sections 2 et 3.
Préserver les relations nécessaires au diagnostic
Pour une discussion sur l’alignement des domaines, veillez à ce que la relation entre le visible De, l’identité de l’enveloppe et les domaines de signature soit claire. Remplacer chaque domaine par le même espace réservé peut produire un alignement ; le remplacement de domaines alignés par des espaces réservés non liés peut le détruire. Si les domaines réels ne peuvent pas être partagés, fournissez un mappage explicitement illustratif qui préserve la relation et indiquez que DNS réel ne peut pas être vérifié à partir du dérivé.
Pour le routage, conservez l’ordre des sauts et étiquetez clairement les hôtes ou les adresses supprimés. Pour l’analyse de la chronologie, conservez les décalages horaires et expliquez tout décalage horaire. Pour l'analyse de l'état de livraison, conservez les limites de blocage des destinataires, l'action, l'état et les diagnostics pertinents tout en supprimant le contenu du message sans rapport. RFC 3464 définit ces champs par destinataire. RFC 3464 section 2.
Ne promettez pas une rédaction préservant la signature
La modification d'un en-tête ou d'un corps signé peut être interrompue DKIM. Certains changements d'espaces survivent détendus canonisation, mais il ne s'agit pas d'une garantie générale de rédaction. Même un changement en dehors de la couverture d'une signature peut modifier une autre signature ou supprimer le contexte nécessaire pour interpréter la confiance. Conservez les octets signés lorsque la question nécessite une vérification cryptographique. RFC 6376 sections 3.4 et 5.
Un journal de rédaction doit identifier chaque transformation et la capacité de diagnostic qu'elle supprime. Ne prétendez pas qu'un dérivé préserve la vérification de la signature simplement parce qu'il affiche toujours un DKIM-Signature champ. Aucun désinfectant ne peut être considéré comme complet sans examen du contenu résultant.
Inspectez l’intégralité du dérivé avant de le partager
Examinez les en-têtes, les parties en texte brut et HTML, les pièces jointes, les messages imbriqués, les URL, les commentaires et les noms de fichiers. Supprimez les jetons d'action tels que les valeurs de désabonnement spécifiques au destinataire lorsqu'ils ne sont pas nécessaires. Évitez une simple recherche et remplacement comme seul contrôle de confidentialité, car des données codées ou répétées peuvent rester.
Donnez à l'analyste une brève déclaration de capacité : cette copie peut prendre en charge l'interprétation de l'en-tête et la relation d'identité étiquetée, mais ne peut pas établir la validité de la signature originale ou l'état DNS non divulgué. Si l'analyste a besoin de plus, demandez l'autorisation pour les données supplémentaires spécifiques et le destinataire plutôt que d'envoyer automatiquement l'original complet. Gardez le journal de rédaction restreint lorsqu'il contient le mappage avec des données personnelles.
Travailler sur un exemple d’alignement hypothétique
Supposons que la question soit de savoir si un sous-domaine de rebond et un domaine d'auteur visible ont la relation requise par le mode d'alignement configuré. Un mappage illustratif autorisé peut remplacer l'auteur par brand.example , son sous-domaine de rebond par bounce.brand.example et un fournisseur indépendant par vendor.example . Mapper les trois sur example.com masquerait la distinction.
Étiquetez la cartographie comme étant illustrative et indiquez la relation stricte ou détendue pertinente. Cela ne remplace pas l'évaluation des domaines réels, de la politique ou DNS . Si la question change en validité DKIM , utilisez l'original restreint dans le cadre d'un accord d'accès approuvé au lieu de promettre que la copie expurgée peut y répondre.
Avant le partage, inspectez chaque partie pour détecter les adresses, jetons et identifiants répétés, y compris les messages imbriqués. Il s’agit d’un flux de travail de sélection hypothétique, et non d’une expurgation exécutée ou d’une affirmation selon laquelle un échantillon réel peut être divulgué en toute sécurité.
Partagez le moins de preuves qui répondent à la question
- Conservez le seul original restreint et créez un dérivé étiqueté séparément.
- Préservez les relations d’identité nécessaires, les blocs de destinataires, l’ordre des sauts et le contexte temporel.
- Passez en revue toutes les parties MIME , le contenu imbriqué, les liens et les noms de fichiers.
- L'État qui teste la dérivée ne peut plus prendre en charge.
- Obtenez l’autorisation pour les données réelles et le destinataire avant le partage externe.