Vous voyez des centaines de lignes Message Trace avec l’expéditeur ttsender@microsoft.com et l’état GettingStatus ? Rassurez‑vous : ce n’est pas une vague de spam, mais un artefact lié à Microsoft Defender for Office 365. Voici l’explication, les vérifications et les solutions d’affichage.
Pourquoi le traceur de messages affiche‑t‑il des courriels provenant de ttsender@microsoft.com ?
Vue d’ensemble
- Depuis fin mai 2024, de nombreux administrateurs observent dans le Message Trace des centaines d’entrées avec l’expéditeur
ttsender@microsoft.comet le statut GettingStatus. - Aucune copie n’est réellement livrée en boîte de réception ; les utilisateurs ne voient rien.
- Les tentatives de blocage (Tenant Allow/Block List, règles de flux de messagerie, etc.) n’ont pas d’effet, car ce trafic n’est pas un flux SMTP classique.
- Microsoft a indiqué qu’il s’agit d’un comportement de back‑end normal rendu visible par erreur dans l’interface. Un correctif d’affichage est prévu.
Réponse & solution en un coup d’œil
| Point clé | Explications et mesures pratiques |
|---|---|
| Origine probable | ttsender@microsoft.com est un expéditeur interne généré par Microsoft Defender for Office 365 dans le cadre de l’analyse des pièces jointes (Safe Attachments). Lorsqu’un message contenant une pièce jointe est soumis au bac à sable, une notification technique « ttsender » sert de marqueur interne. Ces marqueurs n’auraient normalement pas vocation à apparaître dans le traceur. |
| Pourquoi l’état « GettingStatus » ? | L’interface interroge l’état de traitement pendant que l’analyse antimalware est encore en cours ; l’objet reste donc figé en GettingStatus jusqu’à la fin du cycle, puis n’évolue pas toujours vers un état final visible. |
| Impact réel | Aucun message malveillant n’est délivré. Il s’agit d’un artefact d’affichage. Les utilisateurs finaux n’ont rien à faire ; dans certains tenants, quelques « doublons » peuvent être horodatés au moment où une pièce jointe est réinjectée après analyse. |
| Blocage inutile | Ajouter ttsender@microsoft.com aux listes de blocage ou créer une règle de transport ne supprime pas ces lignes : ce ne sont pas des messages entrants/sortants classiques mais des enregistrements système visibles par inadvertance. |
| Position officielle | Comportement reconnu : « attendu côté service, inattendu dans l’interface ». Un correctif d’UI est planifié ; pas de délai public précis. |
| Recommandations admin | Surveiller normalement vos traces, mais ignorer les lignes où l’expéditeur est ttsender@microsoft.com. Filtrer vos rapports (Sender ≠ ttsender@microsoft.com) pour épurer la vue et se concentrer sur les flux pertinents. Informer le support Microsoft de l’impact volumétrique dans votre tenant pour prioriser le correctif. |
| Test de vérification | Envoyez‑vous un message avec une pièce jointe > 5 Mo ; vous verrez une ligne ttsender apparaître puis rester en GettingStatus le temps de l’analyse, sans livraison en boîte de réception. |
Ce qui se passe réellement côté Defender : Safe Attachments, Dynamic Delivery & co.
Safe Attachments scanne les pièces jointes en exécutant les fichiers dans un environnement isolé. Selon le mode, Defender :
- Retire temporairement la pièce jointe du message remis à l’utilisateur (Dynamic Delivery), puis réinjecte le fichier une fois l’analyse terminée ;
- Remplace la pièce jointe par un indicateur (Replace) jusqu’à validation ;
- ou bloque la livraison si une menace est détectée (Block), voire Monitor (journaliser sans bloquer) pour des phases pilotes.
| Mode Safe Attachments | Comportement | Expérience utilisateur | Interaction avec ttsender |
|---|---|---|---|
| Dynamic Delivery | Message livré sans PJ, puis PJ réinsérée après scan. | Message quasi immédiat ; PJ disponible après quelques minutes. | Génère des marqueurs internes pendant la fenêtre d’analyse. |
| Replace | PJ remplacée par un stub, rétablie après scan. | Indication visuelle que la PJ est en vérification. | Marqueurs internes similaires, visibles dans les traces. |
| Block | Message/pj bloqués si verdict négatif. | Message non remis ou en quarantaine. | Entrées techniques possibles, non livrées à l’utilisateur. |
| Monitor | Journalisation sans action de blocage. | Aucun impact, uniquement des logs. | Peut créer des lignes techniques transitoires. |
Pourquoi « GettingStatus » reste affiché
L’état GettingStatus reflète l’instant où l’UI interroge le pipeline de traitement pour récupérer un verdict (remise, blocage, remplacement). Dans la plupart des tenants, le verdict final existe bel et bien, mais l’interface actuelle ne réconcilie pas toujours ces marqueurs internes avec l’ID de message visible par l’admin. Résultat : la ligne « ttsender » demeure en GettingStatus, même si le message utilisateur a suivi son cours normal.
Symptômes observés vs réalité de sécurité
| Symptôme | Interprétation | Action recommandée |
|---|---|---|
Pic soudain d’entrées ttsender dans les traces | Hausse de trafic avec PJ + visibilité des marqueurs internes | Surveiller les vrai(e)s expéditeurs/destinations ; filtrer ttsender |
| Statut bloqué en GettingStatus | Requête UI vers un objet en analyse ou déjà clôturé | Ignorer ces lignes ou les exclure des exports |
| « Doublons » datés le 22 juin 2024 (exemple) | Mise à jour de cache côté client lors de la réinjection de PJ | Aucune action sécurité ; vérifier l’expérience utilisateur |
| Règles de blocage sans effet | Entrées non liées au transport SMTP traditionnel | Ne pas multiplier les règles ; privilégier le filtrage d’affichage |
Vérifications rapides pour rassurer l’équipe
- Boîtes aux lettres impactées ? Demander à 2–3 utilisateurs de confirmer qu’aucun message étrange n’a été reçu au moment des pics ttsender.
- Quarantaine : parcourir la quarantaine pour s’assurer qu’aucun lot inhabituel n’est bloqué. Les marqueurs ttsender ne s’y accumulent pas.
- Historique d’alertes : vérifier qu’aucune alerte Defender critique n’est corrélée aux horodatages concernés.
- Échantillon de test : s’envoyer un email avec PJ volumineuse (> 5 Mo) et observer l’apparition/disparition d’une ligne ttsender sans livraison d’un message externe associé.
Pourquoi bloquer ttsender@microsoft.com ne change rien
Les mécanismes de blocage (Tenant Allow/Block List, règles de transport, connexions SMTP) agissent sur des messages transitant par Exchange Online. Or, les lignes ttsender correspondent à des événements internes du service de traitement des pièces jointes ; il n’y a pas d’expéditeur externe, pas de serveur distant, pas de flux réseau à bloquer. On ne peut donc pas « empêcher » l’apparition du marqueur ; on peut en revanche éviter de l’afficher dans les rapports.
Comment filtrer/masquer les lignes ttsender
Dans le Centre d’administration Exchange (Message Trace)
- Ouvrez Flux de messagerie > Suivi des messages.
- Définissez votre plage temporelle (24–72 h pour commencer).
- Dans la zone de recherche, ne renseignez aucun expéditeur pour obtenir la vue globale.
- Exécutez la recherche, puis utilisez le filtre de colonnes pour exclure les lignes où Sender =
ttsender@microsoft.com(filtrage côté grille) ; sinon, exportez en CSV et appliquez le filtre dans Excel/Power Query.
Export CSV : modèle de nettoyage
- Exportez le CSV depuis le traceur.
- Dans Excel, utilisez un filtre avancé sur la colonne SenderAddress ≠
ttsender@microsoft.com. - Optionnel : créez une règle Power Query qui exclut toute ligne dont Status =
GettingStatuset OriginalClientIp est vide (souvent le cas de ces marqueurs).
PowerShell (Exchange Online)
Pour quantifier l’ampleur et documenter le phénomène pour le support :
# Fenêtre des 7 derniers jours
$start = (Get-Date).AddDays(-7)
$end = Get-Date
# Comptage des lignes "ttsender"
Get-MessageTrace -StartDate $start -EndDate $end ` | Where-Object SenderAddress -eq "ttsender@microsoft.com"`
| Group-Object Status | Select-Object Name,Count
# Export des lignes non "ttsender" pour analyse métier
Get-MessageTrace -StartDate $start -EndDate $end ` | Where-Object SenderAddress -ne "ttsender@microsoft.com"`
| Export-Csv ".\MessageTrace-nettoyé.csv" -NoTypeInformation -Encoding UTF8 Astuce : si votre environnement charge de gros volumes, utilisez Start-HistoricalSearch pour générer un export asynchrone, puis filtrez côté fichier.
Advanced Hunting (Defender)
Vous pouvez aussi visualiser le phénomène côté Defender :
// Volume quotidien des marqueurs "ttsender"
EmailEvents
| where SenderFromAddress =~ "ttsender@microsoft.com"
| summarize count() by bin(Timestamp, 1d), DeliveryAction
| order by Timestamp desc
Ce graphique montre l’évolution du bruit et confirme qu’il ne s’agit pas de messages livrés.
Procédure de test contrôlé
- Depuis une adresse interne, envoyez un email avec deux pièces jointes (PDF et ZIP) totalisant > 5 Mo vers une boîte de test.
- Placez la politique Safe Attachments de cette boîte en Dynamic Delivery.
- Ouvrez le traceur et lancez une recherche sur la plage dernier jour.
- Observez : apparition d’une entrée expéditeur
ttsender@microsoft.comen GettingStatus. L’utilisateur reçoit le message sans PJ ; quelques minutes plus tard, les PJ sont réinjectées. - Constatez qu’aucun mail au nom « ttsender » n’est livré à la boîte. Seul le marqueur est visible dans les traces.
Questions fréquentes (FAQ)
Est‑ce un indicateur de compromission ? Non. Ces lignes reflètent des marqueurs internes générés par la chaîne d’analyse de Defender. Aucune trace d’envoi externe à vos utilisateurs.
Puis‑je bloquer l’adresse pour « faire disparaître » les lignes ? Non. Les mécanismes de blocage s’appliquent aux courriels transportés via SMTP ; les marqueurs ttsender ne suivent pas ce chemin.
Dois‑je désactiver Safe Attachments pour nettoyer les traces ? Non surtout pas : vous perdriez une couche cruciale d’anti‑malware. Utilisez le filtrage d’affichage.
Pourquoi observe‑t‑on parfois des « doublons » ? Il s’agit le plus souvent d’une mise à jour du cache Outlook au moment où une PJ est réintégrée. Ni renvoi, ni duplication au niveau serveur.
Un correctif est‑il prévu ? Oui : Microsoft a indiqué qu’il s’agissait d’un comportement de back‑end attendu mais d’une exposition UI non souhaitée, avec un correctif planifié. Aucune date publique ferme.
Bonnes pratiques pour traverser la période jusqu’au correctif
- Documenter l’observation : captures d’écran du traceur, volumétrie quotidienne, plages horaires.
- Éduquer le support de niveau 1 : fournir un aide‑mémoire indiquant d’ignorer les lignes ttsender et de se concentrer sur les expéditeurs réels.
- Standardiser un rapport nettoyé (CSV/Excel) distribué aux équipes sécurité/compliance, sans les marqueurs.
- Surveiller la quarantaine et les alertes Defender (là se trouvent les véritables risques).
- Tester après changement de politique (Dynamic Delivery, Replace) pour vérifier l’expérience utilisateur.
Détails utiles pour les équipes techniques
- Chronologie : les premiers pics massifs ont été signalés fin mai 2024, amplifiés lors d’augmentations de trafic PJ.
- Colonnes typiques dans le CSV : SenderAddress =
ttsender@microsoft.com, Status =GettingStatus, MessageId non corrélé à un envoi externe, OriginalClientIp vide ou interne. - Corrélation : pas d’événement inhabituel dans Threat Protection Status ni d’alertes critiques synchrones.
- UX utilisateur : au plus, Dynamic Delivery introduit un léger délai de disponibilité de la PJ (attendu), sans livraison d’email « ttsender ».
Modèle de communication interne (exemple prêt à l’emploi)
Objet : Entrées « ttsender@microsoft.com » dans le Message Trace — pas d’impact sécurité
Depuis le 27/05/2024, le traceur de messages peut afficher des lignes avec l’expéditeur
ttsender@microsoft.comet l’état GettingStatus. Il s’agit d’un artefact d’affichage lié à l’analyse des pièces jointes par Microsoft Defender for Office 365. Aucun message n’est livré aux utilisateurs. Nous filtrons ces lignes dans nos rapports et restons en veille sur les alertes de sécurité effectives. Merci d’ignorer ces entrées lors de vos vérifications.
Checklist d’escalade vers le support
Avant d’ouvrir un ticket, regroupez :
- 3–5 captures d’écran illustrant les colonnes SenderAddress, Status, RecipientAddress, MessageId.
- Le volume quotidien des lignes ttsender sur 7–14 jours.
- Confirmation écrite qu’aucun utilisateur n’a reçu de message « ttsender » correspondant.
- Export CSV nettoyé (sans ttsender) pour montrer la volumétrie réelle du trafic.
- Horodatages précis d’un test maison avec PJ > 5 Mo (avant/après Dynamic Delivery).
Ce qu’il ne faut pas faire
- Ne pas désactiver Safe Attachments pour « faire disparaître » les traces : vous dégraderiez votre posture de sécurité.
- Ne pas empiler des règles de transport ciblant
ttsender@microsoft.com: elles n’auront pas d’effet et alourdiront la maintenance. - Ne pas confondre GettingStatus avec « message bloqué » : cet état décrit une demande d’état en cours, pas un verdict de sécurité.
Résumé exécutif
Les lignes ttsender@microsoft.com avec statut GettingStatus dans le Message Trace résultent de marqueurs internes générés par Microsoft Defender for Office 365 lors de l’analyse des pièces jointes (Safe Attachments). Elles ne correspondent pas à des courriels livrés, ne signalent pas un incident de sécurité et ne sont pas bloquables via les mécanismes habituels de transport. La bonne approche est d’ignorer ces entrées, de filtrer les rapports pour préserver la lisibilité et de continuer à surveiller les véritables indicateurs : quarantaine, alertes Defender, expéditeurs/destinations réels. Un correctif d’interface est planifié par Microsoft ; en attendant, maintenez vos politiques Safe Attachments et votre hygiène opérationnelle.
Annexe : lexique rapide
- Message Trace : interface de suivi des messages dans le Centre d’administration Exchange.
- Safe Attachments : fonctionnalité MDO qui exécute les PJ en bac à sable pour détecter les comportements malveillants.
- Dynamic Delivery : mode de Safe Attachments livrant le message immédiatement puis réinjectant la PJ.
- GettingStatus : état intermédiaire représentant une requête d’obtention de statut/verdict, pas un échec.
- Tenant Allow/Block List : listes d’autorisation/blocage au niveau du tenant pour les expéditeurs, domaines, fichiers.
Conclusion : aucun correctif sécurité n’est requis. Filtrez ou ignorez ces entrées jusqu’à la mise à jour de l’interface, conservez vos protections MDO actives et concentrez‑vous sur les signaux réellement exploitables.