Ambito: identificare la distribuzione Jive prima di modificare DNS
La guida alla configurazione di Jive separa le installazioni cloud e ospitate. Suo SPF le istruzioni distinguono anche le rotte cloud statunitensi e europee. Considera questa ramificazione come un prerequisito: un nome di prodotto familiare non è sufficiente per selezionare i dati DNS . Questa recensione riguarda l'e-mail di notifica Jive, non un altro prodotto denominato Jive o un servizio generale di posta in uscita. Configurazione Jive
L'amministratore deve innanzitutto descrivere l'evento aziendale che produce il messaggio. Una notifica della community, un messaggio relativo alla password e un digest generato dall'applicazione possono avere dipendenze di configurazione o recapito diverse. Registra l'esatta installazione, il proprietario del servizio, il dominio di invio e i destinatari previsti. Non dedurre il modello di distribuzione dal logo di un messaggio di posta elettronica o dalla sede geografica dell'organizzazione. Ottieni una descrizione autorevole del conto prima di scegliere una filiale documentata.
Questo è un metodo di configurazione e accettazione proposto. Non è stato effettuato l'accesso a nessun account Jive, nessun record DNS è stato modificato e nessun messaggio è stato inviato per questo articolo. L'attuale applicabilità a una particolare installazione rimane non verificata. La revisione della documentazione non può fornire la prova del messaggio ricevuto originale necessaria per l'accettazione dell'implementazione.
Ottieni il materiale corretto generato dal fornitore
Il documentato DKIM il flusso di lavoro utilizza materiale pubblico generato dal supporto: TXT per Hosted e CNAME record per Cloud. Il richiesto selettore devono essere esattamente tre caratteri. Fornire il dominio di posta elettronica; I clienti cloud non possono accedere all'impostazione e-mail di amministrazione del server citata e devono comunicarlo al supporto. Jive esegue la parte di implementazione, quindi fornisce le voci DNS del cliente. Suo DMARC la guida alla configurazione affida la responsabilità al team IT del cliente. Flusso di lavoro Jive
Prepara una richiesta invece di inventare una chiave o un selettore. La richiesta proposta dovrebbe identificare l'installazione esistente e l'identità di invio prevista, chiedere quale ramo di distribuzione si applica e richiedere istruzioni DNS pubbliche complete. Non includere mai una chiave di firma privata, una password dell'account o un token di sessione in un foglio di lavoro di modifica. L'assistenza del fornitore per la firma non autorizza un amministratore separato a modificare la politica a livello di dominio dell'organizzazione.
Conservare il materiale fornito allegato ad una specifica versione di modifica. Se in seguito una risposta dell'assistenza modifica il tipo di record, il proprietario o la destinazione, interrompi l'approvazione in sospeso e riconcilia la differenza. Uno screenshot precedente potrebbe ancora sembrare plausibile mentre descrive un'altra regione, distribuzione o generazione di chiavi. L'amministratore DNS necessita di valori correnti completi, non di un modello dedotto assemblato da esempi non correlati.
Preservare la politica SPF esistente
SPF valuta l'identità SMTP appropriata, non semplicemente l'indirizzo che una persona vede nel messaggio. Distinguere il MAIL DA identità da Identità HELO durante la registrazione delle osservazioni. Un risultato positivo per un dominio della busta controllato dal provider non viene stabilito di per sé allineamento con il dominio dell'autore visibile. RFC 7208 , sezioni 2.3 e 2.4
Prima di proporre una modifica, ottenere la policy esistente completa e identificarne il proprietario. Conserva i mittenti approvati che non sono correlati a questa distribuzione Jive. Non creare una seconda policy SPF presso lo stesso proprietario per evitare di comprendere la prima. Esaminare i percorsi di valutazione risultanti, comprese le dipendenze nidificate: il limite dei termini di ricerca del protocollo non è un conteggio di stringhe di inclusione visibili o pacchetti di rete. La memorizzazione nella cache non fornisce l'autorizzazione a superare tale limite. RFC 7208 , sezioni 3.2 e 4.6.4
La pagina Jive contiene una nota dipendente dal percorso sulla rimozione di un riferimento SendGrid dopo la configurazione DKIM . Non applicare questa nota come istruzione di rimozione universale: stabilire prima il percorso effettivo della busta e qualsiasi altra dipendenza dal mittente. Guida Jive SPF
Scrivere la modifica prevista come differenza rispetto alla linea di base approvata. Registrare cosa viene aggiunto, cosa viene mantenuto e cosa si propone di rimuovere. Se la proprietà di una dipendenza esistente è sconosciuta, lascia la domanda irrisolta anziché eliminarla silenziosamente. Una modifica riuscita in un'interfaccia DNS è la prova di un'azione amministrativa, non la prova che l'intera popolazione della posta continua ad autenticarsi.
Pubblica il proprietario esatto e il valore pubblico
Per ogni record proposto, registrare il proprietario completo indipendentemente dalla visualizzazione dell'editor DNS . Alcuni editor accettano etichette relative mentre altri visualizzano nomi completi. Una convenzione master-file non dimostra come una particolare interfaccia grafica gestisce il suffisso del dominio. Conferma il proprietario risultante utilizzando le regole del provider DNS prima di salvare. RFC 1035 , sezione 5.1
Conserva il tipo di record indicato nelle istruzioni del fornitore applicabile. Non trasformare una delega CNAME in una chiave TXT inventata localmente né sostituire una chiave pubblica fornita con una di un esempio. Per i dati TXT , distinguere le stringhe di caratteri all'interno di un singolo record di risorse da record di risorse separati. La suddivisione del testo visualizzato deve preservare i byte previsti; aggiungere un record indipendente è un'operazione diversa. RFC 1035 , sezione 3.3.14
Tratta un selettore esistente come una dipendenza che richiede un'indagine. Identificare il flusso di firma corrente prima di sovrascrivere qualsiasi cosa con quel nome. Una proposta di rollback dovrebbe spiegare quale versione DNS può essere ripristinata e se il provider ha già cambiato il firmatario. Il ripristino del vecchio DNS senza coordinare la parte firmataria può creare un'altra mancata corrispondenza anziché riparare la prima.
Verificare il messaggio, non solo il record
La revisione dell'accettazione dovrebbe raccogliere un messaggio autorizzato dal flusso di lavoro dell'applicazione effettiva e preservare i risultati del destinatario attendibile. Registra il dominio Da visibile, l'identità della busta, ogni dominio e selettore di firma DKIM e i risultati dell'autenticazione del destinatario. DKIM associa una firma a un dominio di firma e ai dati del messaggio selezionati; l'esistenza di una chiave DNS non dimostra che l'applicazione la abbia utilizzata. RFC 6376 , sezioni 3.5 e 3.6.2.2
Separare il successo dell'autenticazione dall'allineamento. DMARC può avere successo attraverso un percorso SPF allineato qualificante o un percorso DKIM allineato qualificante. Né questo successo né la conferma del fornitore garantiscono il posizionamento nella casella di posta o dimostrano che una richiesta commerciale contenuta in un messaggio sia sicura. Valutare gli identificatori effettivi in base alle regole di allineamento applicabili anziché interpretare due etichette verdi del dashboard come prova sufficiente. RFC 9989 , sezioni 2.4 e 4.4
Se un intermediario modifica il percorso di consegna, diagnostica SPF e DKIM in modo indipendente. Un IP di connessione diverso può influire SPF , ma questo fatto da solo non spiega un guasto Firma DKIM. Esaminare la chiave pubblica, la firma e i dati firmati rilevanti prima di attribuire l'errore. Non rispondere aggirando ampiamente l’ispezione di sicurezza. Una correzione del percorso approvata in modo restrittivo richiede prove proprie e la decisione del proprietario.
Diagnosi fittizia: il foglio di lavoro di distribuzione sbagliato
Consideriamo un'organizzazione fittizia, Cedar Esempio, il cui amministratore prepara un foglio di lavoro con chiave TXT dopo aver letto le istruzioni destinate alle installazioni ospitate. Il proprietario dell'account produce quindi una risposta del supporto cloud contenente voci CNAME . Nessuna modifica DNS è stata ancora approvata. La discrepanza è un errore del ramo di distribuzione, non una prova che uno dei due formati di record sia universalmente sbagliato.
Il team di revisione ritira il foglio di lavoro incompleto, registra il percorso confermato dell'account e chiede al proprietario DNS di valutare i nomi e gli obiettivi completi forniti. Lascia intatti i record dei selettori esistenti finché non se ne conoscono i proprietari. Solo dopo un'implementazione autorizzata separatamente il team raccoglierebbe un messaggio ricevuto e confronterebbe le sue identità con il piano approvato. Questo scenario è inventato per illustrare un processo decisionale; non contiene risultati del locatario osservati o valori cliente eseguibili.
Foglio di lavoro vuoto per l'accettazione e decisione di rilascio
- Modello di installazione e distribuzione: ______. Regione e proprietario della prova: ______.
- Flusso di lavoro delle notifiche e visibilità prevista Dal dominio: ______.
- Data attuale delle istruzioni di supporto e ambito del prodotto applicabile: ______.
- Conferma della lunghezza del selettore e revisione della dipendenza del selettore esistente: ______.
- Completare i titolari dei record forniti, i tipi e i valori pubblici: ______.
- Valore di riferimento SPF esistente e differenza di modifica approvata: ______.
- Aspettativa del dominio busta e revisione del percorso di ricerca: ______.
- Comportamento di denominazione dell'editor DNS e conseguente prova del proprietario pubblico: ______.
- Conferma dell'implementazione da parte del provider: ______.
- Riferimento del messaggio autorizzato e tabella identità del destinatario attendibile: ______.
- Esito dell'allineamento, fallimento residuo e titolare del rollback: ______.
- Revisore indipendente, proprietario della pubblicazione e data della revisione: ______.
Lasciare un campo vuoto quando le prove sono assenti. Uno spazio vuoto è un controllo utile perché impedisce che la disponibilità della documentazione diventi una dichiarazione di completamento operativo. Per questa bozza restano aperte le prove originali, la revisione delle PMI umane, l'applicabilità della fonte, i percorsi di produzione, l'accessibilità visiva e il rilascio del proprietario. Rivedi la valutazione quando cambiano il percorso di distribuzione, le istruzioni del fornitore, il materiale per la firma o la proprietà del dominio.