1. Introduction (Introduzione)

L'infrastruttura di posta elettronica attuale ha la caratteristica che qualsiasi host che inietta messaggi nel sistema può utilizzare qualsiasi nome di dominio DNS nei vari identificatori specificati in [RFC5321] e [RFC5322]. Sebbene questa caratteristica sia vantaggiosa in alcuni casi, rappresenta un ostacolo importante nella riduzione delle e-mail di massa non richieste (UBE, Unsolicited Bulk Email, noto anche come spam). Inoltre, gli ADMD (come descritto in [RFC5598]) sono comprensibilmente preoccupati che altre entità possano facilmente utilizzare i loro nomi di dominio, spesso con intenti malevoli.

Questo documento definisce un protocollo attraverso il quale un ADMD può autorizzare gli host a utilizzare il suo nome di dominio nelle identità "MAIL FROM" o "HELO". Gli ADMD conformi pubblicano record Sender Policy Framework (SPF) nel DNS, specificando quali host sono autorizzati a utilizzare i loro nomi, e i destinatari di posta conformi utilizzano i record SPF pubblicati per testare l'autorizzazione di un agente di trasferimento di posta (MTA, Mail Transfer Agent) mittente che utilizza una determinata identità "HELO" o "MAIL FROM" durante una transazione di posta.

Un ulteriore vantaggio per i destinatari di posta è che, dopo aver validato l'uso di un'identità, le decisioni di politica locale riguardanti le e-mail possono essere prese sulla base del dominio del mittente piuttosto che sulla base dell'indirizzo IP dell'host. Questo è vantaggioso perché la reputazione di un nome di dominio può essere più accurata della reputazione di un indirizzo IP dell'host, poiché il nome di dominio potrebbe essere più stabile su un periodo di tempo più lungo. Inoltre, se l'identità dichiarata non può essere validata, la politica locale può adottare misure più severe contro tali e-mail, come rifiutarle.

1.1 Terminology (Terminologia)

1.1.1 Key Words (Parole chiave)

Le parole chiave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" e "OPTIONAL" in questo documento devono essere interpretate come descritto in [RFC2119].

1.1.2 Imported Definitions (Definizioni importate)

ABNF (Augmented Backus-Naur Form) è definito in [RFC5234], i token "ALPHA", "DIGIT" e "SP" (spazio) sono anch'essi definiti lì.

I token "Local-part", "Domain" e "Mailbox" sono definiti in [RFC5321].

"dot-atom", "quoted-string", "comment", "CFWS" (Comment Folded White Space), "FWS" (Folded White Space) e "CRLF" (Carriage-Return/Line-Feed) sono definiti in [RFC5322].

1.1.3 MAIL FROM Definition (Definizione MAIL FROM)

Questo documento riguarda l'identità del mittente del messaggio, come descritto in [RFC5321]:

La transazione inizia con il comando MAIL, che fornisce l'identità del mittente.

Poiché questa identità ha molti altri nomi, è importante scegliere un nome che sia:

Comunemente usato
Chiaramente definito

Pertanto, il termine "MAIL FROM" sarà utilizzato in questo documento, definito come l'identità RFC5321.MailFrom (Reverse-Path) descritta in [RFC5598].

1.1.4 HELO Definition (Definizione HELO)

Questo documento utilizza anche l'identità HELO/EHLO. L'identità "HELO" deriva dal comando SMTP HELO o EHLO (vedi [RFC5321]). Poiché HELO ed EHLO possono essere utilizzati in modo intercambiabile in molti casi, sono generalmente identificati come "HELO" in questo documento. Questo significa RFC5321.HELO/.EHLO come definito in [RFC5598]. Questi comandi forniscono l'identità del client SMTP (host mittente) per la sessione SMTP.

1.2 check_host()

La sezione 4 presenta un algoritmo utilizzato per valutare la politica SPF rispetto a una transazione di posta in arrivo. Nelle prime implementazioni, questo algoritmo era codificato in una funzione chiamata check_host(). Questo nome è utilizzato in questo documento come simbolo dell'algoritmo di valutazione SPF, ma naturalmente gli implementatori non sono tenuti a utilizzare questo nome.