3. Terminology and Definitions (Terminologia e definizioni)

Questa sezione definisce i termini utilizzati nel resto del documento.

Le parole chiave "deve (MUST)", "non deve (MUST NOT)", "richiesto (REQUIRED)", "deve (SHALL)", "non deve (SHALL NOT)", "dovrebbe (SHOULD)", "non dovrebbe (SHOULD NOT)", "raccomandato (RECOMMENDED)", "può (MAY)" e "opzionale (OPTIONAL)" in questo documento devono essere interpretate come descritto in [KEYWORDS].

I lettori sono incoraggiati a familiarizzare con i contenuti di [EMAIL-ARCH]. In particolare, quel documento definisce vari ruoli nell'infrastruttura di messaggistica che possono apparire uguali o separati in vari contesti. Ad esempio, un proprietario di dominio potrebbe, tramite i meccanismi di sicurezza della messaggistica su cui si basa DMARC, delegare la capacità di inviare posta come proprietario di dominio a una terza parte con un altro ruolo. Questo documento non affronta le distinzioni tra tali ruoli; il lettore è incoraggiato a familiarizzare con quel materiale prima di continuare.

Vengono utilizzati anche i seguenti termini:

Authenticated Identifiers (Identificatori autenticati): Gli identificatori a livello di dominio che sono validati utilizzando tecnologie di autenticazione sono definiti "identificatori autenticati". Vedere la Sezione 4.1 per i dettagli sui meccanismi supportati.

