La lotta allo spam è una lotta senza quartiere. Tutti contro tutti. E accade spesso che aziende serie vedono la loro posta finire regolarmente nello spam degli utenti a cui cercano di inviare comunicazioni email. Perchè ?

E’ presto detto: le mail che inviano queste aziende vengono inviate con mezzi di dubbia affidabilità.

Cercerò di spiegarmi meglio : tutti sanno che uno dei modi per filtrare lo spam è analizzare il contenuto del messaggio e filtrarlo in base a specifiche parole chiave. Per esempio è facile capire che si vorrà segnare come spam qualsiasi messaggio che contenga la parola “Cialis”. Combinazioni complesse di queste parole chiave, organizzate in veri e propri dizionari, concorrono a formare quello che si chiama un filtro bayesiano. Ma questo è solo un modo per tenere pulita la posta. I server che ricevono la posta fanno molti altri controlli ancora prima di leggere il contenuto del messaggio e, sulla base dell’esito positivo o negativo, marcano immediatamente come spam (oppure rifiutano direttamente) il messaggio ancora prima di sapere cosa c’è scritto dentro.

Uno di questi controlli è quello che verifica la validità del SPF ovvero Sender Policy Framework: si tratta di una serie di informazioni che il proprietario del dominio mittente, dovrà inserire nel proprio DNS, per informare i server destinatari, quali sono gli indirizzi ip o i server di posta che sono autorizzati ad inviare posta originata dal dominio in questione.

Per esempio : il dominio taldeitali.com (che genera posta nella forma nome@taldeitali.com) avrà sicuramente configurato, nel proprio DNS, uno o più record MX per la ricezione della posta. Ma se vuole anche informare i propri corrispondenti (o meglio i server che ricevono la posta dei corrispondenti) su quali siano i server di posta che inviano la posta con quel dominio, dovrà dotarsi anche, sempre nel DNS, di un record TXT di tipo SPF. Ovvero dovrà iscrivere una istruzione che, grossomodo, dice : “quando ricevete della posta da @taldeitali.com, se la ricevete da questo IP, o da questo, o da questo allora l’abbiamo proprio inviata noi, altrimenti l’ha mandata qualcun altro facendo finta di essere noi, quindi quasi al 100% è spam.”

La direttiva SPF risolve efficacemente uno dei grossi problemi della posta elettronica, ovvero l’attendibilità del mittente. Infatti quando si riceve una mail, siamo in grado di vedere l’indirizzo del mittente, ma non possiamo essere sicuri che effettivamente la mail sia stata scritta dalla persona che è effettivamente titolare di quell’indirizzo email. Tanto è vero che, spesso, vi arriva spam originato addirittura dal vostro indirizzo di posta: e mandarsi lo spam da soli … sarebbe sciocco.

L’implementazione di un record SPF è, a mio modo di vedere, ormai doverosa … se non addirittura obbligatoria, proprio per evitare che la propria posta in uscita (legittima) non venga bloccata dal server del destinatario e marchiata a fuoco come SPAM. E questa necessità è tanto più forte quanto più le aziende (o meglio i loro domini) utilizzano una molteplicità di server per la gestione della posta: per esempio nel caso in cui un server viene dedicato alla ricezione ed un altro all’invio.

Cosa succede se non implemento questo tipo di direttiva ? E’ molto semplice : il server ricevente che effettua controlli sul record SPF tenterà di attribuirvene uno in automatico secondo questa regola: la mail che si sta cercando di recapitare viene consegnata da un server che ha lo stesso indirizzo IP di uno o più dei record MX del dominio ? Se si … Ok. Se no … l’indirizzo IP che sta cercando di recapitare la mail è uno di quelli indicati nel record A del dominio ? Se si … Ok. Se no … Soft-Fail ovvero la mail non passa.

A valle del controllo SPF verranno poi effettuati altri controlli come ad esempio la validità di un record PTR … ma di questo dirò un’altra volta.

Per informazioni dettagliate sul record SPF e per crearne uno … visita www.openspf.org.

Sono un paio d’anni che usiamo, con soddisfazione, Scalix sia per la nostra struttura, che per quella dei nostri clienti. Innumerevoli sono i vantaggi offerti da Scalix rispetto ad Exchange:

