Passa al contenuto principale

Appendix D. SPF/Mediator Interactions (Interazioni SPF/Mediatore)

Appendix D. SPF/Mediator Interactions (Interazioni SPF/Mediatore)

Questa appendice discute l'interazione tra SPF e mediatori di posta (come mailing list e servizi di inoltro) e i loro impatti.

D.1 Originating ADMDs (ADMD di origine)

L'ADMD di origine è il dominio amministrativo che invia inizialmente la posta. In presenza di mediatori, l'ADMD di origine deve considerare i servizi di inoltro e lista attraverso cui le sue mail possono passare.

D.1.1 Identificazione del problema

Presupposto base SPF:

  • Le mail vengono inviate direttamente dai server autorizzati ai destinatari
  • L'identità MAIL FROM rimane invariata
  • L'indirizzo IP mittente è autorizzato nel record SPF

Presupposti infranti dai mediatori:

  • Le mail passano attraverso sistemi intermedi
  • Possono essere rinviate da un indirizzo IP diverso
  • MAIL FROM può essere modificato o rimanere invariato

D.1.2 Scelte per il mittente

Opzione 1: Utilizzare una politica SPF permissiva

example.com IN TXT "v=spf1 mx ~all"

Vantaggi:

  • Consente l'inoltro legittimo
  • Riduce i falsi positivi

Svantaggi:

  • Indebolisce la protezione SPF
  • Più facile da falsificare

Opzione 2: Affidarsi ad altri metodi di autenticazione

Pubblicare firme DKIM:
- DKIM rimane valido durante l'inoltro
- Indipendente dall'indirizzo IP mittente
- Funziona con DMARC

Opzione 3: Accettare i fallimenti SPF

example.com IN TXT "v=spf1 mx -all"
  • Accettare che alcune mail legittime possano essere contrassegnate o rifiutate
  • Fare affidamento sugli utenti per utilizzare il metodo di invio corretto
  • Raccomandare agli utenti di non inoltrare ma di usare "Invia copia"

D.1.3 Migliori pratiche

Configurazione raccomandata:

1. Pubblicare un record SPF rigoroso (-all)
2. Implementare simultaneamente la firma DKIM
3. Pubblicare una politica DMARC
4. Educare gli utenti sui problemi di inoltro

Esempio di configurazione DMARC:

_dmarc.example.com IN TXT "v=DMARC1; p=quarantine; sp=quarantine; adkim=r; aspf=r; pct=100; rua=mailto:[email protected]"

Spiegazione dei parametri:

  • adkim=r: Allineamento DKIM rilassato
  • aspf=r: Allineamento SPF rilassato
  • p=quarantine: Mettere in quarantena in caso di fallimento

D.2 Mediators (Mediatori)

I mediatori sono sistemi che modificano o reinviano mail nella catena di trasmissione. I mediatori comuni includono mailing list, servizi di inoltro e sistemi di risposta automatica.

D.2.1 Mailing list

Problema:

Le mailing list tradizionali conservano il MAIL FROM originale:

Originale: MAIL FROM:`<[email protected]>`
Dopo lista: MAIL FROM:`<[email protected]>`
IP mittente: list-server.mailinglist.org

Verifica SPF:

Interrogare il record SPF di example.com
Verificare l'IP di list-server.mailinglist.org
Risultato: fail (IP non è nel record SPF di example.com)

D.2.2 Soluzioni

Soluzione 1: Riscrivere MAIL FROM (raccomandato)

Riscritto: MAIL FROM:`<[email protected]>`
Reply-To: [email protected]

Vantaggi:

  • La verifica SPF ha successo
  • I rimbalzi tornano al server di lista
  • Il destinatario può identificare correttamente

Svantaggi:

  • Modifica le informazioni del mittente originale
  • Gli utenti devono adattarsi a Reply-To

Esempio di implementazione (Mailman):

# Configurazione Mailman
from_is_list = 2 # Munge From, add Reply-To

Soluzione 2: Utilizzare SRS (Sender Rewriting Scheme)

SRS è uno schema di riscrittura più complesso:

Originale: [email protected]
Riscritto in: [email protected]