Author Domain (Dominio dell'autore): Il nome di dominio dell'autore apparente, come estratto dal campo RFC5322.From.

Domain Owner (Proprietario del dominio): Un'entità o organizzazione che possiede un dominio DNS. Il termine "possiede" qui indica che l'entità o l'organizzazione a cui si fa riferimento detiene la registrazione di quel dominio DNS. I proprietari di dominio vanno da organizzazioni complesse e distribuite globalmente, a fornitori di servizi che lavorano per conto di clienti non tecnici, a individui responsabili della manutenzione di domini personali. Questa specifica utilizza questo termine come analogo a un dominio di gestione amministrativa come definito in [EMAIL-ARCH]. Può anche riferirsi a delegati, come i destinatari di rapporti, quando questi sono al di fuori del loro dominio di gestione immediato.

Identifier Alignment (Allineamento degli identificatori): Quando il dominio nell'indirizzo RFC5322.From corrisponde a un dominio validato da SPF o DKIM (o entrambi), ha un allineamento degli identificatori.

Mail Receiver (Ricevitore di posta): L'entità o organizzazione che riceve ed elabora la posta elettronica. I ricevitori di posta gestiscono uno o più Mail Transport Agents (MTAs) rivolti a Internet.

Organizational Domain (Dominio organizzativo): Il dominio che è stato registrato presso un registrar di nomi di dominio. In assenza di metodi più accurati, vengono utilizzate euristiche per determinare questo, poiché non è sempre il caso che il nome di dominio registrato sia semplicemente un dominio DNS di primo livello più un componente (ad esempio, "example.com", dove "com" è un dominio di primo livello). Il dominio organizzativo è determinato applicando l'algoritmo trovato nella Sezione 3.2.

Report Receiver (Destinatario del rapporto): Un operatore che riceve rapporti da un altro operatore che implementa il meccanismo di segnalazione descritto in questo documento. Tale operatore potrebbe ricevere rapporti sui propri messaggi o rapporti su messaggi relativi a un altro operatore. Questo termine si applica collettivamente ai componenti di sistema che ricevono ed elaborano questi rapporti e alle organizzazioni che li gestiscono.

3.1. Identifier Alignment (Allineamento degli identificatori)

Le tecnologie di autenticazione della posta elettronica autenticano vari aspetti (e disparati) di un singolo messaggio. Ad esempio, [DKIM] autentica il dominio che ha apposto una firma al messaggio, mentre [SPF] può autenticare il dominio che appare nella parte RFC5321.MailFrom (MAIL FROM) di [SMTP] o il dominio RFC5321.EHLO/HELO, o entrambi. Questi possono essere domini diversi e in genere non sono visibili all'utente finale.

DMARC autentica l'uso del dominio RFC5322.From richiedendo che corrisponda (sia allineato con) un identificatore autenticato. Il dominio RFC5322.From è stato selezionato come identità centrale del meccanismo DMARC perché è un campo di intestazione del messaggio obbligatorio e quindi garantito essere presente nei messaggi conformi, e la maggior parte dei Mail User Agents (MUAs) rappresenta il campo RFC5322.From come l'originatore del messaggio e rende parte o tutto il contenuto di questo campo di intestazione agli utenti finali.

Pertanto, questo campo è quello utilizzato dagli utenti finali per identificare la fonte del messaggio e quindi è un obiettivo primario per gli abusi. Molte fonti di posta elettronica di alto profilo, come i fornitori di servizi di posta elettronica, richiedono che l'agente mittente sia autenticato prima che la posta elettronica possa essere generata. Pertanto, per queste caselle di posta, il meccanismo descritto in questo documento fornisce agli utenti finali destinatari prove solide che il messaggio è stato effettivamente originato dall'agente che associano a quella casella di posta, se l'utente finale sa che queste varie protezioni sono state fornite.

I nomi di dominio in questo contesto devono essere confrontati in modo non sensibile alle maiuscole/minuscole, secondo [DNS-CASE].

È importante notare che l'allineamento degli identificatori non può verificarsi con un messaggio che non è valido secondo [MAIL], in particolare uno con un campo RFC5322.From malformato, assente o ripetuto, poiché in tal caso non esiste un modo affidabile per determinare una politica DMARC che si applica al messaggio. Di conseguenza, l'operazione DMARC si basa sul fatto che l'input sia un oggetto messaggio RFC5322 valido e la gestione di tali casi non conformi è al di fuori dell'ambito di questa specifica. Ulteriori discussioni su questo possono essere trovate nella Sezione 6.6.1.

Ciascuna delle tecnologie di autenticazione sottostanti che DMARC prende come input produce domini autenticati come loro output quando hanno successo. Dal punto di vista di DMARC, ciascuna può essere gestita in modalità "strict" o in modalità "relaxed" (rilassata). Un proprietario di dominio selezionerebbe normalmente la modalità strict se desiderasse che i ricevitori di posta applicassero l'elaborazione DMARC solo ai messaggi che portano un dominio RFC5322.From che corrisponde esattamente ai domini che quei meccanismi verificheranno. La modalità rilassata può essere utilizzata quando l'operatore desidera anche influenzare i flussi di messaggi che portano sottodomini dei domini verificati.

3.1.1. DKIM-Authenticated Identifiers (Identificatori autenticati DKIM)

DMARC consente che l'allineamento degli identificatori, basato sul risultato di un'autenticazione DKIM, sia strict o relaxed. (Si noti che questi non sono correlati alle modalità di canonicalizzazione "simple" e "relaxed" di DKIM.)

In modalità rilassata, i domini organizzativi sia del dominio di firma autenticato [DKIM] (preso dal valore del tag "d=" nella firma) sia del dominio RFC5322.From devono essere uguali se gli identificatori devono essere considerati allineati. In modalità strict, solo una corrispondenza esatta tra entrambi i Fully Qualified Domain Names (FQDNs) è considerata produrre un allineamento degli identificatori.

Per illustrare, in modalità rilassata, se una firma DKIM validata verifica con successo con un dominio "d=" di "example.com" e l'indirizzo RFC5322.From è "[email protected]", il dominio DKIM "d=" e il dominio RFC5322.From sono considerati "allineati". In modalità strict, questo test fallirebbe, poiché il dominio "d=" non corrisponde esattamente al FQDN dell'indirizzo.

Tuttavia, una firma DKIM che porta un valore di "d=com" non consentirebbe mai un risultato "allineato", poiché "com" dovrebbe apparire su tutte le liste di suffissi pubblici (vedere Appendice A.6.1) e quindi non può essere un dominio organizzativo.

L'allineamento degli identificatori è richiesto perché un messaggio può portare una firma valida da qualsiasi dominio, inclusi i domini utilizzati da una mailing list o anche da un attore malintenzionato. Pertanto, il semplice fatto di portare una firma valida non è sufficiente per inferire l'autenticità del dominio dell'autore.

Si noti che una singola email può contenere più firme DKIM ed è considerata un "pass" DMARC se qualsiasi firma DKIM è allineata e verifica.

3.1.2. SPF-Authenticated Identifiers (Identificatori autenticati SPF)

DMARC consente che l'allineamento degli identificatori, basato sul risultato di un'autenticazione SPF, sia strict o relaxed.

In modalità rilassata, il dominio autenticato [SPF] e il dominio RFC5322.From devono avere lo stesso dominio organizzativo. In modalità strict, solo una corrispondenza esatta del dominio DNS è considerata produrre un allineamento degli identificatori.

Si noti che l'identità RFC5321.HELO non è tipicamente utilizzata nel contesto di DMARC (tranne quando richiesto per "falsificare" un percorso inverso altrimenti nullo), anche se un'implementazione "SPF puro" secondo [SPF] controllerebbe quell'identificatore.

Ad esempio, se un messaggio supera un controllo SPF con un dominio RFC5321.MailFrom di "cbg.bounces.example.com" e la parte dell'indirizzo del campo RFC5322.From contiene "[email protected]", l'identificatore di dominio RFC5321.MailFrom autenticato e il dominio RFC5322.From sono considerati "allineati" in modalità rilassata, ma non in modalità strict.

3.1.3. Alignment and Extension Technologies (Allineamento e tecnologie di estensione)

Se in futuro DMARC viene esteso per includere l'uso di altri meccanismi di autenticazione, le estensioni dovranno consentire l'estrazione dell'identificatore di dominio in modo che l'allineamento con il dominio RFC5322.From possa essere verificato.

3.2. Organizational Domain (Dominio organizzativo)

Il dominio organizzativo è determinato utilizzando il seguente algoritmo:

1. Acquisire una lista di "suffissi pubblici", cioè una lista di nomi di dominio DNS riservati per le registrazioni. Alcuni Top-Level Domains (TLD) di paesi hanno requisiti di registrazione specifici, ad esempio, il Regno Unito colloca le registrazioni delle società sotto ".co.uk"; altri TLD come ".com" appaiono nel registro IANA dei domini DNS di primo livello. Una lista di suffissi pubblici è l'unione di tutti questi. L'Appendice A.6.1 contiene alcune discussioni sull'ottenimento di una lista di suffissi pubblici.

2. Suddividere il nome di dominio DNS soggetto in un insieme di "n" etichette ordinate. Numerare queste etichette da destra a sinistra; ad esempio, per "example.com", "com" sarebbe l'etichetta 1 e "example" sarebbe l'etichetta 2.

3. Cercare nella lista dei suffissi pubblici il nome che corrisponde al maggior numero di etichette trovate nel dominio DNS soggetto. Sia quel numero "x".

4. Costruire un nuovo nome di dominio DNS utilizzando il nome che corrisponde dalla lista dei suffissi pubblici e prefissandogli l'etichetta "x+1" dal dominio soggetto. Questo nuovo nome è il dominio organizzativo.

Pertanto, poiché "com" è un TLD registrato IANA, un dominio soggetto di "a.b.c.d.example.com" avrebbe un dominio organizzativo di "example.com".

Il processo di determinazione di un suffisso è attualmente euristico. Nessuna lista è garantita essere accurata o aggiornata.