Stabilire l'ambito limitato della configurazione di eRecruiter
Questa guida riguarda il provider-server di posta SPF percorso descritto nel funzionario di eRecruiter Articolo SPF-Record. La fonte distingue la consegna del provider dai server di posta gestiti dal cliente e dalle installazioni locali. Il suo controllo documentato del percorso in due parti utilizza Amministrazione → Varie: Impostazioni obbligatorie → Impostazioni SMTP ed e-mail, dove l'host SMTP del tenant è vuoto, e Amministrazione (a livello di sistema) → Impostazioni statiche correnti, dove SmtpHost viene visualizzato come "epunkt-smtp..." o "er-mail...". Questi sono i modelli visualizzati legacy dell'origine, non una nuova regola di corrispondenza del nome host eseguibile. Conferma la console corrente, i valori di impostazione completi e l'applicabilità del percorso con l'amministratore autorizzato. Specifica a:er-mail.erecruiter.net, espressamente non incluso. La consegna del server cliente non richiede l'autorizzazione del fornitore.
L’ambito di implementazione supportato è quindi ristretto: identificare il percorso documentato, rivedere l’autorizzazione SPF appropriata e pianificare la verifica. Questo articolo non stabilisce un eRecruiter attuale DKIM flusso di lavoro, rilasciato selettore, firma della chiave o distribuzione end-to-end predisposta per DMARC. Mantieni irrisolto questo ambito più ampio anziché riempirlo con una ricetta generica. Il titolo del catalogo viene mantenuto, ma i suoi requisiti di implementazione completa necessitano ancora di ulteriori prove operative e di prodotto attuali.
Prima di qualsiasi modifica, ottenere la configurazione effettiva dell'account da un amministratore autorizzato. Registra l'ambiente, la proprietà del server di posta e le categorie dei messaggi senza esporre le informazioni del richiedente. La corrispondenza di reclutamento può contenere curriculum, dettagli del colloquio e dati di contatto personali; niente di tutto ciò è necessario per decidere quale sistema è responsabile del percorso della posta in uscita. Utilizza riferimenti di configurazione e contenuti di test innocui invece di copiare una vera conversazione di assunzione in un foglio di lavoro diagnostico.
Tratta l'identificazione del percorso come una porta di prova
Un'applicazione può generare un messaggio mentre un sistema diverso esegue la consegna SMTP finale. La domanda rilevante non è semplicemente se l'utente ha fatto clic su Invia all'interno di eRecruiter. Dipende da quale servizio trasmette il messaggio, quale identità della busta viene utilizzata e chi controlla l'autorizzazione del mittente. Registrare la configurazione effettiva del trasporto e la relativa data di osservazione prima di scegliere una modifica SPF . Un precedente piano di migrazione o un'impostazione ricordata non costituiscono prove attuali.
Per un percorso controllato dal cliente, assegnare la responsabilità all'operatore del servizio di posta anziché dare per scontato che l'autorizzazione del fornitore dell'applicazione appartenga a ogni policy di dominio. Per un percorso controllato dal provider, stabilire il dominio e la configurazione esatti a cui si applicano le istruzioni documentate. Se le informazioni sull'account disponibili non distinguono tali percorsi, fermati a quell'incertezza. L'aggiunta dell'autorizzazione "per ogni evenienza" espande la politica senza dimostrare che sia necessaria.
Un inventario dei percorsi dovrebbe distinguere produzione, test ed eventuali unità organizzative gestite separatamente. Non copiare automaticamente DNS di produzione in un ambiente di test e non considerare il comportamento di un account di prova come prova della produzione. Registra qualsiasi eccezione che utilizza un server di posta diverso. Si tratta di passaggi di revisione proposti, non di affermazioni secondo cui il prodotto attuale espone particolari controlli aggiuntivi o che tali eccezioni esistano in un account reale.
Comprendere il meccanismo prima di modificare la policy
RFC 7208 , sezione 5.3 definisce il meccanismo. Verifica l'IP di invio rispetto ai record di indirizzi per il dominio del meccanismo, con la famiglia di indirizzi pertinente e qualsiasi regola di prefisso specificata. Non è intercambiabile con include, che valuta un'altra politica SPF e applica la propria mappatura dei risultati nella sezione 5.2. La modifica del tipo di meccanismo perché le inclusioni abbiano un aspetto più familiare può modificare radicalmente l'autorizzazione da valutare.
Il nome host del provider è una dipendenza, non un indirizzo IP letterale copiato in modo permanente nella policy. Registra il motivo per cui il meccanismo è presente e quale percorso applicativo ne ha bisogno. Non appiattirlo in un elenco di indirizzi senza un piano di manutenzione revisionato separatamente. La sola osservazione dell’indirizzo attuale non stabilisce come verrà mantenuta tale dipendenza quando il servizio cambia infrastruttura. Questo manoscritto non ha risolto o misurato il nome host e non fornisce indirizzi IP rilevati.
Il vecchio esempio del provider include sia TXT che moduli di record di risorse SPF dedicati. L'attuale pubblicazione SPF utilizza TXT : RFC 7208 , sezione 3.1 interrompe il tipo SPF RR dedicato. Correggere esplicitamente l'istruzione legacy anziché duplicare tipi di record obsoleti per imitare l'esempio. La correzione del protocollo non conferma, di per sé, che il nome host specifico della distribuzione del provider rimanga appropriato per un conto corrente; tale applicabilità rimane un cancello separato.
Preservare l’intera politica di autorizzazione e il budget di valutazione
Un dominio esistente può autorizzare la posta dei dipendenti, gli avvisi sul sito Web e altre applicazioni. Esamina l'autorizzazione eRecruiter prevista all'interno dell'inventario completo anziché sostituire la policy con un esempio di servizio singolo. RFC 7208 , sezione 3.2 vieta multipli Registri SPF che verrebbe selezionato per lo stesso proprietario. Mantieni una politica coerente e documenta l'effetto di ogni modifica proposta.
Un meccanismo è uno dei termini dipendenti dal DNS considerati RFC 7208 , sezione 4.6.4. Il limite rilevante si basa su termini valutati, incluso il lavoro annidato ove applicabile, non semplicemente sul conteggio dei pacchetti di rete o dei mancati risultati della cache. Esaminare i percorsi di valutazione plausibili attraverso la politica completa. Aggiungere un meccanismo apparentemente piccolo può comunque avere importanza se il percorso esistente è già vicino a un limite.
Mantenere separati gli errori di sintassi, il budget di valutazione eccessivo, i dati DNS mancanti e il risultato di un mittente valido e non corrispondente. Richiedono rimedi diversi. Non rimuovere arbitrariamente le autorizzazioni legittime per far sì che una pedina venga visualizzata in verde e non indebolire il qualificatore del terminale come sostituto dell'identificazione del mittente effettivo. Un pass SPF è un risultato di autorizzazione per l'identità valutata, non una garanzia di consegna o un giudizio sul contenuto del messaggio di un candidato.
Verifica l'identità della busta e conserva la trattenuta DKIM
RFC 7208 , sezione 2.4 identifica MAIL DA come identità SPF . Confrontare il dominio della busta reale con il dominio in cui è pubblicata la politica proposta. L'indirizzo visibile dell'autore da solo non stabilisce tale relazione. Una politica può essere sintatticamente valida e includere il meccanismo previsto ma essere irrilevante per un messaggio valutato con un'identità di busta diversa.
Un esercizio di accettazione autorizzato separatamente dovrebbe registrare il percorso selezionato, inviando l'identità e il risultato del destinatario fidato utilizzando contenuti di test innocui in stile reclutamento. Non dovrebbe riguardare il curriculum del candidato reale, il programma dei colloqui o i dettagli personali. Evitare di caricare messaggi su un controllore esterno a meno che la decisione sulla condivisione dei dati non sia autorizzata. Per questa guida non è stata eseguita alcuna query DNS , messaggio di prova o caricamento esterno.
RFC 9989 , sezione 4.4 spiega l'addizionale allineamento relazione necessaria per DMARC. Un risultato SPF superato per un dominio non correlato non stabilisce l'allineamento con l'autore visibile. Questa guida non contiene prove specifiche del prodotto che stabiliscano la configurazione DKIM dell'account, pertanto non può chiudere quella parte dell'accettazione dell'autenticazione. Ottenere le istruzioni attuali del fornitore e le prove effettive dei messaggi consentiti prima di dichiarare la completa disponibilità del mittente.
Diagnosi immaginaria e foglio di lavoro di accettazione vuoto
Un team di reclutamento immaginario, Ash Grove Careers, copia l'autorizzazione del fornitore nella propria policy di dominio dopo aver visto il nome dell'applicazione su un messaggio. Il suo amministratore scopre successivamente che il percorso configurato utilizza il servizio di posta dell'organizzazione. Il meccanismo aggiunto quindi non era una prova della reale configurazione del mittente. La correzione proposta consiste nel mappare il percorso, verificare quale autorizzazione è effettivamente necessaria e ottenere un campione di ricevitore innocuo prima di contrassegnare la domanda come pronta. In questo esempio non è rappresentato alcun conto reale, richiedente o osservazione DNS .
- Ambiente e proprietà del server di posta osservata: ______
- Prova del percorso e applicabilità attuale del prodotto: ______
- Tenant SMTP-Host modello legacy SmtpHost vuoto e a livello di sistema, con entrambe le posizioni della console e la conferma corrente: ______
- Dominio effettivo della busta e dominio visibile dell'autore: ______
- Politica TXT SPF completa e modifica giustificata del meccanismo: ______
- Bilancio a termine valutato e revisione dello stato di errore: ______
- Correzione del record SPF dedicato preesistente, se pertinente: ______
- Prova di un ricevitore attendibile derivante da un test innocuo autorizzato: ______
- Flusso di lavoro DKIM irrisolto e prove di autenticazione più ampie: ______
- Modifica proprietario, piano di ripristino e decisione di rilascio: ______
Restano aperte le prove originali dell'implementazione, la revisione umana del materiale, l'applicabilità attuale, i percorsi di produzione, l'accessibilità visiva e il rilascio del proprietario. Questa è una guida documentaria con ambito SPF, non un'implementazione di autenticazione eRecruiter completata. Non è stata apportata alcuna modifica all'account, DNS o al sistema di posta.