la posta elettronica

Transcript

1 la posta elettronica progettazione di un servizio di rete giuseppe di battista e maurizio patrignani nota di copyright questo insieme di slides è protetto dalle leggi sul copyright il titolo ed il copyright relativi alle slides (inclusi, ma non limitatamente, immagini, foto, animazioni, video, audio, musica e testo) sono di proprietà degli autori indicati sulla prima pagina le slides possono essere riprodotte ed utilizzate liberamente, non a fini di lucro, da università e scuole pubbliche e da istituti pubblici di ricerca ogni altro uso o riproduzione è vietata, se non esplicitamente autorizzata per iscritto, a priori, da parte degli autori l'informazione contenuta in queste slides è fornita per scopi didattici e non può essere usata in progetti di reti, impianti, prodotti, ecc. gli autori non si assumono nessuna responsabilità per il contenuto delle slides, che sono comunque soggette a cambiamento questa nota di copyright non deve essere mai rimossa e deve essere riportata anche in casi di uso parziale 1

2 progettazione di un servizio di rete oltre ad illustrare il servizio della posta elettronica cercheremo di rispondere alle domande: quali sono le fasi della progettazione di un servizio di rete? quali scelte di progetto sono coinvolte, quando hanno luogo e in base a quali princìpi? ciò può essere utile in almeno tre diversi contesti: 1) in fase di sintesi di un nuovo servizio 2) in fase di analisi di un servizio esistente 3) in fase documentale, per organizzare in maniera sistematica la descrizione di un servizio il servizio di posta elettronica è uno dei più consolidati ed usati nella rete (in uso da molti anni, il più usato prima dell avvento del Web) fasi della progettazione di un servizio analisi dei requisiti: definisco le caratteristiche del servizio (specifiche, necessità, priorità, aspetti critici...) specifica delle primitive di servizio: definisco l interfaccia al servizio (le funzioni messe a disposizione dal servizio a chi lo usa) definizione dell architettura e delle operazioni: definisco le applicazioni coinvolte nella gestione del servizio, i servizi ausiliari di rete necessari, gli ambienti di supporto, le operazioni e i flussi di informazione definizione dei protocolli: per ogni tipologia di comunicazione definisco la struttura delle PDU (envelope e data), gli stati e le procedure (regole d uso) del protocollo 2

3 attenzione: questa trattazione non comprende gli aspetti relativi al dimensionamento (considerazioni sull efficienza, stime del volume di traffico, ecc.) ed alla dislocazione (posizionamento e numerosità dei server in rapporto all ubicazione e al numero degli utenti, al carico, ecc.) del servizio sulla rete analisi dei requisiti servizio di posta elettronica gestione dei messaggi in partenza spedizione di messaggi ad uno o più destinatari ricezione di messaggi in arrivo gestione messaggi ricevuti preservazione della privatezza dei dati sicurezza della consegna (si ammette anche una consegna differita nel tempo) configurazione non onerosa da parte degli utenti finali interfaccia utente elementare ed intuitiva 3

4 primitive di servizio servizio di posta elettronica gestione dei messaggi in partenza composizione di un messaggio memorizzazione di un messaggio cancellazione di un messaggio caricamento di un messaggio gestione messaggi ricevuti lettura dei messaggi memorizzazione di un messaggio cancellazione di un messaggio stampa di un messaggio ipotesi di architettura connessione diretta mittente-destinatario mitt processo del mittente des processo del destinatario vantaggi: semplicità di implementazione recapito in tempo reale del messaggio certezza della consegna svantaggi: il mittente non può mandare il messaggio se il destinatario non ha lanciato il suo processo oppure ha spento il computer il mittente deve ricordare il nome della macchina del destinatario non è chiaro come si possa autenticare il destinatario 4

5 seconda ipotesi di architettura server del dominio del destinatario mitt server server di ricezione del dominio del destinatario des processo del mittente processo del destinatario vantaggi: i processi di invio e ricezione del messaggio sono disaccoppiati il ricevente può essere autenticato dal server il mittente deve ricordare solo il dominio del destinatario svantaggi: il server può essere guasto o impegnato, e il mittente può chiudere il suo programma prima che il messaggio sia recapitato architettura definitiva server in invio e in ricezione server di inoltro del mittente server server server ausiliari del dominio del destinatario server mitt server primario del dominio del destinatario server des processo del mittente processo del destinatario 5

