Tra quando questa frase è stata scritta e quando è stata pubblicata, il problema dello spam, grande quanto la Rete, sarà probabilmente raddoppiato nella sua gravità— o almeno sembrerà così. C'era una volta, non così tanto tempo fa, un tempo in cui uno poteva gestire una mailing list senza adottare assolutamente nessuna prevenzione per lo spam. Gli occasionali messaggi non pertinenti sarebbero comunque comparsi, ma abbastanza infrequentemente ed essere solo una piccola noia. Quell'era è andata per sempre. Oggi, una mailing list che non adotta misure di prevenzione dello spam sarà velocemente sommersa di email spazzatura, fino al punto di diventare inservibile. La prevenzione dello spam è imperativa.

Dividiamo la prevenzione dello spam in due categorie: prevenire il comparire di messaggi di spam sulla mailing list e prevenire che la vostra mailing list diventi una fonte di nuovi indirizzi email per gli spammer. La prima è più importante, quindi la esaminiamo per prima.

Gli iscritti spesso vogliono mettere le mail della mailing list in una cartella specifica per il progetto, separata dalle altre mail. Il loro software per la lettura di email può fare ciò automaticamente esaminando gli header delle email. Gli header sono i campi in cima della mail che indicano mittente, destinatario, oggetto, data, e varie altre cose riguardo al messaggio. Alcuni header sono noti e anche obbligatori:

From: ...
To: ...
Subject: ...
Date: ...

Altri sono opzionali, anche se abbastanza standard. Per esempio, alle email non è strettamente richiesto di avere il seguente header

Reply-to: sender@email.address.here

