Listas de e-mail são o pão com manteiga das comunicações do projeto. Se um usuário é exposto a qualquer fórum além das páginas web, é bem provável que seja uma das listas de e-mail do projeto. Mas antes que eles experimentes a lista em si, eles irão se deparar com a interface da lista de e-mail—isto é, o mecanismo pelo qual eles se juntarão ("increver a") a lista. Isso nos leva a Regra no. 1 de listas de e-mail:
Não tente gerenciar listas de e-mail manualmente—use um software de gerenciamento de lista.
Será tentador descartar esta possibilidade. Configurar um software de gerenciamento de lista de e-mail pode parecer um pouco exagerado no início. Gerenciar listas pequenas e com pouco tráfego manualmente parecerá muito fácil: você só precisa configurar um endereço de inscrição que encaminhe as mensagens para você, e quando alguém envia um e-mail, você adiciona (ou remove) o endereço e-mail em algum arquivo texto que contém todos os endereços da lista. O que poderia ser mais simples que isso?
A pegadinha é que um bom gerenciamento da lista de e-mail—que é o que as pessoas esperam—não é nem um pouco simples. Não se trata apenas de adicionar ou remover usuários quando eles pedem. Trata-se também de moderar para evitar spam, oferecer um e-mail com resumos ou mensagem a mensagem, fornecer a lista padrão e informações do projeto através de auto-resposta, e várias outras coisas. Uma monitoração humana do endereço de inscrição pode fornecer apenas um mínimo de funcionalidade, e ainda assim não tão confiável e rápido quanto pode fazer um software.
Um software moderno de gerenciamento de listas oferece no mínimo as seguintes funcionalidades:
Quando um usuário se inscreve a uma lista, ele pode imediatamente receber uma mensagem de boas vindas, dizendo que ele foi inscrito, como interagir com o software da lista de e-mail, e (mais importante) como cancelar a inscrição. Esta resposta automática pode ser customizada para conter informações específicas do projeto, tais como o web site, localização do FAQ, etc.
No modo digerido, o inscrito recebe um e-mail por dia, contento toda a atividade da lista naquele dia. Para pessoas que estão acompanhando vagamente a lista, sem participar, este modo é geralmente mais adequado, pois permite a eles olharem todos os assuntos de uma só vez e evitar a distração de e-mails chegando em horários aleatórios.
"Moderar" é verificar os envios e assegurar que eles a) não sejam spam, e b) estejam dentro do tópico, antes que eles sejam enviados para toda a lista. A moderação envolve necessariamente humanos, mas o software pode ajudar bastante para torná-la mais fácil. Haverá mais conteúdo sobre moderação adiante.
Entre outras coisas, ela permite que o administrador acesse e remova endereços obsoletos facilmente. Isso pode tornar-se urgente quando um endereço destinatário passa a enviar respostas automáticas com "Eu não utilizo mais este e-mail" de volta para a lista para todas as outras mensagens. (Alguns softwares conseguem detectar este comportamente e remover a pessoa automaticamente.)
Muitas pessoas possuem filtros sofisticados e regras de resposta configuradas em seus clientes de e-mail. Os softwares de listas de e-mail podem adicionar e manipular alguns cabeçalhos padrões para que essas pessoas possam obter alguma vantagem disso (mais detalhes a seguir).
Todos os enviados para uma lista gerenciada são armazenados e disponibilizados na web; alternativamente, alguns softwares de listas de e-mail oferecem interfaces especiais para conectar uma ferramenta externa de arquivamento como o MHonArc (http://www.mhonarc.org/). Como “Conspicuous Use of Archives” discute no Capítulo 6, Communications, o arquivamento é crucial.
O ponto de tudo isto é meramente para enfatizar que o gerenciamento de listas de e-mail é um problema complexo o qual foi pensado bastante, e resolvido em sua maioria. Você certamente não precisa se tornar um especialista nisso. Mas você deve estar a par que sempre há espaço para aprender mais, e que o gerenciamento da lista irá ocupar a sua atenção de tempos em tempos no curso da execução de um projeto de software livre. A seguir nós examinaremos um pouco dos problemas mais comum na configuração das listas de e-mail.
No intervalo em que esta sentença é publicada, o tamanho do problema de spam provavelmente terá sua gravidade dobrada— ou ao menos estará neste camninho. Há não muito tempo atrás era possível que alguém abrisse uma lista de e-mails sem precisar tomar nenhuma medida de prevenção. Os e-mails de spam ainda iriam aparecer, com com tão pouca frequência que era um problema de nível bem baixo. Este tempo se foi para sempre. Hoje, uma lista de e-mail que não toma medidas de prevenção de spam será rapidamente submersa por lixos de e-mail, ao ponto de ficar inutilizável. A prevenção de spam é obrigatória.
Dividimos a prevenção de spam em duas categorias: previnindo que envios de spam apareçam na sua lista de e-amils, e previnindo a sua lista de e-mails de ser a fonte de novos endereços de e-mails para spammers. A primeira é a mais importante, e iremos examiná-la primeiro.
Existem três técnicas básicas de previnir envios de spam, e a maior parte de software de listas de e-mail oferece todas elas. Elas são melhores se usadas em conjunto:
Permita apenas que os inscritos enviem e-mails para lista.
Isso é muito efetivo efetivo, e envolve apenas um pequeno esforço administrativo, pois geralmente é apenas uma questão de configuração no software de gerenciamento da lista de e-mails. Mas perceba que os envios que não são aprovados automaticamente não podem ser simplesmente descartados. Ao invés disso, eles devem passar por uma moderação, por duas razões. Primeiro, você quer que os não inscritos possam enviar e-mails. Uma pessoa com uma questão ou uma sugestão não precisa se inscrever na lista apenas para deixar uma única mensagem. Segundo, mesmo os inscritos poder de vez em quando enviar mensagens de um endereço diferente que não está inscrito. Endereços de e-mail não são métodos confiáveis de se identificar as pessoas, e não deveriam ser usados para tal fim.
Filtre os envios através de um software de filtro de spams.
Se o software de lista de e-mail permitir (a maioria permite), você pode filtrar as mensagens com um software de filtro de spams. O filtro de spam automático não é perfeito, e nunca será, pois existe uma guerra sem fim entre spammers e escritores de filtros. Contanto, pode ser ótimo em reduzir a quantidade de spam que chegam através da fila de moderação, e como maior o tamanho da fila, mais tempo uma pessoa levará para examiná-la, qualquer quantidade de filtragem automática é benéfica.
Não há espaço aqui para instruções detalhadas de configuraraçã dos filtros de spam. Você terá de consultar a documentação do seu software de lista de e-mails para isso (veja “Software” adiante neste capítulo). Os softwares de listas geramente vem embutido com funcionalidades de prevenção de spam, mas você pode querer colocar filtros de terceiros. Eu tive boas experiências com esses dois: SpamAssassin (http://spamassassin.apache.org/) e SpamProbe (http://spamprobe.sourceforge.net/). Este não é um comentário a respeito de diversos outros filtros de spam existentes por aí, alguns dos quais são aparentemente muito bons. Eu apenas usei esses dois e fiquei satisfeito com eles.
Moderação.
Para e-mais que não são automaticamente autorizados por não ser de um inscrito, e que passou pelos softwares de filtro de spam, caso haja algum, o último estágio é a moderação: o e-mail é direcionado para um endereço especial, onde uma pessoa o examina e o confirma ou o rejeita.
Confirmar um envio pode ser uma das duas formas: você pode aceitar a mensagem apenas desta vez, ou você pode dizer ao software da lista para permitir este e todas as mensagens futuras provenientes do mesmo remetente. Você quase sempre irá preferir a última forma, com objetivo de reduzir o fardo da moderação futura. Detalhes de como confirmar variam de sistema para sistema, mas geralmente é uma questão de responder a um endereço especial com o comando "accept" (significando a confirmação apenas desta mensagem) ou "allow", (permitindo a mensagem atual e futuras).
A rejeição é geralmente feita simplesmente ignorando o e-mail de moderação. Se o software de lista nunca receber a confirmação de que não é uma mensagem válida, então ele não irá repassar a mensagem para a lista, o que simplesmente excluir o e-mail de moderação surte o efeito desejado. Algumas vezes você também tem a opção de responder com os comandos "reject" ou "deny", para desaprovar automaticamente e-mails futuros deste remetente sem precisar passar novamente pela moderação. Raramente há um sentido em fazer isso, pois a moderação trata na maioria de prevenção de spam, e spammers não costumam realizar envios do mesmo endereço mais de uma vez.
Certifique-se de usar a moderação apenas para filtrar spams e mensagens que estão claramente fora do escopo, tais como quando alguém envia uma mensagem acidentalmente para a lista errada. O sistema de moreração geralmente fornece uma forma de se responder diretamente ao remetente, mas não use este método para responder questões que realmente pertencem a lista em si, mesmo se você souber a resposta de cabeça. Fazer isso privaria a comunidade do projeto de uma visão apurada dos tipos de questões que as pessoas estão fazendo, e irá privá-las de uma chance de responder as questões elas mesmas e/ou ver a resposta dos demais. A moderação da lista é estritamente sobre manter a lista livre de e-mails de lixo e fora do tópico, e nada mais.
Para evitar que suas listas de e-mail sejam uma fonte de endereços para spammers, uma técnica comum é camuflar os endereços das pessoas nos arquivos, substituindo por exemplo
jrandom@somedomain.com
por
jrandom_AT_somedomain.com
ou
jrandomNOSPAM@somedomain.com
ou alguma codificação similar e óbvia (para humanos). Como os caçadores de e-mails para spam geralmente trabalham rastreando páginas da internet—incluindo os arquivos online se suas listas de e-mail—e procurando por sequências que contenham "@", camuflar os endereços é uma forma de deixar os endereços de e-mail das pessoas invisível ou sem utilidade para os spammers. Claro que isto não faz nada para evitar que spams sejam enviados da própria lista de e-mail, mas evita o aumento do número de spams enviados diretamente para os e-mails pessoais dos usuários da lista.
A camuflagem de endereços pode ser controversa. Algumas pessoas gostam bastante e ficarão surpresas se seus arquivos não fizerem isso automaticamente. Outras pessoas acham muito incoveniente (pois elas também devem traduzí-los antes de o usarem). Algumas vezes as pessoas asseguram que não tem efeito, uma vez que os caçadores podem em teoria compensar qualquer padrão de camuflagem consistente. Entretanto, note que há uma evidência empírica que a camuflagem de endereços é efetiva, veja http://www.cdt.org/speech/spam/030319spamreport.shtml.
Idealmente, o software de gerenciamento da lista deixará a escolha a cada inscrito, tanto por um cabeçalho especial com um Sim/Não ou então nas preferências da conta daquele inscrito. Contanto, eu não conheço um software que oferece uma opção por inscrito ou por mensagem em relação a isso, deixando uma decisão a ser tomada pelo administrador para todos (assumindo que o arquivador oferece esta funcionalidade, o que nem sempre é o caso). Eu fico levemente inclinado em direção a ligar a opção de camuflagem. Algumas pessoas são muito cuidadosas e evitam colocar seus endereços de e-mail em uma página web ou qualquer outra local que um caçador de e-mails para spam possa vê-lo, e eles ficarão desapontados ao ter todo o trabalho jogado fora por um arquivo de lista de e-mails; enquanto isso, a incoveniência que a camuflagem e e-mails impõe aos usuários de arquivos são bem leves, pois é fácil transformar um e-mail camuflado em um e-mail válido se você precisar contatar diretamente a pessoa. Mas tenha em mente que, no final, ainda é uma corrida de armamentos: no momento que estiver lendo isto, os caçadores podem muito bem ter evoluído ao ponto que eles possam reconhecer as formas mais comuns de camuflagem, e nós teremos de pensar em alguma outra coisa.
Os assinantes de listas geralmente querem deixar os e-mails da lista em uma pasta específica do projeto, separando-os dos demais e-mails. O software de e-mail pode fazer isto automaticamente examinando os cabeçalhos dos e-mails. Os cabeçalhos são campos especiais no topo do e-mail que identifica o remetente, destinatário, assunto, data, e várias outras informações sobre a mensagem. Certos cabeçalhos são bem conhecidos e obrigatótios efetivamente:
De: ... Para: ... Assunto: ... Data: ...
outros são opcionais, mas ainda assim padrões. Por exemplo, e-mails não requerem estritamente ter o cabeçalho
Responder a: sender@email.address.here
mas a maioria o faz, porque isso dá aos destinatários uma forma infalível de se chegar ao autor (isto é especialmente útil quando o autor teve que enviar de um endereço diferente ao qual as respostas deveriam ser direcionadas).
Alguns softwares de leitura de e-mail ofecerem uma interface amigavel para arquivamento de e-mails baseado em padrões no cabeçalho Assunto. Isso leva as pessoas a solicitarem que a lista de e-mail adicione automaticamente um prefixo em todos os Assuntos, e então eles poderão configurar os leitores para buscar por aquele prefixo e automaticamente arquivar a mensagem na pasta correta. A idéia é que o autor original escreveria:
Assunto: Construindo o release 2.5.
mas o e-mail apareceria na lista desta forma:
Assunto: [discuss@lists.example.org] Construindo o release 2.5.
Apesar da maioria de software de gerenciamento de listas oferecer uma opção para isso, eu sou fortemente contra este opção habilitada. O problema que ela resolve pode facilmente ser resolvido de uma maneira menos importuna, e o preço de se perder boa parte do campo de Assunto é extremamente alto. Usuários experientes de listas de e-mail normalmente olham os assuntos de e-mails que chegaram no dia para decidir quais ler e/ou responder. Prefixar o nome da lista no assunto pode empurrar o Assunto para a direita na tela, deixando-o invisível. Isso ofusca a informação que as pessoas dependem para decidir quais e-mails serão abertos, reduzindo assim a funcionalidade geral da lista para todo mundo.
Ao invés de adulterar o cabeçalho Assunto, ensine aos seus usuários a usarem a vantagem de outros cabeçalhos padrões, começando com o "Para", que deve informar o nome da lista:
Para: <discuss@lists.example.org>
Qualquer leitor de e-mail que pode filtrar o Assunto deve ser capaz de filtrar o Para facilmente.
Existem outro cabeçalhos opcionais mas padrões para listas de e-mail. Filtrar por eles é ainda mais confiável que usar os cabeçalhos "Para" ou "Cc"; como esses cabeçalhos são colocados em cada mensagem pelo próprio software de gerenciamento da lista, alguns usuários podem estar contando com a presença deles:
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
Eles são auto-explicativos na sua maioria. Veja http://www.nisto.com/listspec/list-manager-intro.html para maiores esclarecimentos, ou se você precisa de uma especificação formal e realmente detalhada, veja http://www.faqs.org/rfcs/rfc2369.html.
Perceba em quanto esses cabeçalhos complicam caso você tenha uma lista de e-mail com o nome de "list", e que você tenha os endereços administrativos "list-help" e "list-subscribe", para inscrições, e "list-owner", para contatar os administradores da lista. Dependendo do software de gerenciamento da lista que você usa, esses e/ou vários outros endereços administrativos poderiam estar encrencados; a documentação terá os detalhes. Normalmente uma explicação completa de todos estes endereços especiais é enviado para cada novo usuário como parte de um e-mail automático de "boas vindas" na inscrição. Provavelmente você terá uma cópia deste e-mail de boas vindas. Se não tiver, peça uma cópia a alguém, para saber o que os seus usuários estão vendo quando eles assinam a lista. Mantenha a cópia por perto para poder responder questões sobre a lista de e-mails, ou melhor ainda, coloque-a em uma página web em algum lugar. Desta forma quando alguém perder a própria cópia das instruções e perguntar "Como eu cancelo a inscrição nesta lista?", você apenas envia a ela a URL.
Alguns softwares de lista de e-mail oferecem a opção de anexar as instruções de cancelamento ao final de todas as mensagens. Se esta opção estiver disponível, habilite-a. Ele coloca apenas algumas linhas extras por mensagem, em um local inofensivo, e te ajuda a ganhar tempo, diminuindo o número de pessoas que enviam mensagens para você—ou pior, enviam para lista!—peguntando sobre como cancelam a inscrição.
Anteriormente em “Evite Discussões fechadas”, eu enfatizei a importância de certificar-se de que as discussões fiquem nos forums públicos, e falei sobre a necessidade de algumas medidas ativas para evitar que as conversas passem para um ambiente com discussão privada; além disso, este capítulo tratou da configuração de softwares de comunicação do projeto para fazer o máximo de trabalho possível para você. Por isso, se o software de gerenciamento de lista oferece uma maneira de manter as discussões na lista automaticamente, você certamente pensará que deixar esta opção ligada é a uma escolha óbvia.
Bem, não é bem assim. A tal opção existe, mas ela possui algumas desvantagens graves. A questão de usá-la ou não é uma das discussões mais fervorosas sobre gerenciamento de listas de e-mail.—na verdade, não é uma controvérsia que iria ao noticiário do horário nobre na sua cidade, mas ele pode vir a tona de tempos em tempos em projetos de software livre. A seguir, descreverei esta opção, elucidando os argumentos dos dois lados, e farei a melhor recomendação que puder.
A opção em si é bem simples: o software da lista de e-mails pode, se você quiser, colocar automaticamente o cabeçalho "Responder a" em todas as mensagens para redirecionar as respostas para a lista de e-mail. Isto é, não importa o que o remetente original coloque no cabeçalho "Responder a" (ou mesmo se ele não incluir nenhum), quando os assinantes da lista virem a mensagem, o cabeçalho irá conter o endereço da lista:
Reply-to: discuss@lists.example.org
A primeira vista, isto parece ser algo bom. Por que virtualmente todo leitor de e-mail reconhece o cabeçalho "Responder a", então quando alguém responder a mensagem, a resposta irá diretamente para toda a lista automaticamente, e não apenas ao remetente da mensagem original. Claro que quem responde ainda pode mudar manualmente para onde vai a mensagem, mas o que é importante aqui é que as respostas serão direcionadas a lista por padrão. É um exemplo perfeito de utilizar a tecnologia para encorajar a colaboração.
Infelizmente, existem algumas desvantagens. A primeira é conhecida como o problema Não consigo encontrar o caminho de volta pra casa: Algumas vezes, o remetente original irá colocar o seu endereço de e-mail "real" no campo "Responder a", pois por uma razão ou outra ele envia e-mails de um endereço diferente do qual ele usa para recebê-los. Pessoas que sempre leem e enviam do mesmo local não tem este problema, e podem até ficar surpresos que isso possa existir. Mas para aqueles que possuem configurações de e-mail diferenciadas, ou que não possuem controle para alterar o endereço de envio (talvez porque enviem do trabalho e não possuem nenhuma influência no departamento de TI), usando o "Responder a" pode ser a única forma que eles tem de assegurar que as respostas cheguem até eles. Quando tal pessoa envia mensagem para a lista de e-mails o qual ela não está inscrivta, sua configuração de "Responder a" torna-se uma informação essencial. Se o software da lista o sobrescreve, pode ser que ele nunca veja as respostas para sua mensagem.
A segunda desvantagem tem a ver com as expectativas, e na minha opinião é o argumento mais forte contra a alteração do "Responder a". Usuários de e-mails mais experientes estão acostumados a dois métodos básicos de resposta: responder a todos e responder ao autor. Todos os softwares modernos de leitura de e-mail possuem formas diferenciadas para estas duas ações. O usuários sabem que para responder a todos (isto é, incluindo a lista), eles precisam escolher "Responder a todos", e para responder somente ao autor, eles precisam escolher "Responder ao autor". Embora você queira encorajar as pessoas a responder para a lista sempre que possível, existem certas circunstâncias onde uma resposta privada é a prerrogativa do autor—por exemplo, eles podem querer dizer algo confidencial para o autor da mensagem original, algo que seria inapropriado para para a lista pública.
Agora considere o que acontece quando a lista sobreescreveu o "Reponder a" original do rementente. Quem responder irá acionar a opção "responder ao autor", com a expectativa de estar enviando uma mensagem privada de volta ao autor original. Como este é o comportamento experado, ele pode nem mesmo se importar em olhar cuidadosamente para o endereço do destinatários na nova mensagem. Ele compõe sua mensagem confidencial e privada, da qual talvez diga algo embaraçoso sobre alguém da lista, e envia o e-mail. Inexperadamente, alguns minutos depois a mensagem aparece na lista de e-mails! É verdade que na teoria ele deveria olhar atentamente ao campo de destinatário, e não deveria aceitar qualquer coisa sobre o cabeçalho "responder a". Mas os autores quase sempre colocam o "Responder a" para seu endereço pessoal (ou então, o software de e-mails configura isso para eles), e muitos usuários antigos de e-mail vem a esperar por isso. Na verdade, quando alguém propositalmente configura o "responde a" para algum outro endereço, ele geralmente cita isso no corpo da mensagem, para que as pessoas não fiquem surpreendidas com o que acontece quando elas responderem a nebsagem.
Devido a possibilidades de consequências sérias por este comportamento inexperado, minha preferência pessoal é conifigurar o software para nunca todas no cabeçalho "responder a". Esta é uma área onde usar a tecnologia para encorajar a colaboração possui ao meu ver, efeitos colaterais altamente perigosos. Entretanto, existem fortes argumentos do outro lado desta discussão. Independente de qual você escolha, sempre haverão pessoas perguntando porque você não utilizou a outra maneira. Como isto não é algo que você irá querer como tópico perincipal de discussão na sua lista de e-mail, pode ser interessante ter uma responta pronta para isso, uma do tipo que irá frear a discussão ao invés de encorajá-la. Certifique-se que você não insista que a sua decisão, independende de qual seja, é obviamente a única e a mais sensata (mesmo que você realmente ache isto). Ao invè disso, diga que isto é um debate antigo, e que há bons argumentos dos dois lados, e nenhuma escolha irá satisfazer a todos os usuários, e que você procurou tomar a melhor decisão que você pode. Educadamente peça que o assunto não seja levado adianta a menos que alguém tenha algo genuinamente novo a dizer, e então fique fora da discussão e espere que ele morra de morte natural.
Alguém pode sugerir em votar em uma maneira ou na outra. Você pode fazer isso se quiser, mas eu pessoalmente não acho que contar votos é uma solução adequada neste caso. A penalidade para quem for surpreendido por este comportamento é tão grande (enviar acidentalmente um e-mail para uma lista pública), e a inconveniência para todos os outros é razoavelmente pequena (ocasionalmente ter que lembrar alguém a responder para toda a lista ao invés de a você somente), que não é claro que a maioria, mesmo que eles sejam a maioria, deveriam ser capazes de colocar a minoria em risco.
Eu não enderecei todos os aspectos deste problema aqui, apenas os que parecem ser de extrema importância. Para uma discussão completa, verifique estes dois documentos ortodoxos, os quais são sempre citados quando as pessoas entram neste debate:
Leave Reply-to alone (Deixe o Responder a em paz), por Chip Rosenthal
Set Reply-to to list (Configure o Responder a para lista), por Simon Hill
Apesar a leve preferência indicada acima, eu não acho que haja uma resposta "certa" para esta questão, e participo com felicidade em muitas listas que realmente configuram o "responder a". A coisa mais importante que você pode fazer é configurar uma das formas logo no início, e procurar não se envolver em futuros debates depois disso.
Algum dia, alguém terá a idéia brilante de implementar o botão responder a lista no leitor de e-mails. Isto utilizarias um dos cabeçalhos de lista customizados mencionados anteriormente para identificar o endereço da lista de e-mails, e então responde diretamente e apenas para a lista, deixando de lado todos os outros e-mails de destinatários, pois a maioria está inscrita de qualquer forma. Eventualmente, outros leitores de e-mail irão adotar a característica, e todo esta discussão irá embora. (Na verdade, o leitor de e-mail Mutt oferece esta funcionalidade.[15])
Uma outra solução ainda melhor seria a configuração para cada usuário quanto a alteração do "Responder a". Aqueles que quiserem configurar a alteração automática da lista (tanto das próprias mensagens de e-mail quanto dos demais) poderia solicitar isso, e aqueles que não quiserem a alteração, não mexem em nada. No entanto, eu não conheço um software de gerenciamento de lista que oferece isto no nível de perfil de inscritos. No momento, parece que estamos presos a uma configuração global.[16]
Os detalhes técnicos da configuração de arquivamento de listas de email são específicas do software que está gerenciando a lista, e vão além do escopo deste livro. Ao escolher ou condigurar um sistema de arquivamento, considere as seguintes qualidades:
As pessoas irão frequentemente se referir a uma mensagem arquivada enviada nas últimas uma ou duas horas. Se possível, o arquivador deve arquivar cada mensagem instantaneamente, de forma que no momento em que a mensagem aparecer na lista de e-mails, ela já estará presente nos arquivos. Se esta opção não estiver disponível, então procure ao menos configurar o arquivador para executar de hora em hora. (Por padrão, alguns arquivadores executam seu processo uma única vez a noite, mas na prática isto é um espaço muito grande de tempo para uma lista de e-mails ativa.)
Uma vez que a mensagem é arquivada em uma URL em particular, ela deve permanecer acessível na mesma URL para sempre, ou o mais próximo disso. Mesmo que os arquivos sejam reconstruídos, restaurados de backup ou fixos de alguma forma, qualquer URL que já tenha se tornado pública deve permanecer a mesma. Referências estáveis fazem com que seja possível que os motores de busca da Internet possam indexar os arquivos, o que é um grande benefício para usuários que buscam respostas. Referências estáveis também são importantes porque as mensagems e discussões da lista de e-mails são frequentemente conectadas ao Bug Tracker (veja “Bug Tracker”) adiante neste capítulo ou de outros a outros documentros do projeto.
Idealmente, o software de lista de e-mail irá incluir a URL da mensagem arquivada, ou ao menos a parte específica da URL da mensagem, em um cabeçalho quando ele distribui as mensagens para os destinatários. Desta forma as pessoas que possuem uma cópia da mensagem serão capazes de saber sua localização no arquivo sem ter que visitar os arquivos, o que é muito útil pois qualquer operação que envolve um navegador web é automaticamente demorado. Se há esta opção em algum software de lista de e-mails, eu não sei; infelizmente, o que eu utilizo não a possui. Entretanto, é algo a se procurar (ou, se você escreve um software de lista de e-mails, por favor, é uma opção a se considerar a implementação).
Deveria ser óbvio sobre como manter um backup dos arquivos, e a receita para sua restauração não deveria ser tão complicada. Em outras palavras, não trate o seu arquivo como uma caixa preta. Você (ou alguém do projeto) deve saber os as mensagens são armazenadas, e como regerar as páginas atuais do arquivo se isso alguma vez for necessário. Estes arquivos são dados preciosos—um projeto que os perdem, perde também uma boa parte de sua memória coletiva.
Deve ser possível ir de qualquer mensagem individual para a thread (grupo de mensagens relacionadas) de que a mensagem original faz parte. Cada thread deve possuir também sua própria URL, separada das URLs de mensagens individuais dentro da thread.
Um arquivo que não suporta buscas—tanto no corpo das mensagens assim como de autores e assuntos— é um arquivo quase que inútil. Note que alguns arquivadores suportam a busca simplesmente deixando o trabalho para um motor de busca externo como o Google. Isto é aceitável, mas o suporte a busca direta é geralmente mais aperfeiçoado, pois permite ao pesquisador especificar que o termo apareça no assunto ao invés do corpo, por exemplo.
O que foi descrito é apenas uma checagem técnica para ajudar você a avaliar e configurar um arquivador. Fazer com que as pessoas usem o arquivador com vantagens para o projeto é discutido mais tarde nos capítulos, em particular no “Conspicuous Use of Archives”.
Aqui estão algumas ferramentes de código aberto para realizar o gerenciamento e arquivamento da lista. Se o site onde você está hospedando o seu projeto já possui uma configuração padrão, então talvez você não poderá escolher a ferramenta. Mas se você mesmo precisa instalar, estas são algumas possibilidades. A que eu já utilizei são Mailman, Ezmlm, MHonArc, e Hypermail, mas isto não significa que as demais não são boas também (e claro que provavelmente existem outras ferramentas por aí que eu apenas não encontrei, então não considere esta uma lista completa).
Softwares de gerenciamento de listas de e-mail:
Mailman — http://www.list.org/
(Possui um arquivador embutido, e ganchos para conectar arquivadores externos.)
SmartList — http://www.procmail.org/
(Feito para ser usado com o sistema de processamento de e-mail Procmail.)
Ecartis — http://www.ecartis.org/
ListProc — http://listproc.sourceforge.net/
Ezmlm — http://cr.yp.to/ezmlm.html
(Desenhado para trabalhar com o sistema de entrega de e-mailQmail.)
Dada — http://mojo.skazat.com/
(Apesar das bizzarras tentativas do site web de esconder o fato, este é um software livre, lançado sob a GNU General Public License. Ele também possui um arquivador interno.)
Software para arquivamento de lista de e-mails:
MHonArc — http://www.mhonarc.org/
Hypermail — http://www.hypermail.org/
Procmail — http://www.procmail.org/
(Companheiro de software do SmartList, este é um sistema de processamento de e-mail genérico, que pode aparentemente, ser configurado com um arquivador.)
[15] Logo depois que este livro apareceu, Michael Bernstein me escreveu para dizer: "Existem outros clientes de e-mail que implementam a função de responder a lista além do Mytt. Por exemplo, o Evolution tem esta função como um atalho de teclado, mas não um botão (Ctrl+L)."
[16] Desde que escrevi isso, eu descobri que existe ao menos um sistema de gerenciamento de lista que oferece isto: Siesta. Veja também este artigo sobre ele: http://www.perl.com/pub/a/2004/02/05/siesta.html