Simple Mail Transfer Protocol

Simple Mail Transfer Protocol (SMTP) è un protocollo standard per la trasmissione di email. Inizialmente proposto nella RFC 788 nel 1981, poi aggiornato con RFC 821 nel 1982 ed ulteriormente modificato nel 2008 con l'introduzione di extended SMTP, che è il protocollo attualmente in uso.

Anche se i server di posta elettronica utilizzano SMTP per inviare e ricevere mail, i client mail a livello utente utilizzano SMTP solo per inviare il messaggio al server mail, il quale si occupa dell'invio del messaggio stesso. Per recuperare i messaggi, le applicazioni client usano solitamente protocolli come IMAP o POP3.

La comunicazione tra i server mail utilizza il protocollo TCP sulla porta 25. I client mail, tuttavia, spesso inviano le mail in uscita al server sulla porta 465 o 587.

È possibile rendere sicura una connessione SMTP con TLS, nota come SMTPS, attraverso STARTTLS.

Anche se sistemi proprietari (come Microsoft Exchange e IBM Notes) e sistemi webmail (come Outlook.com, Gmail e Yahoo! Mail) utilizzano protocolli non standard per accedere alla mail box dell'account del rispettivo server mail, tutti utilizzano SMTP, per l'invio e la ricezione di mail, al di fuori dei loro sistemi.

Descrizione

È un protocollo testuale relativamente semplice, nel quale vengono specificati uno o più destinatari di un messaggio e, dopo aver verificato la loro esistenza, il messaggio viene trasferito. È abbastanza facile verificare come funziona un server SMTP mediante un client telnet. Il protocollo SMTP utilizza come protocollo di livello di trasporto TCP. Il client apre una sessione TCP verso il server sulla porta 25 (molti Provider per limitare lo spam utilizzano al suo posto la porta TCP 587 come previsto dalla RFC 2476 del dicembre 1998). Per associare il server SMTP a un dato nome di dominio (DNS) si usa un Resource Record di tipo MX (Mail eXchange).

Poiché SMTP è un protocollo testuale basato sulla codifica ASCII (in particolare ASCII NVT 7-bit), non è permesso trasmettere direttamente testo composto con un diverso set di caratteri (quindi nemmeno file binari). Lo standard MIME permette di estendere il formato dei messaggi mantenendo la compatibilità col software esistente. Per esempio, al giorno d'oggi molti server SMTP supportano l'estensione 8BITMIME, la quale permette un trasferimento di un testo che contiene caratteri accentati (non-ASCII) senza bisogno di trascodificarlo. Altri limiti di SMTP, quale la lunghezza massima di una riga, impediscono la spedizione di file binari senza trascodifica. (Nota che per i file binari inviati con HTTP si utilizza il formato MIME senza bisogno di una trascodifica.)

SMTP è un protocollo che permette soltanto di inviare messaggi di posta, ma non di richiederli ad un server: per fare questo il client di posta deve usare altri protocolli, quali POP3 (Post Office Protocol) e IMAP (Internet Message Access Protocol).

Storia

Negli anni '60 venivano utilizzate già diverse soluzioni one-to-one per lo scambio di messaggi. Le persone comunicavano tra di loro utilizzando sistemi sviluppati per uno specifico mainframe. Al crescere dei computer connessi, soprattutto in ARPANET, vennero sviluppati diversi standard per permettere lo scambio di mail tra utenti di sistemi differenti. SMTP nacque da questi standard durante gli anni 70.

Le radici di SMTP possono essere trovate in due implementazioni descritte nel 1971: il protocollo Mail Box, la cui implementazione è stata discussa, ma viene trattata in varie RFC tra cui la RFC 196, ed implementata nel programma SNDMSG che, secondo la RFC 2235, è stato inventato da Ray Tomlinson della BBN per essere utilizzato su computer TENEX al fine di inviare messaggi su ARPANET.

