Manejo de listas con SmartList
------------------------------
Copyright (c) 1993-1996, Stephen R. van den Berg, Holanda.
NOTA: Ejecute "flist -v" para saber más sobre la versión de SmartList que
tenga instalada.
Contenido:
---------
1. Creación y borrado de listas de correo o servidores de ficheros.
2. Mantenimiento remoto de listas de correo.
3. Personalización.
3a.Proceso de gacetas.
3b.Restrición de suscripciones.
3c.Restricción de envíos.
3d.Autosuscripción en el primer envío.
3e.Envío automático de ficheros a los nuevos suscriptores.
3f.Listas moderadas.
3g.Listas de listas.
3h.Discriminación positiva de algunos daemons.
3i.Respuestas de ayuda por omisión.
3j.Asistencia en la des-suscripción
3k.Expansión de otras listas (de tipo no SmartList).
3l.Cómo hacer pública la lista de suscriptores.
3m.Visión esquemática de lo que ocurre en el interior.
4. El servidor de ficheros.
4a.Envío de ficheros al servidor.
4b.Restricción de acceso al servidor de ficheros.
5. El formato del fichero dist.
6. Multigram y la tolerancia (`thresholds') en rc.init/rc.custom.
7. Choplist y sendmail.
8. Direcciones de FTP y la lista de correo SmartList.
1. Creación y borrado de listas de correo o servidores de ficheros
---------------------------------------------------------------
Asegúrese de que el directorio .bin está en el PATH. Ahora se pueden
ejecutar órdenes tales como:
createlist pruebas
createlist pruebas curro@dondesea.es
createlist -a pruebas curro@dondesea.es
removelist pruebas
La primera orden crea una lista de correo con dos direcciones útiles:
pruebas
pruebas-request
La segunda orden hace lo mismo, pero también especifica a
curro@dondesea.es como la persona de contacto resposable para esta lista.
La tercera orden hace lo mismo, excepto que en lugar de crear una lista de
correo, crea un servidor de ficheros.
La cuarta orden elimina todo vestigio de la lista de correo "pruebas".
Hay otras cuatro utilidades que se pueden utilizar:
led Un intermediario para el editor, debe utilizarse en lugar
de llamar al editor directamente cuando se vaya a editar
un fichero manejado por SmartList. Automáticamente se
encarga del bloqueo adecuado y realiza comprobaciones
de los atributos.
delink
Desenlaza un fichero de aquél o aquellos a quienes
esté enlazado (sin borrarlo).
showlink
Muestra qué grupos de ficheros están enlazados.
donatelist
Pone una lista bajo el control completo y exclusivo
del mantenedor (un usuario local). Véase más abajo.
Si usted tiene varias listas mantenidas por administradores distintos, se
puede dar a un administrador el completo control sobre su lista sin
necesidad de tener los derechos del usuario o grupo list. Para que esto
funcione, simplemente hay que ejecutar "donatelist el_administrador
su_lista" y esto [?] cambia el propietario del árbol completo que contiene
la lista a él o ella. Asegúrese de que el GID de todos los ficheros
necesarios del árbol son todavía escribibles por el grupo "list", porque
ese es el privilegio de acceso bajo el que la lista está funcionando.
El mantenedor debe tener cuidado de usar una umask de 007 al editar
ficheros en su directorio de lista. Esto permite funcionar a los programas
de la lista de correo al mismo tiempo que el acceso a los ficheros de las
listas de correo se limita a *una* sola persona (el mantenedor).
Nota: La persona a la que se dona una lista puede obtener acceso a la
cuenta de SmartList, si pone suficiente empeño. Para obtener
varias listas seguras, instale SmartList varias veces.
2. Mantenimiento remoto de listas de correo
----------------------------------------
Para facilitar el mantenimiento remoto de algunas listas de correo por sus
mantenedores, he creado el script .bin/x_command. Este script analiza los
mensajes que se envían a la dirección -request y puede ejecutar algunas
órdenes administrativas.
El mensaje debe enviarse a la dirección -request de una lista de correo
y debe contener un campo en la cabecera con un aspecto como este:
X-Command: curro@dondesea.es contraseña orden
"orden" puede ser cualquiera de las siguientes:
subscribe direccióndecorreo
unsubscribe direccióndecorreo
checkdist direccióndecorreo Para ver las coincidencias
multigram de direccióndecorreo
con la lista (muestra las ocho
mejores coincidencias).
showdist Para mostrar el fichero dist.
showlog Para mostrar el log
wipelog Para borrar el log.
help Muestra este resumen de órdenes.
info Eso.
(OJO)
El nombre exacto del campo es por omisión "X-Command", pero se puede
personalizar a lo que uno quiera.
La contraseña por omisión es "password", pero se puede/debe cambiar.
El "curro@dondesea.es" es siempre la dirección de correo del
mantenedor. Debe coincidir con la que se especificó en la línea de
la orden de "createlist" cuando se creó la lista.
El campo X-Command: debe ser parte de la cabecera, cuando está en el
cuerpo del mensaje, no tiene ningún efecto.
Siempre que un mensaje con X-Command: ha sido procesado, el resultado
se devuelve al mantenedor de la lista, y el campo X-Command:
se renombra a X-Processed:.
Aunque esta facilidad remota es cómoda, algunos pueden decir que
presenta un agujero de seguridad. Bien, para hacer este agujero
de seguridad lo más pequeño posible, se puede mantener la contraseña
secreta. Asimismo, la dirección exacta del mantenedor podría no ser
publicamente conocida. Se puede cambiar simplemente el campo
X-Command por algo distinto como X-MyCommand. Pero sobre todo, dado que
falsificar un mensaje es una posibilidad bien conocida sería ridículo
tomar más precauciones que estas. Además, si alguien en efecto se las
arregla para enviar un X-Command: falso, no pasaría inadvertido, porque
el mantenedor (y sólo el mantenedor) recibirá siempre el mensaje
X-Processed.
Para su comodidad, se puede encontrar un script de muestra "doxcommand"
en el directorio examples. Se puede utilizar para generar fácilmente estos
mensajes X-Command. Recuerde proteger de lectura este script una vez que
la contraseña se haya cambiado.
3. Personalización
---------------
Las listas de correo se pueden personalizar de diversas formas:
- Para todas las listas:
- Dado que todas las listas inicialmente comparten los mismos
ficheros help.txt, subscribe.txt, unsubscribe.txt, rc.init,
rc.submit and rc.request (enlazados), cualquier cambio afectará a
todas las listas.
- Dado que todas las listas tienen el directorio .bin en el
PATH, cualquier cambio a cualquiera de los shell scripts
que hay ahí afectará a todas las listas.
- Por cada lista:
- Cada lista contiene un fichero de inicialización "rc.custom"
que se puede editar a voluntad para personalizar ciertos
parámetros para esta lista únicamente.
- Se pueden conseguir pequeñas personalizaciones locales
descomentando una o más de las asignaciones RC_LOCAL_* que hay
en rc.custom. Entonces hay que crear el fichero rc.local*
apropiado en el que se pueden poner las órdenes que se quieran
(por ejemplo añadir una "signature" general a cada mensaje
saliente).
- Para una personalización más avanzada, se puede eliminar el
enlace duro (utilizando .bin/delink, por ejemplo) de cualquiera
de los ficheros en un directorio de lista y proporcionar a esa
lista con su propia copia para editarla al gusto de cada cual.
- Como el directorio actual está en el PATH antes que el
directorio .bin, se pueden crear copias específicas para cada
lista de cualquiera de los shell scripts que hay en .bin, que
pueden entonces cambiarse sin afectar a otras listas.
- Por grupos de listas:
- Lo mismo se aplica cuando se personalizan listas, pero entonces
hay que enlazar los ficheros apropiados entre los directorios
de las listas del grupo.
Por omisión los scripts crean y utilizan enlaces duros en diversos sitios.
Usted es completamente libre de cambiar algunos o todos por enlaces
simbólicos (o sustituir "ln" por "ln -s" en algunos scripts).
Algunos editores tienen la costumbre de mover el fichero que estamos
editando a un fichero de respaldo y escribir una nueva copia en su lugar.
Esto puede ocasionar problemas si el editor no está al tanto de los
enlaces simbólicos o fuertes que haya. Asegúrese de que el editor tiene
constancia del enlace y lo conserva, incluso después de que el fichero ha
sido editado (por ejemplo usando emacs: pruebe a poner la variable
backup-by-copying-when-linked con el valor true).
Usando el script "led" en lugar de llamar al editor directamente
seremos advertidos a tiempo de cualquier cosa que el editor haga mal.
Si no está utilizando la facilidad de mantenimiento remoto y comienza a
editar o personalizar scripts o ficheros a mano, entonces debe asegurarse
de que no llega ningún mensaje a estas listas que esté afectado por los
cambios. La mejor manera de hacer esto es utilizando la orden "led"
siempre que vayamos a editar un fichero gobernado por SmartList. Led se
encargará de todos los bloqueos necesarios para cualquier fichero, led se
puede utilizar también para editar ficheros que no sean de SmartList.
Si no utiliza "led" pero quiere que los mensajes de llegada esperen
temporalmente, entonces se puede hacer esto:
- para todas las listas creando el fichero: .etc/rc.lock
- solamente para una lista creando el fichero: rc.lock
en el directorio de la lista correspondiente.
La orden .bin/flist comprueba si existen estos ficheros rc.lock y no son
más antiguos que 17 minutos antes de entregar el mensaje. Así que, si se
crea un fichero rc.lock, los mensajes que se envían a esas (o a todas)
listas se quedan esperando [?] durante 17 minutos. Si necesita más tiempo,
toque el fichero (touch) con frecuencia. Se deben borrar los ficheros
rc.lock otra vez después de terminar la edición.
Si usted quiere cambiar el alias -dist (que se utiliza para distribuir los
mensajes a los suscriptores) por algo menos desconocido, adelante, pero
recuerde cambiar la asignación correspondiente a listdist. Para hacer la
gracia completa, uno debería también corregir los scripts createlist y
removelist en tal caso. Si estamos utilizando cophdist para expandir el
fichero dist, entonces ni siquiera nos hace falta un alias -dist.
3a.Proceso de gacetas
------------------
Se puede configurar una lista para que envíe gacetas de los mensajes
acumulados. Para ello, simplemente descomente la asignación apropiada a
digest_flag en rc.init (si quiere que todas las listas sean gacetas) o en
rc.custom (si sólo desea que esta lista esté en forma de gaceta). Las
gacetas se envían con una frecuencia que depende del tamaño y
antigüedad de los mensajes acumulados.
Las condiciones para enviar una gaceta se comprueban durante la llegada de
cada nuevo mensaje. Sin embargo, si el tráfico en la lista es a veces
demasiado bajo (p.ej. menos frecuente que la antigüedad máxima de una
gaceta) entonces una gaceta puede estar en espera más tiempo que el
periodo máximo especificado (3 días por omisión).
Para asegurarse de que la gaceta se envía de todas formas, se debe
ejecutar el programa .bin/cronlist de vez en cuando. El procedimiento
recomendado es crear un trabajo de cron (en la cuenta de la lista)
que contenga algo como la siguiente línea:
0 6 * * * /var/list/.bin/cronlist
El script cronlist se puede personalizar según el gusto (tal vez necesite
ajustar la variable PATH).
Ojo: Llame a cronlist con un path absoluto o relativo, no confíe en el
PATH para que lo encuentre por usted (cronlist utiliza $0 para encontrar
el lugar de las listas de las que es responsable).
Por omisión, cronlist ejecuta el programa flush_digets.
Usando la entrada de crontab antes mencionada, nos aseguraremos de que a
las seis de la mañana se enviarán todas las gacetas pendientes.
flush_digets normalmente comprueba la antigüedad de la gaceta y no la
envía hasta que ha llegado el momento. Si usted quiere obligar a
flush_digest a que envíe una gaceta de una lista particular, se puede
crear el fichero ".digest.force" en el directorio de la lista. Durante la
próxima ejecución de flush_digests, se borrará el fichero .digest.force y
enviará la gaceta independientemente de su antigüedad.
Si usted crea un fichero llamado digest.admin bien en el directorio
principal de la lista en forma de gaceta o en el directorio archive/latest
que le pertenece, será cogido [?] por el próximo flush_digest e incluido
al principio de la gaceta real con el encabezamiento "Administrivia".
El fichero archive/latest/digest.admin se borrará automáticamente después
de que la gaceta se lo haya comido.
El fichero digest.admin en el directorio principal de la lista en forma de
gaceta no será borrado y se incluirá en todas las gacetas.
Si quiere dar a sus suscriptores la elección de recibir gacetas o no, esto
es lo que se puede hacer:
Cree dos listas. Por ejemplo, si la lista se llamara "lalista",
entonces tendremos la lista `auténtica' llamada "lalista" (creada
y utilizada como una lista normal) y la lista en forma de gaceta
llamada "lalista-d".
En el fichero dist de lalista se debe incluir lalista-d como
uno de los suscriptores. En el fichero rc.custom de lalista-d
se debe editar la asignación de undigested_list para que quede
así: "undigested_list = lalista@$domain".
Después de haber hecho esto, ya está. La gente que quiera gacetas
se suscribirá simplemente a lalista-d, y la gente que no, a
lalista.
3b.Restricciones de suscripción
----------------------------
Hay tres formas en que se puede restringir quién puede suscribirse a
una lista:
- Se puede poner la dirección de suscriptores no deseados en la así
llamada lista de rechazo (el fichero `reject').
- Se puede ejecutar un programa (p.ej. un shell script) llamado
"subscreen". Debe ser ejecutable y recibirá la dirección de correo del
posible suscriptor como primer argumento. Si la suscripción para esa
dirección está permitida, el programa debe volver con código de salida
cero (no error). Si la suscripción está vedada, simplemente vuelve con
código de salida uno (error). Hay un programa de ejemplo en el
directorio "examples".
- Se puede desactivar por completo la suscripción automática
descomentando la línea "auto_subscribe" apropiada en rc.custom.
- Se puede desactivar completamente la des-suscripción automática
descomentando la línea "auto_unsubscribe" apropiada en rc.custom.
3c.Restricción de envíos
---------------------
Se puede restringir el envío de mensajes a la gente que esté en la lista
de aceptación (el fichero `accept'). Los mensajes que provengan de
cualquier otra persona serán redirigidos al mantenedor de la lista en
lugar de ser enviados. Para activar esto hay que descomentar la línea
foreign_submit apropiada en rc.custom. Por omisión el fichero accept es un
enlace duro al fichero dist (es decir, si el envío está restringido,
solamente los suscriptores podrán hacerlo). Si usted quiere permitir
solamente a un grupo más reducido, deshaga el enlace y edítelo a su gusto.
Si usted quiere tener tanto un fichero accept dinámico como uno estático,
cree un nuevo fichero accept2, se buscará en él además de en el fichero
accept normal.
Tenga en cuenta que el uso de un fichero accept es incompatible con
tener un alias owner- para esta lista (las listas administradas por
procmail no necesitan el alias owner- en cualquier caso).
Si, además de notificar al mantenedor usted quiere que se genere una
respuesta automática a la persona que envió el mensaje pero que no está en
el fichero accept, esto se puede conseguir simplemente creando un fichero
accept.txt. Su contenido será devuelto (como el contenido del fichero
help.txt) a la persona que envió el mensaje.
Esta característica no es la misma que una lista moderada, las dos
características se pueden utilizar acumulativamente.
3d.Auto-suscripción en el primer envío
-----------------------------------
En lugar de rechazar los mensajes de las personas que no estén en la
lista accept (dist), se puede activar "force_subscribe". Esto causará
que las personas que envíen mensajes a la lista se autosuscriban a la lista
si no estaban en el fichero dist.
3e.Envío automático de ficheros a los nuevos suscriptores
------------------------------------------------------
Se puede crear un fichero llamado "subscribe.files". Puede contener
cualquier número de órdenes para el servidor de ficheros. Los resultados
(es decir, los ficheros solicitados), serán enviados al nuevo suscriptor.
3f.Listas moderadas
----------------
Primero cree un fichero llamado "moderators", debe contener la dirección
de correo completa de todos los moderadores para esta lista (es decir,
solamente nombres de usuario local no son suficientes, hay que incluir
@loquesea). Luego descomente la línea "moderated_flag" apropiada en
rc.custom.
Desde ese momento, todos los mensajes que no contengan un campo
"Approved: dirección_de_uno_de_los_moderadores" será reenviado a todos
los moderadores.
Uno de los moderadores debe entonces reenviar el mensaje a la lista
después de añadir un campo "Approved: su_propia_dirección" a la cabecera
(y posiblemente editando el contenido del mensaje). No hay problema si
varios moderadores reenvían el mismo mensaje al mismo tiempo, dado que la
listas de correo filtra los duplicados en cualquier caso (o sea, solamente
la primera saldrá y será archivada).
*--------------------------------------------------------------------------
Nota importante: Este mecanismo acaba de cambiar en SmartList-3.11pre5.
Ahora hay una contraseña para la moderación, y es la contraseña lo que
debe aparecer en la línea Approved. Estoy pendiente de que el autor
corrija el manual para corregir yo la traducción adecuadamente.
*--------------------------------------------------------------------------
3g.Lista de listas
---------------
Si quiere usted que la gente sea capaz de obtener una visión panorámica
[?] de qué listas son públicamente disponibles en su máquina, puede
decirles a los mantenedores de listas que creen un fichero info.txt en el
directorio de la lista. Este fichero info.txt debe contener una
descripción corta del propósito y tema principal de esta lista particular.
Se puede entonces poner una orden tal y como el gatherinfo del
directorio examples en el crontab para recoger todos estos ficheros
info.txt una vez al día.
Los ficheros info.txt recogidos se pueden situar en un directorio que sea
accesible por un servidor de ftp, gopher o web, o bien, se puede poner en
el directorio `archive' de un servidor de ficheros manejado por procmail
(por ejemplo, bajo el alias "metalista").
3h.Discriminación Positiva de algunos daemons
------------------------------------------
SmartList normalmente no acepta mensajes o suscripciones de daemons.
Si usted quiere hacer una excepción para alguno de ellos, se puede hacer
afinando la variable daemon_bias. Se puede encontrar una sencilla
plantilla en el fichero rc.init. Esta variable se puede por supuesto
establecer en rc.init, rc.custom o en los ficheros rc.local. En lugar de
especificar directamente un peso y una expreg, se puede especificar
solamente un peso. Entonces hay que asegurarse de que la variable se
activa solamente cuando llega un mensaje de nuestros daemons
particulares.
3i.Textos de ayuda de respuesta por omisión
----------------------------------------
Descomentando la línea "auto_help" apropiada en el fichero rc.custom, la
lista responderá a cualquier mensaje de petición indescifrable como si se
hubiera solicitado ayuda. Los mensajes que pasarán a través del mantenedor
serán aquellos que:
- parezcan provenir de un daemon.
- parezcan una respuesta ("Subject: Re: ").
Dependiendo de las personas [?] que tengamos en la lista, activar esto
podría no ser una buena idea.
3j.Ayuda a la des-suscripción
--------------------------
Descomentando la línea "unsub_assist" apropiada en el fichero rc.custom
se puede activar la asistencia a la des-suscripción. Si alguien está
intentando borrarse de la lista, pero su dirección no se encuentra,
le será devuelto un número de coincidencias multigram (determinadas
por el valor de unsub_assist) entre su mensaje de des-suscripción y el
fichero dist.
Para activar esta opción, por favor tenga presente lo siguiente:
- De esta forma, la gente puede obtener fragmentos del fichero dist.
- Individuos maliciosos se podrían animar a borrar montones de personas
de la lista. Esto no pasará inadvertido, por supuesto.
Será registrado y los suscriptores inocentes recibirán una copia
de la petición de des-suscripción que no enviaron. Cuando menos,
puede causar una molestia considerable.
3k.Expansión de otras listas (no SmartList)
----------------------------------------
Una lista SmartList puede ser utilizada fácilmente para que funcione como
distribuidora local de una lista más grande. Las ventajas sobre usar un
alias normal son tres:
- Las suscripciones/borrados se manejan automáticamente.
- Los mensajes de rebote van a la lista del distribuidor local (en lugar
de a la lista más grande, que no está interesada realmente en sus
problemas de correo con algunos alias locales).
- Las peticiones administrativas erróneas se pueden filtrar y eliminar del
canal habitual a través del que se envían los mensajes.
Si la lista más grande que está distribuyendo localmente es una lista
SmartList también, entonces no hay ninguna precaución especial que tomar
en absoluto. Si la lista más grande no está gestionada por SmartList, las
peticiones administrativas serán interceptadas y manejadas por la lista
local; si este "manejo" resulta ser un problema se puede desactivar
descomentando la variable "pass_diverts" apropiada en rc.custom
(esto causará que las peticiones administrativas mal dirigidas serán
interceptadas, pero serán pasadas al mantenedor tal cual).
3l.Cómo hacer pública la lista de suscriptores
-------------------------------------------
Si usted quiere que cualquiera pueda obtener una lista de los suscriptores
actuales a una lista, simplemente cree un enlace del fichero dist a
archive/subscribers. Esto hace posible que cualquiera envíe una petición
al servidor de ficheros pidiendo el fichero "subscribers".
3m.Visión esquemática de lo que ocurre en el interior
--------------------------------------------------
Supongamos que tenemos dos entradas en el fichero aliases, una para
lalista@dominio.es y otra para lalista-request@dominio.es.
Cuando llega un mensaje a cualquiera de estas direcciones, ocurre lo
siguiente:
- Se llama suid root a flist con lalista como su argumento.
- cambia su directorio actual al del directorio principal de las
listas (internamente fijo).
- cambia su uid y gid al de la cuenta `list' (internamente fijo).
- cambia el directorio actual al de lalista.
- espera hasta que tanto ../.etc/rc.lock como rc.lock se hayan
ido o sean suficientemente antiguos (17 minutos).
Entonces, si era un mensaje normal a lalista@dominio.es:
- flist ejecuta procmail con fichero de configuración rc.submit.
- toma los valores que hay en rc.init.
- toma los valores que hay en rc.custom que prevaleven
sobre algunos por omisión (si hay).
- comprueba el formato del mensaje
- si es necesario, comprueba:
- la lista accept
- la lista de moderadores (Approved:)
- comprueba el caché de msgid para envíos duplicados
- si hace falta realiza el proceso de gacetas (y para)
- archiva el mensaje
- modifica la cabecera del mensaje al gusto
- le dice a sendmail que envíe el mensaje a
lalista-dist@dominio.es
- Si el mensaje era una petición administrativa, no va a la lista,
en su lugar, procmail sigue rc.request.
Pero, si era un mensaje administrativo para lalista-request@dominio.es
- flist ejecuta procmail con rc.request como fichero de configuración.
- lee rc.init que establece los valores por omisión
- lee rc.custom que sustituye alguno de estos valores
- realiza las acciones necesarias, dependiendo del contenido
- si el contenido era indescifrable, pasa al mantenedor
de la lista
Si hay algún fallo del sistema grave durante todo esto, el script rc.post
lo recogerá y se asegurará de que el mensaje quedará aparcado [?] en algún
lugar o será reenviado al mantenedor, lo que funcione. Esto es para
asegurarse de que no se pierde ningún mensaje.
4. El servidor de ficheros
-----------------------
Todos los mensajes (excepto los que se envían desde otra lista de correo)
que se envían a cualquiera de las listas queda archivado de forma muy
simple. Por ejemplo, si tenemos una lista llamada "naranjas", entonces
todos los mensajes son archivados en naranjas/archive/latest. Los mensajes
serán almacenados cada uno en un fichero. Los ficheros estarán numerados.
Ahora, normalmente, tan sólo los dos últimos mensajes serán conservados,
los otros se borran periódicamente. Eso es para mantener en un nivel bajo
el costo del archivo para gente con especio en disco limitado. Para
cambiar el tamaño del "archivo histórico" edite el fichero rc.custom.
Para obtener un archivado más sofisticado, tal y como agrupación mensual
de los mensajes, se debe crear un trabajo de cron o editar el fichero
.bin/arch_trunc.
Se puede acceder al servidor de ficheros de cada lista enviando un mensaje
a la dirección -request con el siguiente Subject:
Subject: archive
El cuerpo del mensaje o el resto de la línea de Subject puede ser entonces
rellenada con peticiones al servidor de ficheros. Básicamente entiende
cinco órdenes:
get fichero ...
ls directorio ...
egrep expresión_regular fichero ...
maxfiles nnn
help
[La expresión regular no distingue mayúsculas de minúsculas]
El servidor de ficheros hace una comprobación minuciosa de las órdenes y
los ficheros que son solicitados. Esto es para asegurarse de que no se
accede a ningún fichero fuera del directorio naranjas/archive. Cualquier
fichero de texto que se ponga en el directorio naranjas/archive (o en
cualquiera de sus subdirectorios) puede ser recuperado mediante las
órdenes del archivo.
Si un fichero solicitado a través del servidor comienza con una cabecera
que comienza [?] con `Content-Type:' entonces el fichero se envía tal y
como es, sin encapsulado. Esto permite preparar los ficheros en formatos
especiales que estén soportados directamente por el agente de usuario del
receptor. El Content-Type: inicial y cualquier campo que le siga se
convertirá en parte de la cabecera.
El resto de ficheros se encapsula con MIME antes de la transmisión. Se
debe echar un vistazo al directorio /var/list/.bin/mimencap.local si
queremos extender o personalizar los tipos de ficheros reconocidos.
El encapsulado MIME es automático y depende de la disponibilidad del
paquete metamail en el PATH definido en rc.init. Los programas de este
paquete que deben estar disponibles son: mimencode y splitmail.
Si mimencode no se encuentra en el PATH, los ficheros serán enviados con
un intermedio estándar alrededor. [?]
Se puede cambiar de codificación MIME a uuencode aplicando el
correspondiente parche uuencode.dir del directorio examples.
Si se ponen enlaces en el árbol "scuba/dive" se puede permitir al
servidor de ficheros que obtenga ficheros procedentes de otras partes del
sistema de ficheros.
El servidor de ficheros completo se puede encontrar en el script
.bin/arch_retrieve. El servidor de ficheros se puede extender con órdenes
arbitrarias a través del script retrieve.local del directorio examples que
viene con la distribución.
4a.Envío de ficheros al servidor de ficheros
-----------------------------------------
El servidor de ficheros tal y como se instala con SmartList no soporta
directamente la recepción y almacenaje de ficheros. Lo que se puede hacer
es mirar el script putfile del directorio examples. Le proporciona todo lo
que necesitaría para recibir y almacenar ficheros.
4b.Restricción de acceso al servidor de ficheros
---------------------------------------------
Se puede restringir el acceso a la gente en las listas `accept'
(los ficheros accept y accept2). Los mensajes de cualquier otra persona
serán pasados al mantenedor en lugar de al servidor de ficheros. Para
activar esto hay que descomentar la línea "restrict_archive"
apropiada en rc.custom.
5. El formato del fichero dist
---------------------------
Esto no es necesario saberlo, a menos que quiera editar el fichero dist a
mano o quiera incorporar una lista de direcciones que ya exista.
Para distribuir los mensajes que llegan, se le da el fichero dist a
sendmail con el alias :include:. Así que el formato de este fichero debe
estar de acuerdo con lo que sendmail esperaría. Además de esto, este
fichero es examinado y editado por multigram para encontrar suscriptores
particulares. El formato que multigram espera es un poco más rígido que lo
que sendmail admite.
Deben cumplirse las siguientes condiciones:
- Un suscriptor por línea.
- Se permiten líneas vacías.
- La dirección de correo del suscriptor debe ser la primera palabra de
la línea.
- Puede haber comentarios después de la dirección (pero separados de
la dirección por al menos un carácter de espacio en blanco).
- Todo lo que preceda a la línea que contenga:
(Only addresses below this line can be automatically removed)
está a salvo de ser escrito por cambios por multigram (es
decir, estas direcciones nunca pueden ser borradas
automáticamente/accidentalmnente).
- Si la línea:
(Only addresses below this line can be automatically removed)
no está presente en absoluto, entonces las dessuscripciones automáticas
a esta listas son imposibles.
- Cuando multigram borra automáticamente una dirección de la lista,
reescribe el fichero dist `in situ'. Esto quiere decir que el fichero
dist será contraído [?] en ese punto. He decidido escribir in
situ para evitar copiar el fichero dist cada vez que
cambia (un verdadero ahorro si la lista crece mucho).
- Multigram siempre añade nuevos suscriptores en la línea que sigue
inmediatamente a la última entrada rellena del fichero dist.
Algunas entradas de muestra (el formato preferido):
curro@dondesea.es
curro@dondesea.es (algún comentario)
curro@dondesea.es (algún comentario) (algunos comentarios más)
Obsoleto, pero permitido:
algún comentario
(algún comentario)
No permitido por multigram (aunque a sendmail no le importa):
(algún comentario) curro@dondesea
algún comentario
6. Multigram y la tolerancia en rc.init/rc.custom
----------------------------------------------
Los scripts rc.init y rc.custom definen algunos valores de tolerancia:
match_threshold, off_threshold, reject_threshold, submit_threshold.
Esto valores se proporcionan a multigram como valores tope con los que se
decide si una determinada dirección de correo está en la lista.
Cuanto más alta es la tolerancia, mejor debe ser la coincidencia. Las
tolerancias tienen una escala de -16383 a 32766. Esto quiere decir que,
por ejemplo una tolerancia de 30730 se puede utilizar para encontrar
solamente direcciones de correo que está casi exactamente igual en la
lista. Un valor de 24476 por otro lado permite ciertos errores (tales como
direcciones de correo alteradas por pasarelas, etc.) al encontrar
coincidencias con la lista.
Los valores 30730 y 24476 son valores algo arbitrarios que parecen
funcionar bien para nuestros problemas particulares
Para hacerse una idea de los valores que multigram calcula, se puede hacer
la siguiente prueba:
Cree un fichero con el mismo formato que el fichero dist,
rellénelo con cualquier cantidad de direcciones que le parezca
(por ejemplo, se puede tomar un fichero dist que ya exista).
Ahora haga una copia de este fichero `dist' y altere algunas
de las direcciones un poquito (tal y como omitir un carácter,
o añadir alguna información sobre pasarelas, intercambiar dos
palabras, cambiarla por una dirección uucp, etc.).
Ahora llamamos a multigram con la siguiente línea:
multigram -l-16000 -b300 pseudo_ficherodist < ficherodist_alterado
Multigram mostrará hasta las 300 mejores coincidencias que encuentre
después de hacer las referencias cruzadas entre pseudo_ficherodist
y ficherodist_alterado.
El resultado producido por multigram se puede [disect?] como sigue:
númerodelínea. nombre1 bondad nombre2
Númerodelínea y nombre1 se refieren al número de línea del fichero
pseudo_ficherodist que contiene la dirección de correo nombre1.
Bondad es la medida que corresponde a los valores de tolerancia
mencionados, y nombre2 es la dirección de correo coincidente del
ficherodist_alterado (que usualmente es el mensaje entrante).
Una vez que se le coge el tranquillo, se puede jugar un poco
con las entradas del ficherodist_alterado reduciéndolo cada vez
más para ver lo que nultigram hace con él (intente insertar
también algunas direcciones que no existan).
7. Choplist y sendmail
-------------------
Existen dos formas de distribuir el mensaje a las direcciones que aparecen
en el fichero dist: O bien directamente a través de sendmail y la
expansión de alias :include:, o indirectamente, a través de choplist, que
realiza la expansión por sí solo y llama a sendmail en trozos apropiados.
Por omisión, choplist se encarga de la expansión, descomente la variable
de entorno alt_sendmail apropiada en rc.init para volver a la expansión
estándar con sendmail.
Choplist intenta asegurarse de que incluso para listas grandes, la
expansión de alias se realiza tan swiftly como sea posible y varios
sendmails estarán entregando el mensaje a los suscriptores al mismo
tiempo. Los diversos límites que se pueden imponer en este proceso se
pueden afinar en el fichero rc.init.
La mayoría de los sendmails hacen un peor trabajo si choplist no hace de
preprocesador.
Un efecto secundario de usar choplist como preprocesador es que ya no hay
necesidad de un alias -dist.
8. Direcciones de FTP y la lista SmartList
---------------------------------------
Se puede conseguir una versión reciente en varios archivos de
comp.sources.misc. La última versión se puede obtener directamente
del servidor de ftp que hay en:
ftp.informatik.rwth-aachen.de
como fichero tar comprimido con gzip: /pub/packages/procmail/SmartList.tar.gz
como fichero tar comprimido: /pub/packages/procmail/SmartList.tar.Z
Existe una lista de correo específica para los usuarios de SmartList,
envíe las peticiones de suscripción a:
SmartList-request@informatik.rwth-aachen.de
Para preguntas relacionadas con procmail que no sea específicas del
paquete SmartList se puede también escribir a la lista de correo sobre
procmail, envíe la petición de suscripción a:
procmail-request@informatik.rwth-aachen.de
*--------------------------------------------------------------------------
Notas:
* Este documento ha sido traducido por Santiago Vila
* Última modificación: 9-4-1997
* Cuando hay una interrogación entre corchetes [?] se trata de una duda
de traducción. Se entiende que cuando el documento esté en su estado
definitivo, no debe quedar ninguna interrogación de estas.
*--------------------------------------------------------------------------
