L'implementazione di una mailing list implica più di un'identità di invio. Il dominio che ospita l'elenco può inviare avvisi di iscrizione e ridistribuire messaggi scritti da persone in altri domini. I dipendenti possono anche postare dal dominio dell'organizzazione a elenchi gestiti altrove. Ogni percorso necessita della propria autenticazione e valutazione delle politiche.
Inizia nominando il ruolo in fase di revisione. Un record la protezione degli avvisi di gestione delle liste non risolve automaticamente l'autenticazione per i post ridistribuiti. Una firma di elenco valida non si allinea automaticamente al dominio Da dell'autore originale.
Separa i tre flussi di posta
Costruisci un piccolo registro dei percorsi prima di cambiare politica:
- Posta amministrativa originata dal servizio di elenco, come conferme di iscrizione.
- Post ricevuti dagli autori e ridistribuiti agli iscritti.
- Messaggi che gli utenti inviano dal tuo dominio a elenchi esterni.
Per ciascuno, registrare l'operatore responsabile, il dominio visibile Da, l'identità della busta, i domini di firma e le trasformazioni. Mantieni l'elenco delle impostazioni del software con quel percorso anziché trattare ogni messaggio proveniente dallo stesso server come lo stesso flusso.
IL catena di identità e-mail spiega quali campi contano. Sotto RFC 9989 §3.2.2, un indirizzo di risposta o un nome di elenco descrittivo non può sostituire il dominio dell'autore per DMARC allineamento.
Confrontare la consegna diretta e quella ridistribuita
La tabella seguente è un confronto sintetico, non i dati dei messaggi acquisiti. Presupporre una policy DMARC valida applicabile, controlli completati e domini organizzativi non correlati per writers.example e lists.example . Supponiamo che un messaggio originale proveniente author@writers.example sia firmato correttamente con d=writers.example e inviato tramite un percorso originale autorizzato da SPF.
- Osservazione: Visibile dal dominio; Percorso diretto: writers.example ; Ridistribuzione dell'elenco che preserva Da: writers.example
- Osservazione: collegamento della sorgente; Itinerario diretto: servizio di invio originale; Ridistribuzione dell'elenco che preserva Da: server di elenco
- Osservazione: dominio dell'inviluppo; Percorso diretto: writers.example ; Ridistribuzione dell'elenco che preserva From: lists.example , dopo la riscrittura dell'elenco
- Osservazione: originale Firma DKIM; Percorso diretto: valido in questo esempio; Ridistribuzione dell'elenco che conserva Da: dipende dalla sopravvivenza del contenuto firmato
- Osservazione: firma aggiuntiva dell'elenco; Percorso diretto: nessuno ipotizzato; La ridistribuzione delle liste che preserva From: d=lists.example può essere verificata
- Osservazione: domanda DMARC ; Percorso diretto: un'identità originale transitoria si allinea?; Ridistribuzione dell'elenco che preserva From: qualche identità di passaggio sopravvissuta è ancora in linea con writers.example ?
Sotto RFC 9989 §4.4.2 E RFC 7208 §2.4, se l'elenco riscrive la busta in lists.example , an SPF pass autentica l'identità dell'elenco. Non si allinea con writers.example semplicemente perché la ridistribuzione era legittima. Sotto RFC 9989 §4.4.1 E RFC 9989 §5.3.5, se la firma DKIM originale sopravvive e si allinea, può comunque fornire il percorso necessario. Se il piè di pagina di un elenco o un'intestazione firmata modificata invalida la firma originale, una nuova firma da un dominio di elenco non correlato non sostituisce l'allineamento mancante.
Il risultato effettivo dipende dalle trasformazioni effettive, dalle firme e dal destinatario. Esamina entrambe le versioni invece di presumere che ogni elenco preservi o rompa lo stesso materiale.
Conserva la prova della modifica del messaggio
Quando un messaggio ridistribuito fallisce DKIM, confrontare la versione firmata originale con la versione presso l'abbonato. Controlla le modifiche al corpo, le modifiche all'oggetto e altri campi firmati come descritto in RFC 6377 §3.3. Le normali intestazioni di recapito dei messaggi aggiunte successivamente non invalidano tutte DKIM ; la copertura della firma e canonicalizzazione materia sotto RFC 6376 §3.4 E RFC 6376 §3.7.
Conserva ogni firma e i relativi valori d e s. Un messaggio può avere più firme e un errore non implica che ogni firma abbia avuto esito negativo. Utilizzo l'indagine sull'hashish corporeo quando il corpo è cambiato e distinguere il risultato da una chiave mancante o da un altro errore di verifica.
Non rimuovere mai il piè di pagina di un'attività autentica solo supponendo che abbia causato un fallimento. Dimostrare la modifica e consultare la configurazione supportata dall'operatore dell'elenco. L'utile correzione preserva la funzione di elenco richiesta rendendo chiaro il comportamento dell'identità risultante.
Valutare le scelte operative disponibili
Un operatore di lista può esaminare i modi supportati per evitare di danneggiare la firma originale, firmare la propria posta e scegliere come presentare la paternità. Come discusso in RFC 7960 §4.1.3.3, se il servizio riscrive il Da visibile in un dominio controllato da elenchi, la valutazione DMARC risultante riguarda quel nuovo dominio di autore. Ciò può modificare l'identità mostrata agli abbonati e l'esperienza di risposta, quindi testa sia la sicurezza che l'usabilità.
Come descritto in RFC 6377 §5.8, firmando la posta ridistribuita come lista si può stabilire la responsabilità per quel dominio della lista. Non può da solo certificare l'autore originale o ripristinare l'allineamento con un dominio Da non correlato.
Per le organizzazioni ospitanti, l'analisi locale può riconoscere un percorso indiretto legittimo. Sotto RFC 9989 §5.4, l'accettazione in base a tale analisi non equivale al passaggio DMARC . Conserva il risultato effettivo e qualsiasi spiegazione di override disponibile ed evita di considerare una regola di autorizzazione ampia come una soluzione permanente per ogni messaggio che utilizza l'infrastruttura dell'elenco.
Scegli la policy per l'utilizzo effettivo del dominio
RFC 9989 §7.4 mette esplicitamente in guardia contro il rifiuto di pubblicazione per i domini i cui utenti generali potrebbero postare su mailing list Internet. La sua sezione sull'interoperabilità descrive sia l'impatto dell'utente che le responsabilità del destinatario. Un programma dovrebbe applicare tale guida nella scelta della politica, piuttosto che promettere che tutti i settori alla fine dovrebbero utilizzare il rifiuto.
Un dominio che origina solo avvisi di amministrazione di liste controllate ha un utilizzo diverso da un dominio staff i cui utenti partecipano a più liste esterne. Esaminare gli importanti flussi indiretti prima di scegliere la politica per entrambi. Il rifiuto della pubblicazione dei domini deve applicare firme DKIM valide e non deve fare affidamento esclusivamente su SPF .
Mantenere un test dell'elenco riproducibile
Utilizzare autori di test e account di abbonati approvati. Invia un controllo diretto e un post di elenco rappresentativo, quindi conserva le versioni, il percorso, i timestamp e i risultati del destinatario attendibile entro i limiti specificati da RFC 8601 §7.1. Includere le funzionalità dell'elenco effettivamente utilizzate, come piè di pagina e prefissi degli oggetti. Registra la versione e la configurazione del software quando influiscono sulla trasformazione.
Dal confronto in questa guida non risulta alcuna reale esecuzione dell'elenco. Nel tuo ambiente, conserva le osservazioni effettive e ripeti il test quando vengono elencati software, gateway, firme o modifiche alle policy. Un risultato da un percorso o da un destinatario non stabilisce la consegna universale.
Un'utile valutazione della mailing list mostra chi ha originato ogni messaggio, cosa è cambiato nella lista, quali identità autenticate sono sopravvissute e come il destinatario dell'abbonato lo ha gestito. Conserva i risultati presso il proprietario dell'elenco in modo che le modifiche successive non riavviino l'indagine da un'etichetta di policy.
Registrare la decisione e i suoi limiti
Con il mittente invariato e il presunto dominio dell'elenco non correlato, la perdita della firma DKIM originale passata non lascia allineati né SPF della busta riscritta né la firma dell'elenco. Se la firma originale sopravvive, può preservare il percorso. Una riscrittura From crea una valutazione diversa, non una prova del superamento del dominio dell'autore originale. Il solo fallimento DKIM non identifica quale hop ha modificato il contenuto: preserva anche la chiave, la firma e la prova della canonicalizzazione.