Un portale può accettare una domanda anche se la sua ricezione non riesce o inviare promemoria con successo mentre gli aggiornamenti di stato utilizzano un relè dimenticato. In entrambi i casi il cittadino sperimenta un servizio interrotto. Tratta ricevute, promemoria e notifiche di stato come tre percorsi indipendenti prima di fare affidamento su una metrica di autenticazione combinata.
Associa ogni notifica a una transizione di stato
Per una ricevuta, identificare l'evento dell'applicazione che la crea e l'identificatore che la collega all'invio. Per un promemoria di appuntamento, registra il sistema di pianificazione, il fuso orario e il comportamento di riprogrammazione. Per un aggiornamento dello stato, identificare la transizione della gestione del caso e il luogo autorevole dove il cittadino può verificarlo. Mantieni l'ora della notifica separata dall'ora dell'evento sottostante.
Associare ogni evento all'applicazione di invio, al tenant del fornitore, al dominio mittente della busta, DKIM dominio e selettore. Il dominio del portale Web e il certificato TLS non mostrano quale sistema invia e-mail. Un'integrazione dell'applicazione può selezionare un provider diverso per ogni famiglia di notifiche, anche quando tutti i messaggi condividono lo stesso design visivo.
Progettare test attorno ai cambiamenti, non solo al percorso felice
Utilizzare applicazioni fittizie e caselle di posta di prova autorizzate. Attivare un invio, un appuntamento modificato, un appuntamento annullato e un cambiamento di stato in un ambiente di test approvato, ove disponibile. Esamina i byte finali del messaggio e il risultato dell'autenticazione affidabile del destinatario. Confermare che i collegamenti e i riferimenti visualizzati conducano al servizio ufficiale previsto, senza includere dettagli sui casi di cittadini reali nei registri generali dei test.
Un promemoria in coda prima della riprogrammazione può essere firmato correttamente e descrivere comunque un appuntamento obsoleto. L'autenticazione del dominio non risolve il difetto dell'applicazione. Tieni traccia dell'evento e della versione di origine della notifica in modo che le operazioni possano distinguere il contenuto non aggiornato da un errore di identità. Allo stesso modo, una ricevuta duplicata dovrebbe essere esaminata come un evento o un problema di nuovo tentativo invece di essere automaticamente classificata come spoofing.
Decidi chi ferma un viaggio interrotto
Il proprietario dell'applicazione dovrebbe valutare se il cittadino può continuare in sicurezza quando la posta elettronica non è disponibile. Il proprietario della pianificazione dovrebbe gestire le discrepanze nei promemoria e le operazioni del caso dovrebbero gestire gli avvisi sullo stato. Definire il percorso alternativo approvato di controllo dello stato e il contatto di escalation prima di inasprire la politica. Non promettere un canale alternativo a meno che non sia veramente supportato e dotato di personale.
Se un mittente non è allineato, verificare l'effettiva funzionalità di dominio personalizzato del servizio e i record generati dal tenant. Modifica solo il percorso dell'identità approvato, testalo e mantieni un piano di rollback datato. Evitare ampio SPF aggiunte apportate esclusivamente perché un IP di origine sembra familiare. Un provider può autenticare il proprio dominio senza riuscire a stabilirlo allineamento con il dominio Da del servizio pubblico.
Monitorare la completezza anziché solo le percentuali
Registrare quali famiglie di notifiche sono state osservate, quali sono state testate e quali rimangono non verificate. Includi eventi poco frequenti del ciclo di vita e varianti nella lingua locale quando utilizzano modelli o sistemi diversi. Utilizzo rapporti aggregati per identificare modelli all'interno della loro effettiva copertura di reporting, quindi indagare sui percorsi mancanti o difettosi con prove di servizio. Aggiorna la mappa dopo aggiornamenti del portale, modifiche allo scheduler, sostituzione del fornitore e modifiche al dominio Da. Non viene qui affermato alcun termine legale specifico per la notifica.
Elabora tre registrazioni scritte del percorso
Questi domini di esempio riservati, selettori, ruoli e premesse DKIM di passaggio sono fittizi. In questi casi non vengono forniti o eseguiti messaggi firmati, chiavi, verifiche crittografiche, ricerche DNS , transazioni SMTP o test del servizio live. Non è necessario alcun codice di prova o campione esterno per verificare il ragionamento riportato di seguito.
- ricevuta: visibile Dal dominio receipts.civic.example ; DKIM d=receipts.civic.example; selettore demo1; presupporre il passaggio DKIM esclusivamente per questo caso scritto. SPF MAIL FROM identità e risultato sconosciuti; altre firme sconosciute; la scoperta e la consegna effettive della politica sono sconosciute. Proprietario proposto: proprietario del servizio applicativo. Azione successiva: ottenere un campione autorizzato e un risultato di un ricevitore attendibile per questo esatto tenant.
- promemoria appuntamento: visibile dal dominio appointments.civic.example ; DKIM d=appointments.civic.example; selettore demo2; presupporre il passaggio DKIM esclusivamente per questo caso scritto. SPF MAIL FROM identità e risultato sconosciuti; altre firme sconosciute; la scoperta e la consegna effettive della politica sono sconosciute. Proprietario proposto: proprietario della pianificazione. Azione successiva: conferma questo percorso separato e il relativo evento aziendale anziché ereditare il risultato del primo percorso.
- avviso di stato: visibile dal dominio status.civic.example ; DKIM d=provider.example.net; selettore demo3; presupporre il passaggio DKIM esclusivamente per questo caso scritto. SPF MAIL FROM identità e risultato sconosciuti; altre firme sconosciute; la scoperta e la consegna effettive della politica sono sconosciute. Proprietario proposto: titolare della gestione del caso. Azione successiva: chiedere al fornitore verificato il percorso di firma allineata supportato da questo tenant; non estendere l'autorizzazione a tutta la sua rete.
Per le prime due firme stipulate, d= è esattamente uguale al dominio From, quindi l'identificatore soddisfa un allineamento rigoroso e rilassato. Dato il risultato DKIM positivo previsto, esiste un percorso di autenticazione allineato per questi ipotetici messaggi. Il terzo firmatario è deliberatamente estraneo al dominio dell'autore e non può fornire quel percorso allineato. Non chiamare il terzo messaggio a DMARC fallimento: SPF allineato o altro passaggio allineato Firma DKIM potrebbero ancora soddisfare il meccanismo e tali input sono sconosciuti. Non dedurre la distribuzione reale o il posizionamento della posta in arrivo da alcuna riga.
Una firma crittografica autentica la responsabilità del dominio che firma, non la verità o l'autorizzazione di ogni istruzione. Le modifiche ai byte canonizzati coperti possono invalidare una firma; non tutte le modifiche visibili modificano necessariamente l'input firmato. L'autenticazione e l'accettazione a livello di applicazione rimangono separate.
Risolvi un esempio di promemoria obsoleto
Supponiamo che la versione 1 dell'appuntamento nel caso immaginario C-01 fosse alle 10:00 GST e che la versione 2 lo sposti alle 11:00 GST dello stesso giorno. È previsto un promemoria della versione 1 già in coda per superare DKIM allineato. Il suo risultato di identità non rende attuali le 10:00. Il titolare della programmazione dovrà applicare la regola di cancellazione o sostituzione approvata, verificare l'appuntamento corrente nel portale ufficiale e verificare se è stata effettivamente recapitata una correzione. Se invece il messaggio contiene la versione 2 ma nessuna prova di autenticazione attendibile, indagare separatamente sul percorso della posta. Qui non è stato utilizzato alcun caso reale, messaggio, lavoro di riprogrammazione o invio di correzione.
Applicare gli standard senza pretenderne la conformità
RFC 9989 Sezioni 4.4 e 5.3.5 supportare l’allineamento e la distinzione del meccanismo. La sua Sezione 7.4 mette in guardia sull'interoperabilità della posta indiretta: i domini che utilizzano p=reject deve utilizzare DKIM valido, non solo SPF , e l'uso generico della mailing list richiede particolare attenzione. Un inventario del percorso non è di per sé un'autorizzazione per imporre il rifiuto. RFC 6376 Sezioni 3.4–3.7 e 6.1 descrivere gli input firmati e la verifica. RFC 9990 Sezione 3.1 fornisce il contesto del reporting, non la prova di arrivo per destinatario. RFC 5321 Sezione 4.2.5 distingue la responsabilità dell'accettazione del server dai risultati della consegna successiva. Le scelte del flusso di lavoro settoriale qui sono raccomandazioni editoriali; l'ambito giuridico, l'idoneità dei fattori e l'autorizzazione locale necessitano di una propria revisione responsabile.