Passa al contenuto principale

Appendix B. Changes from RFC 4408 (Modifiche rispetto a RFC 4408)

Appendix B. Changes in Implementation Requirements from RFC 4408 (Modifiche dei requisiti di implementazione rispetto a RFC 4408)

Questa appendice riassume i principali cambiamenti di RFC 7208 rispetto al suo predecessore RFC 4408.

B.1 Cambiamenti principali

B.1.1 Tipo RR SPF deprecato

Requisito RFC 4408:

  • Pubblicazione simultanea di record TXT e SPF (tipo 99)
  • Le implementazioni devono verificare entrambi i tipi di record

Cambiamento RFC 7208:

  • Utilizzare solo record TXT (tipo 16)
  • Il tipo RR SPF non è più supportato
  • Implementazione e distribuzione semplificate

Motivo: Tasso di adozione molto basso del tipo RR SPF, sistema a doppio tipo che causava problemi di interoperabilità.

B.1.2 Chiarimento dei limiti di query DNS

RFC 4408:

  • Limite di query DNS descritto in modo insufficientemente chiaro
  • Limite "void lookup" non definito

RFC 7208:

  • Definizione chiara del limite di 10 query DNS
  • Aggiunto limite "void lookup" (raccomandato 2)
  • Descrizione dettagliata dei limiti aggiuntivi per i meccanismi MX e PTR

Limiti specifici:

- Query DNS totali: ≤ 10 (include, a, mx, ptr, exists, redirect)
- Per meccanismo mx: ≤ 10 query di indirizzo
- Per meccanismo ptr: ≤ 10 query di indirizzo
- Void lookups: ≤ 2 (raccomandato)
- Tempo di valutazione: ≥ 20 secondi (raccomandato)

B.1.3 Gestione del "local-part"

RFC 4408:

  • Gestione del local-part insufficientemente chiara
  • Gestione del local-part vuoto non definita

RFC 7208:

  • Specifica chiara: se <sender> non ha local-part, utilizzare "postmaster"
  • Miglioramento della gestione del percorso inverso vuoto (<>)

Esempio:

MAIL FROM:<>
→ SPF utilizza l'identità HELO, local-part è "postmaster"

B.1.4 Forte opposizione al meccanismo "ptr"

RFC 4408:

  • Meccanismo "ptr" consentito ma non raccomandato

RFC 7208:

  • Chiaramente contrassegnato come "do not use" (non utilizzare)
  • Avvertimento aggiunto nel nome del meccanismo
  • Enfasi sui problemi di prestazioni e affidabilità

Motivi:

  • Query DNS inverse lente
  • Dipende dalla configurazione di terze parti (proprietario indirizzo IP)
  • Carico sui server dei nomi .arpa

B.1.5 Correzione della sintassi delle macro

RFC 4408:

  • Definizione della sintassi delle macro ambigua

RFC 7208:

  • Definizione ABNF migliorata
  • Chiarimento delle regole di espansione delle macro
  • Corretti casi limite

B.1.6 Considerazioni di sicurezza per il modificatore "exp"

RFC 4408:

  • Considerazioni di sicurezza insufficientemente dettagliate

RFC 7208:

  • Aggiunti avvertimenti di sicurezza sulle stringhe di spiegazione esterne
  • Raccomandazione di limitare la lunghezza delle stringhe di spiegazione
  • Enfasi sulla necessità di identificare le spiegazioni come provenienti da terze parti

B.2 Cambiamenti dei requisiti di implementazione

B.2.1 Cambiamenti MUST (Deve essere implementato)

Nuovi requisiti:

  1. Le implementazioni devono interrogare solo record TXT (non più SPF RR)
  2. Le implementazioni devono limitare il numero totale di query DNS a 10
  3. Le implementazioni devono gestire il limite "void lookup"
  4. Le implementazioni devono restituire "permerror" in caso di superamento dei limiti

Requisiti rimossi:

  1. Supporto del tipo RR SPF non più necessario
  2. Logica di conversione per record a doppio tipo non più necessaria

B.2.2 Cambiamenti SHOULD (Dovrebbe essere implementato)

Nuove raccomandazioni:

  1. Dovrebbe implementare timeout di valutazione (almeno 20 secondi)
  2. Dovrebbe limitare "void lookup" a 2
  3. Dovrebbe verificare le identità HELO e MAIL FROM
  4. Dovrebbe effettuare la verifica durante la transazione SMTP

B.2.3 Cambiamenti MAY (Può essere implementato)

Nuove opzioni:

  1. Può utilizzare algoritmi non canonici (purché i risultati siano identici)
  2. Può configurare il limite "void lookup"
  3. Può limitare la lunghezza delle stringhe di spiegazione

B.3 Cambiamenti di terminologia

B.3.1 Standardizzazione dei nomi delle identità

RFC 4408:

  • Utilizzava più nomi: "MAIL FROM", "SMTP MAIL FROM", "reverse-path"
  • Terminologia incoerente

RFC 7208:

  • Utilizzo uniforme dell'identità "MAIL FROM"
  • Definizione chiara come RFC5321.MailFrom
  • Riferimento alla terminologia standard RFC 5598

B.3.2 Adozione della terminologia "ADMD"

