Passa al contenuto principale

6. Rilevamento e gestione dei problemi (Problem Detection and Handling)

Questa sezione tratta il modo in cui le implementazioni SMTP dovrebbero gestire vari problemi che si presentano durante la trasmissione della posta.

6.1. Consegna affidabile e risposte via email​

Notifiche di stato della consegna (DSN)​

Quando la posta non può essere consegnata, il sistema mittente dovrebbe generare una Delivery Status Notification, cioè un messaggio di rimbalzo, per informare il mittente.

Requisiti DSN:

  • devono essere inviate al reverse-path, cioè all'indirizzo MAIL FROM (MUST);
  • devono usare un reverse-path nullo (MAIL FROM:<>) per prevenire cicli (MUST);
  • dovrebbero includere il messaggio originale o gli header (SHOULD);
  • dovrebbero specificare il motivo del fallimento (SHOULD).

Esempio di messaggio di rimbalzo:

From: [email protected]
To: [email protected]
Subject: Undelivered Mail Returned to Sender

Your message to [email protected] could not be delivered:

  550 5.1.1 Mailbox does not exist

--- Original message headers follow ---
From: [email protected]
To: [email protected]
Subject: Important message
...

Notifiche di successo​

Le notifiche di consegna riuscita generalmente non vengono inviate, poiché creano traffico aggiuntivo. Tuttavia, l'estensione DSN consente richieste esplicite di conferma positiva della consegna.

Timeout e ritentativi​

Pianificazione dei ritentativi:

  • fallimento iniziale: riprovare dopo 30 minuti;
  • fallimenti successivi: backoff esponenziale, ad esempio 1 ora, 2 ore, 4 ore, ecc.;
  • periodo massimo di ritentativo: almeno 4-5 giorni;
  • fallimento finale: inviare un rimbalzo al mittente.

Messaggi di avviso:

  • dopo 4-6 ore: inviare un avviso di ritardo al mittente;
  • includere il motivo del ritardo;
  • informare il mittente che i tentativi di consegna continuano.

6.2. Messaggi indesiderati, non sollecitati e di "attacco"​

I server SMTP dovrebbero implementare protezioni contro gli abusi.

Prevenzione dello spam​

Tecniche:

  1. Verifica del destinatario: verificare che il destinatario esista prima di accettare posta.
  2. Verifica del mittente: controllare SPF, DKIM e DMARC.
  3. Rate limiting: limitare messaggi per connessione o per ora.
  4. Greylisting: rifiutare temporaneamente mittenti al primo contatto.
  5. Filtraggio del contenuto: analizzare il contenuto del messaggio per pattern di spam.
  6. Sistemi di reputazione: tracciare la reputazione del mittente.

Protezione Denial of Service (DoS)​

Difese:

  1. Limiti di connessione: limitare le connessioni concorrenti da un singolo IP.
  2. Rate limiting: limitare i comandi al secondo.
  3. Tarpit: rallentare mittenti sospetti.
  4. Limiti di risorse: limitare uso di CPU e memoria per connessione.
  5. Applicazione dei timeout: disconnettere connessioni inattive.

Attacchi Directory Harvest (DHA)​

Gli attaccanti inviano comandi RCPT TO con indirizzi indovinati per scoprire caselle postali valide.

Contromisure:

Vulnerabile:
C: RCPT TO:``&lt;[email protected]&gt;``
S: 550 No such user        (rivela che non è valido)
C: RCPT TO:``&lt;[email protected]&gt;``
S: 250 Ok                  (rivela che è valido)

Protetto:
- ritardare le risposte ai comandi RCPT
- usare la stessa risposta per valido e non valido, per esempio sempre "250 Ok"
- verificare il destinatario solo durante o dopo DATA
- limitare i comandi RCPT

Prevenzione del backscatter​

Backscatter: rimbalzi inviati ad indirizzi mittente falsificati, creando spam collaterale.

Prevenzione:

  1. Rifiutare durante SMTP: rifiutare destinatari non validi durante la transazione SMTP, prima di DATA.
  2. Verificare il mittente: non accettare posta da mittenti falsificati.
  3. Non generare rimbalzi: per posta da fonti sconosciute o sospette.