Ulteriori implementazioni includono FTP Mail e Mail Protocol, entrambe del 1973. Il lavoro di sviluppo continuò durante gli anni 70, finché, intorno al 1980, la rete ARPANET si trasformò nella moderna rete internet. Jon Postel propose un Mail Transfer Protocol nel 1980 che iniziò a rimuovere la dipendenza delle mail da FTP. SMTP venne pubblicato come RFC 788 nel novembre del 1981.

Agli inizi degli anni '80, SMTP divenne largamente utilizzato. A quell'epoca era un'estensione di UUCP (abbreviazione di Unix-to-Unix Copy Program, è una suite di programmi e protocolli che permettono l'esecuzione remota di comandi e il trasferimento di file ed email tra computer), che era più adatto a gestire il trasferimento di email tra computer connessi in maniera intermittente. SMTP tuttavia funziona meglio con mittente e destinatario sempre connessi alla rete. Entrambi utilizzano un meccanismo di store and forward e sono esempi di logica push.

Sendmail, rilasciato con 4.1cBSD, subito dopo la RFC 788, fu uno dei primi mail transfer agent ad implementare SMTP. Grazie al fatto che BSD Unix divenne il sistema operativo più diffuso su internet, sendmail diventò il mail transfer agent (mail server) più utilizzato. Altri SMTP server sono Postfix, qmail, Novell GroupWise, Exim, Novell NetMail, Microsoft Exchange Server e Oracle Communications Messagging Server.

La possibilità di inviare messaggi (RFC 2476) e SMTP-AUTH (RFC 2554) furono sviluppati nel 1998 e 1999, introducendo un nuovo trend nella consegna della email. Inizialmente, i server SMTP erano tipicamente all'interno di una organizzazione, ricevendo mail per l'organizzazione dall'esterno e consegnando messaggi dall'organizzazione per l'esterno. A causa della veloce espansione del World Wide Web, i server SMTP hanno dovuto inserire regole specifiche e metodi per consegnare email ed autenticare gli utenti per prevenire abusi come consegna di mail non richieste (spam). Il lavoro sull'invio dei messaggi (RFC 2476) fu sviluppato perché i più famosi mail server spesso sovrascrivevano la mail per sistemare i problemi contenuti in essa come, per esempio, aggiungendo il nome di dominio ad un indirizzo non specificato. Questo comportamento è desiderato quando il messaggio viene corretto mentre si trova in uno stato iniziale ma pericoloso e dannoso quando il messaggio è stato generato altrove e sta per essere trasmesso. Separare mail tra consegna e trasmissione è visto come un modo per permettere ed incoraggiare il rewriting submission e bloccare il rewriting relay. Questa separazione tra consegna e trasmissione divenne velocemente la base della sicurezza mail.

Essendo nato come puro protocollo ASCII text-based 7-bit, SMTP non gestiva bene i file binari e i caratteri non utilizzati nella lingua Inglese. Standard come Multipurpose Internet Mail Extension (MIME) furono sviluppati per codificare i file binari per il trasferimento tramite SMTP. I mail transfer agent (MTA) sviluppati dopo Sendmail tendevano ad essere implementati come 8-bit-clean così da poter trasmettere qualsiasi file di testo contenente dati (in una qualsiasi codifica 8-bit ASCII-like) attraverso SMTP. Oggigiorno gli 8-bit-clean MTA tendono a supportare l'estensione 8BITMIME, permettendo la facile trasmissione di file binari, come avviene per file di testo. Recentemente è stata sviluppata l'estensione SMTPUTF8 per permettere il supporto di testo con codifica UTF-8, garantendo lo scambio di messaggi in lingue come Cirillico e Cinese.

Molte persone contribuirono allo sviluppo delle specifiche SMTP, tra i quali Jon Postel, Eric Allman, Dave Crocker, Ned Freed, Randall Gellens, John Klensin e Keith Moore.

Modello di gestione delle mail

Una mail è inviata da un client di posta (mail user agent, MUA) ad un server mail (mail submisson agent, MSA), usando SMTP attraverso TCP sulla porta 587. La maggior parte dei provider di posta tuttavia permettono ancora l'invio sulla tradizionale porta 25. L'MSA consegna la mail al mail transfer agent (MTA). Spesso MSA e MTA sono istanze dello stesso software, avviato con opzioni diverse sulla stessa macchina. Oltre che con un classico client, un account di posta in uscita con protocollo SMTP può essere configurato in qualsiasi applicazione software che possa inviare posta elettronica.