6 tipologia e molteplicità delle applicazioni due tipi di applicazione sono coinvolte nel servizio: MUA (Mail User Agent) detto anche mailer, implementa un interfaccia per l utente l utente lo manda in esecuzione quando vuole accedere al servizio di posta elettronica (e lo può interrompere subito dopo aver usato le primitive che gli interessano) MTA (Mail Transmission Agent) è un applicazione che fa da intermediaria nel processo di trasmissione del messaggio dalla sorgente fino alla destinazione il servizio è offerto in maniera il più possibile continuativa e stabile nel tempo architettura ruolo delle macchine che ospitano un MTA: Outgoing Mail Server la macchina il cui MTA è quello a cui fa diretto riferimento il MUA per l inoltro della posta Mail exchanger ogni dominio definisce nel DNS una lista di host (in ordine di priorità) che ospitano gli MTA che sono incaricati di ricevere posta per quel dominio Incoming Mail Server la macchina che ospita l MTA da cui il MUA ritira la posta generalmente coincide con il Mail exchanger primario del dominio 6

7 configurazione del MUA il requisito che il MUA sia facilmente configurabile è soddisfatto: si richiede la sola specifica dell outgoing mail server e dell incoming mail server MUA MTA outgoing mail server MTA MTA incoming mail server MTA MTA architettura di dettaglio talvolta il MTA che è ospitato sull outgoing mail server è suddiviso in due processi, il primo si chiama MSA (Message Submission Agent) ed è quello a cui il MUA si rivolge per spedire la posta ed il secondo è il vero e proprio MTA, che cura la spedizione al MTA del dominio del destinatario lo stesso avviene sull incoming mail server, nel quale si distinguono due processi, il primo è l MTA che riceve la posta dal dominio del mittente mentre il secondo si chiama MDA (Mail Delivery Agent) ed è responsabile del recapito all utente 7

8 definizione delle operazioni è necessario definire (anche a più livelli di dettaglio successivi) come ogni primitiva possa essere evasa tramite una successione di operazioni eseguite dalle applicazioni coinvolte esempio tutte le primitive di gestione dei messaggi in partenza e dei messaggi ricevuti sono delegati al MUA... quando l utente richiede il salvataggio della mail, il MUA salva il documento nel file system locale... alla primitiva salvataggio della mail corrispondono le seguenti azioni: il MUA accede al file delle mail salvate nel file system locale, creandolo nel caso non esista, e accoda ad esso il testo della nuova mail... azioni per evadere la primitiva: spedizione di un messaggio il MUA trasmette il messaggio al suo Outgoing Mail Server il Mail Server richiede (tramite il DNS) la lista dei Mail exchanger del dominio destinazione (in ordine di priorità) e cerca di trasmettere il messaggio ad uno di essi; se fallisce con tutti, salva la mail nel suo file system e riprova ad inoltrarla ad intervalli di tempo regolari; se fallisce per tre giorni consecutivi notifica al mittente il fallimento un Mail exchanger secondario cerca ad intervalli di tempo regolari di trasmettere il messaggio al Mail exchanger primario 8

9 servizi ausiliari al servizio di posta elettronica DNS (Domain Name System): necessario all Outgoing Mail Server per ottenere la lista e la priorità dei Mail exchanger del dominio destinazione X-Server: sistema per la gestione di un ambiente a finestre di cui può far uso il MUA per offrire un interfaccia grafica all utente NFS (Network File System): se l incoming mail server non coincide con il Mail exchanger primario del dominio destinazione, l incoming mail server deve poter accedere ai file delle mail tramite un sistema per il file system distribuito MTA NFS MTA MUA Mail exchanger primario incoming mail server servizi ausiliari alla posta elettronica esempio di richiesta del Mail exchanger al DNS <utente@poincare ~>nslookup Default Server: poincare.dia.uniroma3.it Address: > set type=mx > dia.uniroma3.it Server: poincare.dia.uniroma3.it Address: dia.uniroma3.it preference = 50, mail exchanger = mail.uniroma3.it dia.uniroma3.it preference = 60, mail exchanger = luna.uniroma3.it dia.uniroma3.it preference = 0, mail exchanger = mail.dia.uniroma3.it dia.uniroma3.it nameserver = mail.uniroma3.it dia.uniroma3.it nameserver = luna.uniroma3.it dia.uniroma3.it nameserver = dns.nis.garr.it mail.uniroma3.it internet address = luna.uniroma3.it internet address = mail.dia.uniroma3.it internet address = dns.nis.garr.it internet address = > 9