• Lo stack di investimento: per avere un server Exchange devi comprare per forza Windows Server e relative CAL. Con Scalix invece puoi affidarti ad un robusto e spesso gratuito server Linux tra quelli compatibili. Con soddisfazione abbiamo sempre adottato CentOS (ora alla versione 5.4) spendendo solo quanto necessario per dotarsi di un buon hardware sufficientemente dimensionato. In termini di costo licenza per il mail server poi i due prodotti non sono nemmeno comparabili con un indubbio vantaggio a favore di Scalix. E’ pur vero che il costo di licenza andrebbe rinnovato di anno in anno per poter ricevere le nuove release. Ma se la vostra installazione è stabile, protetta da un buon firewall e non sono cambiate le vostre esigenze di interfacciamento con altre periferiche o software, potete rimanere allo stato dell’ultima release che avete installato.
• Continuità : è un fatto che i continui windows update richiedono sempre più spesso riavvii della macchina.  Con Scalix, e Linux ovviamente, i tempi di down per l’applicazione delle patch di aggiornamento sono significativamente ridotti.
• Spazio : Exchange nella versione Standard ha dei limiti di spazio, per quanto ampi, allo storage della posta e degli altri elementi. Scalix invece ha come unico limite lo spazio fisico dei dischi presso i quali è attestato il suo database.
• Multi Client : Exchange elegge come client preferenziale Outlook. Per usarlo con altri client è necessario sfruttarne la connessione IMAP o POP3 (in questi casi molte funzionalità vengono perse, specialmente per tutti gli elementi NON POSTA come i contatti, il calendario ecc.) oppure limitarsi ad accedervi tramite l’interfaccia Web. Scalix offre tutto questo (con una WebMail decisamente più avanzata) e come plus offre anche un connettore per Evolution il che vi rende possibile l’integrazione di un PIM Linux all’interno della struttura di rete (davvero tutti gli utenti devono avere Windows per forza ? Perchè non iniziate a risparmiare su quelle postazioni che non richiedono applicazioni office ????).

Ovviamente anche Scalix, dato che il suo competitor è proprio Exchange, cerca di combattere nello stesso campo (Windows), offrendo un sistema di autenticazione integrato SSO (Single Sign On) basato su Active Directory: in pratica l’accesso a Scalix tramite Outlook avviene nell’ambito delle credenziali di accesso a Windows (esattamente come Exchange).

Anche Scalix comunque, come tutti i server di posta, soffre. E soffre si di un male che non ha nulla a che vedere con l’aspetto tecnico: la “pigrizia” degli utenti. Pigrizia che porta a mantenere nelle caselle postali migliaia di messaggi, risalenti alla notte dei tempi, nell’eterna convinzione che prima o poi mi serviranno anche queste mail vecchie. Tutto questo trasforma il server di posta in un archiviatore mostruoso sul quale gli utenti avranno sempre modo di lamentarsi perchè diventa lento nelle ricerche.

Ovviamente il lavoro dell’archiviatore NON lo deve fare il server di posta. Piuttosto dei servizi specifici che tengano traccia di tutte le email che passano dal server e le organizzino in archivi debitamente indicizzati che poi andranno interrogati successivamente. Tenendo la posta “archiviata” a parte è poi possibile tenere il mail server “snello” con dei clean-up periodici (magari settimanali) che eliminino dalle mailbox tutto quello che non è lavoro quotidiano.

La nostra scelta è caduta su MailArchiva, un software open, disponibile sia in versione “community” (gratuita) sia in versione “enterprise” (a pagamento). Abbiamo adottato la versione community per l’archiviazione della posta.

