10. Altri Argomenti

Questa sezione tratta vari argomenti relativi alla distribuzione e al funzionamento di DMARC.

10.1. Problemi Specifici di SPF

SPF presenta alcuni problemi quando utilizzato con DMARC di cui i proprietari di domini e i ricevitori di posta devono essere consapevoli:

Autenticazione solo SPF: Se un proprietario di dominio pubblica solo una policy SPF e non una policy DKIM, tutti gli inoltri di posta elettronica (dove il dominio RFC5321.MailFrom cambia) causeranno errori di Identifier Alignment.
Mailing List: Molte mailing list utilizzano il dominio dell'autore originale nel campo RFC5322.From ma cambiano il dominio RFC5321.MailFrom con il proprio. Questo rompe l'Identifier Alignment SPF.
Forwarder: Il semplice inoltro (dove un utente inoltra la posta a un altro indirizzo) non cambia il dominio RFC5321.MailFrom ma può causare errori SPF perché l'indirizzo IP del server di inoltro non è elencato nel record SPF del dominio originale.

Gli implementatori di DMARC devono essere consapevoli delle seguenti considerazioni relative al DNS:

Volume di query: I ricevitori di posta interrogheranno il DNS per i record DMARC per ogni messaggio sottoposto a valutazione DMARC. I ricevitori ad alto volume devono implementare strategie di caching appropriate.
Caching: I record DNS per le policy DMARC devono essere memorizzati nella cache secondo i loro valori TTL (Time To Live). I proprietari di domini devono impostare valori TTL appropriati:
- TTL brevi (es. 300 secondi) durante il rollout o le modifiche delle policy
- TTL più lunghi (es. 86400 secondi) per policy stabili
Caching negativo: L'assenza di un record DMARC deve essere memorizzata nella cache secondo il TTL della cache negativa del record SOA.

Quando una policy DMARC indica che un messaggio deve essere rifiutato, i ricevitori di posta devono considerare quanto segue:

Rifiuto SMTP vs. Post-SMTP:
- Il rifiuto SMTP (durante la transazione SMTP) è preferito perché fornisce feedback immediato all'MTA mittente e non richiede la generazione di un messaggio di rimbalzo.
- Il rifiuto Post-SMTP (dopo aver accettato il messaggio) deve essere evitato poiché può portare al backscatter.
Codici di rifiuto: Quando si rifiuta durante SMTP, utilizzare codici di risposta SMTP 5xx appropriati. Un messaggio appropriato potrebbe essere:
```
550 5.7.1 Message rejected per DMARC policy for example.com
```
Notifica utente: Considerare se notificare gli utenti legittimi se i loro messaggi vengono rifiutati a causa di errori DMARC.

Diverse considerazioni si applicano all'Identifier Alignment:

Alignment dei sottodomini: In modalità relaxed, i sottodomini sono considerati allineati. I proprietari di domini devono essere consapevoli che ciò significa che la posta da qualsiasi sottodominio sarà considerata allineata se SPF o DKIM passa per il dominio organizzativo.
Mittenti di terze parti: Quando si utilizzano servizi di posta elettronica di terze parti, i proprietari di domini devono garantire che:
- La terza parte possa inviare messaggi firmati DKIM con il dominio del proprietario del dominio nel tag "d=", OPPURE
- Gli indirizzi IP di invio della terza parte siano inclusi nel record SPF del proprietario del dominio e il dominio RFC5321.MailFrom possa essere impostato per allinearsi
Fonti di invio multiple: I proprietari di domini con più fonti di invio (server di posta interni, servizi di email marketing, sistemi CRM, ecc.) devono garantire che tutte le fonti possano produrre messaggi allineati.

La distribuzione di DMARC può causare problemi di interoperabilità con alcune pratiche di posta elettronica:

Mailing List:
- Problema: Le liste spesso modificano i messaggi (aggiunta di footer, tag del soggetto, ecc.) che rompe le firme DKIM
- Soluzioni:
  - Le liste possono ri-firmare i messaggi con la propria firma DKIM
  - Le liste possono riscrivere l'indirizzo RFC5322.From (ma questo cambia il mittente apparente)
  - I proprietari di domini possono utilizzare una policy più rilassata per i domini utilizzati sulle mailing list
Inoltro:
- Problema: L'inoltro rompe SPF (l'IP del server di inoltro non è autorizzato)
- Soluzioni:
  - Fare affidamento su DKIM (che sopravvive all'inoltro se il contenuto non è modificato)
  - I forwarder possono implementare SRS (Sender Rewriting Scheme)
Flussi di posta indiretti: Qualsiasi flusso di posta in cui i messaggi vengono modificati o inoltrati attraverso intermediari può avere problemi DMARC. Vedere [DMARC-INDIRECT] per una discussione dettagliata.
Messaggi di notifica: I sistemi di notifica automatizzati devono essere configurati per utilizzare identificatori allineati o potrebbero dover utilizzare un dominio di policy "p=none".