Per motivi che ancora non riesco ad individuare accade piuttosto frequentemente che sul nostro server Scalix si verifichino degli errori di attribuzione permessi sulle directory e sui file del message store di Scalix.

Tali errori si evidenziano eseguendo il comando omcheck -i -d e riguardano quasi sempre, nel nostro caso,  l’owner dei file.

Come workaround del problema, in attesa di ulteriori investigazioni, ho deciso di automatizzare il processo di correzione inserendolo nel ciclo frequent del batch sxmaint (che abbiamo schedulato ogni 30 minuti). L’integrazione è piuttosto semplice. Editate il file sxmaint (/opt/scalix/bin/sxmaint) ed inserite il seguente blocco appena sopra la prima Action (Check disk space Utilization):


# ACTION: Runs omcheck and runs correction if needed
#
FIXCMD=/tmp/sxmaint.$$.fixcmd
$SX_BIN_DIR/omcheck -s -d | grep -v "^#" > $FIXCMD
if [ -s $FIXCMD ]
then
sh $FIXCMD
fi
rm -f $FIXCMD


Hope it helps

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.an-lan.it mentre questo nuovo si chiama scalix1.an-lan.it. Dobbiamo modificare le impostazioni del nodo sulle impostazioni di utenti e cartelle digitanto il seguente comando :
    
   sxmodfqdn -o suse1.an-lan.it -n scalix1.an-lan.it <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.an-lan.it/scalix1.an-lan.it/g' \
`grep -iRl suse1.an-lan.it $i 2>/dev/null \
| egrep -iv 'scalix1.an-lan.it|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.an-lan.it
/var/opt/scalix/s1/caa/scalix.res/config/ubermanager.properties:ubermanager.console.localDomains=scalix1.an-lan.it
/var/opt/scalix/s1/mobile/mobile.properties:platform.url=scalix1.an-lan.it
/var/opt/scalix/s1/platform/platform.properties:imap.host=scalix1.an-lan.it
/var/opt/scalix/s1/platform/platform.properties:smtp.host=scalix1.an-lan.it
/var/opt/scalix/s1/platform/platform.properties:hibernate.connection.url = jdbc:postgresql://scalix1.an-lan.it:5733/scalix
/var/opt/scalix/s1/res/config/res.properties:res.ubermanager.host=scalix1.an-lan.it
/var/opt/scalix/s1/res/config/res.properties:res.kerberos.allowedclients=ubermanager/scalix1.an-lan.it
/var/opt/scalix/s1/webmail/swa.properties:swa.email.domain=scalix1.an-lan.it
/var/opt/scalix/s1/webmail/swa.properties:swa.email.imapServer=scalix1.an-lan.it
/var/opt/scalix/s1/webmail/swa.properties:swa.email.smtpServer=scalix1.an-lan.it
/var/opt/scalix/s1/webmail/swa.properties:swa.platform.url=http://scalix1.an-lan.it:8080/api
/var/opt/scalix/s1/webmail/swa.properties:swa.ldap.1.server=scalix1.an-lan.it
/var/opt/scalix/s1/webmail/swa.properties:swa.ldap.2.server=scalix1.an-lan.it
 
   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.an-lan.it/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.an-lan.it/sxidx:\/\/scalix1.an-lan.it/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.an-lan.it


   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.an-lan.it <enter>
Disabling 1 subsystem(s).
Directory Relay Server Stopped
Enabling 1 subsystem(s).
Directory Relay Server Started
[root@scalix1 ~]# omshowmnmp
scalix1 scalix1.an-lan.it 

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.

Tutti sanno cosa sia un messaggio e-mail, come si faccia a mandarlo e come si possa ricevere. Eppure solo una piccola parte degli utenti internet conosce davvero cosa succede “dietro le quinte” quando si invia o si riceve posta elettronica. Del resto i moderni client di posta elettronica (Thunderbird, Outlook Express, Outlook, Eudora, The Bat! ecc..) svolgono silenziosamente il “vero” lavoro di comunicazione e trasmissione dei nostri messaggi: tutto quello che ci è richiesto è di impostare correttamente alcuni parametri iniziali (server POP/IMAP, server SMTP ecc) e poi siamo pronti ad inserire un indirizzo email, compilare un oggetto, digitare un po’ di testo nel corpo del messaggio e … voilà, dopo un clic su Invia il messaggio viene recapitato.

Ma cosa avviene in realtà ?

