In caso non l’aveste notato (sono ovviamente sarcastico) il mondo della produttività office non è più un esclusivo monopolio di Microsoft.  E questo è tanto più vero se ci si sofferma ad analizzare gli strumenti per la comunicazione ed in particolare la messaggistica via e-mail.

Nelle nostre attività di business siamo totalmente condizionati dalla disponibilità ubiqua delle e-mail nonostante il loro trasporto sia basato su una tecnologia di protocollo praticamente “preistorica”. Molti strumenti di instant-messaging cercano in ogni modo di soppiantare la cara vecchia e-mail, ma, anche se concettualmente possono assolvere egregiamente al compito di contatto continuo nei gruppi di lavoro, sono ancora troppo avvolti da un’aura di “gioco” o, peggio, di “fancazzismo” che male si accoppia ad un concetto di professionalità e di ordine. Perfino in mobilità i più moderni device portatili, siano essi tablet, smartphone o “semplici” telefoni, pur infarciti di tutti i possibili strumenti per comunicare in modalità “chat”, non si azzardano nemmeno ad uscire sul mercato senza un adeguato supporto per la posta elettronica.

Già, perchè nel mondo del lavoro la posta elettronica è ancora dominatrice incontrastata. E’ flessibile, non ha virtualmente limiti, è intuitiva e, qui arriva il bello, seppure non progettata per questo scopo, si è adattata nel tempo ed in modo improprio al document-workflow. Le sue capacità di trasporto di oggetti allegati, unite alla pigrizia mentale dei suoi utilizzatori che sono sempre poco inclini al cambiamento oltre che, purtroppo, alla loro ignoranza di fronte ad un computer, hanno fatto che si che, specialmente nelle aziende, la comunicazione via e-mail sia il perno su cui tutta l’attività si regge. Se manca la posta elettronica l’azienda si ferma … tragedia !!! Perfino nelle piccole, piccolissime realtà (meno di 10 postazioni in rete locale) condividere i documenti via e-mail, anzichè tramite cartelle condivise, è pratica consolidata e quasi impossibile da scalzare. Inutile disquisire su quali e quanti problemi questa tecnica possa portare : enorme dispendio di spazio con copie e copie dei medesimi documenti che vanno e vengono, impossibilità di avere controlli di versione coerenti, lamentele sui limiti di spazio alle caselle sulle quali sempre più frustrati it-manager cercano di porre dei limiti, pretesa di poter tenere archiviati i messaggi di posta elettronica dall’inizio dei tempi ecc. ecc.

In questo contesto e nell’ambito di una sempre crescente necessità di razionalizzazione dei costi, le aziende rivolgono una, parimenti, crescente attenzione a soluzioni “cloud” anche e soprattutto per la gestione dei servizi connessi alla posta elettronica: mondo nel quale i due player di maggior riferimento sono Google, con le sue Apps, e Microsoft con Office365 e nello specifico Outlook.com.

L’immaginario collettivo pretende di credere che la semplice esternalizzazione dei servizi di posta elettronica ad un provider nella nuvola possa far magicamente sparire odiosi ed apparentemente improduttivi costi legati a server, spazio, copie e supporto specialistico per “far-funzionare-il-server” (quei loschi figuri che girano in azienda che fanno cose che nessuno capisce ma che si beccano tutti i sacramenti della direzione quando il manager tal-dei-tali non riceve la posta sul suo nuovissimo iTelefono-che-fa-tutto). In realtà molti aspetti operativi non vengono assolutamente considerati o maliziosamente sottovalutati. Ecco, invece, a cosa dovete pensare se state pensando di passare a Google Apps for Business per la gestione della posta elettronica nella vostra piccola o grande azienda.

On-line e Off-line

Se la disponibilità, all’interno di una rete LAN, di un servizio locale è indipendente dalla stabilità e disponibilità di connessione al web, non appena si passa ai servizi nella nuvola questa opzione cade. Miseramente. Un banale disservizio di poche ore del vostro carrier di connettività vi taglia letteralmente fuori, non solo dal mondo esterno, ma anche dalla comunicazione intra aziendale. Non potendo raggiungere il servizio esterno di consegna e recapito della posta elettronica, non posso comunicare con soggetti esterni alla struttura e nemmeno con il vicino di tavolo.

Document Workflow

