Il mio client di posta preferito, Thunderbird, era ancora fermo alla release 2.x perchè non riuscivo a trovare un plug-in per Funambol che mi permettesse di sincronizzare contatti e calendario tra il mio BB e Lightning. Inspiegabilmente, infatti, nonostante Thunderbird 3 sia public già da un bel pezzo, l’ultimo plug-in per Funambol rilasciato ufficialmente sul sito degli add-ons per Mozilla, è compatibile solo con la versione 2.x del client di posta.

Ho deciso allora di armarmi di pazienza e di cercare un po’ sul web quale fosse lo stato dell’arte. Salta fuori che lo sviluppo di Funambol è tutt’altro che arrestato, ma un bug (per altro non sistematico) che manda in crash Thunderbird 3, ha suggerito ai responsabili di funambol forge di non considerare stabile il plug-in e di rimandarne il rilascio ufficiale a data da destinarsi. Nello specifico il bug è stato verificato tanto dagli sviluppatori di Funambol quanto da quelli di Mozilla ma questi ultimi dichiarano che il bug va esclusivamente ricercato nel codice del plug-in.

Ad ogni modo, dato che il bug sembra verificarsi solo in alcuni casi, e dato che era stata comunque rilasciata una beta, ho deciso di rischiare e lanciarmi oltre l’ostacolo. Ho scaricato quindi l’installer .xpi del plugin (lo potete trovare a questo link) e, ovviamente, l’installer di Mozilla Thundebird 3.1.

Ho quindi proceduto a :

• disinstallare il plug-in funambol dal mio TB 2.x
• installare TB 3.1 (mi ha automaticamente aggiornato Lightning)
• installare il plug-in funambol per TB3

Dopo la configurazione del calendario e della rubrica da sincronizzare … il processo di sincronizzazione è “andato” senza problemi (ne ho provati un paio) e penso quindi di aver risolto il mio problema: finalmente posso beneficiare delle nuove funzionalità di TB3 senza perdere l’utile sincronizzazione con il mio BlackBerry.

Attenzione comunque : si tratta di una beta ed è noto che può causare dei crash a Thunderbird ! Io vi ho avvertito.

Oggi, 2 dicembre 2010, ancora nessuna notizia da parte di Xandros in merito alla prosecuzione o meno del progetto Scalix.

In ritardo ormai di oltre un anno sulle previste tappe di rilascio, Scalix sembra avviato verso una morte inevitabile: la community, fino a qualche tempo fa piuttosto attiva sul forum (http://www.scalix.com/forums) è stata inoltre frustrata nel vedere i propri messaggi e le proprie preoccupazioni relative alla prosecuzione in affari del prodotto, sistematicamente cancellati dalla board. Ovviamente non si tratta di un comportamento “eticamente corretto”, specialmente per un prodotto che si fa un vanto di essere “parzialmente” open-source e che, pertanto, necessariamente deve vivere anche di una diffusione pubblica perseguita tramite l’aiuto di appassionati che ne indagano eventuali bug e si mettono a disposizione degli altri per risolvere problematiche di varia natura.

Allo stato attuale quindi, a meno di clamorosi miracoli dell’ultima ora, l’immagine del prodotto è irrimediabilmente compromessa: difficilmente oggi un’azienda che intenda procedere alla implementazione, all’interno della propria struttura, di un sistema di messaggistica e groupware che non comporti l’adozione di Exchange, si rivolgerà con fiducia a Scalix. Le incognite stanno diventando troppe e nessuno ha informazioni valide in merito a quesiti fondamentali quali : “Il prodotto verrà supportato ? Esiste un team di sviluppo in grado di far evolvere il software per integrarlo con le più recenti tecnologie, specialmente quelle mobili ?”. A queste domande l’unica risposta che si è stati in grado di ricevere è una sola : silenzio. Probabilmente la risposta peggiore dato che lascia clienti e semplici appassionati nel limbo di una incertezza mistica : “Aspetto ancora per vedere cosa succede oppure inizio a pianificare la migrazione verso un altro prodotto ?”

Probabilmente un’utenza non professionale (oppure estremamente skillata) opterà per rimanere con Scalix all’ultima release stabile, magari adeguando i propri comportamenti di messaggistica alle funzionalità del prodotto. Ma l’utenza commerciale si trova ad affrontare problemi ben diversi : gli utenti evolvono, le società di telefonia forniscono apparati sempre più moderni, le esigenze di interconnessione con clienti e fornitori si modificano … insomma non possono aspettare. E per costoro rimanere bloccati al palo non è certo un’opzione valida.

Le alternative sono molteplici: ritornare sui propri passi e rimettersi nelle mani Microsoft tornando ad abbracciare Exchange oppure volgere lo sguardo verso altri brand come Zimbra, Zarafa, Open-Xchange ecc.. Tutte soluzioni che permettono sempre l’utilizzo del client di posta primario Outlook ma che differiscono profondamente tra loro per le modalità di licensing ed il prezzo.

Quello che è, purtroppo, consolidato è che Scalix … sembra sparito nel nulla come del resto altri progetti acquisiti e gestiti da Xandros (vedasi Linspire per esempio).

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.