Sophos Phish Threat: risolvere errori di recapito e bounce
Quando gli utenti non ricevono un’e-mail Sophos Phish Threat, le cause possibili sono diverse: la campagna non ha ancora raggiunto il destinatario, l’indirizzo di destinazione non è valido, un gateway limita la velocità di invio oppure un controllo di sicurezza blocca o mette in quarantena la simulazione. La diagnosi inizia quindi in Sophos Fusion (in precedenza Sophos Central) e prosegue seguendo il percorso di recapito effettivamente utilizzato.
Importante: gli utenti elencati nella pagina Bounced Mailboxes non ricevono e-mail dalle campagne future finché la causa non è stata corretta e gli utenti non sono stati rimossi dall’elenco. La rimozione non è quindi il primo passaggio della diagnosi, ma deve avvenire solo dopo la risoluzione del problema.
Diagnosi rapida
| Osservazione | Controllare prima | Successivamente |
|---|---|---|
| La campagna è appena iniziata | attendere almeno un’ora e controllare la pianificazione dell’invio | controllare di nuovo l’avanzamento della campagna |
| Solo alcuni utenti hanno ricevuto un’e-mail | invio a intervalli, elenco dei destinatari e cassette postali attive | controllare Bounced Mailboxes e la sincronizzazione delle directory |
| Central mostra Bounced o Not Sent | dettagli dell’errore in Bounced Mailboxes | esaminare l’indirizzo, gli errori DNS/SMTP e il flusso di posta |
| Central mostra Delivered, ma l’e-mail non è visibile | Message Trace, log del gateway, quarantena e cartella Posta indesiderata | individuare la regola di filtro attivata |
| Molte e-mail non vengono recapitate con volumi elevati | limitazione della velocità o throttling | distribuire l’invio su più ore o giorni |
| Direct Delivery è configurato per il dominio | configurazione di Direct Delivery | proseguire la diagnosi nel runbook pertinente |
1. Registrare un caso riproducibile
Prima di apportare modifiche, registra le seguenti informazioni:
- nome della campagna
- ora di inizio pianificata ed effettiva, incluso il fuso orario
- da uno a tre destinatari interessati e un destinatario funzionante per il confronto
- dominio di invio utilizzato
- stato di recapito dell’utente interessato
- ora del tentativo di invio
- testo completo dell’errore, codice DNS ed errore SMTP, se visualizzati
- ultime modifiche alla campagna, all’elenco dei destinatari, alla sincronizzazione delle directory o ai filtri e-mail
Non avviare subito un’altra campagna di grandi dimensioni. Gli invii completi ripetuti rendono più difficile la correlazione e possono attivare nuovamente limiti di velocità o regole di sicurezza.
2. Controllare la pianificazione e l’avanzamento della campagna
In Phish Threat > Campaigns, apri la campagna interessata. Controlla che sia attiva e in fase di elaborazione e verifica quale stato di recapito mostra Central per gli utenti interessati.
Dopo l’avvio di una campagna trascorre almeno un’ora prima dell’invio delle e-mail. Una campagna può inoltre recapitare le e-mail in modo scaglionato: dal recapito immediato a lotti pari ad appena il 5%. Se solo una parte del gruppo di destinatari ha ricevuto l’e-mail, controlla prima la pianificazione configurata e gli intervalli di invio ancora in sospeso.
Per modificare la pianificazione o sospendere una campagna in corso, segui la procedura Gestire le campagne Sophos Phish Threat. Non modificare una campagna attiva senza documentare l’effetto sulle e-mail ancora in sospeso.
3. Esaminare Bounced Mailboxes
Apri l’icona Global Settings e vai a Products and Services > Sophos Phish Threat > Bounced Mailboxes. Per i recapiti non riusciti, questa pagina contiene l’Email ID, il nome della campagna e i dettagli dell’errore, come il codice DNS e l’errore SMTP.
Puoi filtrare l’elenco in base alle seguenti informazioni:
- nome utente
- indirizzo e-mail
- nome della campagna
- tipo di bounce
Inizia dall’indirizzo e-mail interessato e dal nome della campagna. Registra il testo e l’ora dell’errore senza modificarli. L’Email ID è un campo di Sophos Fusion e non deve essere equiparato a un Message-ID RFC, a un ID del log del gateway o a un ID di traccia senza prove della correlazione.
La voce indica che il recapito non è riuscito, ma non ancora quale sistema ha causato l’errore. Non rimuovere gli utenti da Bounced Mailboxes finché i controlli seguenti non sono stati completati e la causa non è stata corretta.
4. Controllare i destinatari e la sincronizzazione delle directory
Per ogni utente interessato, controlla quanto segue:
- L’indirizzo e-mail è scritto correttamente ed è completo?
- La cassetta postale esiste, è attiva e può ricevere messaggi normali?
- Gli indirizzi errati provengono da un’importazione CSV manuale?
- L’indirizzo principale corrente è stato sincronizzato con Sophos Fusion?
- La sincronizzazione delle directory in uso viene eseguita senza errori?
Correggi prima gli indirizzi di destinazione errati o obsoleti nella relativa origine, quindi verifica che la sincronizzazione sia riuscita. La semplice rimozione di un utente da Bounced Mailboxes non corregge né un indirizzo non valido né una cassetta postale disabilitata.
5. Determinare il percorso di recapito
Prima di cercare nei log, determina se il dominio interessato utilizza Direct Delivery o il normale flusso di posta.
Se è configurato Direct Delivery, prosegui con Configurare e verificare Sophos Phish Threat Direct Delivery. I controlli relativi ad API, autorizzazioni e provider fanno parte di tale procedura, non di un’analisi SMTP.
Per il recapito tramite il normale flusso di posta, controlla i log di tutti i sistemi effettivamente coinvolti. Per Microsoft 365, Recapito di Sophos Phish Threat in Microsoft 365 descrive i passaggi specifici del provider; per Google Workspace, consulta Recapito di Sophos Phish Threat in Google Workspace.
6. Esaminare Message Trace e i log del gateway
Esegui una ricerca nel Log Viewer o in Message Trace del gateway di posta locale utilizzando un intervallo di tempo ristretto. A seconda dell’ambiente, può trattarsi dei log e-mail di Sophos Firewall, di Message Trace nell’Exchange Admin Center o dei log di un filtro antispam a monte.
Limita la ricerca ai seguenti attributi:
- indirizzo esatto del destinatario
- ora del tentativo di invio
- indirizzi IP di invio regionali di Sophos Phish Threat documentati
- dominio di invio utilizzato nella campagna
Non copiare indirizzi IP di invio e domini da ticket precedenti. I valori correnti sono disponibili in Phish Threat > Settings > Sending domains and IPs.
Registra quanto segue per l’ultimo hop confermato:
- Il gateway ha rifiutato la connessione?
- L’e-mail è stata bloccata o messa in quarantena a causa del rilevamento di spam o phishing?
- È stata rifiutata a causa dell’allineamento SPF, DKIM o DMARC?
- È stata applicata una limitazione della velocità o il throttling?
- L’e-mail è stata accettata e inoltrata all’hop successivo?
Registra l’errore SMTP completo, l’host che ha risposto e il timestamp. Se lo stato è Delivered, controlla anche la quarantena, la cartella Posta indesiderata e le regole a valle.
Se non è presente alcuna voce di log, controlla prima l’intervallo di tempo, il fuso orario, il destinatario, l’IP o il dominio di invio e il percorso di recapito selezionato. Solo a quel punto puoi presumere che non sia stato effettuato alcun tentativo di recapito.
7. Correggere la causa specifica
Limitazione della velocità o throttling
Utilizza la funzione di invio in batch per distribuire l’invio su più ore o giorni anziché inviare tutte le e-mail contemporaneamente. Quindi utilizza un piccolo gruppo di destinatari autorizzato per verificare se il gateway accetta la nuova velocità.
Un filtro blocca o mette in quarantena la simulazione
Non creare un’eccezione globale estemporanea. Configura gli indirizzi IP regionali di Sophos necessari, i domini di invio e i controlli interessati secondo Consentire in modo controllato i mittenti Sophos Phish Threat.
Per ogni modifica diagnostica temporanea, registra:
- configurazione originale
- persona responsabile e approvazione
- ambito strettamente limitato
- ora di inizio e di scadenza
- passaggio di ripristino
- risultato del test di recapito e del test di regressione dopo il ripristino
Anche le eccezioni permanenti per le simulazioni richiedono un ambito documentato, un responsabile e una revisione periodica. Non estenderle a reti o mittenti Sophos arbitrari né a tutti i controlli di sicurezza.
Destinatari non validi o errori di sincronizzazione
Correggi l’indirizzo o la cassetta postale nel sistema di origine, attendi che la sincronizzazione termini senza errori e solo a quel punto ripeti il test.
8. Eliminare la voce da Bounced Mailboxes ed eseguire un test limitato
Dopo la correzione tecnica, procedi nell’ordine seguente:
- Documenta la causa e la correzione.
- Verifica che l’indirizzo, la cassetta postale e il percorso di recapito utilizzato ora funzionino.
- Rimuovi l’utente interessato da Bounced Mailboxes.
- Utilizza una piccola campagna di test autorizzata o il successivo invio controllato della campagna.
- Controlla lo stato di recapito in Phish Threat > Campaigns.
- Per il normale flusso di posta, conferma l’accettazione e l’inoltro nei log dei sistemi coinvolti.
- Controlla se l’e-mail appare nella cassetta postale prevista o nella quarantena prevista.
Includi altri destinatari solo dopo la riuscita del test. Se il test non riesce di nuovo, esamina la nuova voce in Bounced Mailboxes e i log del gateway corrispondenti anziché rimuovere ripetutamente l’utente.
Pacchetto di prove per l’escalation
Se il problema resta riproducibile dopo la correzione, fornisci le seguenti informazioni tramite il canale di assistenza sicuro:
- ID tenant Central o ID account
- nome della campagna
- indirizzo del destinatario interessato, oscurato ove possibile in conformità ai requisiti di protezione dei dati
- stato e ora del recapito, incluso il fuso orario
- Email ID da Bounced Mailboxes
- codice DNS ed errore SMTP completi
- percorso di recapito utilizzato
- per il normale flusso di posta: codice SMTP, host che ha risposto, ultimo hop confermato ed eventuale identificatore di Message Trace o del gateway disponibile
- correzione eseguita e risultato del test limitato
Password, token, link delle campagne ed esportazioni complete degli utenti non devono essere inclusi nel pacchetto di prove. Le intestazioni e i log possono contenere nomi host interni, indirizzi IP, indirizzi e-mail e valori di tracciamento e non devono essere copiati in ticket o forum pubblici.