RFC 4408:

  • Utilizzava "domain owner", "sending domain"

RFC 7208:

  • Adozione di "ADMD" (Administrative Management Domain)
  • Descrizione più precisa della parte responsabile

B.4 Miglioramento delle considerazioni di sicurezza

B.4.1 Nuovi argomenti di sicurezza

  1. Contraffazione tra utenti (Sezione 11.4):

    • Non coperto in RFC 4408
    • RFC 7208 discute esplicitamente i problemi di contraffazione degli utenti intra-dominio
  2. Esposizione della privacy (Sezione 11.6):

    • Le macro nelle query DNS possono divulgare informazioni sensibili
    • Raccomandazione di utilizzare con cautela le macro contenenti informazioni sul mittente
  3. Fonti di informazioni non attendibili (Sezione 11.5):

    • Discussione dettagliata dei rischi di intestazioni e spiegazioni esterne
    • Enfasi sull'importanza della validazione e del filtraggio

B.4.2 Rafforzamento della protezione DoS

RFC 4408:

  • Limiti di query di base

RFC 7208:

  • Meccanismi di protezione a più livelli
  • Valori limite chiari
  • Raccomandazioni di timeout
  • Limite "void lookup"

B.5 Cambiamenti di registrazione IANA

B.5.1 Tipo RR SPF

RFC 4408:

  • Registrazione del tipo RR SPF (tipo 99)

RFC 7208:

  • Tipo RR SPF contrassegnato come obsoleto
  • Raccomandazione di utilizzare solo record TXT

B.5.2 Registro dei modificatori

Nuovo RFC 7208:

  • Creazione del registro dei modificatori SPF
  • Processo di registrazione standardizzato per nuovi modificatori
  • Requisito che i modificatori sconosciuti devono essere ignorati

B.6 Miglioramenti dell'interoperabilità

B.6.1 Chiarimento della selezione dei record

RFC 4408:

  • Gestione di più record poco chiara

RFC 7208:

  • Specifica chiara: più record SPF portano a "permerror"
  • Regole migliorate di corrispondenza delle stringhe di versione
  • Chiarimento delle regole di concatenazione dei record (stringhe multiple)

B.6.2 Standardizzazione della gestione degli errori

Miglioramenti RFC 7208:

  • Tutte le situazioni di errore hanno risultati chiari
  • Gestione standardizzata degli errori DNS
  • Miglioramento della gestione dei timeout

B.7 Retrocompatibilità

B.7.1 Cambiamenti compatibili

La maggior parte dei cambiamenti sono retrocompatibili:

  • Formato record TXT invariato
  • Sintassi dei meccanismi e modificatori essenzialmente identica
  • Algoritmo di base rimane coerente

B.7.2 Cambiamenti che possono influire sulla compatibilità

  1. Rimozione del tipo RR SPF:

    • Le vecchie implementazioni potrebbero ancora interrogare SPF RR
    • Raccomandazione: Rimuovere i record SPF RR, mantenere solo TXT
  2. Limiti più rigorosi:

    • Il limite "void lookup" è appena aggiunto
    • Alcuni vecchi record potrebbero superare i nuovi limiti
    • Raccomandazione: Ottimizzare i record SPF per rispettare i limiti
  3. Opposizione al meccanismo "ptr":

    • Deve ancora essere supportato ma fortemente sconsigliato
    • Raccomandazione: Migrare ad altri meccanismi

B.8 Cambiamenti della struttura del documento

Miglioramenti RFC 7208:

  • Organizzazione dei capitoli più chiara
  • Esempi estesi aggiunti (Appendice A)
  • Raccomandazioni di implementazione aggiunte (Appendici C-G)
  • Presentazione migliorata delle definizioni ABNF

B.9 Guida alla migrazione

Migrazione da RFC 4408 a RFC 7208:

Editori:

  1. Rimuovere i record SPF RR, mantenere solo i record TXT
  2. Verificare e ottimizzare il numero di query DNS (≤ 10)
  3. Sostituire il meccanismo "ptr" con "ip4" o "ip6"
  4. Validare il numero di "void lookup" (≤ 2)
  5. Testare se i record superano 512 ottetti

Destinatari:

  1. Smettere di interrogare il tipo SPF RR
  2. Implementare i nuovi limiti di query DNS
  3. Implementare il limite "void lookup"
  4. Aggiornare la logica di gestione degli errori
  5. Considerare l'implementazione del timeout di valutazione

Test:

# Utilizzare uno strumento di validazione SPF per testare i record
# Ad esempio: https://www.kitterman.com/spf/validate.html

# Verificare il numero di query DNS
dig +short example.com TXT | grep "v=spf1"

# Validare la dimensione del record
dig example.com TXT | grep -A1 "ANSWER SECTION"

B.10 Aggiornamento dei documenti di riferimento

RFC 7208 fa riferimento a standard aggiornati:

  • RFC 5321 (sostituisce RFC 2821)
  • RFC 5322 (sostituisce RFC 2822)
  • RFC 5234 (aggiornamento ABNF)
  • RFC 5598 (terminologia dell'architettura di posta)
  • RFC 5890 (nomi di dominio internazionalizzati)