Sia Scalix che MailArchiva permettono l’integrazione con Active Directory per l’autenticazione degli utenti e la loro configurazione è decisamente alla portata. Tuttavia MailArchiva, se attivata l’autenticazione con Active Directory, non trova nessuna mail per gli utenti. Perchè ? Il motivo è molto semplice. MailArchiva “legge” gli indirizzi email associati all’utente nell’attributo proxyAddresses dello schema di Active Directory (l’impostazione predefinita per chi ha installato Exchange) mentre Scalix scrive gli indirizzi email in un suo attributo nominato scalixEmailAddress. Ne consegue che MailArchiva non sa quali siano le email di pertinenza dell’utente che ha effettuato l’accesso e, a meno che non sia un admin, non ne mostra nessuna.  La soluzione proposta dal team di MailArchiva è quella di passare ad un sistema di autenticazione LDAP e di specificare quale sia l’attributo dello schema che specifica l’indirizzo email : a meno che non abbiate la versione Enterprise (a pagamento) è una spina nel sedere.

La vera soluzione è molto più semplice e di facile implementazione. Basta copiare gli indirizzi email presenti nell’attributo scalixEmailAddress e metterli anche nell’attributo proxyAddresses (che è un attributo standard di Active Directory e quindi presente anche se non avete Exchange montato). I due attributi hanno forme sintattiche leggermente diverse ma con un piccolo script (facilmente schedulabile) potete mantenere allineate le informazioni.

Siete pigri ? … vabbè … ecco lo script per farlo.

Download ScxPAUtil.zip

Scarica lo zip ed estrai il contenuto (incluse sottodirectory) in una cartella di tua scelta. Per lanciare l’allineamento tra i due attributi basta eseguire, da una macchina membro del dominio e nelle credenziali di un utente che ha diritti di scrittura su AD:

cscript ScxPAUtil.wsf


Verrano eseguite le seguenti operazioni :

1. Estrazione di tutti gli oggetti “user” dallo schema Active Directory
2. Se l’oggetto user non è associato ad email Scalix, l’attributo proxyAddress viene svuotato
3. Se l’oggetto è associato ad email Scalix, l’attributo proxyAddress viene popoplato (o aggiornato) con i valori presenti in scalixEmailAddress.

Semplice e lineare. Ora MailArchiva “vede” le email corrette.

Ho già detto di come sia possibile sfruttare le possibilità di sincronizzazione del vostro BlackBerry senza dover installare il, per me, fastidioso BlackBerry Desktop Manager ed utilizzando il software open-source Funambol. Nel test che avevo fatto mi ero limitato a provare il client Funambol per Outlook rimandando ad altro momento la prova del client Funambol per Thunderbird.

“L’altra data” è arrivata e, dismesso definitivamente Outlook dal mio desktop dopo che ho imparato ad apprezzare tutte le eccezionali caratteristiche di Thunderbird, mi sono cimentato con la sincronizzazione del BlackBerry: un successo, nonostante venga indicato essere un componente ancora sperimentale.

Il componente aggiuntivo di Thunderbird per la sincronizzazione del BlackBerry (alla data del presente articolo è disponibile la versione 0.9.1) si installa come tutti i componenti extra di Mozilla tramite un semplice file .xpi. Dopo l’installazione troverete nel menu Strumenti la nuova voce che vi permette di accedere al “classico” pannello di controllo di Funambol già noto nella versione per Outlook.

Noterete subito che rispetto alla versione per Outlook non è disponibile la sincronizzazione degli elementi di tipo Note che non sono comunque gestibili da Thunderbird. Per gli elementi di tipo Contatti i dati vengono sincronizzati con gli elementi della Rubrica (eventualmente potete creare una Rubrica dedicata) mentre per quanto riguarda Calendario e Attività i dati vengono sincronizzati con le informazioni di Lightning.

Nella mia configurazione i dati salienti sono : Mozilla Thunderbird 2.0.0.23 e Lightning 0.9. quest’ultimo connesso al mio backend Scalix tramite iCal.

Nel menu Strumenti -> Opzioni di Mozilla troviamo il facile ed intuitivo pannello di Configurazione del componente nel quale potremo indicare le credenziali di connessione al server Funambol e quali siano i parametri per la sincronizzazione con Contatti e Calendari, lo schedulatore delle sincronizzazioni e l’utile visualizzatore dei log delle attività svolte.

La sincronizzazione è tanto semplice quanto rapida: rispetto all’omologo per Outlook gode dell’indubbio vantaggio di non dover accedere ad elementi MAPI il che rende l’attività di sincronizzazione uno sparo. Unico neo, non comunque imputabile a questo fantastico componente, è il fatto che nella mia configurazione con iCal verso Scalix non sono supportati gli elementi di tipo Attività. Poco male comunque dato che in genere mi servono solo i Contatti ed il Calendario.

Ovviamente sul vostro BlackBerry non dovrete fare nulla di più di quanto ho già descritto nel precedente articolo.

E’ bene notare che Thunderbird dispone di una funzione che inserisce automaticamente in Rubrica tutti gli indirizzi email utilizzati almeno una volta: a questo proposito è bene configurare Thunderbird in modo che questi Indirizzi Collezionati vengano raccolti in una apposita rubrica separata per evitare di trovarvi la rubrica del BlackBerry riempita con decine e decine di indirizzi che non sono di uso frequente.

In conclusione la solita raccomandazione: assicuratevi che il vostro BlackBerry sia abbinato ad un piano tariffario dati altrimenti per ogni connessione pagherete un sacco di soldi.

Un’altro punto a favore del software open.

Ho avuto modo di visionare il video di presentazione di Wave, il nuovo sistema di messaggistica che verrà lanciato, secondo le previsioni di BigG, entro la fine del 2009. Chi fosse interessato alla visione può sedersi comodo, prendersi una bibita fresca e cliccare qui : YouTube – Google Wave Developer Preview at Google I/O 2009.

Indubbiamente c’è di che rimanere impressionati per lo sforzo notevole profuso dagli sviluppatori nel cercare di dare nuova vita ai sistemi di messaggistica “tradizionalmente” offerti dal Web. Lo slogan che più spesso ricorre è quello secondo il quale Wave sarà in grado di rivoluzionare la cara vecchia email (Come sarebbe la posta elettronica se fosse stata inventata oggi ?). In realtà di “rivoluzionario” c’è poco trattandosi più di una evoluzione/integrazione della normale messaggistica asincrona (email) mixata con le più moderne tecniche di instant messaging. Quindi non spaventatevi : la nostra email classica continuerà a vivere ancora per un bel pezzo.

Ma di cosa si tratta ? Wave, più che un’applicazione, è un nuovo framework di messaggistica integrata che permette la condivisione istantanea dei messaggi da e verso sorgenti/origini di tipo diverso. Il vero core è il set di funzioni API che Google rilascerà agli sviluppatori per integrare le loro applicazioni. La preview, concepita, sviluppata e presentata dagli stessi sviluppatori che hanno, sempre per Google, creato Maps, è interamente imperniata sulla interazione che tre postazioni diverse (ovviamente per motivi di semplificazione, ma bisogna immaginare che le postazioni/utenti potrebbero essere centinaia per volta) possono sperimentare nella comunicazione. Accade dunque che il normale messaggio email venga non più concepito come oggetto autonomo, ma viva all’interno di un’oggetto padre (la conversazione) al quale possono partecipare, in tempo reale, attori diversi come ad esempio, persone reali, blog, feed rss, applicazioni di social networking e via di questo passo. La digitazione del messaggio viene trasmessa (salvo i casi in cui l’autore espressamente vieta questo comportamento) carattere per carattere a tutti i partecipanti, come pure l’inserimento di documenti allegati che vengono istantaneamente condivisi. Molto efficace davvero la funzionalità di replay che permette di rivedere, come in un film riprodotto dall’inizio, l’evoluzione della conversazione che ha portato al risultato finale.

Tutto molto interessante e, almeno nelle attese, molto efficace. Non vi è modo, infatti, di dubitare che anche questa volta la cura che BigG ha messo nello sviluppo di un ottimo prodotto sia molto elevata. Da vedere invece quale possa essere il successo che incontrerà questa nuova tecnologia. Non sempre infatti Google ha centrato i propri obiettivi e, particolarmente in questo caso, mi permetto di sollevare alcune perplessità che potrebbero ostacolarne la diffusione.

Non ho gli strumenti in questo momento per sollevare eccezioni tecniche su Wave: il codice non è ancora stato distribuito. A occhio, e a intuito, direi che i requisiti di banda emergenti da un sistema di comunicazione istantanea così sofisticato saranno notevoli, specialmente in quelle situazioni dove il sistema dovrà essere utilizzato per il document sharing ed il content management.