Formato SRS:

SRS0=<hash>=<timestamp>=<domain>=<localpart>@<forwarder>

Esempio:
[email protected]

Vantaggi:

  • Preserva le informazioni del mittente originale (nel local-part)
  • La verifica SPF ha successo
  • Può essere tracciato e verificato

Svantaggi:

  • Implementazione complessa
  • Necessita di un database SRS
  • Il local-part diventa difficile da leggere

Soluzione 3: Utilizzare DKIM invece di SPF

Configurazione:

1. Il mittente originale utilizza la firma DKIM
2. Il server di lista conserva la firma originale
3. Il server di lista aggiunge la propria firma DKIM
4. Il destinatario verifica DKIM (ignora il fallimento SPF)

Configurazione DMARC:

_dmarc.example.com IN TXT "v=DMARC1; p=none; adkim=r; aspf=r"
  • p=none: Nessuna applicazione (consente il fallimento SPF)
  • adkim=r: Allineamento DKIM rilassato (consente la firma di lista)

D.2.3 Servizi di inoltro posta

Tipo 1: Inoltro semplice

Configurazione utente: [email protected][email protected]
Il servizio di inoltro conserva: MAIL FROM:`<[email protected]>`
Invia dall'IP del server di inoltro

Problema SPF:

Gmail verifica SPF di original.com
L'IP del server di inoltro non è nel record SPF
Risultato: fail

Soluzione A: Riscrittura SRS

Il servizio di inoltro utilizza SRS:
MAIL FROM:<[email protected]>

Soluzione B: Utilizzare ~all invece di -all

original.com IN TXT "v=spf1 mx ~all"

Le mail inoltrate otterranno softfail invece di fail, più probabilmente accettate.

Tipo 2: File .forward

# ~/.forward
[email protected]

Problema identico all'inoltro semplice.

Migliori pratiche:

1. I servizi di inoltro dovrebbero implementare SRS
2. Il mittente originale dovrebbe utilizzare DKIM
3. I destinatari dovrebbero considerare i risultati DKIM, non solo SPF

D.2.4 Sistemi di risposta automatica e notifica

Problema:

Mail originale: [email protected][email protected]
Risposta automatica: MAIL FROM:`<[email protected]>`
(Inviata dal server company.com)

La verifica SPF fallirà.

Soluzione:

Inviare notifiche con MAIL FROM vuoto:
MAIL FROM:<>
From: Mail Delivery System `&lt;[email protected]&gt;`

Oppure:

Utilizzare un indirizzo locale:
MAIL FROM:`&lt;[email protected]&gt;`
From: Automatic Reply `&lt;[email protected]&gt;`
Reply-To: [email protected]

D.3 Receiving ADMDs (ADMD destinatari)

L'ADMD destinatario deve gestire le mail provenienti da mediatori e prendere decisioni appropriate.

D.3.1 Identificazione delle mail di mediatori

Identificatori:

1. Salti intermedi nelle intestazioni Received
2. Intestazioni List-* (mailing list)
3. Precedence: bulk o list
4. MAIL FROM in formato SRS
5. Firma DKIM da servizio di lista noto

Esempio di logica di rilevamento:

def is_mailing_list(message):
# Verificare intestazioni List-*
list_headers = [
'List-Id', 'List-Post', 'List-Unsubscribe',
'List-Help', 'List-Subscribe', 'List-Owner'
]

for header in list_headers:
if message.get(header):
return True

# Verificare Precedence
if message.get('Precedence') in ['bulk', 'list']:
return True

# Verificare SRS
mail_from = message.get('Return-Path', '')
if mail_from.startswith('SRS0=') or mail_from.startswith('SRS1='):
return True

return False

D.3.2 Raccomandazioni di politica

Politica 1: Trattamento permissivo delle mail di lista

if is_mailing_list(message):
if spf_result == 'fail':
# Verificare DKIM
if dkim_result == 'pass':
accept_message()
else:
# Verificare la reputazione della lista
if list_is_trusted(list_id):
accept_message()
else:
quarantine_message()

Politica 2: Affidarsi a DMARC

