Las listas de correo son el pan y la mantequilla de las comunicaciones del proyecto. Si algún usuario es expuesto a algún foro aparte de las paginas web, probablemente sea la lista de correos del proyecto. Pero antes de trabajar con las listas en si mismas, deben tomar experiencia con la interfaz—esto es, el mecanismo por el cual se pueden unir ("suscribirse a") a la lista. Esto nos brinda la regla número uno de las listas de correo:
No intentes dirigir las listas de correo a mano—consigue un software de manejo de listas.
Será tentador dejar esto de lado. Configurar un software para listas de correo puede parecer demasiado difícil al principio. Manejar listas pequeñas de bajo tráfico a mano puede parecer seductor al principio: sólo hay que montar una lista de suscripción que te reenvía todo y cuando alguien envía un mensaje, se agrega (o elimina) su dirección de correo en algún tipo de fichero de texto que almacena todas las direcciones de la lista. ¿Qué podría ser más sencillo?
El truco está en hacer un buen manejo de las listas de correo—lo cual no es lo que la gente espera— no es nada sencillo. No es solo sobre suscribir y de suscribir usuarios cuando lo solicitan. También es sobre moderar para prevenir SPAM, ofrecer la lista resumida en lugar de mensaje por mensaje, proporcionar una lista estándar e información del proyecto a través de auto respuestas y muchas otras cosas. Un ser humano monitorizando las direcciones de suscripción es solo una pequeña parte del mínimo de funcionalidad e incluso así, no es la forma más segura y puntual que un software podría ofrecer.
Un software para el manejo de listas de correo usualmente ofrece las siguientes características:
Cuando un usuario se suscribe a la lista, debería recibir una respuesta de bienvenida sin demora, explicándole como seguir interactuando con el software y (más importante) con eliminar la suscripción. Esta respuesta automática puede ser modificada para contener información específica del proyecto, por supuesto, como el sitio web, localización del FAQ, etc.
En modo resumen, el suscriptor recibe un correo conteniendo toda la actividad de la lista en ese día. Para aquellos quienes desean seguir la lista indirectamente, sin participar, el modo resumen es a menudo el preferible, porque les permite revisar todos los temas a la vez y evitar las distracciones de los correos que llegan en momentos al azar.
Moderar es revisar los mensajes para asegurar que: a) no es SPAM y b) en tema, antes de que lleguen a la lista. La moderación incluye necesariamente a seres humanos, pero el software puede hacer mucho para hacerlo más sencillo. Se discute más acerca de la moderación luego.
Entre otras cosas, le permite a un administrador eliminar direcciones obsoletas fácilmente. Esto puede hacerse urgentemente cuando la dirección del receptor empieza a enviar respuestas automáticas del tipo "Ya no tengo ésta dirección de correo" a la lista en respuesta a cada mensaje. (Algunas aplicaciones para listas de correo pueden incluso detectar esto por si mismas y eliminar la suscripción de ésta persona automáticamente.)
Muchas personas tienen sofisticados filtros y reglas de respuestas configuradas en sus clientes de correo. Las aplicaciones de listas de correo pueden añadir y manipular ciertas cabeceras estándar de las que estas personas se puedan beneficiar (más detalles a continuación).
Todos los mensajes enviados a las listas son almacenados y hechos públicos en la web. Alternativamente, algunas aplicaciones de software para listas de correo ofrecen interfaces especiales para conectar alguna herramienta externa de archivo como MHonArc (http://www.mhonarc.org/). Al igual “Sobresaliente uso de los archivos” en Capítulo 6, Comunicaciones se discute que el archivo es crucial.
El objetivo de todo esto es sencillamente enfátizar que la administración de las listas de correo es un problema complejo sobre el cual se ha pensado mucho y que está casi resuelto. Ciertamente no es necesario convertirse en un experto, pero hay que reseñar que siempre hay lugar para el aprendizaje y que la administración de las listas ocupara algo de atención de vez en cuando durante la duración del proyecto. A continuación examinaremos algunos de los problemas más comunes que podemos encontrar al configurar las listas de correo.
Entre el momento cuando ésta frase es escrita y cuando es publicada, el problema a lo largo y ancho de Internet el problema del Spam probablemente sea el doble de severo—o al menos parecerá que es así. Hubo una época, no mucho tiempo atrás, cuando se podía administrar una lista de correos sin la necesidad de tomar medidas para prevenir el Spam. Algún mensaje extraviado ocasional aparecía pero con tan poca frecuencia que solo era una molestia de bajo nivel. Esa época ya es historia. Hoy, las listas de correo que no toman medidas preventivas en contra del Spam se verá sumergida rápidamente en correo basura hasta el punto de ser inútil. Prevenir el Spam es una prioridad.
La prevención de Spam se divide en dos categorías: prevenir que mensajes basura aparezcan en la lista y prevenir que la lista sea utilizada como fuente de nuevas direcciones de correo para los spammers. La primera es la más importante, así que la examinaremos primero.
Existen tres técnicas básicas para prevenir mensajes basura y muchas aplicaciones para listas ofrecen las tres. Lo mejor es utilizarlas en tandem:
Sólo permitir automáticamente mensajes de los suscriptores a la lista.
Esto es efectivo hasta cierto punto y necesita de poca administración ya que usualmente es sólo cuestión de cambiar algunos puntos en la configuración de la aplicación de listas. Hay que apuntar que aquellos mensajes que no son aprobados automáticamente no deben ser desechados. En su lugar, deben ser moderados por dos razones. Primero, se deben permitir mensajes de quienes no están suscritos. Alguna persona con una pregunta o sugerencia no debería tener que suscribirse a la lista para enviar un solo mensaje. Segundo, incluso quienes están suscritos envían mensajes desde cuentas diferentes de la que han utilizado para suscribirse. Las direcciones de correo electrónico no son un método eficaz para identificar a las personas y no debe ser utilizado para esto.
Filtrar los mensajes utilizando un programa de filtro de spam.
Si la aplicación de listas de correo lo permite (la mayoría lo hace) se pueden filtrar los mensajes utilizando un filtro anti-spam. El filtrado automático de Spam no es perfecto, y nunca lo será, ya que existe un pulso sin fin entre los spammers y los escritores de filtros. A pesar de esto, se puede reducir enormemente la cantidad de Spam que llega a la cola de moderación y dado que mientras más larga sea ésta cola, se necesitaran más tiempo examinándola, así que cualquier filtrado automático es beneficioso.
No hay lugar suficiente para unas instrucciones detalladas sobre como configurar filtros de Spam. Habrá que consultar la documentación de la aplicación de listas de correo para esto (en “Software” más adelante en éste capítulo). Las aplicaciones para listas vienen con características para la prevención de Spam, pero quizás sería una buena idea añadir una solución de un tercero. He tenido buenas experiencias con estas dos: SpamAssassin (http://spamassassin.apache.org/) y SpamProbe (http://spamprobe.sourceforge.net/). Esto no es una crítica contra otros filtros anti spam open source que al parecer son muy buenos también. Sucede que sólo he tenido la oportunidad de utilizar estos dos y estar satisfecho con ellos.
Moderación.
Para aquellos correos que no son automáticamente aceptados por su virtud de ser enviados por un suscriptor a la lista y que pasan a través del filtro anti-spam, si es que lo hay, la ultima fase es la moderación: el correo es enrutado a una dirección especial, donde alguien lo examina y lo confirma o rechaza.
Confirmar un mensaje se puede hacer de dos formas: se puede aceptar el mensaje sólo una vez o se le puede indicar a la aplicación que acepte éste y todos los mensajes futuros de éste remitente. Casi siempre deseamos hacer lo último de manera que podamos reducir la carga futura en la moderación. Los detalles sobre como confirmar esto, varían entre sistemas pero usualmente es una cuestión de responder a una dirección en especial con el comando "aceptar" (lo que significa que sólo se aceptará éste mensaje) o "permitir" (permitir éste y todos los mensajes futuros).
Rechazar un mensaje se hace simplemente ignorando el correo de moderación. Si la aplicación nunca recibe confirmación de que algo es un mensaje valido entonces no pasará a la lista, así que con solo ignorar el correo de moderación creará el efecto deseado. En algunos casos, existe la opción de responder con los comandos "rechazar" o "denegar" para que automáticamente se desaprueben los mensajes del remitente sin siquiera pasarlos por la moderación. Raramente existe una razón para hacer esto ya que la moderación es por lo general para prevenir el spam y los spammers no suelen utilizar una misma dirección dos veces.
Hay que asegurarse de que la moderación sólo se utiliza para filtrar el spam y mensajes fuera de contexto, como cuando alguien envía un correo a la lista equivocada. El sistema de moderación por lo general ofrece una manera de responder directamente al remitente pero es mejor no utilizarlo para responder a preguntas que realmente pertenecen a la lista, incluso si se sabe la respuesta inmediatamente. De hacer esto, se privaria a la comunidad del proyecto de una visión exacta de que tipo de preguntas la gente hace y privarlos de la oportunidad de responder ellos mismos a preguntas y/o ver las respuestas de otros. La moderación de las listas debe ser estrictamente para mantenerlas libres de basura y de correos fuera de contexto, nada más.
Para prevenir que los spammers utilicen las listas de correo como una fuente de direcciones, una técnica muy común es la de ocultar las direcciones de correo de la gente en el registro, reemplazándolas como por ejemplo:
jrandom@somedomain.com
por
jrandom_AT_somedomain.com
o
jrandomNOSPAM@somedomain.com
o algo similar igual de obvio (para un humano). Ya que los recolectores de direcciones por lo general funcionan reptando por paginas web—incluyendo el archivo de nuestra lista de correo— y buscando secuencias conteniendo "@", modificar las direcciones es una forma para que sean invisibles o inútiles para los spammers. Esto no hace nada para prevenir que se envié spam desde la lista, por supuesto, pero si evita que se incremente la cantidad de spam enviado directamente a las cuentas personales de los usuarios de la lista.
Ocultar las direcciones puede ser algo controversial. A algunas personas les puede gustar mucho y se sorprenderán si el registro no lo hace automáticamente. Otras pueden pensar que es demasiado inconveniente (porque los humanos también tenemos que traducir las direcciones antes de utilizarlas). Algunas veces las personas afirman que es inefectivo, porque los recolectores en teoría pueden compensar cualquier patrón de modificación consistente. No obstante, hay que señalar que existe evidencia empírica de que ocultar las direcciones es efectivo, como se puede ver en http://www.cdt.org/speech/spam/030319spamreport.shtml.
Lo ideal sería que la aplicación administrativa de la lista diese la posibilidad de escoger a cada individuo, utilizando una cabecera si/no especial o configurándolo en las preferencias de la cuenta del suscriptor. Sin embargo, no conozco ninguna aplicación que permita hacer esto para cada suscriptor o para cada mensaje, así que por ahora el administrador de la lista debe tomar la decisión en nombre de todos (asumiendo que el archivador ofrece ésta característica, lo cual no es siempre así). Yo me inclino ligeramente hacia ocultar las direcciones. Algunas personas son muy cuidadosas para evitar enviar sus direcciones de correo electrónico en paginas web o en cualquier lugar donde un recolector de spam pueda verla, y podrían ser decepcionante que todo ese cuidado sea perdido gracias al registro de la lista de correo. Mientras tanto, la inconveniencia al ocultar las direcciones que impone en los usuarios del registro es muy pequeña, dada la trivialidad de transformar las direcciones al formato correcto si se necesita contactar con esa persona. Pero hay que seguir pensando en que, al final, sigue siendo una lucha sin fin: para cuando haya leído esto, los recolectores podrían haber evolucionado hasta el punto de reconocer la mayoría de formas comúnmente utilizadas para ocultar y tendremos que pensar en algo más.
Por lo general, los suscriptores de las listas mueven estos correos a una carpeta específica para el proyecto, separados de su otro correo personal. Sus clientes de correo hacen esto automáticamente al examinar las cabeceras de los mensajes. La cabecera son los campos que se encuentran en la parte superior de los correos, los cuales indican el remitente, destinatario, asunto, fecha e información variada sobre el mensaje. Cabeceras certeras son bien conocidas y obligatorias:
From: ... To: ... Subject: ... Date: ...
Otras son opcionales, aunque de cierta manera estándar. Por ejemplo, no es estrictamente requerido que un correo electrónico tenga la cabecera
Reply-to: sender@email.address.here
pero muchas lo tienen, porque da al destinatario una manera a prueba de errores de responder al remitente (es especialmente útil cuando el remitente ha tenido que enviar un correo desde una dirección diferente a la cual las respuestas deben ser dirigídas).
Algunos clientes de correo ofrecen una interfaz fácil de usar para rellenar correos basados en patrones en la cabecera Asunto. Esto lleva a que la gente pida que la lista de correo añada automáticamente un prefijo a todos los Asuntos, de forma que puedan configurar sus clientes para que busquen esos prefijos y archivar los correos en el directorio correcto. La idea es que el autor original escribiría:
Asunto: Trabajando en la versión 2.5
pero el correo aparecería en la lista así:
Asunto: [discuss@lists.example.org] Trabajando en la versión 2.5
Aunque la mayoría de las aplicaciones de administración de listas ofrecen la opción de hacer esto, yo recomiendo no utilizarla. El problema que resuelve puede ser resuelto de otras formas menos intrusas y los costes de utilizar espacio en el campo del Asunto son demasiado grandes. Los usuarios experimentados de las listas de correos revisan el asunto de los correos entrantes del día para decidir acerca de qué van a leer y qué van a responder. Fijar el nombre de la lista al Asunto puede mover hacia la derecha el verdadero Asunto y fuera de la pantalla, haciéndolo invisible. Esto oculta información necesaria para aquellos quienes dependen en la decisión de cuales correos van a abrir, reduciendo la funcionalidad conjunta de la lista para todos.
En lugar de sobrecargar el Asunto, hay que enseñar a los usuarios para que saquen ventajas de otras cabeceras estándar, empezando con el campo "Para", el cual debería contener el nombre de la lista de correos:
To: <discuss@lists.example.org>
Cualquier cliente de correo capaz de filtrar los mensajes basándose en el Asunto debe ser capaz de filtrar utilizando el campo Para facilmente.
Existen otras cabeceras opcionales pero estándar para las listas de correo. Filtrar utilizándolos es incluso más fiable que utilizar las cabeceras "Para" o "Cc" dado que estas cabeceras son añadidas a todos los mensajes por el programa de administración de la lista, así que algunos usuarios están contando con su presencia:
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
La mayoría se explican en si mismos. En http://www.nisto.com/listspec/list-manager-intro.html se explican mejor o en http://www.faqs.org/rfcs/rfc2369.html para una especificación formal más detallada.
Hay que señalar como estas cabeceras implican que si se tiene una lista de correos llamada "list" entonces se tienen también unas direcciones administrativas "list-help" y "list-unsubscribe". Además de estas, es normal tener "list-subscribe" para unirse y "list-owner" para contactar con el administrador de la lista. Dependiendo en la aplicación administrativa que se use, estas y/o otras direcciones administrativas varias pueden ser configuradas; la documentación debería detallar esto. A menudo una explicación completa de todas estas direcciones especiales es enviada a cada nuevo suscriptor como parte de un mensaje de bienvenida automático. Probablemente usted mismo reciba una copia de esto correo de bienvenida. Si no lo ha recibido, pida una copia a alguien, de manera que pueda saber qué están recibiendo los nuevos suscriptores. Mantenga la copia a mano de manera que pueda responder preguntas acerca del funcionamiento de la lista, o mejor aun, ponerlo en una página web en alguna parte. Así, cuando alguien pierda su copia de las instrucciones y pregunte cómo pueden eliminarse de la lista, se les facilita la URL.
Algunas aplicaciones para listas de correos ofrecen la opción de agregar al final de cada mensaje las instrucciones para eliminar la suscripción. Si ésta opción está disponible, usela. Solo causa algunas lineas extra por mensaje en un sitio inofensivo y puede ahorrar mucho tiempo al reducir el número de gente que escriba —o peor aún, que escriban a la lista—preguntando cómo eliminar la suscripción.
Antes en “Evitar discusiones privadas” hice incapie en la importancia de asegurar que las discusiones se mantengan en foros públicos y hable acerca de porque a veces tomar medidas activas es necesario para prevenir que algunas conversaciones deriven a hilos privados. Este capítulo es acerca de todo lo relacionado con preparar el software de comunicación del proyecto para que realice la mayor cantidad de trabajo posible. Así que, si la aplicación para la administración de las listas de correo ofrece una manera automática de encausar las discusiones a la lista, habría que pensar que habilitarla es la opción correcta.
Bueno, quizás no. Existe tal característica, pero tiene algunas desventajas muy importantes. Usarla o no es uno de los debates más calientes en la administración de las listas de correo—admitamoslo, no es una controversia que vaya a aparecer en las noticias, pero se puede iniciar de vez en cuando en los proyectos de software libre. A continuación, voy a describir esta característica, proponer los argumentos de cada posición y hacer la mejor recomendación que puedo.
Esta característica en si misma es muy sencilla: la aplicación para las listas puede, si lo deseamos, automáticamente establecer la cabecera Reply-To en todos los mensajes para dirigir todas las respuestas a la lista. Así que, sin importar lo que escriba el remitente en este campo (o si ni siquiera lo establecen) para cuando los suscriptores a la lista vean el mensaje, éste contendrá la dirección de la lista en la cabecera:
Reply-to: discuss@lists.example.org
Esto puede parecer algo bueno, porque virtualmente todos los clientes de correo prestan atención a esta cabecera y ahora cada vez que alguien responda a algún mensaje, su respuesta será automáticamente dirigida a la lista, no sólo a quien ha enviado el mensaje que se responde. Por supuesto que el remitente puede manualmente modificar esto, pero lo importante es que por defecto las respuestas son enviadas a la lista. Este es un ejemplo perfecto de como utilizar la tecnología para animar la colaboración.
Desafortunadamente, existen algunas desventajas. La primera es conocida como el problema No puedo llegar a casa: a veces, el remitente original establece su dirección de correo real en el campo Reply-To porque por alguna razón u otra envían correos utilizando una dirección diferente a la que utilizan para recibirlos. Las personas que envían y reciben correos desde el mismo sitio no tienen éste problema y quizás se sorprendan de que siquiera existe. Pero para quienes utilizan configuraciones de correo inusuales o quienes no pueden controlar como se forma el campo From de su dirección de correo electrónico (quizás porque envían correos desde sus trabajos y no tienen ninguna influencia sobre el departamento de sistemas) el utilizar el campo Reply-To quizás sea la única manera que tienen para asegurarse de que las respuestas a sus mensajes les llegan (encuentran el camino a casa). Así que si la aplicación de las listas sobre escribe esto, esta persona puede que nunca vea las respuestas a sus mensajes.
La segunda desventaja se refiere a las expectativas y en mi opinión, el argumento más fuerte en contra del cambio del Reply-To. La mayoría de los usuarios experimentados de correo electrónico están acostumbrados a dos métodos básicos de responder: Responder a todos y Responder al remitente. Todos los clientes de correo tienen botones separados para estas dos acciones. Sus usuarios saben que para responder a todos los incluidos en la lista, deben escoger, responder a todos y que para responder sólo al remitente en privado, deben seleccionar Responder al remitente. Aunque se desee animar a que la gente responda a la lista siempre que sea posible, existen ciertas circunstancias cuando un mensaje privado al remitente es prerrogativo—por ejemplo, desean compartir información confidencial, algo que sería inapropiado para una lista pública.
Ahora consideremos lo que sucede cuando la lista sobre escribe la cabecera Reply-To original del remitente. Quien responde pulsa la opción de Responder al remitente, con la esperanza de enviar un mensaje privado al autor original. Porque esta es la conducta esperada y quizás esta persona no se moleste en examinar cuidadosamente la dirección del destinatario en el nuevo mensaje. Redacta su correo privado, un mensaje confidencial, uno que puede diga algo embarazoso acerca de alguien de la lista y pulsa el botón de enviar. Inesperadamente el mensaje llega a la lista unos minutos después. Cierto, en teoría debería haber revisado cuidadosamente el destinatario y no debería haber asumido nada acerca del campo Reply-To. Pero por lo general este campo se compone con su dirección de correo personal (o en su lugar, los clientes de correo lo hacen) y muchos usuarios asiduos del correo electrónico dan esto por seguro. De hecho, cuando alguien determina deliberadamente el campo Reply-To a alguna otra dirección, como la de la lista, usualmente señalan esto en el contenido del mensaje, de forma que quienes respondan no se sorprendan de lo que sucede cuando lo hacen.
Dada la posibilidad de consecuencias muy severas de esta conducta inesperada, mi preferencia es la de configurar la aplicación de la lista para que nunca toque la cabecera Reply-To. Este caso de cuando se utiliza la tecnología para animar la colaboración tiene, a mi parecer, efectos colaterales potencialmente peligrosos. Por otro lado, existen argumentos concretos del otro lado de este debate. Sea lo que sea que se escoja, puede que en ocasiones algunas personas pregunten por qué no se ha escogido el otro camino. Dado que esto no es algo que se quiere sea el principal tema de discusión en la lista, puede ser conveniente tener una respuesta preparada del tipo que sea más propensa a poner fin a la discusión en lugar de animarla. Hay que asegurarse de no insistir en que esta decisión, sea cual sea, es obviamente la única correcta (incluso cuando se crea que esto es así). En cambio, hay que señalar que este es un viejo debate, que existen buenos argumentos de cada lado, que ninguna decisión iba a satisfacer a todos los usuarios y que por esto se ha tomado la mejor decisión que se podía. Amablemente se pide que el tema no vuelva a surgir a menos que alguien tenga algo realmente nuevo que decir, entonces hay que mantenerse alejado y esperar a que muera por causas naturales.
Alguien podría sugerir una votación. Se puede permitir esto si se quiere, pero personalmente no creo que contar manos sea una solución satisfactoria en este caso. El castigo para alguien que se vea sorprendido por este comportamiento es demasiado (accidentalmente enviar un correo privado a la lista publica) y las molestias para todos los demás es pequeña (ocasionalmente recordarle a alguien que deben responder a la lista) por esto no está claro de que la mayoría, aunque sean la mayoría, deban poner a una minoría bajo ese riesgo.
No he llegado a tocar todos los aspectos acerca de este tema, sólo los que me han parecido de especial importancia. Para una discusión completa, se pueden leer los siguientes documentos, los cuales son siempre citados cuando se entra en el debate:
Leave Reply-to alone, por Chip Rosenthal
Set Reply-to to list, por Simon Hill
A pesar de las benignas preferencias indicadas anteriormente, no creo que exista una única respuestas correcta y he participado felizmente de muchas listas que cambiabanel Reply-To. Lo mejor que se puede hacer, es centrarse en alguna de las dos vías desde el principio e intentar no verse enredado en debates sobre esto despues.
Algún día, alguien tendrá la brillante idea de implementar una opción Responder a la lista en su cliente de correo. Podría utilizar alguna de las cabeceras para listas mencionadas antes para descubrir la dirección de la lista de correos y luego direccionar las respuestas directamente a la lista, ignorando cualquier otro destinatario, ya que probablemente muchos estén suscritos a la lista de todas formas. Eventualmente, otros clientes implementarán esta característica y todo el debate desaparecerá. (De hecho, el cliente de correos Mutt ofrece esta opción.[13])
Una mejor solución sería que el tratamiento del campo Reply-To fuese una opción por suscriptor. Quienes deseen que la lista modifique sus cabeceras Reply-To (ya sea en sus mensajes o en los de otros) podría solicitarlo, y quienes no lo desean, se les deja tranquilos. Aunque no conozco ninguna aplicación para listas de correo que permita esto para cada suscriptor. Así que por ahora, parece que estamos atados a una configuración global.[14]
Los detalles técnicos para configurar un archivo para la lista de correos son específicos de la aplicación utilizada y están fuera del alcance de este libro. Al escoger o configurar un archivador, es conveniente considerar lo siguiente:
A menudo la gente querrá ser referida a un mensaje enviado durante la ultima hora o dos. Si es posible, el archivador deberá archivar cada mensaje instantáneamente, de tal manera de que cuando el mensaje aparezca en la lista de correos, ya esté en el archivo. Si esa opción no esta disponible entonces al menos hay que intentar configurar el archivado para que se realice cada hora o así. (Por defecto, algunos archivadores ejecutan el proceso de actualización cada noche, pero en la práctica esta demora es demasiado larga para una lista de correos.
Una vez que un mensaje es archivado bajo una URL en particular, debe ser accesible desde esa URL para siempre. Incluso si el archivo es reconstruido o restaurado de un respaldo, cualquier URL que haya sido hecha publica debe permanecer igual. Las referencias estables hacen posible que los buscadores de Internet sean capaces de indexar el archivo, lo cual es una gran ventaja para los usuarios que buscan respuestas. Las referencias estables son también importantes porque los mensajes de la lista y los hilos son enlazados desde el gestor de fallos ( “Seguimiento de errores”) más adelante en este capítulo o en la documentación de otros proyectos.
Lo ideal sería que la aplicación de la lista de correos incluya la URL del mensaje archivado o al menos la porción de la URL específica del mensaje en una cabecera cuando este es distribuido. De esta manera la gente que haya recibido el mensaje podrá conocer su lugar en el archivo sin la necesidad de visitar el archivo, lo cual es de gran ayuda, ya que cualquier actividad que implique el uso del navegador web es automáticamente un consumo de tiempo. Que alguna aplicación de listas de correos ofrece esta posibilidad no lo sé. Desafortunadamente, los que he utilizado no la tienen. Pero esto es algo que hay que buscar (o si desarrolla una aplicación de listas, esta es una característica que debe considerar implementar, por favor).
Debe ser obvio como respaldar el archivo y la receta para restaurarlo no deben ser muy complicada. En otras palabras, no hay que tratar el archivo como una caja negra. Debe conocer donde se almacenan los mensajes y como restaurar las páginas del archivo del almacén si alguna vez es necesario. Estos archivos contienen datos muy preciados—un proyecto que los pierde, pierde buena parte de su memoria colectiva.
Desde cualquier mensaje debe ser posible ir al hilo (grupo de mensajes relacionados) al que pertenece el mensaje. Cada hilo debe tener su propia URL también, separado del URL de los mensajes del hilo.
Un archivo que no permita búsquedas—tanto en el cuerpo de los mensajes como por autor o según el asunto—es casi inútil. Hay que señalar que algunos archivadores permiten búsquedas al remitir la labor a un buscador externo como Google. Esto es aceptable, pero por lo general, las búsquedas directas son más finas, porque permiten a quien busca, especificar que los resultados sean mostrados, por ejemplo, según el asunto y no según el cuerpo del mensaje.
Lo anterior es sólo una lista técnica para ayudar a evaluar y configurar un archivador. Hacer que la gente de hecho utilice el archivo como ventaja para el proyecto es discutido en capítulos posteriores en particular en “Sobresaliente uso de los archivos”.
Aquí hay algunas herramientas open source para la gestión de las listas de correo y su archivo. Si el hosting del proyecto ya tiene una configuración por defecto, quizás no sea necesario siquiera decidir cual herramienta utilizar. Pero si se tiene que instalar una, existen algunas posibilidades. Las que he utilizado son Mailman, Ezmlm, MHonArc e Hypermail, lo cual no significa que no haya otras que sean igual de buenas (y por supuesto, probablemente existan otras que no he logrado encontrar, así que no considere esto como una lista completa).
Aplicaciones de gestión de listas de correo:
Mailman — http://www.list.org/
(Tiene un archivador incorporado y la posibilidad de conectarse a archivadores externos.)
SmartList — http://www.procmail.org/
(Para ser utilizado con el sistema de procesamiento de correos Procmail.)
Ecartis — http://www.ecartis.org/
ListProc — http://listproc.sourceforge.net/
Ezmlm — http://cr.yp.to/ezmlm.html
(Diseñado para funcionar conQmail .)
Dada — http://mojo.skazat.com/
(A pesar del bizarro intento de su sitio web, es un software libre, liberado bajo la licencia GNU GPL. También tiene un archivador incluido.)
Software para el archivo de las listas de correo:
MHonArc — http://www.mhonarc.org/
Hypermail — http://www.hypermail.org/
Procmail — http://www.procmail.org/
(Software que acompaña a SmartList, un sistema de procesado general de correos que puede, aparentemente, ser configurado como un archivo.)
[13] Poco después de que este libro apareciera, Michael Bernstein me escribió para comentarme lo siguiente: "Existen otros clientes de correos que implementan una función de responder a la lista a parte de Mutt. Por ejemplo, Evolution tiene una combinación de teclas, pero no un botón (Ctrl+L)."
[14] Desde que escribí esto, he aprendido que existe al menos un sistema de gestión de listas que ofrece esta característica: Siesta. Hay un artículo sobre este en http://www.perl.com/pub/a/2004/02/05/siesta.html