ma molti ce l'hanno, perchè dà ai destinatari un modo per raggiungere l'autore assolutamente sicuro (è specialmente utile quando l'autore ha dovuto inviare da un indirizzo diverso da quello a cui le risposte andrebbero inviate).

Alcuni software per la lettura delle email offrono semplici interfacce per riempire le email basandosi sul modello dell'header dell'oggetto della mail. Questo porta la gente a richiedere che la mailing list aggiunga automaticamente un prefisso a tutti gli oggetti delle email, così che loro possano configurare i loro software per cercare tale prefisso e mettere le email nelle giusta cartella in modo automatico. L'idea è che l'autore scriva:

Oggetto: fare la release 2.5.

ma l'email inviata nella mailing list sarà del tipo:

Oggetto: [discuss@lists.example.org] fare la release 2.5.

Anche se la maggior parte dei software di gestione offre l'opzione di farlo, raccomando fortemente di non abilitare questa opzione. Il problema che risolve può essere facilmente affrontato in altri modi meno intrusivi, e il costo dello spazio sprecato nell'header dell'oggetto è davvero troppo alto. Gli utenti esperti di mailing list scorrono gli oggetti delle email in arrivo per decidere cosa leggere e/o a cosa rispondere. Aggiungere il nome della mailing list all'inizio dell'oggetto delle email può spingere la parte destra dell'oggetto fuori dallo schermo, invisibile. Ciò nasconde l'informazione di cui la gente ha bisogno per decidere quali email aprire, riducendo quindi per tutti la funzionalità complessiva della mailing list.

Invece di usare l'header dell'oggetto, insegnate ai vostri utenti ad usare a loro vantaggio gli altri header standard, a cominciare dall' header del destinatario (To), che dovrebbe dire il nome della mailing list:

To: <discuss@lists.example.org>

Ogni software di lettura mail che può applicare filtri sull'oggetto dovrebbe essere in grado di filtrare altrettanto facilmente l'header del destinatario.

Ci sono alcuni altri header opzionali ma standard che sono previsti nelle mailing list. Applicare filtri su questi è persino più affidabile che usare gli header "To" o "Cc" (Carbon copy, Copia carbone); dato che questi header sono aggiunti dal software di gestione ad ogni nuovo messaggio pubblicato, alcuni utenti potrebbero contare sulla loro presenza:

list-help: <mailto:discuss-help@lists.example.org>
list-unsubscribe: <mailto:discuss-unsubscribe@lists.example.org>
list-post: <mailto:discuss@lists.example.org>
Delivered-To: mailing list discuss@lists.example.org
Mailing-List: contact discuss-help@lists.example.org; run by ezmlm

Per la maggior parte, sono auto-esplicativi. Vedi http://www.nisto.com/listspec/list-manager-intro.html per ulteriori spiegazioni, o se avete bisogno della specifica formale e veramente dettagliata, http://www.faqs.org/rfcs/rfc2369.html.

Va notato che questi header implicano che se avete una mailing list che si chiama "list", allora avete anche gli indirizzi amministrativi "list-help" e "list-unsubscribe" a disposizione. Oltre a questi, è normale avere "list-subscribe", per iscriversi, e "list-owner", per contattare gli amministratori della mailing list. A seconda del software di gestione che usate, questi e/o vari altri indirizzi amministrativi possono essere creati; la documentazione conterrà dettagli su questo. Solitamente una spiegazione completa di tutti questi indirizzi speciali è inviata ad ogni nuovo utente come parte di una email automatica di benvenuto quando si iscrive. Voi stessi probabilmente avrete una copia di questa mail di benvenuto. Se non l'avete, allora chiedetene una copia a qualcun altro, così saprete cosa gli utenti vedono quando si iscrivono alla mailing list. Tenete questa copia a portata di mano così da poter rispondere alle domande riguardo alle funzionalità della mailing list, o ancora meglio mettetela su una pagina web da qualche parte. In questo modo quando la gente perde la loro copia delle istruzioni e scrive per chiedere "Come mi disiscrivo dalla mailing list?", possiate semplicemente passar loro l'URL.

Alcuni software di gestione offrono come opzione l'appendere le istruzioni per la disiscrizione al fondo di ogni messaggio. Se tale opzione è disponibile, usatela. Provoca solo qualche riga in più ad ogni messaggio, in un posto che non dà problemi, e può risparmiarvi molto tempo, riducendo il numero di persone che scrivono—o peggio, scrivono alla mailing list!—chiedendo come disiscriversi.

Prima, in sezione chiamata «Evitare discussioni private», ho sottolineato l'importanza di fare in modo che le discussioni avvengano sui forum pubblici, e ho parlato di come misure sono a volte necessarie per prevenire che le conversazioni finiscano in flussi di email private; inoltre, questo capitolo tratta di come configurare il software di comunicazione del progetto per fargli fare al vostro posto la maggior parte di lavoro possibile. Quindi, se il software di gestione offre un modo di far rimanere in modo automatico le discussioni nella mailing list, potreste pensare che abilitare questa funzionalità sia la scelta più ovvia.

Be', non proprio. Questa funzionalità esiste, ma ha alcuni importanti svantaggi. La domanda riguardante il suo uso o meno è uno dei dibattiti più accesi nella gestione di mailing list—magari non la notizia che compare sui giornali della sera, ma può comparire di tanto in tanto nei progetti di free software. Più avanti, descriverò questa funzionalità, darò le argomentazioni a sostegno di entrambe le fazioni, e darò il miglior consiglio che posso.

La funzionalità in sè è molto semplice: il software di gestione può, se volete, configurare automaticamente l'header Reply-to (Rispondi A) di ogni messaggio in modo da ridirigere le risposte sulla mailing list. Cioè, nonostante cosa il mittente originale ha messo nell'header Reply-to (o anche se non è stato incluso del tutto), al momento in cui gli iscritti vedono il messaggio, l'header conterrà l'indirizzo della mailing list:

Reply-to: discuss@lists.example.org

A prima vista, sembra essere una buona cosa. Dato che virtualmente ogni software di lettura mail presta attenzione all'header Reply-to, quando chiunque risponde ad un messaggio, la risposta sarà automaticamente mandata all'intera mailing list, non solo al mittente del messaggio a cui si è risposto. Sicuramente, chi risponde può ancora cambiare a mano il destinatario, ma la cosa importante è che per default le risposte siano mandate alla mailing list. E' un esempio perfetto dell'uso della tecnologia per incoraggiare la collaborazione.

Sfortunatamente, ci sono alcuni svantaggi. Il primo è noto come il problema del Non Riesco a Trovare la Strada di Casa: a volte il mittente originale potrà mettere il proprio "vero" indirizzo email nel campo Reply-to, perchè per una qualche ragione manda la mail da un indirizzo diverso da quello dove lo riceve. La gente che legge e manda sempre dallo stesso indirizzo non ha questo problema, e potrebbe essere sorpresa della sua esistenza. Ma per chi ha configurazioni email particolari, o chi non può controllare come il suo indirizzo mittente sarà composto (magari perchè scrivono dal lavoro e non hanno influenze sul dipartimento IT), usare il Reply-to potrebbe essere l'unico modo che hanno per assicure che la risposta li raggiunga. Quando una persona di questo genere scrive ad una mailing list a cui non è iscritto, la sua configurazione del Reply-to diventa un'informazione essenziale. Se il software di gestione lo sovrascrive, potrebbe non vedere mai la risposta al suo messaggio.

Il secondo svantaggio ha a che fare con le aspettative, e secondo la mia opinione è l'argomento più potente contro l'occultamento del Reply-to. La maggior parte degli utenti esperti di email sono abituati a due modi basilari di risposta:rispondi a tutti (reply-to-all) e rispondi all'autore (reply-to-author). Tutti i moderni software di lettura mail hanno comandi separati per queste due azioni. Gli utenti sanno che per rispondere a tutti (quindi, includendo la mailing list), devono scegliere reply-to-all, e che per rispondere privatamente all'autore, devono scegliere reply-to-author. Anche se volete incoraggiare le persone a rispondere alla mailing list ogni volta sia possibile, ci sono certe circostanze in cui una risposta privata è prerogativa di chi risponde— per esempio, potrebbero volere dire qualcosa di confidenziale all'autore del messaggio originale, qualcosa che potrebbe essere non appropriato per la mailing list pubblica.

Considerate ora cosa succede quando la mailing list sovrascrive il Reply-to del mittente originale. Chi risponde schiaccia il tasto reply-to-author, aspettandosi di rispondere con un messaggio privato all'autore originale. Dato che questo è il comportamento atteso, potrebbe non preoccuparsi di guardare con attenzione all'indirizzo di destinazione nel nuovo messaggio. Scrive il suo messaggio privato e confidenziale, uno in cui magari dice cose imbarazzanti riguardo a qualcuno della mailing list, e schiaccia il tasto di invio. Inaspettatamente, pochi minuti dopo il suo messaggio appare sulla mailing list!. D'accordo, in teoria dovrebbe avere controllato al campo destinatario, e non dovrebbe aver presunto nulla riguardo all'header Reply-to. Ma gli autori praticamente sempre mettono nel Reply-to il loro indirizzo personale (o meglio il software di posta lo fa per loro), e molti utilizzatori di email di lunga data se lo aspettano. Infatti, quando una persona mette deliberatamente nel Reply-to qualche altro indirizzo, come la mailing list, solitamente lo scrive nel corpo del messaggio, così che la gente non sarà sorpresa per cosa succede quando rispondono.

A causa delle conseguenze anche serie di questo comportamento inaspettato, la mia personale preferenza è la configurazione del software di gestione della mailing list in modo che non tocchi mai l'header Reply-to. Questo è un caso in cui usare la tecnologia per incoraggiare la collaborazione ha, mi sembra, effetti collaterali potenzialmente pericolosi. In ogni caso, ci sono anche alcuni buoni argomenti nell'altra fazione del dibattito. Qualunque modo sceglierete, ogni tanto troverete persone che scrivono sulla mailing list chiedendo perchè non abbiate scelto l'altro modo. Dato che questo non è qualcosa che desiderate avere come argomento principale di discussione, potrebbe essere conveniente avere una risposta pronta preconfezionata, del tipo che sia incline a fermare la discussione piuttosto che incoraggiarla. Cercate di non insistere sul fatto che la vostra decisione, qualunque sia, è ovviamente l'unica giusta e sensata (anche se pensate che sia così). Cercate invece di precisare che è un vecchio dibattito, che ci sono buone argomentazioni a favore di entrambe le fazioni, che nessuna scelta soddisferà tutti gli utenti e quindi avete solo preso la miglior decisione che potevate. Educatamente chiedete che l'argomento non sia ripreso a meno che qualcuno abbia qualcosa di davvero nuovo da dire, quindi stare fuori dalla discussione e sperate che muoia di morte naturale.

Qualcuno potrebbe suggerire una votazione per scegliere un modo piuttosto che un altro. Potete farlo se volete, ma personalmente non penso che votare sia una soluzione soddisfacente in questo caso. La penalità per qualcuno che è sorpreso da questo comportamento è così grande (mandare accidentalmente una email privata ad una mailing list pubblica) e l'inconveniente per gli altri è talmente leggero (doversi ricordare qualche volta di rispondere a tutta la mailing list invece che solo a voi), che non è chiaro perchè la maggioranza, anche se rimane la maggioranza, dovrebbe poter esporre la minoranza a tale rischio.

Non ho trattato tutti gli aspetti del problema qui, solo quelli che sembravano di primaria importanza. Per una discussione completa, vedete questi due documenti 'canonici', che sono quelli che la gente cita sempre quando affrontano questo dibattito:

Nonostante la debole preferenza indicata sopra, non penso che ci sia una risposta "giusta" a questo problema, e participo felicemente a molte mailing list che configurano il Reply-to. La cosa più importante che possiate fare è di implementare un modo o l'altro da subito, cercando di non essere coinvolti in questo dibattito in seguito.

I dettagli tecnici della configurazione della mailing list sono specifici rispetto al software che è in uso, e sono fuori dall'ambito di questo libro. Al momento della scelta o della configurazione dell'archiviatore, considerate queste caratteristiche:

Cosa scritto sopra è solo una lista di punti tecnici per aiutarvi a valutare e configurare un archiviatore. Fare in modo che la gente davvero usi l'archiviatore per il bene del progetto, è discusso nei prossimi capitoli, in particolare sezione chiamata «Uso Ben Visibile degli Archivi».

Qui di seguito ci sono alcuni strumenti open source per gestire mailing list e archiviazione. Se il sito dove è ospitato il vostro progetto ha già una configurazione di default, allora potreste non avere mai bisogno di decidere sull'uso di nessun strumento. Ma se dovete installarne uno da voi, ci sono alcune possibilità. Quelli che ho effettivamente usato sono Mailman, Ezmlm,MHonArc, e Hypermail, ma questo non vuol dire che altri non siano pure buoni (e di sicuro ci saranno altri strumenti là fuori che non ho trovato, quindi non prendete questa come una lista completa).

Software di gestione di mailing list:

Software di archiviazione mailing list: