Le mailing list sono il sale delle comunicazioni all'interno di un progetto. Se un utente fa parte di un forum che non siano pagine web, � molto probabile questo che sia la mailing list. Ma prima che gli utenti provino la mailing list, devono provare l'interfaccia della mailing list—cio� il meccanismo con cui si aggiungono ("subscribe to") alla mailing list. Questo ci porta alla Regola numero 1 della mailing list:
Non provate a gestire le mailing list a mano— usate un software di gestione.
Si pu� essere tentati di farne a meno. Configuare un software di gestione di mailing list pu� sembrare un massacro, di primo acchito. Gestire liste, piccole e con poco traffico, a mano sembrer� seduttivamente facile: si crea un indirizzo di sottoscrizione che fa il forward delle mail su di voi, e quando qualcuno ci scrive, aggiungete (o togliete) gli indirizzi email in qualche file di testo che contiene tutti gli indirizzi della lista. Cosa c'� di pi� facile?
Il trucco sta nel fatto che una buona gestione di mailing list—che � cosa le persone sono arrivate ad aspettarsi—non � per niente facile. Non � solo questione di aggiungere o rimuovere utenti quando essi lo richiedono. E' anche moderare per prevenire lo spam, offrire la mailing list come compendio piuttosto che messaggio per messaggio, fornire una lista standard e informazioni sul progetto come le risposte automatiche, e varie altre cose. Un essere umano che controlla gli indirizzi di sottoscrizione pu� fornire appena un minimo di funzionalit�, e neppure in modo affidabile e pronto come lo farebbe un software.
I moderni software di gestione di mailing list solitamente offrono almeno le seguenti funzionalit�:
Quando un utente si iscrive alla mailing list, dovrebbe velocemente ricevere un messaggio automatico di benvenuto in risposta, che spieghi cosa ha sottoscritto, come interagire ulteriormente con il software di mailing list e (soprattutto) come disiscriversi. Questa risposta automatica pu� essere personalizzata in modo da contentere informazioni specifiche del progetto, di sicuro, come il sito web del progetto, dove si trovano le FAQ, eccetera.
Nella modalit� aggregata, il sottoscrittore riceve una mail al giorno, contenente tutta l'attivit� di quel giorno. Per le persone che stanno seguendo la mailing list senza parteciparvi attivamente, la modalit� aggregata � spesso preferibile, perch� permette loro di vedere tutti gli argomenti in una volta sola e di evitare la distrazione causata da email in arrivo ad ogni momento.
"Moderare" � l'attivit� di controllare i messaggi per assicurarsi che siano a)�non�spam, e b)�sull'�argomento, prima che vengano mandati a tutta la mailing list. L'attivit� di moderazione necessariamente impiega gli esseri umani, ma il software pu� fare molto per semplificarla. Pi� avanti verr� detto altro riguardo alla moderazione.
Tra le altre cose, permette ad un amministratore di entrare e rimuovere facilmente indirizzi obsoleti. Questo pu� diventare urgente quando un indirizzo destinatario inizia a mandare indietro risposte automatiche "Non sono pi� a questo indirizzo" alla mailing list in risposta ad ogni messaggio. (Alcuni software per mailing list possono perfino capirlo da soli e rimuovere la persona in maniera automatica)
Molta gente definisce nei propri programmi di posta sofisticate regole di filtro e risposta. I software di gestione di mailing list possono aggiungere e manipolare certi header standard per queste persone cos� da guadagnare vantaggio da (maggiori dettagli sotto).
Tutti i messaggi della mailing list sono memorizzati e resi disponibili sul web; come alternativa, alcuni software di gestione offrono speciali interfacce per l'integrazione di strumenti di archiviazione esterni come MHonArc (http://www.mhonarc.org/). Come sezione chiamata �Uso Ben Visibile degli Archivi� in Capitolo�6, Comunicazione sostiene, l'archiviazione � cruciale.
Lo scopo di tutto questo � semplicente mettere l'accento sul il fatto che la gestione delle mailing list � un problema complesso che ha dato molti problemi, la maggior parte dei quali � stata risolta. Sicuramente non avrete bisogno di diventarne degli esperti. Ma dovete essere consci del fatto che c'� sempre modo di imparare cose nuove, e che la gestione della mailing list occuper� la vostra attenzione di tanto in tanto durante la vita di un progetto open source. Pi� avanti esamineremo alcuni dei problemi di configurazione delle mailing list pi� comuni.
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.
Ci sono tre tecniche di base per prevenire i messaggi di spam, e la maggior parte dei software di gestione di mailing list li offre tutti. E' meglio usarli tutti insieme:
Permettere la pubblicazione automatica di messagggi solo da parte degli iscritti della mailing list.
Questo � efficace finch� funziona, e comporta un piccolissimo sforzo amministrativo, dato che solitamente si tratta di cambiare una configurazione nel software di gestione di mailing list. Ma bisogna notare che i messaggi che non sono approvati automaticamente non devono essere semplicemente scartati. Invece, dovrebbero essere passati alla moderazione, per due ragioni. Primo, potete voler permettere ai non inscritti di pubblicare messaggi. Una persona con una domanda o un consiglio non dovrebbe avere bisogno di iscriversi alla mailing list solo per pubblicare un solo messaggio. Secondo, anche gli iscritti possono a volte pubblicare da un indirizzo diverso da quello con cui si sono iscritti. Gli indirizzi email non sono un metodo affidabile per identificare le persone, e non dovrebbero essere trattati come tali.
Filtrare i messaggi attraverso software che filtrano spam.
Se il software di gestione lo rende possibile (molti lo fanno), potete avere i messaggi filtrati da un apposito software. Il filtro automatico per lo spam non � perfetto, e non lo sar� mai, dato che ci sar� una corsa alle armi senza fine tra spammer e creatori di filtri. Comunque, pu� considerevolmente ridurre la quantit� di spam che passa attraverso la coda di moderazione, e dato che pi� lunga � la coda e pi� tempo gli esseri umani ci mettono a controllarla, ogni quantit� di filtro automatico � vantaggiosa.
Non c'� spazio qui per le istruzioni dettagliate su come configurare i filtri per lo spam. Dovrete consultare la documentazione del vostro software di gestione mailing list per questo (vedi sezione chiamata �Software� pi� avanti in questo capitolo). Tali software a volte arrivano con alcune funzionalit� precostruite di prevenzione spam, ma potreste voler aggiungere alcuni filtri di terze parti. Ho avuto buone esperienze con questi due: SpamAssassin (http://spamassassin.apache.org/) e SpamProbe (http://spamprobe.sourceforge.net/). Questo non � un commento sui molti altri filtri open source per lo spam al di fuori di questi, alcuni dei quali sono a prima vista abbastanza buoni. Semplicemente mi � capitato di usare questi due e ne sono rimasto soddisfatto.
Moderazione.
Per le mail che non sono automaticamente autorizzate in virt� del fatto che provengono da un iscritto alla mailing list, e che passano attraverso il software di filtraggio spam, se presente, l'ultimo passo � la moderazione: la mail viene mandata ad uno speciale indirizzo, dove un essere umano la esamina e la conferma o la respinge.
Confermare un messaggio assume una tra due forme: potete accettare il messaggio solo per questa volta, o potete dire al software di ammettere questo e i prossimi messaggi dallo stesso mittente. Dovreste quasi sempre fare cos�, per ridurre la futura mole di moderazione. I dettagli su come fare ad accettare cambiano da sistema a sistema, ma � solitamente questione di rispondere ad uno speciale indirizzo con il comando "accept" (che significa accettazione solo per questo messaggio) o "allow" (permetti questo e i messaggi futuri).
Si respinge solitamente ignorando la mail di moderazione. Se il software di gestione non riceve mai conferme che qualcosa � un messaggio valido, allora non lo passer� alla mailing list, quindi semplicemente ignorando la mail di moderazione ottiene l'effetto desiderato. A volte avete anche l'opzione di rispondere con un comando "rejet" o "deny", per disapprovare automaticamente le future mail dallo stesso mittente senza neppure farle passare attraverso la moderazione. Raramente c'� motivo di fare cos�, dato che la moderazione si occupa soprattutto di spam, e gli spammer tendono a non usare lo stesso indirizzo due volte.
Cercate di usare la moderazione solo per scartare spam e messaggi palesemente non attinenti, come quando qualcuno uno manda un messaggio alla mailing list sbagliata. Il sistema di moderazione solitamente vi fornir� un modo per rispondere direttamente al mittente, ma non usate questo metodo per rispondere a domande che in realt� appartengono alla stessa mailing list, anche se sapete al volo la risposta. Fare cos� priver� la comunit� del progetto dell'immagine accurata dei tipi di domande che la gente pone, e negher� un'opportunit� di rispondere alle domande e/o di vedere le risposte di altri. La moderazione di mailing list riguarda soltanto l'evitare i messaggi spazzatura e email non pertinenti, nient'altro.
Per prevenire che la vostra mailing list diventi una fonte di indirizzi per gli spammer, una tecnica comune � nascondere gli indirizzi delle email delle persone presenti negli archivi, ad esempio sostituendo
jrandom@somedomain.com
con
jrandom_AT_somedomain.com
oppure
jrandomNOSPAM@somedomain.com
o qualche altra simile evidente (per gli esseri umani) codifica. Dato che i raccoglitori di indirizzi di spam spesso funzionano elaborando le pagine web—compresi gli archivi onlime della vostra mailing list—e cercando sequenze di caratteri contententi "@", codificare gli indirizzi � un modo di rendere gli indirizzi email della gente invisibili o inutili per gli spammer. Questo non evita che dello spam sia inviato alla mailing list stessa, certo, ma evita che la quantit� di spam inviata direttamente agli indirizzi personali degli utenti aumenti.
Nascondere gli indirizzi pu� essere controverso. Alcune persone lo apprezzano molto e saranno sorpresi se i vostri archivi non lo fanno automaticamente. Altri pensano che sia un disturbo (perch� gli esseri umani devono anche ritradurre gli indirizzi prima di usarli). A volte la gente afferma che � inutile, perch� un raccoglitore di indirizzi potrebbe in teoria supplire ogni modo coerente di codifica. Comunque, va notato che c'� una prova empirica del fatto che nascondere gli indirizzi � efficace, vedi http://www.cdt.org/speech/spam/030319spamreport.shtml.
Idealmente il software di gestione dovrebbe lasciare la scelta ad ogni iscritto individualmente, o attraverso uno speciale header si/no oppure una configurazione nelle preferenze del proprio account. Comunque, non sono a conoscenza di alcun software che offre una scelta per iscritto o per messaggio, quindi per ora il gestore della mailing list deve prendere una decisione per tutti (assumendo che l'archiviazione abbia tale funzionalit�, il che non accade sempre). Tendo moderatamente verso l'attivazione dell'occultamento degli indirizzi. Alcune persone sono molto attente ad evitare di pubblicare i loro indirizzi email su pagine web o in qualunque altro posto in cui un raccoglitore di indirizzi potrebbe vederlo, e sarebbero dispiaciute di vedere tutta la loro cura buttata via da un archivio di mailing list; allo stesso tempo, il disturbo che l'occultamento di indirizzi crea agli utenti � molto leggero, dato che � banale ritrasformare un indirizzo oscurato in uno valido se avete bisogno di contattare quella persona. Ma tenete a mente che, alla fine, � sempre una corsa alle armi: nel tempo in cui avete letto questo, i raccoglitori di indirizzi potrebbero essersi evoluti al punto in cui possono riconoscere i metodi pi� comuni di occultamento, e dovremo pensare a qualcos'altro.
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:
Lasciate Reply-to solo, by Chip Rosenthal
Mettete Reply-to alla mailing list, di Simon Hill
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.
Un giorno, qualcuno avr� la brillante idea di implementare un tasto reply-to-list nel software di lettura posta. Userebbe qualcuno degli header menzionati prima per capire l'indirizzo della mailing list, e quindi invierebbe la risposta direttamente alla mailing list soltanto, lasciando fuori ogni altro indirizzo di destinatazione, dato che la maggior parte dei quali � comunque iscritto nella lista. Infine, altri software di email adotteranno tale funzionalit� e tutta questa discussione scomparir�. (Veramente, il sofware di posta Mutt offre questa funzionalit�.[13])
Una soluzione persino migliore per l'occultamento del Reply-to sarebbe una preferenza dell'iscritto. Coloro che vogliono la mailing list con il Reply-to nascosto potrebbero chiederlo, e coloro che non lo vogliono potrebbero chiedere di lasciare il Reply-to com'�. Comunque, non sono a conoscenza di nessun software di gestione di mailing list che offra questa opzione per l'iscritto. Per ora, pare di essere fermi ad un'impostazione di tipo globale. [14]
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:
La gente a volte vuole far riferimento ad un messaggio in archivio inviato nell'ultima ora o due. Se possibile, l'archiviatore dovrebbe archiviare ogni messaggio istantaneamente, cos� che per il momento in cui il messaggio compare nella mailing list, � gi� presente negli archivi. Se questa opzione non � disponibile, cercate almeno di provare a fare in modo che l'archiviatore si aggiorni all'incirca ogni ora. (per default, alcuni archiviatori compiono i loro processi di aggiornamento una volta ogni notte, ma in pratica � un tempo troppo grande per una mailing list attiva)
Una volta che un messaggio � memorizzato ad una particolare URL, dovrebbe rimanere accessibile a quella stessa URL per sempre, o per il maggior tempo possibile. Anche se gli archivi saranno ricostituiti, ristabiliti da backup o messi a posto in qualche altro modo, tutte le URL che sono gi� state rese pubblicamente disponibili dovrebbero rimanere invariate. Riferimenti stabili rendono possibile per i motori di ricerca Internet di indicizzare gli archivi, che � una manna per gli utenti in cerca di risposte. Referimenti stabili sono anche importanti perch� il bug tracker spesso fa riferimento ai messaggi della mailing list (vedi sezione chiamata �Tracciamento dei bug�) pi� avanti in questo capitolo o in documenti da altri progetti.
Idealmente, il software di gestione della mailing list dovrebbe includere in un header quando distribuisce il messaggio ai destinatari, una URL di archiviazione del messaggio, o almeno una porzione della URL specifica per il messaggio. In questo modo la gente che ha una copia del messaggio possa essere in grado di sapere la sua collocazione nell'archivio senza dovere veramente visitare l'archivio, il che sarebbe d'aiuto dato che ogni operazione che coinvolge il proprio web browser automaticamente occupa del tempo. Non so se ogni software di gestione include tale funzionalit�; sfortunatamente, quelli che ho usato no. Comunque, � qualcosa da cercare (o, se scrivete software per mailing list, � una funzionalit� la cui implementazione �, per favore, da considerare).
Dovrebbe essere ragionevolmente ovvio come fare il backup degli archivi, e il modo di ristabilirli non dovrebbe essere troppo difficile. In altre parole, non trattate il vostro archiviatore come una scatola nera (black box). Voi (o qualcuno nel vostro progetto) deve sapere dove i messaggi sono memorizzati, e come rigenerare l'archivio corrente dal backup se dovesse essere necessario. Questi archivi sono dati preziosi—un progetto che li perde, perde una buona parte della sua memoria collettiva.
Dovrebbe essere possibile andare da ogni singolo messaggio al thread (gruppo di messaggi correlati) di cui il messaggio originale fa parte. Ogni thread dovrebbe avere anche la propria URL, diversa dalle URL dei messaggi singoli che lo compongono.
Un archiviatore che non supporta la ricerca—sui contenuti dei messaggi, cos� come sugli autori e oggetti—� praticamente inutile. Va notato che alcuni archiviatori supportano la ricerca semplicemente appoggiandosi per l'elaborazione su di un motore di ricerca esterno come Google. Questo � accettabile, ma il supporto alla ricerca diretta � solitamente meglio rifinito, perch� permette a chi cerca, per esempio, di specificare che la chiave di ricerca appaio nell'oggetto piuttosto che nel corpo del messaggio.
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:
Mailman�—�http://www.list.org/
(contiene un archiviatore, e ha la possibilit� di aggiungerne di esterni.)
SmartList�—�http://www.procmail.org/
(Fatto per essere usato con il sistema di elaborazione email Procmail.)
Ecartis�—�http://www.ecartis.org/
ListProc�—�http://listproc.sourceforge.net/
Ezmlm�—�http://cr.yp.to/ezmlm.html
(Progettato per lavorare con il sistema di consegna mail Qmail )
Dada�—�http://mojo.skazat.com/
(Nonostante i bizzarri tentativi di nasconderlo, questo � free software, rilasciato sotto la licenza GNU General Public License. Contiene anche un archiviatore.)
Software di archiviazione mailing list:
MHonArc�—�http://www.mhonarc.org/
Hypermail�—�http://www.hypermail.org/
Procmail�—�http://www.procmail.org/
(Software complementare a SmartList, questo � un sistema generale di processamento email che pu�, apparentemente, essere configurato con archiviatore.)
[13] Poco dopo la pubblicazione di questo libro, Michael Bernstein mi scrisse per dirmi : "Ci sono altri software di mail che implementano la funzionalit� reply-to-list oltre a Mutt. Per esempio, Evolution ha questa funzionalit� come scorciatoia da tastiera, ma non come pulsanti (Ctrl+L)."
[14] Da quando ho scritto ci�, ho saputo che c'� almeno un sistema di gestione che offre tale funzionalit�: Siesta. Vedete anche questo articolo a riguardo: http://www.perl.com/pub/a/2004/02/05/siesta.html