Un gateway di sicurezza in uscita o un servizio di firma aziendale può ispezionare e modificare la posta dopo che l'applicazione l'ha già firmata. Una stalla DKIM la progettazione inserisce la fase finale di firma autorizzata dopo le modifiche del contenuto richieste e verifica l'intero percorso. La domanda importante è quale componente emette il messaggio finale, non quale prodotto visualizza per primo un'impostazione DKIM abilitata.
Disegna l'ordine di elaborazione effettivo
Invio di mappe, ispezione del contenuto, inserimento di dichiarazione di non responsabilità o firma, serializzazione MIME , firma DKIM e distribuzione esterna. Includere percorsi alternativi utilizzati dalle applicazioni e dal failover di emergenza. Non dare per scontato che la posta della casella di posta dei dipendenti e la posta della domanda seguano lo stesso percorso.
Per ciascun componente, registra se cambia il corpo, le intestazioni selezionate, l'identità della busta o solo i metadati di instradamento. Un blocco della firma e-mail aziendale è il contenuto del corpo; non è correlato alla crittografia DKIM-Signature intestazione nonostante la parola condivisa “firma”. Anche la riscrittura degli URL, la gestione degli allegati e la ricostruzione dell'HTML possono influire sui contenuti coperti.
RFC 6376 §5.3 E RFC 6376 §5.5 richiedere al firmatario di operare sulla rappresentazione trasmessa prevista e di modificare i ri-firmatari per apportare modifiche prima di firmare nuovamente. La progettazione dovrebbe rendere tale sequenza visibile e verificabile.
Scegli il dominio e il proprietario della chiave
Un gateway può aggiungere una firma valida sotto il proprio dominio. Ciò non soddisfa automaticamente DKIM allineamento per il tuo dominio dell'autore sotto RFC 9989 §4.4.1. Se la progettazione richiesta utilizza la firma del dominio personalizzato, verificare la funzionalità documentata del prodotto, i valori DNS generati e la custodia della chiave privata. Non inventare selettore nomi o copiare la configurazione di un altro tenant.
Decidi chi può modificare la configurazione della firma, ruotare le chiavi e alterare la pipeline del contenuto finale. Proteggi le chiavi private dall'esportazione in note di incidenti o pacchetti di test. La pubblicazione di una chiave pubblica è solo una parte della configurazione; i veri messaggi in uscita devono portare una firma corrispondente creata dopo l'elaborazione finale.
Testare la pipeline con due controlli
Disegno illustrativo A firma prima e poi aggiunge un blocco di contatti aziendali. La firma originale di tutto il corpo può fallire. Il progetto B inserisce il blocco, completa la serializzazione MIME e quindi firma con un dominio allineato autorizzato. La firma prevista può sopravvivere se l'elaborazione successiva lascia intatti i dati coperti. Queste sono aspettative di test, non un'affermazione su un fornitore indicato.
Invia testo semplice, HTML, contenuto non ASCII e un allegato attraverso il percorso previsto. Includere messaggi generati dall'applicazione e un percorso di failover supportato, ove pertinente. Cattura il messaggio dopo l'ultimo processore e presso un destinatario esterno affidabile. Associa ciascun risultato a d e s anziché accettare un'etichetta di passaggio indifferenziata.
Mantenere i controlli di sicurezza nella progettazione
Lo spostamento successivo della firma non dovrebbe spostare silenziosamente l'ispezione al di fuori del flusso di lavoro protetto o ignorare la scansione richiesta. Se il firmatario finale non può essere eseguito dopo un servizio di riscrittura obbligatorio, valutare le integrazioni supportate o un diverso limite di firma autorizzata. Evitare di utilizzare l per escludere contenuti successivi semplicemente per produrre un conteggio dei passaggi; RFC 6376 §8.2 spiega i rischi legati ai contenuti non firmati.
Una nuova firma a valle può coesistere con una precedente fallita. Conferma quale firma fornisce l'allineamento previsto e in che modo il servizio ricevente lo segnala. Non eliminare la prova del precedente fallimento dai record dei test.
Gestisci il confine come un servizio controllato dalle modifiche
Conservare il diagramma del percorso, i proprietari responsabili, il piano di conservazione delle chiavi e la suite di test del formato. Ritestare dopo aggiornamenti del gateway, modifiche al modello di branding, modifiche al routing e attivazione del failover. Il successo richiede il contenuto previsto, un percorso di autenticazione valido e allineato e una consegna corretta, con l'approvazione umana ancora separata dal risultato tecnico.
Registra la decisione successiva
Per un messaggio ipotetico, ordine del processore di registrazione, modifiche previste del contenuto, ciascuna coppia d/s, verdetto e allineamento del destinatario. Se il gateway firma solo come dominio di un fornitore non correlato, contrassegna DKIM allineato come non risolto anche se la sua firma passa. Se lo spostamento del firmatario eluderebbe l'ispezione, interrompere la modifica alla progettazione e cercare un'integrazione supportata. Questi sono criteri di pianificazione, non prove di percorso eseguite.