if dmarc_result == 'pass':
accept_message()
elif spf_result == 'fail' and dkim_result == 'fail':
reject_message()
else:
# SPF o DKIM ha successo
if is_mailing_list(message):
accept_message()
else:
apply_content_filtering()

Politica 3: Regole specifiche dell'utente

Gli utenti possono configurare whitelist:
- Mailing list affidabili
- Indirizzi di inoltro noti
- Trattamento permissivo di domini specifici

D.3.3 Raccomandazioni di implementazione

Configurazione SpamAssassin:

# Trattamento permissivo delle mailing list
header LIST_ID exists:List-Id
score LIST_ID -0.1

# SPF fail ma con intestazione List-Id
meta SPF_FAIL_LIST (SPF_FAIL && LIST_ID)
score SPF_FAIL_LIST 0.5

# SPF fail normale (senza intestazione di lista)
score SPF_FAIL 5.0

Configurazione Postfix:

# smtpd_recipient_restrictions
reject_unauth_destination,
check_policy_service unix:private/spf-policy,
permit

# Il servizio di politica SPF può identificare le mail di lista e adattarsi

Configurazione rspamd:

-- Configurazione modulo SPF
spf {
-- Applicare peso diverso per le mailing list
symbol_fail = "R_SPF_FAIL";
symbol_softfail = "R_SPF_SOFTFAIL";

-- Regole personalizzate
custom_symbols = {
R_SPF_FAIL_LIST = {
score = 2.0,
description = "SPF failed but from mailing list",
condition = function(task)
local spf = task:get_symbol('R_SPF_FAIL')
local list_id = task:get_header('List-Id')
return spf and list_id
end
}
}
}

D.4 Raccomandazioni di interoperabilità

D.4.1 Standardizzazione

Utilizzare intestazioni standard:

Le mailing list dovrebbero aggiungere:
- List-Id: &lt;list-name.domain.com>
- List-Post: &lt;mailto:[email protected]>
- List-Unsubscribe: &lt;mailto:[email protected]>
- Precedence: bulk

Firma DKIM:

I server di lista dovrebbero:
1. Conservare la firma DKIM originale (se presente)
2. Aggiungere la propria firma DKIM
3. Non modificare le intestazioni firmate

D.4.2 Comunicazione

Notifica del mittente:

Il servizio di lista dovrebbe informare gli iscritti:
- Le mail saranno rinviate dal server di lista
- MAIL FROM sarà riscritto
- Raccomandazione di utilizzare Reply-To per rispondere alla lista

Documentazione del destinatario:

Documentare le politiche di ricezione:
- Come vengono trattate le mail di lista
- Meccanismo di whitelist
- Opzioni configurabili dall'utente

D.5 Direzione dello sviluppo futuro

D.5.1 ARC (Authenticated Received Chain)

RFC 8617 ha introdotto ARC:

ARC consente ai mediatori di aggiungere informazioni di autenticazione:
- ARC-Seal: Firma del mediatore
- ARC-Message-Signature: Firma del messaggio
- ARC-Authentication-Results: Risultati di autenticazione

Esempio:

ARC-Seal: i=1; a=rsa-sha256; t=1234567890; cv=none;
d=mailinglist.org; s=arc-seal; b=...
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=mailinglist.org; s=arc-msg; h=from:to:subject; b=...
ARC-Authentication-Results: i=1; mailinglist.org;
spf=pass [email protected];
dkim=pass header.d=example.com

Vantaggi:

  • Preserva i risultati di autenticazione originali
  • Consente la verifica a catena
  • I destinatari possono fidarsi dei mediatori

D.5.2 Raccomandazioni

Per le nuove distribuzioni:

  1. Implementare DKIM e SPF
  2. Pubblicare una politica DMARC
  3. Considerare il supporto ARC (se mediatore)
  4. Testare l'interoperabilità con le mailing list comuni

Per i sistemi esistenti:

  1. Esaminare la rigidità delle politiche SPF
  2. Monitorare i rapporti DMARC
  3. Identificare le fonti problematiche (liste, inoltri, ecc.)
  4. Adattare le politiche o implementare SRS