Usare la posta elettronica per questa attività è concettualmente sbagliato: mandare decine di allegati da distribuire in azienda è una bestemmia informatica. Tuttavia si fà e l’abitudine è dura a morire. Quindi bisogna gestirlo. E come funziona con i servizi cloud ? Pessimamente. Per rendere l’idea è utile un piccolo esempio. Supponiamo che voi siate in una stanza in cui lavorate voi ed un vostro collega, proprio due tavoli uno accanto all’altro. Dovendo consegnare un fascicolo al vostro collega che fareste ? Chiamereste la Dhl per prenotare una consegna, aspettereste che arrivasse il fattorino, prendesse la consegna, la portasse al loro deposito di smistamento, avvisasse il vostro collega che c’è una consegna per lui, arrivasse il giorno dopo con il pacco e lo consegnasse al vostro collega ? Oppure allunghereste il plico da un tavolo all’altro con il semplice gesto di una mano ? Ecco con il document-workflow via e-mail nel cloud succede proprio … la prima opzione. Dal vostro pc, impegnate la banda in output per inviare il documento ad un server esterno, che lo recapita nella mailbox di destinazione del vostro collega (che vi ricordo è seduto accanto a voi) il quale per scaricarlo sul suo computer dovrà impegnare nuovamente la banda in ingresso aziendale per ottenere un documento che, a logica, non avrebbe dovuto nemmeno uscire.

Fat-Client vs. Thin Client

Il cambiamento nella modalità di gestione della posta elettronica avviene troppo spesso basandosi su decisioni sbagliate. La prima su tutte è “Che server adottiamo ?” oppure “Che servizio adottiamo ?“. In realtà l’unica domanda a cui davvero si dovrebbe dare peso è : “Quale è il client di posta che utilizzano e a cui sono abituati i dipendenti ? Se glielo cambiamo quali sono i costi in termini di perdita di produttività ? E di addestramento ?“. Piaccia o no Outlook la fa ancora da padrone e una qualsiasi decisione presa alla leggera che comporti la sua abolizione porta spesso a risultati imprevedibili e a piccole sommosse popolari. In azienda poi pensare di sostituire un client di posta con uno basato su interfaccia web è un errore madornale. In primo luogo perchè l’integrazione del client di posta nella shell del computer è parecchio ostica: in altre, volgari e semplicistiche parole, disporre del vecchio click-destro-invia-a-destinatario-di-posta-elettronica è cosa impossibile senza l’installazione di add-on specifici e, purtroppo, non sempre efficaci. Vi è poi da considerare l’interfaccia stessa. Gmail, anche nella versione business, è identico al “normale” Gmail gratuito per uso privato. L’unica differenza sta nel fatto che se paghi non ti sorbisci la pubblicità. I team di sviluppo di Google non sono mai riusciti a dare coerenza e semplicità ai loro strumenti tant’è che tenere sott’occhio account diversi, impersonare identità diverse, accedere a cartelle di posta secondo criteri privilegiati è operazione per pochi e skillatissimi eletti. Ma andando nello specifico dell’operatività “normale” di posta elettronica la loro interfaccia è decisamente disorganizzata, a volte illeggibile e irrazionale. La fisica e comprensibile suddivisione della mia casella in cartelle è stata soppiantata dalle etichette, componendo un nuovo messaggio DEVO iniziare a digitare il nome del destinatario (sempre che lo abbia in rubrica contatti o lo abbia già utilizzato almeno una volta) per avere dei suggerimenti dal momento che il pop-up della rubrica non mi permette di navigarla secondo mio piacimento (magari ordinando per nome di azienda). L’impostazione di default di ordinamento dei messaggi (per thread) è controintuiva e, ovviamente, scordatevi di lavorare off-line. Ma c’è di più: avendo un allegato corposo da inviare dovrete attendere che sia completato l’upload prima di poter inviare il messaggio, mentre con un fat client, il lavoro di upload viene fatto in background dopo che avete cliccato su Invia.

E non pensate di adottare con leggerezza nemmeno l’Outlook Connector perchè non vi avvicinereste nemmeno lontanamente alle funzionalità offerte dall’accoppiata Outlook Exchange. Piuttosto optate per Thunderbird come client in modalità IMAP e Lightning per collegarvi al calendario. Avrete un simulacro abbastanza soddisfacente di quello che facevate con Outlook.

Warning supremo. Non fate mai l’errore di adottare il servizio Gmail pensando di connettere Outlook (o altro client) in modalità POP3. Scaricando in POP3 non avrete mai evidenza di cosa è finito nella cartella di Gmail dedicata alla posta indesiderata (SPAM) e rischiate di perdere mail molto importanti che magari vi arrivano da nuovi potenziali clienti.

