MailServer Daniele Dolfini, Giovanni Franza, Neil Otupacca IPAP3 2010/2011 Relazione sulla costruzione del sistema di messaggeria elettronica. Parte relativa ai server Giovanni Franza Sono stati implementati tre servizi relativi alle tre modalità di accesso al servizio 1. SSL per accesso amministrativo 2. SMTP per l'inserimento dei messaggi 3. POP3 per la lettura dei messaggi Tutti i tre servizi sono stati implementati come classi che estendono la classe Thread, dato che la loro principale caratteristica è quella di funzionare indipendentemente. La classe principale del pacchetto (MailServer), che contiene il metodo main(), istanzia le tre classi SSL, SMTP, POP e le attiva utilizzando il metodo start(), disponibile in quanto le classi estendono Thread. La classe principale attende che un operatore dia un invio sulla console per terminare tutte le operazioni. In tutti e tre i servizi si ottiene un socket facendo uso di una factory (SSLSocketFactory per SSL e SocketFactory per SMTP e POP) in modo da semplificare al massimo le operazioni, sopratutto per ció che riguarda SSL. Ottenuto il socket ci si mette in attesa e, ricevuto una connessione, si attiva un Worker. Ogni worker estende la rispettiva classe (SSLWorker estende SSL, SMTPworker estende SMTP, POPWorker estende POP) e quindi Thread, per cui sono eseguibili in maniera asincrona e permettono quindi di non dover serializzare le richieste, operando quindi come un server reale. Tutti i Worker sono realizzati con la massima seplicità e sono classi separate a causa delle loro particolarità: SSLWorker individua una parte minimale degli header ovvero quello relativo al GET/POST dal quale puó reperire la parte interna della URL cercata e quello relativo al Content-Length indispensabile per la lettura dei dati che il POST accoda alla richiesta. SMTPWorker e POPWorker fanno entrambi uso di una macchina a stati finiti realizzata tramite una classe (StateManager) condivisa in quanto sufficentemente generica. La classe StateManager viene nutrita con oggetti di tipo Action che corrispondono alle azioni lecitamente richieste alla StateMachine. Per introdurre questi oggetti la classe StateMachine dispone di un metodo add( Action a ) il quale immagazzina l'azione e la mette in relazione con gli stati corretti. Ció viene fatto a partire da costanti simboliche (StateManager.SAME, StateManager.CHANGE, StateManager.ABORT) che definiscono le operazioni senza che sia necessario computare manualmente la tabella degli stati. La StateMachine ha inoltre un medodo nexthop( String data, Integer state ) che verifica la fattibilità del comando data ricevuto in relazione allo stato state. MailServer, pagina 1 di 5
Dato che in alcuni casi le verifiche sono complesse è stata introdotta una interfaccia ( ) la quale definisce due metodi ( verify( String, Object ) e getresponse( Object ) che permettono di eseguire verifiche e di dare risposte. Per essere chiari: quando il comando ricevuto identifica un utente ( comando USER di POP3 o comando RCPT TO: di SMTP ) occorre chiamare un opportuna classe per conoscere l'esistenza dell'utente. Ció viene fatto con una classe User che viene istanziata e passata come parametro di creazione della corrispondente Action. Tale classe ha un metodo verify al quale viene passato come primo parametro il nome dell'utente (in realtà l'indirizzo di email) ed un null come secondo parametro. La funzione cerca l'utente e, se esistente, ritorna un puntatore ad un oggetto persistente con i dati, come gestito dalla parte di gestione utenti, mailbos e persistenza preparata da Nello Otupacca. La scelta puó sembrare bizzarra ma la sua ratio si vede nella gestione del comando PASS al quale è abbinata la password: la Action relativa ha un puntatore ad un oggetto Pass che ha il metodo verify capace di comparare la password con quella immagazzinata nell'oggetto Mailbox individuato dalla classe User appena vista. Il passaggio dell'informazione tra le due Action è compito di StateManager il quale memorizza l'oggetto Mailbox tornato da User.verify() e lo ripropone come parametro a Pass.verify. In sostanza l'oggetto StateManager gestisce uno stato interno costituito dallo stato vero e proprio (livello del diaologo con il client) e dall'oggetto (mantenuto volutamente generico) che in questo caso indica la mailbox. Ovviamemte gli oggetti StateManager sono creati e configurati dagli oggetti POP e SMTP e poi sono ereditati dai relativi Workers che li duplicano per mantenere disaccopiati i relatii thread (ricordiamoci che lo StateManager contiene uno stato e quindi ne serve uno per ogni dialogo attivo perna in indescrivibile confusione che renderebbe l'applicazione non funzionante. Sistemati i protocolli POP e SMTP occorre tornare brevemente al protocollo SSL in quanto possiede un'altra particolarità. Per rendere piú sicuro possibile il protocollo le azioni di GET e POST non accedono al filesystem ma intergiscono con opportuni listener. Nell'attivare il protocollo SSL vengono registrati dei Listener (che devono implementare l'interfaccia ServerHandler). Quando il server SSL riceve una GET o una POST passa tutto il ricevuto (headers ed eventuali dati) come una stringa al metodo run( String ) del listener associato alla stringa interna alla URL ricevuta per poi ritrasmettere la stringa resa dal metodo al client. Ció rende piú robusto il server lasciandolo, allo stesso tempo, flessibile a sufficenza per introdurre nuove classi. Il compito di registrare gli handler è nella funzione Main nella già citata classe MailServer. MailServer, pagina 2 di 5
Il quadro complessivo delle classi realizzate è Classe Tipo Scopo MailServer Classe Attiva tutto il server SSL Classe Gestisce il protocollo SSL SMTP Classe Gestisce il protocollo SMTP POP Classe Gestisce il protocollo POP3 SSLWorker Classe Gestisce la singola connessione SSL SMTPWorker Classe Gestisce la singola ricezione di un messaggio in ingresso POPWorker Classe Gestisce il singolo dialogo con un client che scarica la sua mailbox StateManager Classe Gestisce lo stato di ogni dialogo POP3/SMTP Action Classe Gestisce la singola fase di ogni dialogo POP3/SMTP Interfaccia Gestisce i necessati controlli accessioni a particolari Action User Classe Gestisce identificazione Mailbox per SMTP e POP3 Pass Classe Gestisce autenticazione Mailbox per POP3 Stat Classe Reperisce le statistiche per Mailbox per POP3 List Classe Lista le mail contenute in una Mailbox per POP3 Uidl Classe Lista hash per le mail in una Mailbox per POP3 Retr Classe Reperisce una Mail in POP3 Dele Classe Cancella una Mail in POP3 Dump Classe Utile per debug POP3/SMTP ServerHandler Interfaccia Definisce un'interfaccia per il listener su SSL ServerEcho Classe Listener di debug per SSL Gerarchia delle classi Superclasse/Interfaccia Classe Sottoclasse Thread SSL SSLWorker Thread SMTP SMTPWorker Thread POP POPWorker StateManager Action User Pass Stat MailServer, pagina 3 di 5
ServerHandler List Uidl Dele Dump ServerEcho Composizioni Classe SSL SMTP POP SSLWorker SMTPWorker POPWorker Componenti HashMap<String,ServerHandler> StateManager, User StateManager, User, Pass, Stat, List, Uidl, Dele SSL, Socket SMTP, Socket Pop, Socket Users e Messages Neil Otupacca La parte di gestione degli utenti e dei messaggi è stata implementata principalmente con due classi: User e Message, queste ultime sono delle sottoclassi di PersistentObject la quale si occupa di rendere persistenti gli oggetti che identificano rispettivamente gli utenti e i propri messaggi. Allo stato attuale, la persistenza è realizzata tramite un database MySQL locale rispetto al server, ad ogni modo, le classi User e Message sono realizzate in modo da essere indipendenti dal tipo di persistenza utilizzata che, all occorrenza, potrebbe essere implementata su un altro supporto. Sebbene i messaggi di ogni utente siano salvati su un unica tabella messages (discriminati da una FOREIGN KEY che fa riferimento alla PRIMARY KEY dell utente stesso nella tabella users ), concettualmente i messaggi sono associati all utente proprietario per dipendenza diretta. Questo significa che i messaggi (i relativi oggetti) sono accessibili solo attraverso l utente proprietario e, di conseguenza, tramite l oggetto utente relativo. Sono inoltre disponibili due ulteriori classi di iterazione con le quali è possibili iterare la lista di tutti gli utenti e tutti i messaggi di un determinato utente. Suddetti iteratori sono ottenuti dalla classe User: con il metodo statico getuseriterator() si ottiene l iteratore per gli utenti, con getmessageiterator() invece, si ottiene l iteratore per i messaggi appartenenti all utente identificato dall oggetto user. Dato che il tipo di persistenza è trasparente alle classi User e Message, le operazioni di lettura, aggiornamento e scrittura su database sono implicite. Ergo, quando si crea ad esempio un oggetto utente, passando al suo costruttore le sue properties, l utente stesso viene aggiunto al database immediatamente; modificando tramite gli appositi setters i dati di un utente, tali modifiche vengono aggiornate nella relativa tabella, in sintesi, l oggetto in memoria è sempre consistente con la relativa immagine sul database. Le classi User e Message sono a disposizione sia per essere utilizzate in un contesto di richiesta via SMTP e POP, che per una richiesta HTTPS. MailServer, pagina 4 di 5
In quest ultimo caso, tra la ricezione di un messaggio HTTP e l eventuale interazione con User/Message si frappone la classe WebAdminPage che, dopo aver analizzato il tipo di richiesta, si avvale di tali classi. A fare da corollario alle due classi pricipali della sezione mailbox, sono state implementate svariate classi di utility per svolgere compiti di parsing sui dati in ricezione, eccone una breve descrizione: RFC822Parser Una volta istanziato un oggetto di questa classe, passando al suo constructor la stringa contenente il QTC (headers + body), è possibile estrarre varie informazioni quali ad esempio il subject, il mittente ecc. HTTPRequestParser Un oggetto di questo tipo viene istanziato passando al suo constructor la stringa della richiesta HTTP ricevuta. In seguito sarà possibile estrarre svariate informazioni indispensabili per l interpretazione della request. In particolar modo, sono disponibili i dettagli della URL, del metodo (GET/POST), gli headers e le variabili di GET/POST. FriendlyNameAddress MySQLDateFormatter Questa classe permette di determinare l indirizzo email da una indirizzo in formato FriendlyName, quindi Label<address>. Tramite questa classe è possibile formattare la data MySQL, con formato YYYY-MM-DD hh:mm:ss, in un formato definito da una stringa di formattazione. La stringa di formattazione, in stile printf(), è costituita da degli specificatori, introdotti dal carattere %, e da eventuale testo normale che viene restituito as-it-is. A completamento del progetto, sono state create delle classi di Exception per gestire tutti quei casi particolari o di errore che possono verificarsi nel corso dell utilizzo del MailServer. Infine, i test inseriti comprendono il metodo testgetuser() che presuppone la presenza di MySQL e della entry con l account del sottoscritto. WebAdminPage Daniele Dolfini La parte amministrativa della mailbox è fatta da delle pagina html statiche contenenti la struttura delle relative pagine e dei placeholder dove bisogna inserire delle informazioni su richiesta, e da tre classi che servono per leggere le pagine html, sostituire i placeholder e ritornare la pagina. La classe WebAdminPage si occupa di ricevere la richiesta della pagina voluta, chiama il metodo buildpage della classe BuildPage per generare la pagina con le informazioni richieste e ritorna il codice html della pagina come stringa. Attualmente ritorna sempre la stessa pagina, è stata creata la classe HTTRequestParser che dovrebbe venir usata da questa classe per sapere cosa è stato richiesto e ritornare le relative informazioni. La classe BuildPage si occupa di aprire il file contenente il codice html della pagina html richiesta, sostituire i placeholder con le informazioni necessarie, contenute in un hashmap, e ritornare la pagina html completa come stringa. Questa classe genera anche l hashmap, nella versione attuale del programma vengono gestite tre pagine, due che non necessitano sostituzioni, e che comunque contengono il placeholder <!-- ***noreplacement***--> che sarà la chiave dell hashmap e come valore avrà una sringa vuota, la terza pagina invece contiene il placeholder <!--***userlist***--> che come valore nell hashmap avrà la lista degli utenti che viene presa tramite i metodi della classe User. La classe FileIO contiene i metodi per leggere e scrivere file, nel nostro programma utilizziamo solo i metodi per leggere il codice html base. MailServer, pagina 5 di 5