10 servizi ausiliari alla posta elettronica esempio di richiesta del Mail exchanger al DNS ~>dig -t MX fastweb.it < ;; QUESTION SECTION: ;fastweb.it. IN MX ;; ANSWER SECTION: fastweb.it IN MX 15 smail4.fastweb.it. fastweb.it IN MX 50 mxk1.fastweb.it. fastweb.it IN MX 50 mxk2.fastweb.it. fastweb.it IN MX 15 smail3.fastweb.it < ;; ADDITIONAL SECTION: smail3.fastweb.it IN A smail4.fastweb.it IN A < ;; Query time: 123 msec ;; SERVER: #53( ) ;; WHEN: Mon Dec 28 10:36: ;; MSG SIZE rcvd: 282 > primo tipo di flusso di informazione tra il Mail User Agent (client) e il suo Outgoing Mail Server (server) e tra i vari Mail Transfer Agent che si trasmettono i messaggi fino a che questi non arrivano al Mail exchanger primario del dominio destinazione conversazione tra un client che intende trasferire uno o più messaggi e un server che ha facoltà di accettarli non occorre autenticare gli interlocutori perché o entrambi hanno i privilegi di amministratore, oppure uno di essi è quello del mittente (e non si considera vitale assicurarsi che il mittente corrisponda a quanto dichiarato) 10

11 secondo tipo di flusso di informazione tra un Mail User Agent (client) e il Mail Transfer Agent (server) che conserva la posta dell utente il client si informa sul numero e la dimensione dei messaggi conservati dal server e destinati ad un utente indispensabile l autenticazione del destinatario per preservare la privatezza dei dati necessità di conoscere il numero e la dimensione dei messaggi prima di procedere alla loro trasmissione esigenza di poter cancellare i messaggi senza trasferirli o di leggerli senza cancellarli definizione delle comunicazioni data la diversità delle due tipologie dei flussi di informazione si decide di ricorrere a due sistemi di comunicazione differenti per entrambi i sistemi si riconosce la necessità di trasferire una quantità di dati non quantificabile a priori (un messaggio può essere imprevedibilmente lungo) è conveniente, dunque, istituire in entrambi i casi un canale di comunicazione connesso (uso di TCP su IP) il progetto delle tipologie di comunicazione si riduce dunque alla definizione del protocollo relativo al trasferimento dei messaggi fino al server del dominio di destinazione (smtp) e del protocollo relativo al trasferimento del messaggio dal server del dominio destinazione al MUA del destinatario (per esempio pop3) 11

12 aspetti della definizione di un protocollo Protocol Data Unit descrizione del formato delle informazioni che vengono trasmesse nella comunicazione divise in: richieste del client (comandi + argomenti) risposte del server procedure le regole d uso del protocollo, le regole sintattiche, l effetto dei comandi stati gli stati che le due applicazioni assumono a seguito dei comandi emessi o delle risposte ricevute, i comandi ammessi in ogni stato simple mail transfer protocol definito la prima volta nella rfc 821 e quindi rivisto in varie rfc, tra cui le 5321 e 5322 usa la porta well known TCP 25 protocollo molto semplice, text based il body dei messaggi di posta elettronica è definito nella rfc 12

13 simple mail transfer protocol pdu - richieste del client HELO <dominio> comando di apertura: inizia qualsiasi conversazione in smtp MAIL FROM:<mittente> iniza il trasferimento di una mail per uno o più destinatari RCPT TO:<destinatario> individua un destinatario se la mail è destinata a più riceventi, il comando viene iterato se il destinatario non è del dominio locale, è sottinteso che si richiede all applicazione ricevente di fare da intermediaria verso i Mail exchanger del dominio (Relaying) simple mail transfer protocol pdu - richieste del client DATA il ricevente tratterà le linee seguenti come facenti parte della mail finché l applicazione che inoltra la mail non invierà la combinazione <CRLF>. <CRLF> (un punto ad inizio di riga seguito da un accapo) in trasmissione tutte le righe del messaggio vengono preventivamente processate e ai punti ad inizio di riga vengono sostituiti dei doppi punti (.. ) in ricezione avviene la sostituzione inversa RSET reset: il trasferimento corrente viene abortito (il comando non viene riconosciuto se inserito all interno di una mail) 13

