X-Git-Url: https://git.jsancho.org/?p=blog.git;a=blobdiff_plain;f=posts%2F20.html;fp=posts%2F20.html;h=0000000000000000000000000000000000000000;hp=df333f571972f514d82c72acc3099dda884355c7;hb=e7b6ce04fe8fee9ae651f50b29f6c37fef87b41d;hpb=3e096e3d39e9924369271dade89f029c40c799b5 diff --git a/posts/20.html b/posts/20.html deleted file mode 100644 index df333f5..0000000 --- a/posts/20.html +++ /dev/null @@ -1,30 +0,0 @@ -title: Configurando listas de correo distribuidas con Mailman -date: 2004-05-07 16:42 ---- -
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.
-