Per semplificare possiamo tranquillamente equiparare il servizio di posta-elettronica ad un normale servizio di posta cartacea (le normali buste che mettiamo nella buca delle lettere): la logica è la stessa anche se, ovviamente, la tecnica è molto differente. Con la normale posta cartacea (detta anche posta di superficie) mettiamo il nostro foglio dentro una busta, scriviamo sulla busta l’indirizzo del destinatario ed anche il nostro indirizzo (mittente) in modo che, ove non sia possibile raggiungere il destinatario, la busta ci venga restituita, ed infine mettiamo la busta in una buca per le lettere o la portiamo direttamente all’ufficio postale per essere spedita. Supponendo di mandare una lettera da Milano a Roma, il servizio postale di Milano manderà la nostra busta al centro postale di Roma dove un postino provvederà a portarla nella cassetta della posta del destinatario. Se per qualche motivo il destinatario è stato indicato con un indirizzo sbagliato, o ha cambiato residenza, il postino riporterà la busta al centro di Roma che la rispedirà a Milano per essere recapitata al mittente.

Tutto chiaro no ? Bene: con la posta elettronica la logica è esattamente la stessa.

Quando siamo pronti ad inviare il nostro messaggio di posta elettronica succede questo: il nostro client (per esempio Outlook Express) prepara una “busta elettronica” (envelope) nella quale indica i dati del destinatario e del mittente (gli indirizzi email di chi deve ricevere il messaggio e di chi lo manda), ci inserisce il testo che abbiamo scritto e gli eventuali allegati (foto, documenti ecc) e consegna il tutto all’ufficio postale che è incaricato della consegna ovvero il server SMTP che, generalmente, ci è stato indicato dal nostro provider di connettività o dal gestore che mantiene le nostre caselle postali. A questo punto il server SMTP (che possiamo assimilare al centro postale di Milano) trasmette il messaggio al server SMTP che è autorizzato a ricevere le email per il destinatario che abbiamo indicato (come fosse ad esempio il centro postale di Roma): quest’ultimo verifica se il destinatario esiste nei propri archivi (ovvero se esiste una casella postale con quell’indirizzo) e, in caso affermativo, deposita il messaggio nell’opportuna casella postale, mentre in caso negativo, risponde al server che gli sta inoltrando il messaggio chiedendo di informare il mittente che il destinatario non è raggiungibile.

Il processo che ho descritto è volutamente semplificato (trascuro in questo post quelle che possono essere le implicazioni di passaggi in uffici postali intermedi – i cosiddetti relay servers) ma rispecchia fedelmente quello che avviene in realtà.

Ma cosa è un server SMTP ? O meglio … cosa è SMTP ? Come la stragrande maggioranza delle sigle che si incontrano nel mondo dei computer, SMTP è l’acronimo inglese di Simple Mail Transfer Protocol ovvero il protocollo per la trasmissione internet di messaggi mail. I server che implementano questo protocollo si chiamano MTA (Mail Transfer Agent ovvero Agenti di Trasporto e Consegna delle mail) e sono quei server che dobbiamo indicare nella configurazione del nostro client di posta elettronica alla voce server SMTP.

Il protocollo SMTP è un protocollo relativamente semplice, fondamentalmente testuale in codifica ASCII (quindi “leggibile” da un umano), apparso agli inizi degli anni 80 e da allora rimasto sostanzialmente immutato. La sua semplicità è sicuramente punto di forza per la facilità di implementazione e per l’indubbia efficacia, ma è anche gravata da un notevole peso: la mancanza di sicurezza.

Il maggiore punto debole di SMTP sta nel fatto che non è in grado di verificare l’autenticità del mittente. Esattamente come un uomo può inviare una busta affrancata indicando come mittente un nome/indirizzo di fantasia (che può esistere o meno), così nelle email il protocollo SMTP non offre nessuna garanzia che il mittente di un messaggio sia effettivamente quello indicato. Iniziate a capire vero ? Questa mancanza di autenticazione del mittente apre la stura ad una serie di problemi : in primo luogo lo SPAM ed in secondo luogo l’attendibilità della fonte da cui arrivano le informazioni che leggiamo nel messaggio.

