SMTP - Simple Mail Transfer Protocol

Cosa fa

#

SMTP è il protocollo che trasporta le email dal client al server e tra server — si occupa solo della consegna, non dello storage (quello è IMAP/POP3).

TL;DR

#

SMTP  → consegna (postino)        porta 25 server-to-server, 587 client-to-server
IMAP  → leggi le email (cassetta) porta 993
POP3  → scarica le email          porta 995

SMTP non sa nulla della cassetta delle lettere.
Consegna e sparisce.

Analogia postale

#

Mittente                Ufficio postale locale     Ufficio postale remoto     Destinatario
(scrive la lettera) --> (smista per zona)       --> (smista localmente)    --> (cassetta)

Stesso dominio (local delivery):
  Mittente --> MTA locale --> cassetta destinatario

Domini diversi (outside delivery):
  Mittente --> MTA mittente --> MTA destinatario --> cassetta destinatario

Architettura — MUA e MTA

#

Dal punto di vista network-defense interessa solo la coppia MUA → MTA e MTA → MTA.

Flusso stesso dominio:

MUA (user1@abc.com)  --SMTP 587-->  MTA (abc.com)  --IMAP/POP3-->  MUA (user2@abc.com)

Flusso domini diversi:

MUA (user1@abc.com)  --SMTP 587-->  MTA (abc.com)  --SMTP 25-->  MTA (xyz.com)  --IMAP/POP3-->  MUA (user2@xyz.com)

Porte SMTP

#

SMTP in chiaro — cosa si vede in Wireshark

#

SMTP senza TLS è completamente leggibile in dfir. Una sessione tipica:

Client: EHLO mittente.com
Server: 250-smtp.destinatario.com Hello
Server: 250-STARTTLS
Server: 250 OK

Client: MAIL FROM:<user1@abc.com>
Server: 250 OK

Client: RCPT TO:<user2@xyz.com>
Server: 250 OK

Client: DATA
Server: 354 Start input, end with <CRLF>.<CRLF>

Client: From: user1@abc.com
        To: user2@xyz.com
        Subject: Test
        [corpo email]
        .
Server: 250 OK: queued

Client: QUIT
Server: 221 Bye

DNS MX — stesso meccanismo del DNS web

#

I record MX funzionano esattamente come i record A per il web — stessa catena resolver → root → TLD → authoritative NS. L'unica differenza:

# Web: record A → IP diretto
dig A gmail.com → 142.250.x.x

# Email: record MX → hostname, poi serve seconda query A
dig MX gmail.com → gmail-smtp-in.l.google.com (priority 5)
dig A gmail-smtp-in.l.google.com → 142.250.x.x

I record MX hanno una priority — numero più basso = preferito. Se il server primario è down, il MTA prova il successivo in ordine di priorità. È un failover nativo del protocollo.

dig MX gmail.com
# gmail-smtp-in.l.google.com      priority 5   ← primo tentativo
# alt1.gmail-smtp-in.l.google.com priority 10
# alt2.gmail-smtp-in.l.google.com priority 20
# alt3.gmail-smtp-in.l.google.com priority 30

Flusso completo in dfir — 3 step

#

Step 1 — Client → MTA locale (porta 587)

#

Sequenza comandi nel TCP stream:

220 mail01 ESMTP Postfix (Ubuntu)        ← server annuncia identità e software
EHLO [172.16.16.225]                     ← client si presenta con IP
250-STARTTLS                             ← server lista feature supportate
250-SIZE 10240000
250-VRFY
...
MAIL FROM:<user1@skynet.local> SIZE=556  ← mittente + dimensione
250 2.1.0 Ok
RCPT TO:<user2@cyberdyne.local>          ← destinatario
250 2.1.5 Ok
DATA                                     ← inizio trasmissione body
354 End data with <CR><LF>.<CR><LF>     ← server pronto, termina con punto
[headers + body email in chiaro]
.                                        ← fine messaggio
250 2.0.0 Ok: queued as 931C4400D5      ← accettato, in coda
QUIT
221 2.0.0 Bye

User-Agent nel body — dentro il DATA viaggiano header che rivelano il client (Thunderbird/38.5.0, Outlook/...). Dato utile in un'indagine forense.

skynet.local — dominio con .local = rete interna aziendale, non raggiungibile da internet. Tutto il traffico rimane sulla LAN anche se i client usano Outlook o Thunderbird.

Step 2 — MTA locale → MTA remoto (porta 25)

#

Stesso identico protocollo SMTP. Il server non sa se sta parlando con un client o un altro MTA — applica le stesse regole.

Header Received: — traccia forense — ogni MTA che tocca l'email aggiunge una riga in cima al body:

