Gruppo Mailing CCR Settembre

Progetto di lavoro  Studio della centralizzazione del servizio di posta elettronica Situazione attuale Scenari logici Soluzioni tecniche Costi e benefici  Partecipanti: Mirko Corosu, Fulvia Costa, Rosario Esposito, Ombretta Pinazza, Alessandro Spanu, Riccardo Veraldi, Giulia Vita Finzi  Termine dei lavori: dicembre 2007, consegna del documento

Servizio di posta: situazione 2007 Servizi calcolo - PersonaleTotaleValor medio Tecnologi/ricercatori Tecnici (FTE) 78 (62.3 FTE) 3.0 (2.4) Totale 115 (99.3) 4.4 (3.8) Hardware impegnato Macchine Spazio disco allocato ?? (~ 16 TB) 700 GB (BO) Spazio disco utilizzato ?? (~ 3 TB) 125 GB (BO) Utenza Mailbox dipendenti associati

Scenari logici: la situazione attuale 1/4  Ogni servizio legato alla posta è gestito localmente (tranne, in parte, le mailing-list)  Esiste un mailserver centrale utilizzato solo come MX ausiliario (infngw.infn.it) Server centrale SMTPUtilizzato solo come MX secondario IMAPnessuno Server locale SMTPServer MTA in ogni sede IMAPServer IMAP in ogni sede

Scenario completamente centralizzato 2/4  Tutti i servizi di posta sono gestiti centralmente con un unico dominio.  Il servizio può essere gestito dall’INFN, dato in outsourcing o affidato a provider. Server centrale SMTPServer centrale che gestisce un unico dominio infn.it IMAPCaselle di posta sul server centrale Server locale SMTPNessuno IMAPNessuno

Scenario federativo 3/4  Un MTA gateway centrale implementa politiche antispam e antivirus comuni (si evitano i ritardi dovuti a greylist, si unificano le fasi di configurazione e aggiornamento) Server centrale SMTPMTA gateway con politiche antispam/antivirus IMAPsolo eventuali aliases opp. aggregatore IMAP Server locale SMTPIl server centrale fa da MX principale, il server locale smaltisce la posta locale IMAPLe caselle di posta sono mantenute localmente

Scenario cooperativo 4/4  I domini locali sono mantenuti sia nel server SMTP centrale che nell’IMAP centrale  La centralizzazione è trasparente e può essere parziale  Possono essere mantenute le politiche di servizio locali e l’amministrazione Server centrale SMTPServer centrale che gestisce vari domini xx.infn.it IMAP Server locale SMTPSolo per le sedi non-aderenti, o durante la fase di migrazione IMAP

Tecnologie software  Tre scenari possibili: Sistema completamente commerciale Strumenti opensource Integrazione di strumenti commerciali e strumenti opensource

Sistemi commerciali Oracle Collaboration Suite Microsoft Exchange Google Apps Apple Mail Server SUN Java Messaging Server IBM Lotus Domino

Confronto SW commerciali SWDescrServiziCosto Oracle CS Suite di collaborazione IMAP(S)/POP(S)/ webmail, HA/LB di Oracle 33+8 /anno /mailbox > E Google Apps Premiere: uptime 99% POP/webmail, av/as non conf., quota 10GB, no BCK 40 /anno /mailbox =~ E Apple Mail Server OSX 10.4, certif. per 100K mailbox Tutti i ns attuali opensource: cyrus, postfix, mailman, spamassassin, … Lic client unlim. MAC OS X server = 999 E +~10 KE HW MS Exchange SUN Java IBM Lotus Notes

Implementazioni esistenti: Genova  CSITA (Università di Genova): sistema misto commerciale/public domain 4000 dip studenti, accessi/ora MTA: postfix+LDAP+PM inst. da SOPHOS Mailbox: Cyrus/Proxy/LDAP HW: 4 MTA, 3 Cyrus, 1 storage FC (120 GB dip GB studenti)

Università di Napoli e Bologna  CSI (Università di Napoli) mailbox gestite centralmente 3 x MX, 1 SAN FC su biproc HP, vari TB) per mailbox, 1 x LDAP Cyrus IMAP, backup settimanale su nastro  CeSIA (Università di Bologna) mailbox (dipendenti) + mailserver locali; studenti gestiti dal Cineca MS Exchange (licenza server + CAL per ogni mailbox + infrastruttura HW) Personale dedicato con assistenza MS

CERN  mailbox (ognuna 80 MB in media, max 3 GB)  mail ham su ogni giorno  Infrastruttura basata su MS Windows 2003 server e Exchange: IMAP: 14 server SMTP: 6 server CERN SpamKiller: 4 server Frontend HTTP e LDAP: 4 server

Le ricadute sul personale del servizio: l’helpdesk 1/3  Problemi segnalati dagli utenti Problemi di configurazione Messaggi d’errore Mail che rimbalzano Tracciabilità dei mail Spam falsi positivi Mail sospetti Quota Backup Richiedono tutti (tranne i primi due) accesso al servizio centrale

L’helpdesk 2/3  Richieste degli utenti: Configurazione dei client Forward, vacation, filtri Mailing list  Gestione del servizio Creazione e cancellazione account Gestione quota Monitoraggio e controllo (es. mail a postmaster) Aggiornamenti software

Rapporto fra servizi locali e centrali 3/3  I servizi locali devono poter accedere ai sistemi centrali in modo sicuro per Creare e gestire mailbox, quota, filtri Accedere ai LOG e alle code Accedere al backup per fare restore Segnalazione falsi positivi e falsi negativi  Cambiano le procedure ma non il carico di lavoro

Lavori in corso  Contatti con CMU  Studio dell’integrazione con AAI  Studio di sistemi HW  Scadenza: dicembre 2007  Input dalla Commissione? Sistemi commerciali o opensource Gestiti dall’INFN o da terzi  Interesse delle sedi?