Sicuramente uno dei progetti più complessi da costruire, il Mail o servizio di consegna della posta elettronica. Ai tempi in cui fu scritto l'RFC 821 erano stati esposti i migliori presupposti sul funzionamento del protocollo SMTP: doveva essere veloce, efficiente e soprattutto un protocollo indipendente anche dal tipo di rete sottostante, indipendente anche da Internet.
Così riferendosi a questo ultimo, la consegna di un messaggio di posta elettronica dal mittente al destinatario avviene utilizzando un collegamento TCP tra la porta U del Client SMTP e la porta L=25 del Server SMTP (ovviamente U è un numero non fisso ed assegnato dal sistema del Client di volta in volta).
In queste comunicazioni la presenza di un Server SMTP fa si ché diventi necessaria la sua capacità di fare il relay del messaggio di posta fino al computer di destinazione. Il relay è indispensabile anche se nella spedizione del messaggio si incontra un solo Server SMTP.
Nota sulle caratteristiche del canale TCP : il canale che si forma tra il Client ed il Server SMTP viene utilizzato per spedire caratteri nel formato ASCII (o 7-bit), ( il TCP supporta sequenze di 8-bit), pertanto l'ultimo bit viene impostato a zero. SMTP relay : come già accennato il ruolo principale di un Server SMTP è quello di far funzionare il relay dei messaggi di posta. Ma il relay dei messaggi di posta elettronica non è un concetto semplice.
Per inviare un messaggio, la prima cosa che deve fare il Client SMTP è quella di inviare un comando al Server SMTP specificando nel Reverse-Path o MAIL FROM:<elenco host> il percorso che deve fare a ritroso il Server SMTP per rispondere al Client nel caso in cui dovesse ritornare al mittente una mail contenente errori di spedizione. Il primo host nel Reverse-Path è in pratica la casella di posta del Client (o colui che invia i comandi di posta).
Nel comando successivo, sempre il Client SMTP, indica al Server SMTP il Forward-Path o RCPT TO:<elenco host> per l'inoltro del messaggio di posta. Queste due informazioni sono necessarie per descrivere il percorso che la mail dovrà fare dal mittente al destinatario, il primo host o indirizzo di posta presente in questo elenco dovrà essere quello del Server SMTP (o colui che riceve i comandi di posta), ma in questo caso non è necessario, se manca sarà il Server SMTP stesso ad aggiungerlo.
I due percorsi sono fondamentali per il Server SMTP in quanto attraverso il Reverse-Path è in grado di rispondere al Client o host da cui riceve i comandi, mentre attraverso il Forward-Path è in grado di individuare i successivi Server STMP a cui inviare comandi.
È a questo punto che interviene il relay. Il relay in pratica è l'operazione attraverso cui il server SMTP toglie il primo host che trova nella coda del Forward-Path e lo aggiunge al primo posto nella coda del Reverse-Path. Con questa sostituzione può ora inviare i comandi al server SMTP successivo facendo fare un passo in avanti al nostro messaggio di posta, e così via fino a quando non si raggiunge la destinazione o la fine della coda nel Forward-Path.
Altro concetto da tenere in mente in questa operazione è la distinzione tra host e casella di posta elettronica. Sia nel Reverse che nel Forward Path l'host verrà indicato in questo modo: @dominio, mentre la casella di posta in quest'altro: utente@dominio. La casella di posta elettronica contiene quindi due informazioni una relativa all'utente a cui si deve consegnare la posta (solo se questa compare nel RCPT TO), e l'altra relativa all'host. Questo aspetto chiarisce così anche il concetto di Forward di un messaggio di posta elettronica, ovvero il Server SMTP è in grado di inoltrare il messaggio ad un indirizzo di posta a lui conosciuto (o conosciuto nel dominio a cui il Server appartiene) nel caso in cui il Client Smtp non abbia specificato alcun indirizzo di posta nel Forward-Path, ma ad esempio soltanto l'indirizzo di un dominio.
Esempio di relay:
Prima di descrivere il relay bisogna ricordare che la comunicazione SMTP viene aperta con il comando HELO inviato dal Client al Server o da Server a Server, e chiusa con il comando QUIT. Nel comando HELO si può indicare il proprio nome o meglio il nome dell'host del Client SMTP.
C.Smtp1: HELO host1
S.Smtp1: Hello host1
C.Smtp1: MAIL FROM:<user1@host1>
S.Smtp1: ok.
C.Smtp1: RCPT TO:<@host2,@host3:user4@host4,user5@host5>
S.Smtp1: ok.
C.Smtp1: DATA:
Prova messaggio di posta
.
S.Smtp1: ok.
C.Smtp1: QUIT
Nel nostro esempio il Client Smtp1 coincide con host1, mentre non necessariamente il Server Smtp1 deve essere uguale al primo host presente nel Forward-Path, pertanto potrebbe essere S.Smtp1=host2, ma anche non esserlo. Per comodità supponiamo che il Server Smtp1 sia host2, ma se così non fosse stato si sarebbe semplicemente allungata la coda nel Reverse-Path, il Server Smtp1 avrebbe aggiunto il proprio dominio all'inizio della coda e così avrebbero fatto tutti gli altri server Smtp qualora non ci sia corrispondenza tra il domino del server Smtp che riceve i comandi ed il primo host presente nella coda del Forward-Path, del resto se un server Smtp sta nel mezzo in una comunicazione o si inserisce specificando i suoi dati, oppure semplicemente fa un eco del messaggio al server successivo senza effettuare alcuna sostituzione.
Non per essere noiosi, ma nemmeno il Client Smtp1 dovrà necessariamente essere uguale all'host1, del resto il primo host del Reverse-Path indica semplicemente il primo indirizzo a cui ritornare eventuali mail contenenti errori.
A questo punto il Server Smtp1 inizierà una comunicazione con il Server Smtp2 che coincide con il dominio @host3 in questo modo:
S.Smtp1: HELO host2
S.Smtp2: Hello host2
S.Smtp1: MAIL FROM:<@hot2,user1@host1>
S.Smtp2: ok.
S.Smtp1: RCPT TO:<@host3:user4@host4,user5@host5>
S.Smtp2: ok.
S.Smtp1: DATA:
Prova messaggio di posta
.
S.Smtp2: ok.
S.Smtp1: QUIT
A questo punto il server Smtp2 che coincide con host3 consegna il messaggio all'utente user4@host4 (evidentemente sa come fare il forward di questo messaggio all'host4), in alternativa l'host3 avrebbe iniziato una comunicazione SMTP con l'host4 oppure se non in grado restituito un errore a user1@host1 grazie alle informazioni contenute nel Reverse-Path, i server avrebbero saputo come raggiungerlo a ritroso.
S.Smtp2: HELO host3
S.Smtp3: Hello
S.Smtp2: MAIL FROM:<@host3,@hot2,user1@host1>
S.Smtp3: ok.
S.Smtp2: RCPT TO:<user5@host5>
S.Smtp3: ok.
S.Smtp2: DATA:
Prova messaggio di posta
.
S.Smtp3: ok.
S.Smtp2: QUIT
A questo punto è stato recapitato il messaggio all'ultimo destinatario presente nella coda.
Possiamo ora focalizzare la nostra attenzione su due concetti emersi da quanto detto sopra:
Il Forward di posta elettronica è il sistema attraverso cui il Server SMTP consegna il messaggio ad un destinatario diverso da quello indicato dal mittente. Il perché lo faccia poco importa, sicuramente lo fa in quanto conosce all'interno del suo dominio il nome dell'indirizzo di posta o del dominio a cui deve inoltrare il messaggio.
Il Relay di posta elettronica è il sistema attraverso cui il Server SMTP invia i comandi ricevuti da un Client SMTP (o da un Server SMTP precedente), ad un server successivo, dello stesso dominio o appartenente ad un altro dominio nel modo esposto sopra.
Per concludere con il relay dei messaggi di posta non ci resta che esaminare eventuali errori durante la consegna di un messaggio da un server ad un altro. Ipotizziamo nell'esempio sopra riportato che lo user5@host5 non esista, o per qualche motivo il server Smtp3 deve restituire un errore indicando il non esito della consegna. A chi restituire l'errore? Sicuramente al primo host indicato nel Reverse-Path ovvero @host3. In questa operazione di relay inverso a rigor di logica si dovrebbero invertire i percorsi, in pratica il Forward-Path diventa uguale al contenuto presente nel Reverse-Path, ma non viceversa. L'operazione è nota con il termine di relayed, il Reverse-Path diventa nullo per evitare che un messaggio generi durante la trasmissione un loop ovvero venga ripetutamente inviato avanti ed indietro da un server all'altro. È l'unico caso in cui il Reverse-Path o MAIL FROM non sia richiesto, o meglio è richiesto il comando: MAIL FROM:<>.
Nella realtà il protocollo SMTP non funziona esattamente nel modo descritto sopra. Non per errata implementazione del protocollo, ma in quanto il concetto di relay va inteso non tanto come un difetto di SMTP, ma bensì come la sua caratteristica fondamentale.
Da quanto detto sopra con l'RFC 821 (anno 1982) ad oggi si è assistito ad una corsa ai ripari per evitare il collasso di un server SMTP, ma i problemi di oggi circa l'abuso del servizio di posta di un server non erano certo i problemi di allora. Non si può quindi ignorare l'origine del servizio SMTP quando e se si vuole capire il suo funzionamento sui server moderni.
Coscienti di quanto detto sopra si può cominciare con l'installare il servizio SMTP presente in Windows 2000 semplicemente aggiungendo l'applicazione dal pannello di controllo.
Ora il server avrà creato un nuovo oggetto all'interno dello Snap-In di IIS per la configurazione del servizio SMTP ed alcune sottodirettori nella direttori di installazione di IIS.
Il ruolo del servizio DNS
La novità sostanziale si ha con l'introduzione del record MX. Questo da un lato richiede che gli indirizzi di posta siano espressi correttamente e non tramite alias o abbreviazioni:Es: <user@nome.com> e non <user@nome>, dall'altro evita che le informazioni relative al relay siano contenute nei campi MAIL FROM ed RCPT TO.
In pratica il server SMTP che riceve il comando RCPT TO conosce il percorso (Forward-Path) che dovrà fare il messaggio per raggiungere il destinatario in base alle informazioni contenute nel record MX del dominio a cui appartiene l'indirizzo di posta del destinatario stesso.
Esempio: l'informazione: RCPT TO:<@mail.pippo.it: user@pluto.com> diventa: RCPT TO:<user@pluto.com> mentre il record MX di pluto.com corrisponde a mail.pippo.it, non è più necessario per il client SMTP specificare il percorso che dovrà fare il messaggio per raggiungere il server SMTP del destinatario.
In altri termini i server SMTP devono utilizzare l'informazione contenuta nel record MX del dominio dell'indirizzo di destinazione per conoscere il nome del server SMTP a cui devono consegnare la posta.
Se viene indicato nel Forward o Reverse Path un elenco di host e caselle di posta elettronica il Server SMTP prenderà in considerazione soltanto gli indirizzi di posta eliminando le informazioni relative agli host.
Così il comando MAIL TO:<@host1,@host2,pippo@host3> diverrà soltanto <pippo@host3> altrettanto dicasi per il comando RCPT TO.
In fine un messaggio di posta elettronica si compone di due parti: l'header o intestazione del messaggio ed il body o corpo del messaggio.
Nell'intestazione sarà contenuto il valore indicato in MAIL FROM, l'indirizzo IP del Client SMTP che ha iniziato l'invio del messaggio ed il campo FOR ovvero l'indirizzo del destinatario di posta.
Queste informazioni sono sufficienti per individuare il reale mittente di un messaggio di posta elettronica, del resto ciascun server SMTP che accetta il relay dei messaggi dovrà aggiungere questa informazione nell'header del messaggio di posta ed avrà una forma simile:
Received FROM <indirizzo mittente> ([indirizzo IP del Client SMTP]) FOR <indirizzo destinatario>.
Il server SMTP di default esiste sempre in quanto associato all'indirizzo IP della macchina o meglio quello specificato nelle proprietà della scheda di rete, in pratica il servizio SMTP come tutti i servizi TCP/IP ha bisogno di uno o più indirizzi IP relativi all'interfaccia di rete attraverso cui rispondere alle richieste. Possono essere tutti gli indirizzi IP, oppure, (se la rete è di tipo multi-homing) solo alcuni di questi.
È possibile creare ulteriori Server SMTP su indirizzi IP diversi o su diverse porte TCP/IP (la porta di default è la 25). A questo punto per permettere a qualsiasi Client o Server SMTP (incluso questo) di spedire i messaggi di posta, ovvero di fare il "relay" dei messaggi è necessario configurare la scheda "Access" che contiene le informazioni sul Relay. Senza questa configurazione non si sarà in grado di spedire messaggi di posta in quanto il Relay di base è disabilitato. Si consiglia di disattivare da subito il check relativo all'opzione Active Directory riportato in fondo in quanto crea seri problemi di sicurezza lasciando sostanzialmente indeterminato l'identificazione del computer a cui si permette di fare il relay. Solo i computer riportati nella lista possono fare il relay tra cui l'indirizzo IP del server stesso.
Nell'esempio sopra sono ammessi al relay i computer con indirizzo IP 172.16.3.1 che è l'indirizzo del server stesso e un computer remoto con IP 213.152.193.6, la lista si può espandere anche a interi intervalli di indirizzi IP oppure a nomi di dominio, anche se specificare il nome di un dominio spesso comporta un enorme lavoro per il servizio in quanto per ciascuna sessione dovrà contattare il server DNS specificato nelle proprietà del protocollo TCP/IP della scheda di rete e prima ancora di accettare il relay dovrà fare un "NSLOOKUP" verificando l'esistenza e le informazioni sull'indirizzo IP corrispondente al contenuto del record DNS di reverse: PTR.
Il Server SMTP di Microsoft non è un server di Posta elettronica completo in quanto manca del servizio POP e IMAP, tutti i messaggi destinati al server stesso vengono consegnati in un'unica cartella denominata "Drop" presente sul server.