Nel merito delle caratteristiche invece penso che si debbano necessariamente fare alcune riflessioni.

La prima riguarda la “qualità” dell’informazione trasmessa. Con il tradizionale canale email, l’autore di un messaggio ha tutto il tempo, ed in genere se lo prende, per approntare un testo (corredato di eventuale documentazione allegata) il più rispondente possibile al proprio pensiero, che possa essere chiaramente e correttamente compreso, senza errori formali, senza errori di grammatica e di sintassi. Insomma, proprio come quando si scrive una lettera. Al contrario l’IM (Instant Messaging) ci ha mostrato come l’immediatezza della trasmissione abbia sacrificato molto le forme ed i contenuti: abbreviazioni assurde, punteggiatura inesistente, smilies ed emoticon ecc. Il tutto condito dalla totale assenza di un tempo ragionevole per la comprensione e la “sedimentazione” dei messaggi ricevuti. Non è un caso che le guerre verbali più violente scaturiscano spesso da incomprensioni e/o cattive interpretazioni dei toni e dei modi espressi dall’interlocutore. Con la normale email questo succede con minor frequenza proprio per il fatto che la comunicazione asincrona non consente un rapido botta-risposta.

Si consideri poi che la digitazione e l’immediata echo dei caratteri che sto battendo sullo schermo dei miei interlocutori mi obbliga a “lavorare di fretta”. Non credo di essere l’unico che rilegge un messaggio email prima di inviarlo. Vorrei evitare di mettere “in chiaro subito i miei pensieri” o la semplice bozza di un messaggio: spesso rimuovo porzioni che ritengo meglio non inserire ad una lettura più approfondita (magari l’argomento è prematuro) ma ovviamente questo sarebbe inutile se chi mi legge dall’altra parte ha già visto tutto.

Un’altra considerazione da non sottovalutare è la congestione della conversazione: l’aggiunta di partecipanti al thread è cosa veramente facile come pure la loro “interazione attiva” con il contenuto in via di sviluppo. Arrivare a capire, superati certi limiti, come si sia formato un documento o un progetto diventa un problema in assenza di chiare gerarchie.

Da ultimo … la privacy. Tramite opportune API è possibile inserire, a puro titolo di esempio, il proprio Blog all’interno di una conversazione Wave. In questo modo, quello che scrivono, magari in via riservata, dei miei interlocutori, verrebbe spiattellato in pubblico su un blog senza specifica approvazione degli interessati.

Insomma … una chat evoluta che, a mio personalissimo modo di vedere, non ha contribuito a correggere nessuna delle lacune della classica email (ad esempio certezza del mittente) ma ha voluto premere sull’acceleratore dell’immediatezza, dell’istantaneità.

Vedremo quale sarà il successo.

Dopo un paio d’anni di onesta militanza del nostro Scalix 11.3 ospitato da una datata SuSE 10.1 era arrivato il momento di aggiornare alla versione ultima disponibile 11.4.3. Sfortunamente, causa fretta, non mi sono letto le specifiche di compatibilità di Scalix 11.4.3 e, sull’onda dell’entusiasmo, ho installato una SuSE 11.1 per accorgermi che su questa release di distribuzione Scalix non funziona. E’ garantita infatti la compatibilità solo con la 11.0 a causa del compilatore GCC.

Dopo aver perso diverse ore per scaricarmi la 11.1 non avevo assolutamente intenzione di perdere nuovamente altro tempo per riscaricare il DVD della SuSE 11.0 e ho deciso di darmi un’occhiata in giro per valutare soluzioni host alternative. Ho optato alla fine per CentOS 5.3 (compatibile con Scalix 11.4.3) e, al termine della procedura che sto per descrivervi, si è rivelata una scelta assolutamente vincente.

Ecco dunque come procedere per spostare Scalix da un server ad un altro oppure per migrare Scalix su un’altra distribuzione Linux.

1. Preparare il necessario: prima di cominciare prendete nota della versione di Scalix che avete attualmente installato ed accertatevi di avere a disposizione il package di installazione corrispondente. In questo caso, avendo in produzione Scalix 11.3 ho scaricato i binari di installazione per RedHat/CentOS che sarà la distribuzione che installerò. Ovviamente, già che ci siete, scaricatevi anche i binari di installazione di Scalix 11.4.3 (o i più recenti se ve ne sono) per la stessa distribuzione.
    