14 simple mail transfer protocol pdu - richieste del client VRFY <destinatario> richiede al ricevente di confermare che il destinatario esiste EXPN <alias> richiede al ricevente di confermare che l alias di posta specificato corrisponde ad una lista di utenti (che eventualmente viene ritornata dal ricevente) HELP mostra tutti i comandi disponibili HELP <comando> mostra un piccolo help sul comando specificato simple mail transfer protocol pdu - richieste del client NOOP non fa nulla oltre a richiedere una risposta affermativa alla controparte QUIT termina la comunicazione entrambe le parti chiudono la connessione 14

15 simple mail transfer protocol pdu - risposte del server sono delle brevi frasi precedute da un codice numerico ecco degli esempi: 500 Command unrecognized 501 Syntax error in parameters 502 Command not implemented 503 Bad sequence of commands 504 Command parameter not implemented 211 System status, or system help reply 214 Help message 250 Requested mail action okay, completed 552 Requested mail action aborted: exceeded storage allocation 553 Requested action not taken: mailbox name not allowed 354 Enter mail, end with "." on a line by itself 554 Transaction failed simple mail transfer protocol procedure e stati la transazione è iniziata dal comando MAIL che deve essere seguito dal comando RCPT (eventualmente iterato) e poi dal comando DATA Il server entra in uno stato di accettazione del messaggio che termina nel momento in cui riceve la sequenza <CRLF>.<CRLF> nessun comando viene accettato durante il trasferimento del messaggio la conversazione è terminata dal comando QUIT 15

16 esempio di spedizione di mail in smtp ~>telnet mail.dia.uniroma3.it mail.dia.uniroma3.it ESMTP Sendmail 8.8.7/8.8.7; Fri, 18 Dec :56: HELO dia.uniroma3.it 250 mail.dia.uniroma3.it Hello poincare [ ], pleased to meet you ~>telnet mail.dia.uniroma3.it mail.dia.uniroma3.it ESMTP Sendmail 8.8.7/8.8.7; Fri, 18 Dec :58: MAIL 503 Polite people say HELO first esempio di spedizione di mail in smtp MAIL 250 OK RCPT 250 OK RCPT 550 No such user here RCPT 250 OK DATA 354: Enter mail, end with "." on a line by itself Blah blah blah... Blah blah blah OK QUIT 16

17 post office protocol 3 usa la porta TCP well known 110 specificato nelle rfc 1725 e 1939 post office protocol 3 i comandi del pop3 sono composti di quattro lettere le risposte del server sono precedute da un +OK se positive o da un -ERR se negative l uso di questi comandi è esemplificato nelle pagine seguenti USER username PASS password STAT LIST LIST numero messaggio RETR numero messaggio DELE numero messaggio NOOP RSET QUIT 17

18 pop3 esempio di sessione logging, autenticazione e chiusura +OK POP3 mail v4.47 server ready USER patrigna +OK User name accepted, password please PASS paperino +OK Mailbox open, 4 messages -ERR invalid password -ERR unable to lock maildrop -ERR maildrop already locked NOOP +OK QUIT +OK Sayonara LIST +OK 2 messages (320 octets) LIST 2 +OK LIST 3 -ERR no such message, only 2 messages in maildrop STAT +OK pop3 esempio di sessione elenco dei messaggi per l utente 18

19 pop3 esempio di sessione richiesta di un messaggio RETR 1 +OK 120 octets <il server POP3 inserisce qui l intero messaggio>. RETR 3 -ERR no such message DELE 1 +OK message 1 deleted DELE 1 -ERR message 1 already deleted RSET +OK maildrop has 2 messages (320 octets) pop3 procedure e stati una sessione pop3 attraversa vari stati: quando la connessione TCP è stata instaurata, pop3 entra nello stato AUTHORIZATION - in questo stato il client deve identificarsi quando ciò è avvenuto, il server acquisisce le risorse associate al client e la sessione entra nello stato TRANSACTION - in questo stato il client richiede servizi da parte del server quando il client spedisce il comando QUIT, la sessione entra nello stato UPDATE - in questo stato il server rilascia le risorse e la connessione TCP viene chiusa 19