Simple Mail Transfer Protocol: differenze tra le versioni

Versione delle 16:01, 3 ott 2023

Versione attuale delle 22:46, 21 gen 2025

(10 versioni intermedie di 5 utenti non mostrate)

Riga 1:

'''Simple Mail Transfer Protocol''' ('''SMTP''') è un [[Protocollo di comunicazione|protocollo standard]] per la trasmissione di [[Posta elettronica|email]]. Inizialmente proposto nella [[Request for Comments|RFC]] 788<ref name="RFC788">{{Cita webIETF|url=https://tools.ietf.org/html/rfc788788|titolo=RFCSimple Mail Transfer 778Protocol}}</ref> nel 1981, poi aggiornato con <nowiki>RFC 821</nowiki><ref name=":0RFC821">{{Cita webIETF|url=https://tools.ietf.org/html/rfc821821|titolo=RFCSimple 821Mail Transfer Protocol}}</ref> nel 1982 ed ulteriormente modificato nel 2008 con l’introduzionel'introduzione di [[ESMTP|extended SMTP]]<ref (RFC name="RFC1869">{{IETF|1869|SMTP eService RFCExtensions}}</ref><ref name="RFC5321">{{IETF|5321)|Simple Mail Transfer Protocol}}</ref>, 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’inviodell'invio del messaggio stesso. Per recuperare i messaggi, le applicazioni client usano solitamente protocolli come [[Internet Message Access Protocol|IMAP]] o [[Post Office Protocol|POP3]].

La comunicazione tra i server mail utilizza il protocollo [[TCP/IP|TCP]] sulla porta 25<ref name=":0RFC821" />. I [[Client di posta elettronica|client mail]], tuttavia, spesso inviano le mail in uscita al server sulla porta 465<ref>{{Cita web|url=https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=submissions|titolo=Service Name and Transport Protocol Port Number Registry|sito=www.iana.org|accesso=2022-06-16}}</ref> o 587<ref>{{Cita webIETF|url=https://tools.ietf.org/html/rfc44094409|titolo=RFCMessage 4409Submission for Mail}}</ref>.

È possibile rendere sicura una connessione SMTP con [[Transport Layer Security|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’accountdell'account del rispettivo server mail, tutti utilizzano SMTP, per l’inviol'invio e la ricezione di mail, al di fuori dei loro sistemi.

== Descrizione ==

È un protocollo [[ASCII|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]]<ref>{{Cita web|url=https://www.port25.com/how-to-check-an-smtp-connection-with-a-manual-telnet-session-2/|titolo=Test comunicazione SMTP con telnet|accesso=4 gennaio 2018|dataarchivio=5 aprile 2017|urlarchivio=https://web.archive.org/web/20170405053531/http://www.port25.com/how-to-check-an-smtp-connection-with-a-manual-telnet-session-2/|urlmorto=sì}}</ref>. Il protocollo SMTP utilizza come protocollo di [[livello di trasporto]] [[Transmission Control Protocol|TCP]]. Il client apre una [[sessione]] TCP verso il server sulla [[porta (reti)|porta]] 25 (molti Provider per limitare lo spam utilizzano al suo posto la porta TCP 587 come previsto dalla RFC 2476 del Dicembredicembre 1998). Per associare il server SMTP a un dato nome di dominio ([[Domain Name System|DNS]]) si usa un Resource Record di tipo [[Tipi di record DNS|MX (Mail eXchange)]].

Poiché SMTP è un protocollo testuale basato sulla codifica [[ASCII]]<ref name=":0RFC821" /> (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 binario|file binari]] senza [[trascodifica]]. (Nota che per i file binari inviati con [[Hypertext Transfer Protocol|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 [[Post Office Protocol|POP3]] (Post Office Protocol) e [[Internet Message Access Protocol|IMAP]] (Internet Message Access Protocol).

=== Storia ===

Negli anni ’60'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<ref>{{Cita web|url=http://www.multicians.org/thvv/mail-history.html|titolo=The History of Electronic Mail|lingua=en|accesso=2017-12-06}}</ref>, ma viene trattata in varie RFC tra cui la <nowiki>RFC 196</nowiki><ref>{{Cita webIETF|url=https://tools.ietf.org/html/rfc196196|titolo=RFCMail 196Box Protocol}}</ref>, ed implementata nel programma SNDMSG che, secondo la RFC 2235, è stato inventato da [[Ray Tomlinson]] della [[BBN Technologies|BBN]] per essere utilizzato su computer [[TOPS-20|TENEX]] al fine di inviare messaggi su ARPANET.

Ulteriori implementazioni includono FTP Mail<ref>{{Cita webIETF|url=https://tools.ietf.org/html/rfc469469|titolo=Network mail meeting summary|autore=M.D. Kudlick|sito=tools.ietf.org|lingua=en|accesso=2017-12-06}}</ref> e Mail Protocol, entrambe del 1973<ref>{{Cita webIETF|url=https://tools.ietf.org/html/rfc524524|titolo=Proposed Mail Protocol|autore=J.E. White|sito=tools.ietf.org|lingua=en|accesso=2017-12-06}}</ref>. 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<ref>{{Cita webIETF|url=https://tools.ietf.org/html/rfc772772|titolo=Mail Transfer Protocol|autore=Postel, J., Sluizer, S.|sito=tools.ietf.org|lingua=en|accesso=2017-12-06}}</ref>. SMTP venne pubblicato come <nowiki>RFC 788</nowiki> nel novembre del 1981<ref>{{Cita web|urlname=https://tools.ietf.org/html/rfc788|titolo=Simple"RFC788" Mail Transfer Protocol|autore=J. Postel|sito=tools.ietf.org|lingua=en|accesso=2017-12-06}}</ref>.

Agli inizi degli anni ’80'80, SMTP divenne largamente utilizzato. A quell’epocaquell'epoca era un’estensioneun'estensione di [[UUCP]] (abbreviazione di Unix-to-Unix Copy Program, è una suite di programmi e protocolli che permettono l’esecuzionel'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 [[Berkeley Software Distribution|4.1cBSD]], subito dopo la RFC 788, fu uno dei primi mail transfer agent ad implementare SMTP<ref>{{Cita web|url=https://docs.freebsd.org/44doc/smm/09.sendmail/paper.pdf|titolo=}}</ref>. Grazie al fatto che BSD [[Unix]] divenne il [[sistema operativo]] più diffuso su internet, sendmail diventò il [[Server di posta elettronica|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 (<nowiki>RFC 2476</nowiki><ref name="RFC2476">{{Cita webIETF|url=https://tools.ietf.org/html/rfc24762476|titolo=Message Submission|autore=Randall Gellens|sito=tools.ietf.org|lingua=en|accesso=2017-12-06}}</ref>) e [[SMTP Authentication|SMTP-AUTH]] (<nowiki>RFC 2554</nowiki><ref>{{Cita webIETF|url=https://tools.ietf.org/html/rfc25542554|titolo=RFCSMTP 2554Service Extension for Authentication}}</ref>) 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’organizzazionel'organizzazione dall'esterno e consegnando messaggi dall'organizzazione per l’esternol'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 (<nowiki>RFC 2476</nowiki><ref name=":1RFC2476" />) 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|lingua Inglese]]. Standard come Multipurpose Internet Mail Extension ([[Multipurpose Internet Mail Extensions|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’estensionel'estensione [[8BITMIME]], permettendo la facile trasmissione di file binari, come avviene per file di testo. Recentemente è stata sviluppata l’estensionel'estensione [[SMTPUTF8]] per permettere il supporto di testo con codifica [[UTF-8]], garantendo lo scambio di messaggi in lingue come [[Cirillico]] e [[Caratteri cinesi tradizionali|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 ([[Client di posta elettronica|mail user agent]], MUA) ad un server mail ([[Server di posta elettronica|mail submisson agent]], MSA), usando SMTP attraverso [[TCP/IP|TCP]] sulla porta 587. La maggior parte dei provider di posta tuttavia permettono ancora l’inviol'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 [[Domain Name System|DNS]] per trovare il record MX di uno specifico dominio (la parte dell’indirizzodell'indirizzo dopo il carattere @). Il record MX contiene il nome dell’hostdell'host target. Basandosi sul nome dell’hostdell'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.

Riga 42:

Una volta che il server destinatario accetta il messaggio in arrivo, lo consegna ad un [[Mail Delivery Agent|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’utentedell'utente, chiamate mail client, usando il protocollo [[Internet Message Access Protocol]] (IMAP), che facilita sia l’accessol'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. [[Post Office Protocol|POP3]] e [[Internet Message Access Protocol|IMAP]] sono protocolli simili ma con alcune differenze sostanziali:

* [[Post Office Protocol|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.

* [[Internet Message Access Protocol|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’l'[[envelope sender]], ma non l’headerl'header (ad eccezione delle informazioni di tracciamento) o il corpo del messaggio stesso. STD 10 e <nowiki>RFC 5321</nowiki><ref name="tools.ietf.orgRFC5321">{{Cita web|url=https://tools.ietf.org/html/rfc5321|titolo=RFC 5321}}</ref> definiscono la struttura di SMTP mentre STD 11 e <nowiki>RFC 5322</nowiki><ref>{{Cita webIETF|url=https://tools.ietf.org/html/rfc53225322|titolo=RFCInternet 5322Message Format}}</ref> 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/IP|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:

# '''<code>MAIL FROM</code>''': comando per definire l’indirizzol'indirizzo di ritorno, chiamato anche return-path<ref>{{Cita web|url=https://cr.yp.to/smtp/mail.html|titolo=The MAIL, RCPT, and DATA verbs}}</ref>, reverse-path<ref name="tools.ietf.orgRFC5321" />, bounce address, mfrom o envelope sender.

# '''<code>RCPT TO</code>''': 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)).

# '''<code>DATA</code>''': comando inviato per segnalare l’iniziol'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. <code>DATA</code> 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’interol'intero messaggio.

Oltre alle risposte intermedie al comando '''<code>DATA</code>''', 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’hostL'host iniziale, il client SMTP, può essere sia un [[Client di posta elettronica|client mail]] dell’utentedell'utente, indicato con [[Mail User Agent|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 ===

Riga 65:

=== 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 '''<code>TURN</code>'''. Questa caratteristica tuttavia è stata giudicata insicura<ref name="ReferenceARFC1985">{{Cita webIETF|titolo=RFC 1985|url=https://tools.ietf.org/html/rfc1985SMTP Service Extension for Remote Message Queue Starting}}</ref> e fu sostituita (<nowiki>RFC 1985</nowiki><ref name="ReferenceARFC1985" />) dal comando '''<code>ETRN</code>''' 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 [[Lingua latina|Latino]] o che usano simboli non contenuti nel set di caratteri [[ASCII]], possono aver problemi causati dal fatto che l’indirizzol'indirizzo mail richiede solamente caratteri Latin. <nowiki>RFC 6531</nowiki><ref>{{Cita webIETF|url=https://tools.ietf.org/html/rfc65316531|titolo=RFCSMTP 6531Extension for Internationalized Email}}</ref> nacque per risolvere questo problema, introducendo l’estensionel'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’l'[[indirizzo IP]] del server SMTP di partenza, che deve essere fornito come parte della sua configurazione (solitamente come nome [[Domain Name System|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’usod'uso in base alla posizione geografica del client, permettendo solamente l’usol'uso di client i quali indirizzi IP sono tra quelli gestiti dall'amministratore del server. L’utilizzoL'utilizzo da parte di altri indirizzi IP non era permesso.

* I moderni server SMTP offrono tipicamente un sistema alternativo che richiede l’l'[[autenticazione]] del client attraverso delle credenziali, prima di permettere l’accessol'accesso.

==== Restrizioni di Accesso Basate sulla Posizione ====

Al di sotto di questi sistemi, un [[Internet service provider|ISP]] non permette accesso al server SMTP da parte di utenti al di fuori della rete gestita dall'[[Internet service provider|ISP]] stesso. Più precisamente, il server potrebbe consentire solamente l’accessol'accesso di utenti con un indirizzo IP fornito dall’dall'[[Internet service provider|ISP]], che è equivalente a richiedere che entrambi, mittente e destinatario, siano connessi ad internet usando lo stesso [[Internet service provider|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’accessol'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’indirizzodell'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’autenticazionel'autenticazione dei client attraverso credenziali, prima di permetterne l’accessol'accesso, invece di bloccare direttamente l’accessol'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’autenticazioneL'autenticazione SMTP, spesso abbreviata con [[SMTP AUTH]], è un’estensioneun'estensione di SMTP per permettere l’accessol'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’accessol'accesso è definito [[open relay]]. L’adozioneL'adozione di un sistema di questo tipo è considerato cattiva pratica<ref>{{Cita web|url=http://kb.iu.edu/data/aivh.html|titolo=In Unix, what is an open mail relay? - Knowledge Base|data=2007-06-17|accesso=2017-12-14|urlmorto=sì|urlarchivio=https://web.archive.org/web/20070617083024/http://kb.iu.edu/data/aivh.html|dataarchivio=17 giugno 2007}}</ref>.

==== Porte ====

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

* 587 (consegna), come standardizzato nella <nowiki>RFC 6409</nowiki><ref>{{Cita webIETF|url=https://tools.ietf.org/html/rfc64096409|titolo=RFCMessage Submission 6409for Mail}}</ref>(precedentemente <nowiki>RFC 2476</nowiki><ref name=":1RFC2476">{{Cita web|url=https://tools.ietf.org/html/rfc2476|titolo=RFC 2476}}</ref>).

* 465 (consegna sicura). Originariamente assegnata al servizio [[secure SMTP]] nel 1990, poi deprecata dalla <nowiki>RFC 2487</nowiki><ref>{{Cita webIETF|url=https://tools.ietf.org/html/rfc24872487|titolo=RFCSMTP 2487Service Extension for Secure SMTP over TLS}}</ref>, 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|Internet Service Provider]] ora bloccano tutte le mail inviate dalla porta 25, come misura anti spam<ref>{{Cita web|url=https://www.pcworld.com/article/116843/article.html|titolo=ISPs Pitch In to Stop Spam|sito=PCWorld|lingua=en|accesso=2017-12-14|dataarchivio=19 agosto 2016|urlarchivio=https://web.archive.org/web/20160819051210/http://www.pcworld.com/article/116843/article.html|urlmorto=sì}}</ref> e consentono l'invio solamente dal server mail designato. Il provider così può controllare il traffico in uscita.

== Comandi SMTP ==

Riga 159:

L'inizio della trasmissione del testo della mail è identificata dal comando <code>DATA</code>, dopo il quale il testo è trasmesso linea per linea e termina con la sequenza <code><CR><LF>.<CR><LF></code>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 <code>250</code>, 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<ref>{{Cita webIETF|url=https://tools.ietf.org/html/rfc10471047|titolo=RFCduplicate 1047messages and SMTP}}</ref> e questo può causare problemi di messaggi duplicati. Per limitare questo fenomeno solitamente si specifica un tempo di timeout compreso tra 5 e10e 10 minuti<ref>{{Cita web|url=https://tools.ietf.org/html/rfc5321#section-4.5.3.2.6|titolo=RFC 5321 sezione 4.5.3.2.6}}</ref>.

Il comando <code>QUIT</code> 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 <code>HELO</code> e <code>MAIL FROM</code>, 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’esempionell'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’inviol'invio della risposta <code>221</code>.

== Estensioni ==

Il client può scoprire quali opzioni supporta un server attraverso il messaggio <code>EHLO</code>, come mostrato in seguito, invece di inviare il tradizionale <code>HELO</code>. Il client ritorna ad un messaggio di <code>HELO</code> solo se il server non supporta le estensioni di SMTP.<ref>{{Cita web|urlname=https://tools.ietf.org/html/rfc1869|titolo=Estensioni SMTP - RFC"RFC1869" 1869}}</ref>

I moderni client possono usare la keyword <code>SIZE</code>, 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<ref>{{Cita web|url=https://www.iana.org/assignments/mail-parameters/mail-parameters.txt|titolo=Parametri Mail}}</ref>.

Riga 180:

</pre>

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’utilizzodell'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 <code>EHLO</code>, anche se, secondo la <nowiki>RFC 1870</nowiki><ref>{{Cita webIETF|url=https://tools.ietf.org/html/rfc18701870|titolo=RFCSMTP 1870Service Extension for Message Size Declaration}}</ref>, il parametro <code>SIZE</code> nella risposta <code>EHLO</code> è opzionale. Il client potrebbe invece, quando invia un comando <code>MAIL FROM</code>, 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 ==

Riga 194:

== 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 Notification]]s (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)

* {{cita web|http://www.rfc.altervista.org/rfctradotte.html|RFC 1869 - Estensioni del servizio SMTP (tradotta)}}

Riga 230:

== Altri progetti ==

{{interprogetto|preposizione=sul}}

== Collegamenti esterni ==

* {{Collegamenti esterni}}

* {{FOLDOC}}

* {{Garzanti|SMTP}}

* {{cita web|lingua=en|url=https://www.cloudflare.com/learning/email-security/what-is-smtp/|titolo=What is the Simple Mail Transfer Protocol (SMTP)?|sito=[[Cloudflare]]|accesso=7 febbraio 2024}}

{{IPstack}}