2. Una bella copia di backup, magari due: salti nel buio non se ne fanno. Prima di iniziare ho effettuato un bell’export di tutte le nostre mailbox e delle cartelle pubbliche configurate sul nostro server utilizzando l’utilità sxstoreexp. Questo tipo di esportazione non è veramente completa in quanto esporta solo i dati contenuti nelle cartelle e nelle mailbox ma non si porta dietro le eventuali regole automatiche configurate per i singoli utenti (come ad esempio le regole “Fuori Ufficio”). E’ comunque una bella ancora di salvezza perchè, nel caso, potrete comunque ricreare tutta la struttura del server di posta e poi a manina rimettere al loro posto le regole. Salvatevi il contenuto della copia in un bel dvd o su un disco di rete o dove ritenete opportuno. Nel mio caso ho effettuato il travaso su un minidisk LaCie formattato in NFTS che mi ha obbligato a montare sulla mia “vecchia” SuSE 10.1 i driver ntfs-3G per poter scrivere con Linux su dischi NTFS.
   La seconda copia da effettuare è quella che verrà utilizzata per la migrazione vera e propria: tutto quello che dovete fare è crearvi un archivio dell’intero contenuto della directory /var/opt/scalix/xx/s/ (dove xx sono la prima e l’ultima lettera del nome host della macchina su cui è installato Scalix: nel mio caso la macchina si chiama suse1 e quindi la directory completa è /var/opt/scalix/s1/s). Salvatevi anche questo archivio da qualche parte (potrebbe volerci del tempo in funzione delle dimensioni).
    
3. Installiamo la nuova distro: siamo ora pronti per “brasare” la vecchia suse e rimpiazzarla con CentOS. Se avete già a disposizione un server Linux installato con la nuova distribuzione saltate questo punto. Per la mia installazione ho optato per la modalità via rete (mi sono scaricato solo il disco di boot per l’installazione di rete). Durante il setup ho apprezzato di CentOS il fatto che per impostazione predefinita propone un minimo set di applicazioni lasciando poi ad una fase successiva la possibilità di “ampliare” le funzionalità. Questo ovviamente riduce i tempi installazione. Già che c’ero ho comunque richiesto l’installazione dei componenti minimi per poter far funzionare Scalix e quindi ho incluso Apache, il supporto Java, Sendmail, Postgres, gcc, compat-libsdtc.
   L’installazione è andata senza problemi di sorta (ottimo!!!) ed ha richiesto circa 40 minuti tra il download dei pacchetti ed il setup. Alla fine effettuo il login nel nuovo desktop Gnome. Nota personale: le differenze tra SuSE e CentOS sono evidenti in prima battuta nella differenti “preferenze” desktop. Il nuovo KDE 4 che ho già assaggiato sulla SuSE 11.1 sarà anche bello graficamente ma non è proprio il prototipo della leggerezza mentre Gnome mantiene ancora quel fascino delle “cose antiche” con il quale ho ancora tanta familiarità. Ok sono pronto per procedere. A proposito : il mio nuovo server non si chiama più suse1 ma gli ho dato un nuovo nome : scalix1. Questa nota è fondamentale (e avendolo saputo prima non l’avrei fatto) perchè tutti i dati di scalix sono profondamente legati al nome dell’host su cui è installato. Grazie al cielo si può ovviare al problema ma … ci sarà del lavoro da fare.
    
