[ Sécurité des transports ]
Aucun rapport TLS n'arrive : vérifiez le support, le trafic et la collecte
Séparez les observations d'expéditeur manquantes des échecs de découverte, de livraison, d'intégrité, d'analyse et de tableau de bord lorsque les rapports TLS sont absents.
Par l’équipe de recherche EmailAuth · 8 minutes de lecture
[ Points clés ]
- Le silence ne distingue pas les expéditeurs non pris en charge d'un collecteur défectueux.
- Tracez la découverte, l'entrée, la validation, l'analyse et l'affichage séparément.
- Utilisez les plages horaires et les preuves internes au rapport avant de modifier DNS .
Sur cette page
[ Emporter ]
Trouvez l'étape manquante en utilisant les preuves de trafic, de participation et de collecte au lieu de traiter une carte vide comme la preuve d'un échec de transport.
[ Par rôle ]
Qu'est-ce que cela signifie pour vous
Choisissez votre rôle pour les prochaines étapes pratiques.
Administrateur informatique/courrier
Localiser l'étape manquante
Un rapport peut arriver mais ne jamais apparaître dans un tableau de bord.
Prochaines étapes
- Vérifiez la découverte publique et le trafic de réception réel.
- Suivez l'identifiant du rapport via la boîte aux lettres ou l'entrée HTTP.
- Préservez les résultats de l’analyseur et du filtre.
RSSI / SecOps
Gardez les contrôles d’intégrité intacts
Les données manquantes ne justifient pas l’acceptation de rapports non authentifiés ou dangereux.
Prochaines étapes
- Conservez la validation DKIM requise pour les rapports SMTP .
- Traitez les charges utiles comme des entrées non fiables.
- Enregistrer les écarts de couverture sans déclarer un succès universel.
Fondateur / Non technique
Définir des attentes défendables en matière de reporting
Un faible trafic et une participation facultative peuvent produire des périodes de silence légitimes.
Prochaines étapes
- Identifiez les expéditeurs attendus et le trafic professionnel.
- Attribuez la propriété à chaque étape de la collecte.
- Exiger une décision de fermeture fondée sur des preuves.
[ FAQ ]
Questions fréquemment posées
Aucune donnée TLS-RPT ne prouve-t-elle que MTA-STS est désactivé ?
Non. La déclaration et l’application sont deux choses distinctes. La participation des expéditeurs, le comportement du trafic et des collecteurs peut expliquer le silence indépendamment de la politique des transports.
À quelle vitesse un nouvel enregistrement doit-il produire un rapport ?
Il n’y a pas de date limite universelle. Les rapports doivent couvrir une journée UTC et être retardés ; la génération dépend de la participation et du trafic observé.
Le vidage de mon cache DNS local aidera-t-il les journalistes externes ?
Il n'efface pas les caches des autres systèmes. Comparez les publications faisant autorité et les observations récursives pertinentes avec les horodatages.
Une boîte aux lettres peut-elle contenir un rapport que le collecteur ignore correctement ?
Oui. Les rapports SMTP dépourvus d'une signature DKIM requise valide doivent être ignorés ; d'autres conditions d'intégrité documentées peuvent également affecter l'acceptation.
Un e-mail de test prouve-t-il que le collecteur fonctionne ?
Un email ordinaire ne prouve pas que le rapport MIME , la compression, la validation de signature et l'analyse fonctionnent de bout en bout. Étiquetez la portée de chaque test proposé.
Dois-je m'attendre à des rapports à chaque URI configuré ?
Non. Un journaliste ne peut livrer que vers une seule destination prise en charge. Vérifiez les autres points de terminaison approuvés avant de déclarer tous les rapports interrompus.
Quelle période contrôle le moment où le nom de fichier et le rapport sont en désaccord ?
Le rapport lui-même fait autorité lorsque le nom de fichier ou les métadonnées du sujet ne sont pas d'accord. Inspectez ses filtres d’intervalle interne et de fuseau horaire du tableau de bord.
Que se passe-t-il si deux enregistrements de stratégie TLS-RPT valides sont publiés ?
Après avoir supprimé les enregistrements de ressources TXT qui ne commencent pas par le préfixe littéral « v=TLSRPTv1; », l'expéditeur doit trouver exactement un enregistrement restant. S'il en trouve zéro ou plusieurs, RFC 8460 lui impose de supposer que TLS-RPT n'est pas implémenté. Les limites des enregistrements sont importantes : plusieurs chaînes dans un enregistrement TXT ne signifient pas en elles-mêmes plusieurs enregistrements de stratégie.
[ Sources ]
Sources
- RFC 2308
Sections §5. Mise en cache des réponses négatives
- RFC 8460
Sections §3. Politique de rapport · §4.1 Délai du rapport · §4.3 Types de résultats · §5.2 Compression · §5.3 Transport des e-mails · §5.4 Transport HTTPS · §5.5 Nouvelle tentative de livraison · §5.6 Variations des métadonnées · §7. Considérations de sécurité
[ Glossaire ]
Glossaire
- Participation
- Indique si un système d'envoi génère des observations TLS-RPT pour le trafic concerné.
- Entrée
- Étape à laquelle une boîte aux lettres ou un collecteur HTTP reçoit le rapport.
- Attribution
- Processus d'association des observations analysées au domaine de stratégie et au compte corrects.
- Lacune de couverture
- Un intervalle ou une population d'expéditeurs pour laquelle aucune preuve de rapport utilisable est absente.
Provenance de l'entreprise
Pourquoi les principales institutions financières et gouvernements ont retiré leurs tableaux de bord de sécurité de messagerie.
Les plateformes traditionnelles d'authentification de courrier électronique vous vendent un tableau de bord et demandent à vos ingénieurs de faire le travail. Dans les environnements à enjeux élevés, la surveillance manuelle entraîne des retards dans l’application, des dérives de configuration et des domaines fantômes non surveillés.
EmailAuth est la plateforme agent de provenance des e-mails. Nos agents appliquent p=reject, gardez les expéditeurs tiers alignés et déplacez vos domaines au maximum RFC 9989 conformité, la nouvelle norme DMARC , avec une auditabilité humaine dans la boucle.
SaaS · Location dédiée · Air-gappé sur site · Chiffrement BYOK