Il MTA utilizza il DNS per trovare il record MX di uno specifico dominio (la parte dell'indirizzo dopo il carattere @). Il record MX contiene il nome dell'host target. Basandosi sul nome dell'host e su altre informazioni, il MTA sceglie un server e si connette come SMTP client.

Il trasferimento di messaggi può avvenire in una singola connessione tra due MTA o attraverso una serie di salti attraverso diversi sistemi intermediari. Un server SMTP può essere destinatario del messaggio o intermediario (compiendo operazioni di store and forward) o gateway (può trasmettere il messaggio utilizzando anche altri protocolli, oltre a SMTP). Ogni salto è un trasferimento formale di responsabilità sul messaggio, per cui ciascun server che riceve il messaggio deve consegnarlo o segnalare un errore.

Una volta che il server destinatario accetta il messaggio in arrivo, lo consegna ad un mail delivery agent (MDA), che lo salva in una mailbox per la consegna locale.

Una volta consegnato al mail server, il messaggio è memorizzato per poter esser recuperato da un determinato mail client autenticato (MUAs). La mail è recuperata attraverso applicazioni sul dispositivo dell'utente, chiamate mail client, usando il protocollo Internet Message Access Protocol (IMAP), che facilita sia l'accesso alle mail sia gestisce le mail immagazzinate, o Post Office Protocol (POP) che tipicamente usa il tradizionale formato mbox per le mail, o un sistema proprietario come per esempio Microsoft Exchange/Outlook o Lotus Notes/Domino. I client Webmail possono utilizzare entrambi i modi ma il protocollo per il recupero solitamente non è un protocollo standard. POP3 e IMAP sono protocolli simili ma con alcune differenze sostanziali:

• POP3: il client mail si collega al server, scarica la posta in locale, cancella i messaggi scaricati dal server e si disconnette (è possibile comunque impostare alcuni parametri per evitare la cancellazione della mail dal server). Caratteristiche di questo protocollo: possibilità di avere i messaggi sempre salvati in locale quindi non è necessaria una connessione internet (ovviamente necessaria per invio e scaricamento dei nuovi messaggi) e risparmio di spazio sul server.
• IMAP: il client mail si collega al server, richiede i nuovi messaggi e li presenta all'utente salvandoli sotto forma di file temporanei (analogamente a POP3, è possibile salvare le mail in locale in maniera permanente). Qualsiasi modifica apportata ai messaggi viene riprodotta anche sul server e su qualsiasi altro dispositivo col quale si è effettuato l'accesso. Caratteristiche: posta salvata sul server quindi sempre reperibile da qualsiasi dispositivo tramite autenticazione, possibilità di recuperare la mail anche se un determinato dispositivo sul quale si consultano le mail smette di funzionare, risparmio spazio sul client.

SMTP definisce come viene trasmesso il messaggio, non il suo contenuto. Definisce la struttura e i suoi parametri, come l'envelope sender, ma non l'header (ad eccezione delle informazioni di tracciamento) o il corpo del messaggio stesso. STD 10 e RFC 5321 definiscono la struttura di SMTP mentre STD 11 e RFC 5322 definiscono il messaggio (header e body) attraverso un Internet Message Format.

Struttura del Protocollo

SMTP è un protocollo connection oriented, text based, nel quale un mail sender comunica con un mail receiver inviando stringhe di comandi e fornendo le informazioni necessarie attraverso un canale di comunicazione affidabile, tipicamente basato su TCP. Una sessione SMTP consiste nello scambio di comandi generati da un client SMTP e le corrispettive risposte del server SMTP. Una sessione può includere zero o più transazioni SMTP. Una transazione SMTP consiste in tre sequenze di comandi e risposte:

1. MAIL FROM: comando per definire l'indirizzo di ritorno, chiamato anche return-path, reverse-path, bounce address, mfrom o envelope sender.
2. RCPT TO: comando per definire il destinatario del messaggio. Questo comando può essere inviato più volte, una per ogni destinatario (gli indirizzi fanno parte della struttura (envelope)).
3. DATA: comando inviato per segnalare l'inizio del messaggio di testo, il contenuto del messaggio, come definito nell'envelope. Consiste di un header ed un body, separati da una linea vuota. DATA tuttavia è un insieme di comandi ai quali il server risponde due volte: la prima volta come conferma di ricezione del testo (acknowledge), la seconda dopo la sequenza di end-of-data per accettare o rifiutare l'intero messaggio.

Oltre alle risposte intermedie al comando DATA, ogni risposta del server può essere positiva (caratterizzata dal codice 2xx) o negativa. Le risposte negative possono essere permanenti (5xx) o temporanee (4xx). Un rifiuto (reject) rappresenta un fallimento permanente e il client dovrebbe inviare un bounce message al server dal quale ha ricevuto il messaggio. Un drop è una risposta positiva, seguita dal messaggio di rifiuto, invece che dal messaggio di avvenuta consegna.

L'host iniziale, il client SMTP, può essere sia un client mail dell'utente, indicato con mail user agent (MUA) o fare affidamento su un mail transfer agent (MTA), che di fatto è un server SMTP che si comporta come un client SMTP per la sessione corrente. I server SMTP più avanzati mantengono una coda di messaggi per inviare nuovamente i messaggi che hanno riportato un esito negativo (temporaneo) di consegna.

Un server di trasmissione tipicamente determina quale è il server a cui si deve connettere attraverso il record MX (Mail eXchange) del DNS di ciascun dominio. Se non esiste nessun record MX, alcuni server controllano il record A. La differenza principale tra MTA e MSA consiste nel fatto che la connessione ad un MSA richiede un'autenticazione SMTP. La suddivisione tra MTA e MSA comporta diversi benefici:

• Il MSA, poiché interagisce direttamente con l'utente (attraverso il MUA), può correggere piccoli errori nel formato del messaggio (per esempio, data mancante, destinatario mancante, nome di dominio inesistente ecc). Un MTA che accetta un messaggio non può effettuare in maniera affidabile e sicura queste modifiche a qualsiasi modifica fatta dal MTA raggiunge il mittente del messaggio, dopo che il messaggio è già stato inviato.
• MSA e MTA possono avere diverse soluzioni per il blocco dello spam. La maggior parte dei MSA richiedono un'autenticazione tramite mail e password e quindi il mittente del messaggio può essere rintracciato. Questo permette al MSA di avere una politica meno stringente sullo spam. Vedi anche: message submission agent.

Recupero Messaggi

SMTP è solamente un protocollo di consegna. Nell'utilizzo più comune, il messaggio è inviato al server mail di destinazione, o al server che si trova al passo successivo. Il messaggio è instradato sulla base del server di destinazione, non sulla base dell'utente al quale deve essere inviato. Altri protocolli come Post Office Protocol (POP) e Internet Message Access Protocol (IMAP) sono specificamente sviluppati per essere utilizzati dall'utente, recuperando i messaggi e gestendo la casella di posta. Per permettere ad un server mail connesso ad intermittenza di recuperare i messaggi da un server remoto, SMTP ha una funzione per inizializzare una coda di processamento messaggi su un server remoto (vedi sotto).

Inizializzazione Coda di Messaggi Remota

L'Inizializzazione di una coda di messaggi remota è una caratteristica di SMTP che permette ad un host remoto di iniziare il processamento della coda delle mail su un server, il quale può ricevere messaggi destinati ad esso inviando in comando TURN. Questa caratteristica tuttavia è stata giudicata insicura e fu sostituita (RFC 1985) dal comando ETRN che opera in maniera più sicura utilizzando un metodo di autenticazione basato su Domain Name System Information.

Internazionalizzazione

Utenti per i quali la lingua scritta non è basata sull'alfabeto Latino o che usano simboli non contenuti nel set di caratteri ASCII, possono aver problemi causati dal fatto che l'indirizzo mail richiede solamente caratteri Latin. RFC 6531 nacque per risolvere questo problema, introducendo l'estensione SMTPUTF8 e il supporto per una codifica multi byte per caratteri non ASCII per gli indirizzi mail, per supportare lingue come il greco e cinese.

SMTP Server

Un client di posta elettronica necessita di conoscere l'indirizzo IP del server SMTP di partenza, che deve essere fornito come parte della sua configurazione (solitamente come nome DNS, campo MX).

Restrizioni di Accesso

Gli amministratori dei server necessitano di imporre un qualche tipo di controllo riguardo quali client possono utilizzare il server, per permettere la gestione, per esempio, dello spam. Esistono due soluzioni utilizzate solitamente:

• In passato, molti sistemi imponevano restrizioni d'uso in base alla posizione geografica del client, permettendo solamente l'uso di client i quali indirizzi IP sono tra quelli gestiti dall'amministratore del server. L'utilizzo da parte di altri indirizzi IP non era permesso.
• I moderni server SMTP offrono tipicamente un sistema alternativo che richiede l'autenticazione del client attraverso delle credenziali, prima di permettere l'accesso.

Restrizioni di Accesso Basate sulla Posizione

Al di sotto di questi sistemi, un ISP non permette accesso al server SMTP da parte di utenti al di fuori della rete gestita dall'ISP stesso. Più precisamente, il server potrebbe consentire solamente l'accesso di utenti con un indirizzo IP fornito dall'ISP, che è equivalente a richiedere che entrambi, mittente e destinatario, siano connessi ad internet usando lo stesso ISP. Un utente mobile, tuttavia, potrebbe spesso trovarsi su una rete che non è quella del suo normale ISP e quindi potrebbe non riuscire ad inviare mail perché la configurazione del server SMTP scelto non è più accessibile.

Un server SMTP di una organizzazione potrebbe quindi fornire solamente servizi ad utenti sulla stessa rete, bloccando l'accesso alla rete esterna. Alternativamente il server potrebbe effettuare un range check sull'indirizzo IP del client. Questi metodi vennero tipicamente utilizzati da enti e istituzioni come università che forniscono un server SMTP solamente per un uso interno all'organizzazione. Tuttavia molte di queste organizzazioni ora utilizzano un metodo di autenticazione.

Quando un utente è mobile, e potrebbe connettersi ad internet attraverso diversi ISP, questo tipo di restrizione di utilizzo è onerosa e la modifica dell'indirizzo del server di uscita è impraticabile. È desiderabile aver la possibilità di utilizzare configurazioni mail client che non hanno bisogno di essere cambiate.

Client autentication

I moderni server SMTP solitamente richiedono l'autenticazione dei client attraverso credenziali, prima di permetterne l'accesso, invece di bloccare direttamente l'accesso in base alla posizione, come descritto prima. Questo sistema più flessibile permette agli utenti mobili di avere un server SMTP di outboud fisso. L'autenticazione SMTP, spesso abbreviata con SMTP AUTH, è un'estensione di SMTP per permettere l'accesso attraverso meccanismi di autenticazione.

Open Relay

Un server accessibile su tutta la rete internet e che non adotta questi tipi di restrizioni per l'accesso è definito open relay. L'adozione di un sistema di questo tipo è considerato cattiva pratica.

Porte

La comunicazione tra mail server solitamente avviene attraverso TCP sulla porta 25, anche se i client di posta elettronica solitamente utilizzano un'altra porta. I servizi mail accettano di solito l'invio delle mail sulle porte:

• 587 (consegna), come standardizzato nella RFC 6409(precedentemente RFC 2476).
• 465 (consegna sicura). Originariamente assegnata al servizio secure SMTP nel 1990, poi deprecata dalla RFC 2487, e infine reintrodotta dalla RFC 8314 nel 2018.

La porta 2525 e altre possono essere utilizzate da alcuni provider ma non sono ufficialmente supportate.

Molti Internet Service Provider ora bloccano tutte le mail inviate dalla porta 25, come misura anti spam e consentono l'invio solamente dal server mail designato. Il provider così può controllare il traffico in uscita.

Comandi SMTP

HELO: Inviato da un client per l'autoidentificazione, solitamente con un nome di dominio.

EHLO: Consente al server di identificare il supporto per i comandi ESMTP (Extended Simple Mail Transfer Protocol).

MAIL FROM: Identifica il mittente del messaggio. Utilizzato nella forma MAIL FROM:.

RCPT TO: Identifica i destinatari del messaggio. Utilizzato nella forma RCPT TO:.

TURN: Consente al client e al server di invertire i ruoli e inviare la posta nella direzione opposta senza dovere stabilire una nuova connessione.

ATRN: Il comando ATRN (Authenticated TURN) utilizza, a propria discrezione, uno o più domini come parametro. Il comando ATRN deve essere rifiutato se la sessione non è stata autenticata.

SIZE: Fornisce un meccanismo per mezzo del quale il server SMTP può indicare la dimensione massima supportata per i messaggi. I server compatibili devono fornire delle estensioni della dimensione per indicare la massima dimensione consentita per i messaggi. I client non devono inviare messaggi di dimensione superiore a quella indicata dal server.

ETRN: Un'estensione di SMTP. ETRN viene inviato da un server SMTP per richiedere che un altro server invii gli eventuali messaggi di posta elettronica di cui dispone.

PIPELINING: Consente di inviare un flusso di comandi senza aspettare una risposta dopo ogni comando.

CHUNKING: È un comando ESMTP che sostituisce il comando DATA. Questo comando invia un comando BDAT con un argomento contenente il numero di byte totale del messaggio in modo che l'host SMTP non debba continuamente eseguire la scansione per determinare la fine dei dati. Il server destinatario conta i byte nel messaggio e, quando la dimensione del messaggio corrisponde al valore inviato dal comando BDAT, il server presuppone di avere ricevuto tutti i dati del messaggio.

DATA: Inviato da un client per avviare il trasferimento del contenuto di un messaggio.

DSN: È un comando ESMTP che attiva le notifiche dello stato del recapito.

RSET: Annulla l'intera transazione del messaggio e ripristina il buffer.

VRFY: Verifica che una cassetta postale sia disponibile per il recapito di messaggi. Ad esempio, VRFY ted verifica che sul server locale risieda la cassetta postale di Ted.

HELP: Restituisce l'elenco dei comandi supportati dal servizio SMTP.

QUIT: Termina la sessione.

Esempio di comunicazione SMTP

Di seguito viene riportata una transazione SMTP tra due caselle di posta (Alice e Bob) che si trovano sullo stesso dominio (example.com). Le righe inviate dal client sono precedute da "C:", mentre quelle inviate dal server da "S:" (queste lettere tuttavia non fanno parte dello scambio di messaggi ma servono solamente da esempio).

S: 220 smtp.example.com ESMTP Postfix
    C: HELO relay.example.com
S: 250 smtp.example.com
    C: MAIL FROM: <bob@example.com>
S: 250 OK
    C: RCPT TO: <alice@example.com>
S: 250 OK
    C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
    C: From: "Bob" <bob@example.com>
    C: To: "Alice" <alice@example.com>
    C: Date: Tue, 15 January 2008 16:02:43 -0500
    C: Subject: Messaggio di prova
    C: 
    C: Ciao, questo è un messaggio di prova
    C: .
S: 250 Ok: queued as 12345
    C: QUIT
S: 221 Bye

Il client notifica il destinatario della mail attraverso il comando RCPT TO. Nel caso in cui il messaggio non possa essere consegnato, viene restituito un bounce address. In questo caso il messaggio viene inviato ad una casella di posta sullo stesso server (nel caso in cui fosse stato presente anche un Cc, il messaggio sarebbe stato inviato anche alla sua casella). Il comando SMTP corrispondente è RCPT TO. Ogni comando eseguito con successo porta alla generazione di un acknowledge da parte del server con codice 250.

L'inizio della trasmissione del testo della mail è identificata dal comando DATA, dopo il quale il testo è trasmesso linea per linea e termina con la sequenza <CR><LF>.<CR><LF>detta sequenza di end-of-data. Poiché una linea può contenere solamente un punto (.) come parte del testo, il client manda due punti consecutivi ogni volta che una linea inizia con un punto. Analogamente il server sostituisce ogni sequenza di due punti consecutivi con uno solo (questa tecnica è chiamata dot-stuffing).

La risposta positiva del server all'end-of-data significa che il server si è preso in carico la consegna del messaggio. Un messaggio può essere duplicato se, in questa fase, avviene un problema di comunicazione, causato per esempio da un calo di corrente. Finché il mittente non riceve il messaggio con codice 250, si suppone che il messaggio non sia stato consegnato. Analogamente dopo che il destinatario ha deciso di accettare il messaggio, il mittente assume che il messaggio sia stato consegnato. Tuttavia, durante questo arco di tempo (tempo che intercorre tra quando il messaggio è stato inviato a quando il client riceve la risposta caratterizzata dal codice 250), entrambi gli agent hanno copie attive di messaggi che tentano di consegnare e questo può causare problemi di messaggi duplicati. Per limitare questo fenomeno solitamente si specifica un tempo di timeout compreso tra 5 e 10 minuti.

Il comando QUIT termina la sessione. Se la mail ha altri destinatari, il client si connetterà ad un opportuno server SMTP per i successivi destinatari. Le informazioni che il client invia coi comandi HELO e MAIL FROM, sono inserite (non mostrate nel codice di esempio) nella mail come campi header aggiuntivi, dal server destinatario, aggiungendo rispettivamente i campi Received e Return-Path.

Alcuni client sono implementati in modo da chiudere la connessione dopo che il messaggio è stato accettato (nell'esempio 250 OK: queued as 12345), quindi le ultime due linee possono essere omesse. Questa soluzione tuttavia può causare un errore nel server durante l'invio della risposta 221.

Estensioni

Il client può scoprire quali opzioni supporta un server attraverso il messaggio EHLO, come mostrato in seguito, invece di inviare il tradizionale HELO. Il client ritorna ad un messaggio di HELO solo se il server non supporta le estensioni di SMTP.

I moderni client possono usare la keyword SIZE, introdotta dall'estensione ESMTP, per chiedere al server la dimensione massima del messaggio che viene accettato. In passato, c'era il rischio che client e server tentassero di trasferire messaggi troppo grandi, che sarebbero stati bloccati dopo aver utilizzato le risorse della rete tra cui il tempo di connessione.

Gli utenti possono determinare manualmente, in anticipo, la dimensione massima accettata dal server ESMTP, sostituendo il comando HELO con EHLO, come di seguito

S: 220 smtp2.example.com ESMTP Postfix
C: EHLO bob.example.com
S: 250-smtp2.example.com Hello bob.example.org [192.0.2.201]
S: 250-SIZE 14680064
S: 250-PIPELINING
S: 250 HELP

Dalla risposta si evince che smtp2.example.com dichiara di accettare un messaggio massimo di dimensione fissata non maggiore di 14.680.064 ottetti (8-bit, byte). Tuttavia la dimensione massima del messaggio può variare a seconda dell'utilizzo corrente delle risorse del server (potrebbe non essere in grado di ricevere un messaggio così grande).

Nel caso più semplice, un server ESMTP dichiara una dimensione massima subito dopo la ricezione del comando di EHLO, anche se, secondo la RFC 1870, il parametro SIZE nella risposta EHLO è opzionale. Il client potrebbe invece, quando invia un comando MAIL FROM, includere la dimensione stimata del messaggio che sta per inviare, così il server potrebbe rifiutare la ricezione di messaggi troppo grandi.

La sicurezza del protocollo SMTP

Una delle limitazioni del protocollo SMTP originario è che non gestisce l'autenticazione dei mittenti. Oltre al rischio di spam, esiste la possibilità di inviare e-mail facendo apparire come mittente l'indirizzo corrispondente ad un altro account. Senza accedere all'account di terzi, è possibile stabilire una connessione al mail-server e scrivere un messaggio in codice SMTP contenente i comandi relativi a mittente e destinatario, dare i relativi parametri e il corpo della e-mail.

Per ovviare a questi problemi è stata sviluppata un'estensione chiamata SMTP-AUTH.

Nonostante questo, lo spam rimane ancor oggi un grave problema della posta elettronica. Tuttavia, non si ritiene praticabile una revisione radicale del protocollo SMTP, per via del gran numero di implementazioni del protocollo attuale (ad esempio, è stato proposto Internet Mail 2000 come protocollo alternativo).

Per questo motivo sono stati proposti diversi protocolli ausiliari per assistere le transazioni SMTP. L'Anti-Spam Research Group dell'IETF sta lavorando su varie proposte di autenticazione e-mail centrate sulla flessibilità, leggerezza e scalabilità.

Gli standard RFC relativi

Pubblicato nel 2008, il RFC 5321 - "The Simple Mail Transfer Protocol" è il documento di specifica principale per quanto riguarda il protocollo SMTP e rende obsoleti il RFC 821 (conosciuto anche come STD 10), RFC 974, RFC 1869 e RFC 2821. Inoltre, i seguenti RFC estendono le funzionalità del protocollo SMTP: (in lingua originale)

• RFC 1123 - Requirements for Internet Hosts—Application and Support (STD 3)
• RFC 1870 - SMTP Service Extension for Message Size Declaration (rende obsoleto RFC 1653)
• RFC 2505 - Anti-Spam Recommendations for SMTP MTAs (BCP 30)
• RFC 2920 - SMTP Service Extension for Command Pipelining (STD 60)
• RFC 3030 - SMTP Service Extensions for Transmission of Large and Binary MIME Messages
• RFC 3207 - SMTP Service Extension for Secure SMTP over Transport Layer Security (rende obsoleto RFC 2487)
• RFC 3461 - SMTP Service Extension for Delivery Status Notifications (rende obsoleto RFC 1891)
• RFC 3463 - Enhanced Status Codes for SMTP (rende obsoleto RFC 1893)
• RFC 3464 - An Extensible Message Format for Delivery Status Notifications (rende obsoleto RFC 1894)
• RFC 3798 - Message Disposition Notification
• RFC 3834 - Recommendations for Automatic Responses to Electronic Mail
• RFC 4952 - Overview and Framework for Internationalized E-mail
• RFC 4954 - SMTP Service Extension for Authentication (rende obsoleti RFC 2554)
• RFC 5068 - E-mail Submission Operations: Access and Accountability Requirements (BCP 134)
• RFC 5322 - Internet Message Format (rende obsoleto RFC 822 aka STD 11, and RFC 2822)
• RFC 5336 - SMTP Extension for Internationalized Email Addresses (aggiorna RFC 2821, RFC 2822, and RFC 4952)
• RFC 5504 - Downgrading Mechanism for Email Address Internationalization
• RFC 6409 - Message Submission for Mail (rende obsoleti RFC 4409, RFC 2476)
• RFC 6522 - The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages (rende obsoleti RFC 3462, RFC 1892)
• RFC 8314 - Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access

(tradotti in italiano)

• RFC 1869 - Estensioni del servizio SMTP (tradotta), su rfc.altervista.org.

Voci correlate

• On-Demand Mail Relay
• Multipurpose Internet Mail Extensions (MIME)
• Mail server
• SMTPS

Altri progetti

Altri progetti

• Wikimedia Commons

• Wikimedia Commons contiene immagini o altri file sul Simple Mail Transfer Protocol

Collegamenti esterni

• SMTP, in Lessico del XXI secolo, Istituto dell'Enciclopedia Italiana, 2012-2013.
• (EN) Denis Howe, Simple Mail Transfer Protocol, in Free On-line Dictionary of Computing. Disponibile con licenza GFDL
• SMTP, in Grande Dizionario di Italiano, Garzanti Linguistica.
• (EN) What is the Simple Mail Transfer Protocol (SMTP)?, su Cloudflare. URL consultato il 7 febbraio 2024.