Configurando listas de correo distribuidas con Mailman
Cuando empezó toda la movida del FLUG (Federación de LUGs) Bulma montó una lista de correo y un wiki para que todos pudieran expresar sus puntos de vista y presentar propuestas. En la lista participaba gente de un montón de asociaciones, ya fueran locales o virtuales, formando algo que yo considero fue un germén de lo que algún día será el FLUG.
Días después el servidor de Bulma tuvo algún problema, desconozco los detalles, y el wiki quedó temporalmente fuera de servicio. Ignoro si pasó lo mismo con la lista de correo. Fue algo más bien anecdótico, pero me hizo pensar en que los servicios de un futuro FLUG no deberían depender de un sólo servidor, sino de muchos.
Basándome en el espíritu distribuido de Planeta LUG o MetaSlug o como se llame he investigado un poco y paso a describir cómo debería de ser, bajo mi punto de vista, una lista de correo del FLUG.
En Planeta LUG cada asociación se hace responsable de su parte del proyecto. No existe un servidor centralizado, por lo que la caída de un servidor no afecta demasiado al resto del proyecto y la mayor parte de la información seguirá estando accesible. Probablemente la gente ni llegaría a darse cuenta del problema.
La idea es conseguir algo similar con las listas de correo. Por ejemplo, yo estoy suscrito a flug at aditel.org y todo lo que envío llega a los miembros de flug at aditel.org, de flug at badopi.org, etc. En el caso de que caiga el servidor de Aditel solamente los miembros de Aditel se quedarían sin servicio y los demás seguirían teniendo sus listas funcionando.
He usado Mailman para este experimento por formar parte de GNU y por ser el más usado por las asociaciones que hipoteticamente harían uso de este engendro. Desconozco como se podría montar con un gestor de listas de correo distinto.
Siguiendo con el tema del FLUG, supongamos que Bulma y Aditel se ponen de acuerdo para formar la lista de correo distribuida. Se crean dos listas de correo independientes, flug at aditel.org y flug at bulma.net. Los nombres de las listas no tienen que coincidir necesariamente pero así resulta más homogéneo. En las listas se introducen todos los miembros que sean necesarios o se dejan vacías si las subscripciones se hacen a través de la web.
Para que las listas se comuniquen entre ellas deben estar referenciadas como miembros de las otras. En este caso flug at aditel.org tendría a flug at bulma.net como miembro y viceversa. De esta forma todos los correos enviados a la lista de Aditel serán reenviados a todos los miembros de la lista incluyendo la lista de Bulma. Esto aún no funcionaría del todo pero creo que se va viendo la idea.
Tal como lo tenemos ahora la lista de Aditel intentaría enviar recordatorios de contraseña a Bulma. Para que eso no ocurra tendriamos que desactivarlo para que solamente los reciban los miembros normales y no las listas.
Para que acabe de funcionar el invento tenemos que irnos a los filtros para destinatarios de las opciones de privacidad y poner el require_explicit_destination a verdadero e indicar la dirección de la otra lista en el acceptable_aliases. De esta forma se pueden recibir los correos de la otra lista como si se tratara de la propia.
Finalmente la parte que menos me gusta del invento. Las listas de correo que forman parte de esta macro lista distribuida deben de ser abiertas, es decir, se deben permitir correos de suscritos y de no suscritos, con el consiguiente riesgo de recibir spam a saco, entrada indiscriminada de trolls, etc. Para evitar esto se pueden indicar las direcciones de los suscritos de todas las listas en los filtros de remitente, en concreto en la opción accept_these_nonmembers, pero entonces tenemos el problema de sincronizar todas las listas para que nadie se quede fuera.
Este problema se podría solucionar, por ejemplo, si se pudiera filtrar por alguno de los campos que rellena Mailman pero que yo sepa algo así no es posible.
De todas formas ahí queda la idea, por si algún día alguien esta interesado y consigue hacer una auténtica lista distribuida de correo.