Simple Mail Transfer Protocol

Da Wikipedia, l'enciclopedia libera.
(Reindirizzamento da SMTP)

SMTP è un protocollo standard per la trasmissione di email. Inizialmente definito nella RFC 821 nel 1982, è stato aggiornato nel 2008 con l’introduzione di extended SMTP (RFC 5321), 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 un messaggio al server mail, il quale si occupa dell’invio del messaggio stesso. Per recuperare i messaggi, le applicazioni client usano solitamente IMAP o POP3.

La comunicazione tra server mail utilizza il protocollo TCP sulla porta 25. I client mail, tuttavia, spesso inviano le mail in uscita al server sulla porta 587. Anche se deprecata, i provider mail permettono ancora l’uso della porta non standard 465 per questa operazione.

È 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 proprietari 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[modifica | modifica wikitesto]

È un protocollo relativamente semplice, testuale, nel quale vengono specificati uno o più destinatari di un messaggio, verificata 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 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), non è permesso trasmettere direttamente testo composto con un diverso set di caratteri e tantomeno 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 il POP3 (Post Office Protocol) e l'IMAP (Internet Message Access Protocol).

Storia[modifica | modifica wikitesto]

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. SMPT 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 [1], ma viene trattata in varie RFC tra cui la [rfc:196 196], e il 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[2] e Mail Protocol, entrambe del 1973[3]. 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[4]. SMTP venne pubblicato come RFC 788 nel novembre del 1982[5].

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 [rfc:788 788], fu uno dei primi mail transfer agent ad implementare SMTP[6]. 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[7]) e SMTP-AUTH (RFC 2554[8]) fu sviluppata 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 Word 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[9]) 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, 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-clan 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[modifica | modifica wikitesto]

Una mail è inviata da un client di posta (mail user agent, MUA) ad un server mail (mail submission 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. Il MSA consegna la mail al mail transfer agent (MTA). Spesso questi due agent sono istanze dello stesso software, avviato con opzioni diverse sulla stessa macchina.

Il MTA di confine usa 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 alcuni sistemi intermediari. Un server SMTP può essere destinatario del messaggio o intermediario (compiendo operazioni di store and forward) o un 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) per la consegna locale. Un MDA salva i messaggi in una mailbox.

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 email 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.

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[10] definiscono la struttura di SMTP mentre STD 11 e RFC 5322[11] definiscono il messaggio (header e body) attraverso un Internet Message Format.

Struttura del Protocollo[modifica | modifica wikitesto]

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 TCP. Una sessione SMTP consiste nello scambio di comandi generati da un client SMTP e le corrispettive risposte del server SMTP. Un sessione può includere zero o più transazioni SMTP. Una transazione SMTP consiste in tre sequenze di comandi e risposte:

  1. MAIL: comando per definire l’indirizzo di ritorno, chiamato anche return-path[12], reverse-path[13], bounce address, mfrom o envelope sender.
  2. RCPT: comando per definire il contenuto di un messaggio. Questo comando può essere inviato più volte, una per ogni destinatario. Questi 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 riposte 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 ad 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.

Recupero Messaggi[modifica | modifica wikitesto]

SMTP è solamente un protocollo di consegna. Nell'utilizzo più comune, il messaggio e inviato (pushed) 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 Protcol (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). POP e IMAP sono protocolli non adatti per la consegna dei messaggi da macchine che sono connesse in maniera intermittente.

Inizializzazione Coda di Messaggi Remota[modifica | modifica wikitesto]

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[14] e fu sostituita (RFC 1985[15]) dal comando ETRN che opera in maniera più sicura utilizzando un metodo di autenticazione basato su Domain Name System Information.

Internazionalizzazione[modifica | modifica wikitesto]

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 [rfc:6531 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.

Comandi SMTP[modifica | modifica wikitesto]

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. Questo comando è disattivato per impostazione predefinita nelle implementazioni di Exchange.

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

QUIT: Termina la sessione.

Esempio di comunicazione SMTP[modifica | modifica wikitesto]

Quella che segue è una transazione SMTP valida. Le righe inviate dal client sono precedute da "C:", mentre quelle inviate dal server da "S:". Su molti computer si può stabilire una connessione mediante il comando telnet:

 telnet www.example.com 25

Questo comando apre una connessione a www.example.com sulla porta 25 TCP.

 S: 220 www.example.com ESMTP Postfix
 C: HELO mydomain.com
 S: 250 Hello mydomain.com, pleased to meet you
 C: MAIL FROM: <sender@mydomain.com>
 S: 250 sender@mydomain.com ... Sender ok
 C: RCPT TO: <friend@example.com>
 S: 250 friend@example.com ... Recipient Ok
 C: DATA
 S: 354 End data with "." on a line by itself
 C: Subject: messaggio di prova
 C: From: sender@mydomain.com
 C: To: friend@example.com
 C:
 C: Ciao,
 C: questa è una prova.
 C: .
 S: 250 Ok: queueued as 12345
 C: QUIT
 S: 221 Bye

Sebbene non sia obbligatorio, quasi tutti i client richiedono al server quali estensioni del protocollo SMTP il server supporta usando il saluto HELO. Questi client usano HELO soltanto nel caso in cui il server non risponda ad HELO.

La sicurezza del protocollo SMTP[modifica | modifica wikitesto]

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[modifica | modifica wikitesto]

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)

(tradotti in italiano)

Voci correlate[modifica | modifica wikitesto]

Telematica Portale Telematica: accedi alle voci di Wikipedia che parlano di reti, telecomunicazioni e protocolli di rete
  1. ^ (EN) The History of Electronic Mail, su www.multicians.org. URL consultato il 06 dicembre 2017.
  2. ^ (EN) M.D. Kudlick, Network mail meeting summary, su tools.ietf.org. URL consultato il 06 dicembre 2017.
  3. ^ (EN) J.E. White, Proposed Mail Protocol, su tools.ietf.org. URL consultato il 06 dicembre 2017.
  4. ^ (EN) Postel, J., Sluizer, S., Mail Transfer Protocol, su tools.ietf.org. URL consultato il 06 dicembre 2017.
  5. ^ (EN) J. Postel, Simple Mail Transfer Protocol, su tools.ietf.org. URL consultato il 06 dicembre 2017.
  6. ^ docs.freebsd.org, https://docs.freebsd.org/44doc/smm/09.sendmail/paper.pdf.
  7. ^ (EN) Randall Gellens, Message Submission, su tools.ietf.org. URL consultato il 06 dicembre 2017.
  8. ^ (EN) John Gardiner Myers <jgmyers@netscape.com>, SMTP Service Extension for Authentication, su tools.ietf.org. URL consultato il 06 dicembre 2017.
  9. ^ (EN) Randall Gellens, Message Submission, su tools.ietf.org. URL consultato il 06 dicembre 2017.
  10. ^ RFC 5321, su tools.ietf.org.
  11. ^ RFC 5322, su tools.ietf.org.
  12. ^ The MAIL, RCPT, and DATA verbs, su cr.yp.to.
  13. ^ RFC 5321, su tools.ietf.org.
  14. ^ [RFC 1985 https://tools.ietf.org/html/rfc1985].
  15. ^ [RFC 1985 https://tools.ietf.org/html/rfc1985].