Una segnalazione di reclamo è un input per un flusso di lavoro, non una prova che il flusso di lavoro sia terminato. Il risultato reale è che i relativi sistemi di invio bloccano la comunicazione indesiderata preservando le prove necessarie per spiegare la decisione. Progettare la pipeline in base a fiducia, correlazione, ambito e applicazione.
Convalidare il report prima di estrarre un'istruzione
RFC 5965 definisce un rapporto di feedback in più parti contenente informazioni leggibili dall'uomo, campi leggibili dalla macchina e materiale del messaggio restituito. Affronta inoltre i rischi di falsificazione e privacy. Analizza MIME con dimensioni esplicite e limiti di nidificazione; non eseguire il contenuto restituito né seguire i collegamenti in esso incorporati. RFC 5965.
Richiedere una provenienza adeguata al fornitore e al sistema ricevente. Un nome visualizzato corrispondente non è sufficiente. Preserva i risultati dell'autenticazione attendibile dal confine di ricezione anziché accettare le intestazioni fornite dall'aggressore per valore nominale. Mantieni una segnalazione non attendibile o non valida in una coda di revisione limitata, distinta da un reclamo perseguibile.
Correlare e scegliere l'ambito autorizzato
Risolvere il report rispetto agli identificatori conservati dell'applicazione mittente. L'output dovrebbe identificare un evento di sottoscrizione, streaming e reclamo con una base di confidenza documentata. Se in un report non esiste una corrispondenza univoca sicura, mantienilo irrisolto. Non eliminare tutte le persone che hanno ricevuto un messaggio con lo stesso oggetto.
Applicare la politica di soppressione approvata dall'organizzazione. Un reclamo promozionale può richiedere la rimozione del destinatario dal marketing, mentre le comunicazioni essenziali sulla sicurezza dell'account richiedono una decisione separata sul servizio e sulla politica. Non descrivere questa distinzione come un permesso a riconfezionare le promozioni come posta transazionale. Rispettare le preferenze espresse dal destinatario e gli obblighi applicabili nei confronti del titolare dell'azienda responsabile.
Rendere la persistenza e l'applicazione punti di controllo separati
Scrivere la decisione di soppressione in modo duraturo prima di riconoscere l'avvenuta elaborazione. Propagalo a ogni mittente rilevante e verifica che la pianificazione o la preparazione della coda tenga conto dello stato di soppressione corrente. Una riga del database che il motore della campagna non controlla mai non costituisce una soppressione efficace.
Utilizza una chiave evento stabile per rendere innocui i report duplicati. Registra la prima ricevuta, l'ora della decisione, la conferma a valle e qualsiasi nuovo tentativo. Se un servizio downstream non è disponibile, mantieni un'attività riprovabile e impedisci al flusso di lavoro di segnalare il successo dell'applicazione completa. Evita di eliminare l'evento originale semplicemente perché una chiamata API è riuscita.
Separare una decisione supportata da un report irrisolto
Consideriamo ipotetici abbonamenti ad Alice/News, Alice/Security e Bob/News. Un reclamo la cui fonte è stata convalidata in modo indipendente e il cui identificatore di invio mantenuto è associato in modo univoco ad Alice/News supporta una decisione nell'ambito approvato dall'organizzazione. In base a questa politica didattica deliberatamente ristretta, Alice/News viene soppresso mentre gli altri due record rimangono invariati. Questo esempio di policy non costituisce una decisione legale su ogni reclamo.
Un rapporto non attendibile o un identificatore di invio con due abbonati plausibili non supporta le ipotesi. Conservalo in revisione limitata e richiedi la provenienza mancante o le prove di correlazione. Un evento convalidato ripetuto dovrebbe mantenere la stessa soppressione prevista senza creare una seconda azione non correlata. Per questo esempio non sono stati elaborati report né modificati abbonamenti.
Testare il percorso di errore completo
Prima dell'abilitazione alla produzione, verifica la consegna duplicata, il guasto del parser, i record di correlazione scaduti e le interruzioni del downstream. Verifica che il personale di supporto possa vedere l'applicazione in sospeso senza visualizzare il contenuto del messaggio non necessario. Definire la conservazione dei report non elaborati separatamente dal record di soppressione minimo necessario per evitare di inviare nuovamente posta indesiderata.
Esaminare deliberatamente la nuova iscrizione. Un'importazione successiva non dovrebbe cancellare la soppressione di un reclamo semplicemente perché contiene un valore "sottoscritto" più vecchio. Se la persona effettua una nuova scelta di abbonamento valida, conserva le prove e il processo approvato per tale transizione. Concludere con un risultato misurabile: reclamo verificato, identità supportata, ambito approvato e applicazione confermata o una lacuna esplicitamente pendente.
Mantenere visibile un'interruzione a valle
Supponiamo che la decisione di soppressione venga archiviata in modo duraturo, ma il servizio della campagna non sia disponibile. Contrassegna l'applicazione in sospeso per quello specifico mittente e conserva un'attività riprovabile. Ricevere nuovamente il reclamo dovrebbe trovare l'evento esistente, non creare un altro elemento della posta in uscita o cancellare la decisione in sospeso. Un successivo riconoscimento deve corrispondere al destinatario, all'ambito e al mittente previsti.
Distinguere un riconoscimento API dalla verifica che il successivo percorso di selezione del pubblico rispetti effettivamente la modifica. Se un'esportazione obsoleta può aggirarlo, la soppressione non viene applicata completamente. Questi sono requisiti di stato e di prova proposti, non un esperimento di persistenza o interruzione eseguito. In un test di implementazione autorizzato, conservare il tempo decisionale, i tentativi downstream e l'esclusione controllata dell'invio successivo.
Assegnare il restante lavoro di applicazione
Per una decisione duratura con applicazione in sospeso, conservare l'evento specifico e la destinazione a valle, il prossimo tentativo e il proprietario. Ripristina il percorso fallito senza perdere la decisione o creare effetti collaterali duplicati. Segnala il completamento solo quando il percorso di invio previsto lo rispetta.