Buona pratica:
C: RCPT TO:``&lt;[email protected]&gt;``
S: 550 5.1.1 User unknown    (rifiutare immediatamente)

Cattiva pratica:
C: RCPT TO:``&lt;[email protected]&gt;``
S: 250 Ok                    (accettare la posta)
(generare in seguito un rimbalzo verso un mittente falsificato)

6.3. Rilevamento dei cicli​

I cicli di posta si verificano quando i messaggi vengono inoltrati ripetutamente attraverso gli stessi server.

Metodi di rilevamento​

Metodo 1: conteggio degli header Received

Contare gli header Received nel messaggio
Se conteggio > 100:
  rifiutare con "554 5.4.6 Too many hops"

Metodo 2: analisi degli header Received

Analizzare gli header Received
Controllare se il server corrente appare più volte
Se sì:
  rilevare il ciclo e rifiutare

Metodo 3: tracciamento Message-ID

Ricordare i Message-ID dei messaggi elaborati di recente
Se lo stesso Message-ID viene visto di nuovo in breve tempo:
  probabilmente è un ciclo, rifiutare

Prevenzione dei cicli​

Buone pratiche:

  1. Limitare gli hop: rifiutare dopo 50-100 header Received.
  2. Rilevare pattern: identificare nomi di server ripetuti nelle tracce.
  3. Interrompere i cicli: non inoltrare posta che sembra in ciclo.
  4. Rivedere la configurazione: evitare regole di inoltro che creano cicli.

Esempio di ciclo:

mail.a.example -> mail.b.example ->
mail.c.example -> mail.a.example (loop!)

6.4. Compensazione delle irregolarità​

Le implementazioni SMTP reali talvolta deviano dagli standard. Implementazioni robuste dovrebbero gestire con grazia le irregolarità comuni.

Irregolarità comuni​

1. Spazi aggiuntivi​

Alcune implementazioni inviano spazi aggiuntivi:

Non standard:
C: MAIL  FROM: ``&lt;[email protected]&gt;``    (extra spaces)

Gestione robusta:
Accettare e analizzare correttamente

2. Comandi con maiuscole/minuscole miste​

Non standard:
C: Mail From:``&lt;[email protected]&gt;``

Gestione robusta:
Trattare come non sensibile a maiuscole/minuscole

3. Parentesi angolari mancanti​

Alcuni vecchi sistemi omettono <> intorno agli indirizzi:

Non standard:
C: MAIL FROM:[email protected]

Gestione robusta:
Accettare sia con sia senza parentesi angolari

4. Solo CR o LF, non CRLF​

Lo standard richiede CRLF (\r\n), ma alcuni inviano solo LF (\n) o CR (\r):

Gestione robusta:
Accettare CR, LF o CRLF come terminatore di riga
(ma inviare sempre CRLF)

5. Linee lunghe​

Alcune implementazioni inviano linee oltre i limiti:

Gestione robusta:
- Accettare righe più lunghe di 512 ottetti
- Suddividere internamente se necessario
- Non interrompere durante la transazione SMTP

Principio di robustezza​

"Sii conservativo in ciò che invii, liberale in ciò che accetti."

  • Inviare: conformarsi strettamente agli standard.
  • Ricevere: accettare con grazia deviazioni minori.
  • Registrare: annotare il comportamento non standard.
  • Non fare: correggere e inoltrare silenziosamente, perché mantiene problemi di interoperabilità.

Recupero dagli errori​

Quando si incontrano irregolarità:

Opzione 1: accettare e procedere

Registrare un avviso
Elaborare normalmente il messaggio

Opzione 2: accettare con notifica

Registrare un avviso
Elaborare il messaggio
Inviare al postmaster una DSN sul problema

Opzione 3: rifiutare

Solo per violazioni gravi
Fornire un messaggio di errore chiaro
Registrare per analisi

Test di conformità​

Gli implementatori dovrebbero testare contro:

  • server conformi agli standard: verificare il funzionamento corretto;
  • implementazioni note come difettose: assicurare interoperabilità;
  • input malformati: testare la gestione degli errori;
  • casi limite: condizioni al bordo e scenari insoliti.
Ultimo aggiornamento il