Abbandonare Exchange ?

Per molti l’opzione di abbandonare Exchange è allettante. Non condivido molte delle ostilità gratuite che avversano quel prodotto se non una: in effetti costa parecchio. Tuttavia se utilizzate peculiarità di Exchange come, ad esempio, cartelle pubbliche con proprio indirizzo email, funzionalità di Single Sign On ecc. preparatevi a rinunciarvi o ad inventare accrocchi complicatissimi per poter lavorare nello stesso modo nella nuvola. Più facile pensare a software server alternativi ma sempre in-house.

Lock in

Rimanere intrappolati in una scelta che magari non vi soddisfa è molto facile. L’esuberante offerta di spazio per casella offerto da Gmail porta a considerare con leggerezza il clean-up periodico delle caselle di posta (particolarmente difficile con Gmail) e il moving-away può essere un problema. Se non vi trovate bene dovrete pianificare per tempo spostamenti mastodontici di terabyte di posta qualora le vostre esigenze siano per centinaia di utenti. E tornare ad un servizio in-house potrebbe non essere facile.

Lock Out

L’accesso ad un servizio cloud prevede ovviamente un corrispettivo periodico. Se per contingenze sfortunate doveste trovarvi nella necessità di chiedere al fornitore un posticipo delle scadenze non pensate di trovare in un gestore che ha 350 milioni di utenze attivate un interlocutore amichevole. No paghi ? No posta. Con inevitabili ripercussioni sulle attività dovute all’impossibilità di comunicare con la posta elettronica con clienti e fornitori.

Il Cloud

La c.d. nuvola non è solo “internet”. E’ un concetto di astrazione del “ferro” (un computer/server fisico) dal “servizio” o “i servizi” che questo eroga. Posso avere un cloud anche in casa se già dispongo di un dipartimento IT che sa fare il suo mestiere, con l’indubbio vantaggio che investimenti in impianti e tecnologia possono essere capitalizzati a favore di un aumento del valore dell’azienda: al contrario il mero pagamento di un canone di servizio è un costo che nel momento in cui viene sospeso si “porta via” anche il servizio associato. Una attenta valutazione nel medio periodo di costi annui rispetto agli ammortamenti di un nuovo investimento sono da considerare sempre con grande attenzione.

Già in un mio post precedente ho descritto come sia importante impostare correttamente un record SPF associato al dominio di posta per evitare (o ridurre) il rischio di vedere la propria posta elettronica in uscita categorizzata come SPAM dai filtri automatici a protezione delle mailbox dei destinatari.

In questo nuovo articolo estendiamo l’analisi del problema per tutti coloro che, gestendo direttamente un dominio proprio, utilizzano anche il BlackBerry per la propria posta in mobilità. E’ noto che per ricevere/inviare posta dal proprio telefonino BlackBerry sia necessario attivare uno di questi due servizi:

• BIS – BlackBerry Internet Service : sicuramente l’opzione più diffusa, grazie anche al bundle offerto dai numerosi carrier
• BES – BlackBerry Enterprise Server : per una sincronia completa delle mailbox

La distinzione di questi due servizi non è solo importante per le caratteristiche differenti (BIS sincronizza solo la posta mentre con BES si sincronizza tutto – email, contatti, task, memo ecc), ma anche per il modo in cui la posta in uscita dal nostro telefonino viene recapitata. Infatti mentre gli utenti BES utilizzano come trasporto SMTP quello aziendale ovvero il medesimo che utilizza il normale client di posta del computer di rete, quelli invece che hanno la posta BB configurata in modalità BIS inviano i messaggi utilizzando i server Blackberry.

Pertanto, per questa seconda categoria di utenze, è necessario che il gestore del dominio di posta si occupi di integrare all’interno del record SPF anche le informazioni relative ai server BlackBerry che il telefonino usa per inviare. A questo proposito Research In Motion ha approntato diversi puntamenti che definisicono il range di server SMTP che possono essere utilizzati dai telefonini.

Per gli utenti Europei è necessario integrare il record SPF con la seguente direttiva :

include:srs.bis.eu.blackberry.com

In questo modo un esempio di record SPF può essere il seguente :

"v=spf1 a mx include:srs.bis.eu.blackberry.com -all"

Questa notazione significa : considera attendibili tutte le mail associate al dominio che hanno come indirizzi IP di mittenza un qualsiasi record A associato al dominio, oppure che provengano da un server di posta autoritativo per il dominio o, ancora, che siano state inviate da un server BlackBerry europeo.

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.