Separare i livelli di prova
Un indirizzo può essere sintatticamente ben formato anche se la sua casella di posta non esiste. Un dominio può pubblicare un file Record MX rifiutando un particolare destinatario. Un server può accettare un destinatario durante SMTP e rifiutarlo successivamente oppure accettare la posta per ogni parte locale. Nessuna di queste osservazioni dimostra l'autorizzazione a inviare messaggi di marketing. Mantieni la sintassi, il routing, la risposta del destinatario, la consegna e il consenso in campi separati.
L'autenticazione riguarda un'altra questione: se un messaggio è autorizzato o firmato per domini particolari e se tali identità sono in linea con il dominio visibile dell'autore. Non viene stabilito un risultato di convalida dell'indirizzo del destinatario SPF, DKIM O DMARC successo per un messaggio. Allo stesso modo, un pass DMARC non dice nulla sul fatto che il destinatario volesse quel messaggio.
Interpretare le risposte SMTP nel contesto
RFC 5321 distingue risposte negative temporanee, risposte negative permanenti e risposte riuscite in fasi definite della transazione SMTP . Registra la fase, la risposta e il timestamp. Una risposta temporanea invita a una strategia di nuovo tentativo, non a un'etichetta immediata di indirizzo non valido. La sola accettazione di RCPT TO non equivale all'accettazione del contenuto completo del messaggio o alla prova della consegna in una casella di posta.
Il comportamento catch -all crea un’importante incertezza. Se due parti locali inventate e un indirizzo noto ricevono tutti un'accettazione simile nella fase del destinatario, questa è una prova del modello di risposta del server, non una prova dell'esistenza di ciascuna casella di posta. Alcuni sistemi evitano intenzionalmente di rivelare la validità del destinatario. Altri mettono in coda i messaggi accettati e successivamente producono un errore di consegna. Non promettere una directory completa delle cassette postali da queste osservazioni.
Utilizzare la tabella delle prove di convalida
Consideriamo cinque osservazioni ipotetiche: rifiuto della sintassi da parte di un parser specificato; una risposta 550 all'RCPT TO; una risposta 450 all'RCPT TO; simile accettazione da parte della fase ricevente per diverse parti locali inventate; e l'accettazione completa del messaggio seguita da un errore di consegna. Etichettateli rispettivamente come rifiuto del parser, rifiuto permanente per quella transazione, rifiuto temporaneo, accettazione osservata con esistenza della casella di posta sconosciuta e successivo errore di consegna. Un 550 può riflettere una politica piuttosto che una casella di posta inesistente. Nessuno stabilisce il consenso o l'autenticazione del mittente. Si tratta di input didattici, non di risultati di test forniti o di sonde eseguite.
In un flusso di lavoro di produzione autorizzato, conservare solo le informazioni minime sull'indirizzo e i dettagli della risposta necessari per lo scopo dichiarato. Evitare sondaggi invasivi o non richiesti. Concordare il modo in cui i risultati sconosciuti influenzano il lavoro a valle: attendere per la revisione, richiedere conferma attraverso una relazione esistente o interrompere l'operazione. Una mappatura permissiva da sconosciuto a valido crea falsa fiducia; da sconosciuto a non valido può eliminare i contatti legittimi. Rendi esplicito questo compromesso anziché nasconderlo all'interno di un segno di spunta verde.
Conservare il confine esatto
RFC 5321 Sezioni 3.3, 4.2.1, 4.2.5 e 6.1 distinguere le fasi della transazione, le classi di risposta e la responsabilità di accettazione. Un MX restituito non è un elenco di cassette postali; Anche l'assenza del solo MX non dimostra l'assenza di un percorso di posta perché la Sezione 5.1 definisce la gestione MX implicita. RFC 9989 Sezioni 4.4 e 5.3.5 valutare autenticato allineamento del dominio per un messaggio, non per l'esistenza del destinatario. Non è stato eseguito alcun sondaggio in tempo reale, invio o enumerazione delle cassette postali.