Passa al contenuto principale

7. Considerazioni sulla sicurezza (Security Considerations)

7.1. Sicurezza della posta e spoofing (Mail Security and Spoofing)​

La posta SMTP non è intrinsecamente sicura a causa di: Mancanza di meccanismi di autenticazione integrati, facilità di spoofing degli indirizzi mittente, assenza di crittografia nel protocollo base. Protocolli aggiuntivi come SPF, DKIM e DMARC aiutano a mitigare lo spoofing.

7.2. Copie "cieche" ("Blind" Copies)​

I destinatari BCC (Blind Carbon Copy, Copia Carbone Cieca) NON DEVONO (MUST NOT) apparire negli header del messaggio. Questo è generalmente gestito creando transazioni SMTP separate per i destinatari BCC o rimuovendo i campi header BCC prima dell'invio.

7.3. VRFY, EXPN e sicurezza (VRFY, EXPN, and Security)​

I comandi VRFY ed EXPN possono essere utilizzati per raccogliere indirizzi e-mail validi. I server POSSONO (MAY): Disabilitare questi comandi, richiedere autenticazione prima dell'uso, restituire risposte generiche.

7.4. Reindirizzamento della posta basato sui codici di risposta 251 e 551 (Mail Rerouting Based on the 251 and 551 Response Codes)​

I codici di risposta 251 e 551 possono essere sfruttati. I server DOVREBBERO (SHOULD) essere cauti con l'inoltro automatico e le informazioni divulgate in queste risposte.

7.5. Divulgazione di informazioni negli annunci (Information Disclosure in Announcements)​

I saluti del server (risposta 220) e le risposte EHLO NON DOVREBBERO (SHOULD NOT) divulgare informazioni dettagliate sulla versione del software, architettura di sistema interna o dettagli di configurazione della sicurezza.

7.6. Divulgazione di informazioni nei campi di traccia (Information Disclosure in Trace Fields)​

I campi header Received contengono indirizzi IP, nomi host, informazioni temporali e topologia di rete interna. Queste informazioni possono essere utilizzate per mappatura di rete, analisi del traffico e identificazione dell'infrastruttura di sicurezza.

7.7. Divulgazione di informazioni nell'inoltro messaggi (Information Disclosure in Message Forwarding)​

Quando si inoltrano messaggi, i server DOVREBBERO (SHOULD): Evitare di divulgare indirizzi interni, sanificare informazioni di traccia quando si attraversano confini di fiducia, considerare le implicazioni sulla privacy dell'inoltro automatico.

7.8. Resistenza agli attacchi (Resistance to Attacks)​

I server SMTP DOVREBBERO (SHOULD) implementare protezioni contro le seguenti classi di attacco:

Denial of Service (DoS)​

  • Limiti di connessione per sorgente
  • Rate limiting
  • Limiti al consumo di risorse
  • Applicazione dei timeout

Buffer overflow​

  • Validazione rigorosa dell'input
  • Applicazione dei limiti di lunghezza
  • Gestione sicura delle stringhe

Iniezione di comandi​

  • Parsing corretto dei comandi
  • Validazione degli argomenti
  • Rifiuto di input malformati

Attacchi Directory Harvest​

  • Rate limiting dei comandi RCPT TO
  • Risposte ritardate o generiche
  • Registrazione e blocco dei comportamenti di scansione

7.9. Ambito di operazione dei server SMTP (Scope of Operation of SMTP Servers)​

I server SMTP DOVREBBERO (SHOULD) definire chiaramente il loro ambito operativo, implementare controlli di accesso appropriati e distinguere tra submission interna dei messaggi, relay esterno dei messaggi e consegna finale dei messaggi. I relay aperti (open relay), cioè server che accettano e inoltrano posta da chiunque verso qualunque destinazione, NON DEVONO (MUST NOT) essere distribuiti, perché abilitano la distribuzione di spam, facilitano abusi e danneggiano l'infrastruttura della posta Internet.

Pratiche di sicurezza raccomandate​

  1. Usare TLS/STARTTLS
  2. Implementare autenticazione (SMTP AUTH)
  3. Distribuire SPF/DKIM/DMARC
  4. Rate limiting
  5. Controlli di accesso
  6. Logging
  7. Aggiornamenti regolari
  8. Monitoraggio
Ultimo aggiornamento il