Received: from [172.16.16.225] by mail01 with ESMTP id 931C4400D5
          for <user2@cyberdyne.local>; Tue, 29 Dec 2015 14:13:51 -0500

Leggendo questi header dal basso verso l'alto ricostruisci il percorso completo hop per hop — utile per tracciare phishing o spam.

Feature negotiation tra server — il EHLO/250 permette a server con software diversi (Postfix, Exchange, Sendmail) di capirsi. È il motivo per cui puoi mandare email da Gmail a Outlook senza problemi di compatibilità.

Filtro Wireshark per isolare una connessione specifica:

tcp.stream == 1

Step 3 — MTA remoto → Client finale (IMAP + STARTTLS)

#

Il client recupera l'email con IMAP. La connessione inizia in chiaro, poi:

Pkt 16-18: TCP handshake (porta 143 IMAP)
Pkt 19:    IMAP: * OK [CAPABILITY...] Dovecot ready    ← Dovecot = MDA su Linux
Pkt 21:    IMAP: STARTTLS                               ← client chiede cifratura
Pkt 23:    IMAP: 1 OK Begin TLS negotiation now
Pkt 24-27: TLSv1.2 handshake
Pkt 28+:   Application Data                            ← tutto cifrato

Dovecot — come Postfix è l'MTA, Dovecot è l'MDA/IMAP server su Linux. Compare nel banner iniziale.

Traffico cifrato in Wireshark = rumore — dopo STARTTLS il Follow TCP Stream mostra solo caratteri casuali. È la conferma visiva che TLS funziona. Se una sessione IMAP/SMTP rimane leggibile fino alla fine → misconfiguration.

IMAP vs POP3

#

Email Spoofing — aggiornamento rispetto al libro

#

Il libro (2011) non tratta questo — oggi è fondamentale.

Il campo From: in SMTP è liberamente falsificabile. Chiunque può spedire un'email apparentemente da ceo@azienda.com senza avere accesso a quell'account. I meccanismi difensivi moderni:

# Verifica SPF di un dominio
dig TXT gmail.com | grep spf

# Verifica DKIM (selector specifico)
dig TXT google._domainkey.gmail.com

# Verifica DMARC
dig TXT _dmarc.gmail.com

Allegati SMTP — MIME multipart e base64

#

SMTP nasce per testo. Gli allegati ci sono stati aggiunti dopo con MIME (Multipurpose Internet Mail Extensions) — lo stesso standard che HTTP usa per il Content-Type.

Quando un'email ha un allegato, il Content-Type diventa multipart/mixed con un boundary — una stringa casuale che separa le parti:

Content-Type: multipart/mixed;
  boundary="------------050407080301000500070000"

--------------050407080301000500070000
Content-Type: text/plain; charset=utf-8        ← parte 1: testo email
Content-Transfer-Encoding: 7bit

Testo del messaggio...

--------------050407080301000500070000
Content-Type: image/jpeg; name="newguy.jpg"    ← parte 2: allegato
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="newguy.jpg"

/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAMCAgMCAgMD...  ← dati binari in base64

Concetti chiave:

base64 non è cifratura — è solo un modo per trasmettere dati binari su un canale testuale. Qualsiasi attaccante che intercetta il dfir può estrarre il file in pochi secondi. In Wireshark: Follow TCP Stream → Save as → decodifica base64 → file originale.

MIME boundary — il client sceglie una stringa casuale lunga e improbabile. Il server sa dove finisce una parte e inizia la prossima cercando quella stringa. Lo stesso meccanismo usato nelle API REST con multipart/form-data.

SIZE nel MAIL FROM — nota che con l'allegato la dimensione è SIZE=76692 (75KB) contro i 556 bytes del messaggio di solo testo. Il server usa questo valore per decidere se accettare prima ancora di ricevere i dati.

Scenario Reale — Blue Team

#

Alert Wazuh: connessione SMTP in uscita dalla workstation 192.168.1.45 verso IP esterno sulla porta 25.

Una workstation normale non dovrebbe mai aprire connessioni SMTP dirette — usa il mail server aziendale sulla 587. Traffico SMTP diretto da una workstation = probabile malware che invia spam o esfiltrazione dati via email.

# Analisi dfir — estrai sessioni SMTP
tshark -r capture.dfir -Y "smtp" -T fields -e ip.src -e ip.dst -e smtp.req.command -e smtp.req.parameter

Collegato a

#

• network — hub
• dns-resolution-flow — il MTA usa record MX per trovare il server destinatario
• wireshark — analisi dfir sessioni SMTP
• tshark — estrazione automatica campi SMTP