4. Nuovo Server … installiamo Scalix. Installo sul nuovo server il pacchetto di Scalix “vecchio”. Ero in produzione con Scalix 11.3 e quindi reinstallo la 11.3 (questa volta per CentOS). In questo modo sono ragionevolmente sicuro che la struttura di dati e directory sarà la stessa. L’installazione di Scalix su CentOS è dannatamente veloce (almeno il doppio della velocità che avevo sperimentato sulla vecchia SuSE (con lo stesso identico hardware) ed in pochi minuti ho Scalix up-and-running. Ovviamente vuoto e con solo gli account di base (sxadmin e sxqueryadmin) ed i 4 gruppi amministrativi di base.
    
5. ClamAV era installato ? Se avevate installato, come me, ClamAV è arrivato il momento di installarlo. Se non lo avevate montato passate al punto successivo.
   Per installare ClamAV su CentOS i passi sono brevi e semplicissimi. Utilizzeremo i binari di Dag Wieers RPM per Red Hat, RHEL, CentOS e Fedora.
   Aprite una finestra Terminal con privilegi di root e digitate il comando :
    
   cd /etc/yum.repos.d

   Scaricate ora i file di configurazione del repository digitando il comando
    
   wget http://www.linux-mail.info/files/dag-clamav.repo
    
   Siamo ora pronti per avviare l’installazione di ClamAV che avvieremo con il comando:
    
   yum install clamav clamav-devel clamd
    
   alla richiesta di conferma del download confermate con Y.
   Al termine dell’installazione lanciate il comando freshclam (che effettuerà l’aggiornamento del db delle impronte virali) e provate con clamscan la scansione di una directory qualsiasi. L’installazione di ClamAV crea un nuovo utente di sistema che si chiama clamav. Prima di procedere assicuratevi che l’utente clamav venga inserito anche nel gruppo scalix.
    

6. E’ ora di ripristinare la nostra vecchia base dati. Arrestiamo tutti i servizi di Scalix e Sendmail sempre da riga di comando digitando :
    
   /etc/init.d/scalix stop <enter>
/etc/init.d/sendmail stop <enter>
    
   Siamo ora pronti per recuperare l’archivio che abbiamo salvato dalla vecchia /var/opt/scalix/s1/s ed espanderlo all’interno della nuova directory s che si trova nel percorso /var/opt/scalix/xx/ (dove xx sono la prima e l’ultima lettera del nome host della macchina su cui è installato Scalix: nel mio caso la macchina si chiama scalix1 e quindi la directory completa è /var/opt/scalix/s1/s). Attenzione ! non fatevi ingannare da questa similitudine. Il fatto che il nome dell’istanza sia ancora s1 non vuol dire nulla: il nome host è comunque cambiato da suse1 a scalix1 quindi abbiamo del lavoro da fare !!
   A questo punto siamo pronti per alcune verifiche e correzioni: per prima cosa dobbiamo verificare che i permessi sui file che abbiamo appena ripristinato dall’archivio tar siano corretti e che non ci siano errori. Lanciate quindi il seguente comando :
    
   omcheck -i -d <enter>

   ed esaminate i risultati. Se gli errori rilevati sono pochi potrete effettuare le correzioni a mano, in caso contrario o comunque se volete essere sicuri potete eseguire :
   
omcheck -s -d > /tmp/scalixfix.sh <enter>
sh /tmp/scalixfix.sh <enter>
    
   Questa procedura ripristinerà i corretti permessi e farà il touch di file eventualmente mancanti.
    

7. Correggiamo il nome host : se il nome host del vostro server non è cambiato potete saltare questo passo, altrimenti, come me, dovrete eseguire questa procedura per poter modificare i file interni di configurazione di Scalix in modo che puntino al nome host corretto. Cominciamo (l’articolo completo su come fare lo trovate qui.) :
   Dunque il mio vecchio server si chiamava suse1.anlan.com mentre questo nuovo si chiama scalix1.anlan.com. Dobbiamo modificare le impostazioni del nodo sulle impostazioni di utenti e cartelle digitanto il seguente comando :
    
   sxmodfqdn -o suse1.anlan.com -n scalix1.anlan.com <enter>
    
   Questa procedura si passa tutte le entità interne di scalix ed effettua la correzione. Ma non è ancora finita: dovremo fare le opportune modifiche anche su altri file di configurazione che si trovano nella directory di scalix. Questa istruzione consente la modifica automatica di tutto quanto necessario:
   
[root@scalix1 ~]# source /opt/scalix/global/config; \
for i in /var/opt/scalix//* ; do \
if [ $i != $OMDATADIR ]; then \
sed -i -e 's/suse1.anlan.com/scalix1.anlan.com/g' \
`grep -iRl suse1.anlan.com $i 2>/dev/null \
| egrep -iv 'scalix1.anlan.com|logs|indexes|postgres/data' \
| xargs`; fi; done <enter>
 
per essere sicuri dell’esito del comando digitate :
   
[root@scalix1 ~]# source /opt/scalix/global/config; for i in /var/opt/scalix//* ; do \
if [ $i != $OMDATADIR ]; then grep -iR $OMHOSTNAME $i 2>/dev/null| egrep -iv 'logs|indexes|postgres/data'; \
fi; done <enter>

   per ottenere un output di questo titpo:
   
/var/opt/scalix/s1/caa/scalix.res/config/ubermanager.properties:ubermanager.query.server=scalix1.anlan.com
/var/opt/scalix/s1/caa/scalix.res/config/ubermanager.properties:ubermanager.console.localDomains=scalix1.anlan.com
/var/opt/scalix/s1/mobile/mobile.properties:platform.url=scalix1.anlan.com
/var/opt/scalix/s1/platform/platform.properties:imap.host=scalix1.anlan.com
/var/opt/scalix/s1/platform/platform.properties:smtp.host=scalix1.anlan.com
/var/opt/scalix/s1/platform/platform.properties:hibernate.connection.url = jdbc:postgresql://scalix1.anlan.com:5733/scalix
/var/opt/scalix/s1/res/config/res.properties:res.ubermanager.host=scalix1.anlan.com
/var/opt/scalix/s1/res/config/res.properties:res.kerberos.allowedclients=ubermanager/scalix1.anlan.com
/var/opt/scalix/s1/webmail/swa.properties:swa.email.domain=scalix1.anlan.com
/var/opt/scalix/s1/webmail/swa.properties:swa.email.imapServer=scalix1.anlan.com
/var/opt/scalix/s1/webmail/swa.properties:swa.email.smtpServer=scalix1.anlan.com
/var/opt/scalix/s1/webmail/swa.properties:swa.platform.url=http://scalix1.anlan.com:8080/api
/var/opt/scalix/s1/webmail/swa.properties:swa.ldap.1.server=scalix1.anlan.com
/var/opt/scalix/s1/webmail/swa.properties:swa.ldap.2.server=scalix1.anlan.com
 
   Da ultimo dovremo correggere tutti gli URL del servizio SIS che sono memorizzati all’interno di ogni account. Infatti se digitiamo il comando :
   
[root@scalix ~]# omshowu -n sxadmin
Authentication ID: sxadmin
...
SIS URL : sxidx://suse1.anlan.com/0d100000d97e5164-041.261.961.18
vediamo come il puntamento sia ancora indirizzato al servizio SIS del “vecchio” server. Potremo facilmente cambiare l’impostazione su tutti gli account con questo comando :

   omshowu -m all| while read line; do ommodu "$line" --index `omshowu -n "$line"|grep -i sis|\
sed -e 's/^.*suse1.anlan.com/sxidx:\/\/scalix1.anlan.com/g'`; done


   L’ultima operazione richiesta prevede la correzione del mapping al mailnode corretto. Infatti se digitiamo il comando per la visualizzazione del mailnode corrente otterremo :
   
[root@scalix1 ~]# omshowmnmp <enter>
suse1 suse1.anlan.com


   che non è corretto in quanto è l’impostazione del vecchio server. Per correggerla dobbiamo eliminarla e crearla nuova.

    [root@scalix1 ~]# omdelmnmp suse1 <enter>
Disabling 1 subsystem(s).
Directory Relay Server Stopped
Enabling 1 subsystem(s).
Directory Relay Server Started

    [root@scalix1 ~]# omaddmnmp scalix1 scalix1.anlan.com <enter>
Disabling 1 subsystem(s).
Directory Relay Server Stopped
Enabling 1 subsystem(s).
Directory Relay Server Started
[root@scalix1 ~]# omshowmnmp
scalix1 scalix1.anlan.com 

8. Ok tutto fatto. Potete riavviare il server e tornare ad operare con il vostro Scalix aggiornato. Non dimenticate che se avete cambiato il nome di host o l’indirizzo ip del server, dovrete modificare le impostazioni di connessione dei client.