6. Modifier Definitions (Definizioni dei modificatori)

I modificatori sono coppie nome/valore che forniscono informazioni aggiuntive. I modificatori hanno sempre un "=" che separa il nome e il valore.

I modificatori definiti in questo documento ("redirect" e "exp") dovrebbero apparire alla fine del record, dopo tutti i meccanismi, sebbene possano sintatticamente apparire ovunque nel record. L'ordine di questi due modificatori è irrilevante. Questi due modificatori non devono assolutamente apparire più di una volta in un record. Se lo fanno, check_host() termina con un risultato "permerror".

I modificatori non riconosciuti devono essere ignorati, indipendentemente da dove o quante volte appaiono. Ciò consente alle implementazioni conformi a questo documento di gestire correttamente i record con modificatori definiti in altre specifiche.

6.1 redirect: Redirected Query (redirect: Query reindirizzata)

Il modificatore "redirect" è destinato a consolidare l'autorizzazione e la politica in un insieme comune da condividere all'interno di un singolo ADMD. Gli host autorizzati e le politiche di un numero qualsiasi di domini possono essere controllati da un singolo record.

redirect = "redirect" "=" domain-spec

Se tutti i meccanismi non corrispondono e un modificatore "redirect" è presente, il trattamento procede come segue:

La parte <domain-spec> della parte redirect viene espansa secondo le regole macro della Sezione 7. Quindi check_host() viene valutato con la stringa risultante come <domain>. I parametri <ip> e <sender> rimangono gli stessi dell'attuale valutazione di check_host().

Il risultato di questa nuova valutazione di check_host() viene quindi trattato come il risultato della valutazione corrente, tranne che se non viene trovato alcun record SPF o se <target-name> è formattato male, il risultato è "permerror" invece di "none".

Si noti che il dominio della nuova query può esso stesso specificare un trattamento redirect.

Questo strumento è destinato alle organizzazioni che desiderano applicare lo stesso record a più domini. Ad esempio:

la.example.com. TXT "v=spf1 redirect=_spf.example.com"
ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
_spf.example.com. TXT "v=spf1 mx:example.com -all"

In questo esempio, la posta da uno qualsiasi di questi tre domini è descritta dallo stesso record. Questo può essere un vantaggio amministrativo.

Nota: In generale, il dominio "A" non può utilizzare in modo affidabile un reindirizzamento a un altro dominio "B" che non è sotto lo stesso controllo amministrativo. Poiché <domain> rimane invariato, non vi è alcuna garanzia che il record al dominio "B" funzionerà correttamente per le caselle di posta nel dominio "A", in particolare se il dominio "B" utilizza meccanismi che coinvolgono il local-part. La direttiva "include" sarebbe generalmente più appropriata.

Per chiarezza, qualsiasi modificatore "redirect" dovrebbe apparire come ultimo termine nel record. Se un meccanismo "all" è presente ovunque nel record, qualsiasi modificatore "redirect" deve essere ignorato.

6.2 exp: Explanation (exp: Spiegazione)

explanation = "exp" "=" domain-spec

Se check_host() risulta in "fail" a causa di un meccanismo corrispondente (come "-all") e un modificatore "exp" è presente, la stringa di spiegazione restituita viene calcolata come descritto di seguito. Se non è presente alcun modificatore "exp", deve essere restituita all'applicazione chiamante una stringa di spiegazione predefinita o una stringa di spiegazione vuota.

<domain-spec> viene sottoposto a espansione macro (vedere Sezione 7) e diventa <target-name>. Il RRset DNS TXT per <target-name> viene recuperato.

Se ci sono errori di elaborazione DNS (qualsiasi RCODE diverso da 0), o se non vengono restituiti record, o se viene restituito più di un record, o se ci sono errori di sintassi nella stringa di spiegazione, continuare come se non fosse stato fornito alcun modificatore "exp".

Le stringhe del record TXT recuperato vengono concatenate senza spazi e quindi elaborate come explain-string, che viene sottoposta a espansione macro. Questo risultato finale è la stringa di spiegazione. Le implementazioni possono limitare la lunghezza della stringa di spiegazione risultante per consentire altri vincoli di protocollo e/o limiti di elaborazione ragionevoli. Poiché la stringa di spiegazione è destinata all'uso nelle risposte SMTP e la Sezione 2.4 di [RFC5321] afferma che le risposte sono [US-ASCII], la stringa di spiegazione deve essere limitata a [US-ASCII].

Il software che valuta check_host() può utilizzare questa stringa per comunicare informazioni dal dominio di pubblicazione sotto forma di messaggio breve o URL. Il software dovrebbe rendere chiaro che la stringa di spiegazione proviene da una terza parte. Ad esempio, potrebbe anteporre alla spiegazione la stringa macro "%\{o} explains: ", come mostrato nell'esempio della Sezione 8.4.

Supponiamo che example.com abbia questo record:

v=spf1 mx -all exp=explain._spf.%\{d}

Ecco alcuni esempi di possibili record TXT di spiegazione a explain._spf.example.com:

"Mail from example.com should only be sent by its own servers."

-- un messaggio semplice e costante

"%\{i} is not one of %\{d}'s designated mail servers."

-- un messaggio che contiene più informazioni, incluso l'indirizzo IP che ha fallito il controllo

"See http://%\{d}/why.html?s=%\{S}&i=%\{I}"

-- un esempio complesso che utilizza i parametri di check_host() per costruire un URL in modo che possa essere generata una pagina Web con istruzioni dettagliate e personalizzate

Nota: Durante la ricorsione in un meccanismo "include", il modificatore "exp" da <target-name> non deve assolutamente essere utilizzato. Al contrario, quando si esegue un modificatore "redirect", il modificatore "exp" dal dominio originale non deve assolutamente essere utilizzato. Ciò è dovuto al fatto che "include" è destinato a attraversare i confini amministrativi e la spiegazione da fornire dovrebbe essere quella dell'ADMD ricevente, mentre "redirect" è destinato come strumento per consolidare i record di politica all'interno di un ADMD, e quindi la spiegazione reindirizzata è quella che dovrebbe avere la priorità.