Ed ecco che appare chiara la risposta ad alcune domande molto ricorrenti : “Come mai mi arriva tutto questo SPAM ? Come fanno a sapere il mio indirizzo email ? Come mai a volte lo SPAM arriva dal mio stesso indirizzo ?” Semplicemente perchè il servizio postale elettronico non si cura di verificare che chi ha inviato un tale messaggio abbia indicato in modo corretto il mittente e sia veramente lui: l’unica cosa di cui si occupa l’MTA è quella di tentare di recapitare il messaggio al destinatario indicato e, in caso di fallimento, di ritornare al mittente un avviso (bounce). E qui si apre un altro problema : quello che si chiama il backscattering. Un esempio può aiutare più di mille parole: Mario (il nostro buontempone) invia una busta a Giovanni indicando come mittente Gianluca. Se il postino non riesce a consegnare la busta a Giovanni, cosa farà ? Semplice ritornerà la busta al mittente indicato sulla busta stessa ovvero a Gianluca. Ed ecco che Gianluca si vede, incolpevolmente, coinvolto in un giro di SPAM. Già, perchè gli spammers hanno capito che i “bounce-messages” (ovvero i messaggi di ritorno per mancata consegna) godono di una sorta di “privilegio” nella consegna ed è più facile che eludano i sistemi antispam. Così, volutamente, confezionano dei messaggi destinati ad indirizzi inesistenti indicando come “mittente” il loro vero obiettivo: in questo modo il bersaglio dello SPAM riceverà il messaggio non desiderato sottoforma di errore di recapito, spesso non capacitandosi del perchè si sia verificata questa situazione (“Ma io non ho mandato mai questo messaggio a questo indirizzo !!”).

Ma mentre è piuttosto raro trovare “buontemponi” che si divertano ad imbucare lettere fasulle mandate ad indirizzi a caso (e da indirizzi fasulli) prevalentemente per motivi di costo (il francobollo), l’economicità e la velocità (oltre all’indubbio anonimato) offerte dalla tecnica di trasmissione email valgono oro per gli SPAMMERS. Per un computer generare milioni di indirizzi casuali è un gioco da ragazzi: che importa poi se su qualche milione di email inviate solo poche migliaia raggiungono veramente dei destinatari reali ? Che importa se i server SMTP cercano di inviare ricevute di mancato recapito ad indirizzi inesistenti ? Gli SPAMMER raggiungono comunque i loro obiettivi: che siano economici (come le pubblicità dei prodotti per la virilità o i tentativi di rubarvi le credenziali per l’accesso al vostro conto corrente bancario – phishing) o più sofisticati (come per esempio quello di recapitare sul vostro computer tramite l’email dei programmi malevoli) anche se i tassi di ritorno sono bassi, è talmente alta la quantità dei messaggi inviati che i valori assoluti sono comunque rilevanti. Basti pensare che numerosi studi attestanto mediamente tra il 90% ed il 97% la percentuale dei messaggi NON RICHIESTI inviati quotidianamente.

Ma come ci si può proteggere da tutto questo ? E’ molto difficile rispondere. Una cosa è certa : non è possibile combattere e prevenire lo SPAM basandosi solo sulle caratteristiche di SMTP. E’ necessario chiamare alle armi altri strumenti, altri protocolli, altri software per cercare almeno di ridurre il fenomeno.

Ma è anche importante distinguere due campi di battaglia molto diversi: la protezione personale contro lo spam ovvero il micro campo di battaglia nel quale io stesso cerco di difendere il mio fortino costituito dalla mia casella postale e, su un piano totalmente diverso, la protezione globale che ha come obiettivo quello di ridurre il traffico email SPAM (che impegna banda, risorse di memoria e spazio su centinaia di migliaia di server) per poter garantire servizi internet più efficienti e veloci.

Le tecniche possono essere simili per entrambi gli ambiti, ma vanno applicate con cure ed accortezze molto diverse: se per esempio a livello di protezione personale decido che tutte le email che contengono la parola “Viagra” vadano automaticamente cestinate o messe nella Posta Indesiderata, il gestore di un server di posta per diversi domini non potrà permettersi lo stesso “lusso” perchè potrebbe esserci il caso in cui uno dei suoi clienti sia un medico e che come tale vuole ricevere informazioni mediche sul famoso prodotto della Pfeizer. Anche l’implementazione di tecniche antispam a livello di server aziendali non deve essere presa alla leggera: i contatti via email sono un canale essenziale di comunicazione con la clientela e perdere messaggi magari importanti per errate impostazioni dei filtri può essere un danno per l’azienda.

Insomma la guerra allo SPAM è, per il momento, allo stadio di battaglia persa. Con questo non intendo dire che non si possa validamente riuscire a ridurre lo SPAM, anzi è senz’altro possibile: il problema è che il costo (sia in termini di investimento software, che in termini di tempo) è notevole e supera di gran lunga il poco impegno richiesto a chi vive dello SPAM sfruttando, purtroppo, le debolezze insite in un protocollo nato quasi 30 anni or sono.