Y ¿"ande" están esos directorios? Porque con Cyrus como servidor POP3/IMAP sólo veo un directorio que está en /var/lib/imap/user/u/usuario pero en este directorio sólo hay dos ficheros: usuario.seen y usuario.sub. Luego está un fichero que se llama mailboxes.db en el directorio raiz de imap ¿?

En /var/spool/imap/"nombreusuario" Los va almacenando como 1. 2. 3. 4. ... Un saludo.

El 2004-06-06 a las 15:35 +0200, Camaleón escribió:

Ahí están. Sólo una cosa más, al ejecutar:

# sal-learn --showdots --dir --spam /var/spool/imap/usuario1/spam/*

Me dice: Learned from 0 messages.

No te has leido el manual: --dir Ignored; historical compatability Prueba con "/var/spool/imap/usuario1/spam" sin el asterisco ni la barra. Si así no traga, es que no entiende los ficheros. -- Saludos Carlos Robinson

El 2004-06-06 a las 12:30 +0200, Camaleón escribió:

...

sa-learn --ham --showdots --dir directorio_con_mail_no_spam

Es decir, que el cliente no lo puede entrenar. :( Entonces ¿tengo que leer los correos de los usuarios para poder entrenarlo?

No conocía esa forma que has usado de llamar al spamassassin que comentas, es interesante. No obstante... a ver como lo explico. La filosofía del spamassassin, con filtrado bayesiano, es que el procesado se hace por cada usuario, con ficheros "de aprendizaje" en el directorio del usuario. La idea es que lo que un usuario considera spam, otro puede que no lo considere, y viceversa. Creo recordar incluso haber leido que cuando se llama al spamassassin de forma global, como has hecho, el filtrado bayesiano se desactiva. En cualquier caso, esos ficheros de entrenamiento irán a parar al directorio del usuario que llame al spamassassin, que en tu caso, no se si es el root o "nobody". Los ficheros se llamarán $HOME/.spamassassin/bayes_* Claro, eso en tu caso, con Cyrus, eso es muy inconveniente. Hay algo que debieras leer en la documentación del spamassassin, el fichero "sql/README": Using SpamAssassin With An SQL Database --------------------------------------- SpamAssassin can now load users' score files from an SQL database. The concept here is to have a web application (PHP/perl/ASP/etc.) that will allow users to be able to update their local preferences on how SpamAssassin will filter their e-mail. The most common use for a system like this would be for users to be able to update the white list of addresses (whitelist_from) without the need for them to update their $HOME/.spamassassin/user_prefs file. It is also quite common for users listed in /etc/passwd to not have a home directory, therefore, the only way to have their own local settings would be through an RDBMS system. Así mismo, en la web del spamassassin debiera haber más cosas sobre uso del spamassassin en un servidor de correo con filtrado bayesiano - porque lo de arriba es para guardar las preferencias de los usuarios, excepto precisamente los ficheros bayes_* -- Saludos Carlos Robinson

El 2004-06-07 a las 09:29 +0200, Camaleón escribió:

...

No conocía esa forma que has usado de llamar al spamassassin que comentas, es interesante. No obstante... a ver como lo explico.

¿A qué forma te refieres? :-?

Pues la que dijieste que usas, la del: spamassassin unix - n n - - pipeuser=nobody argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}

...

La filosofía del spamassassin, con filtrado bayesiano, es que el procesado se hace por cada usuario, con ficheros "de aprendizaje" en el directorio del usuario. La idea es que lo que un usuario considera spam, otro puede que no lo considere, y viceversa. Creo recordar incluso haber leido que cuando se llama al spamassassin de forma global, como has hecho, el filtrado bayesiano se desactiva. En cualquier caso, esos ficheros de entrenamiento irán a parar al directorio del usuario que llame al spamassassin, que en tu caso, no se si es el root o "nobody". Los ficheros se llamarán $HOME/.spamassassin/bayes_*

Bueno, el escenario sería el siguiente. SuSE se descarga con Fetchmail los correos de varias cuentas de varios usuarios, SA les pone la marca y los pasa a Cyrus, que los almacena.

Si, eso me imaginaba más o menos.

El "problema" es que los usuarios utilizan como cliente de correo Outlook 2000, y las cuentas son del tipo POP3, pues al IMAP no se acostumbran, no les gusta su funcionamiento (son usuarios locales, la mayor parte).

Ya les vale. ¡Pero si el IMAP es una maravilla! Es hasta parecido a la cosa esa del "exchange server", en el sentido de que puedes acceder a tus correos desde cualquier maquina de la red, con tus carpetitas y todo. Será posible... si no tienen más que donde pone pop3 cambiar a imap y listo, sanseacabó, transparente todo.

Si quiero entrenar al SA tengo que crear cuentas IMAP para los usuarios y llevar a cabo el entrenamiento, pues ellos no lo van a hacer (no lo quieren hacer). :( Una vez afinado el filtro, se podrían bajar el correo vía POP3 con la marca del SA ya ajustada. No se me ocurre otra idea y es lo que actualmente estoy haciendo, autilizando una configuración global y una cuenta de correo creada para llevar a cabo el entrenamiento.

El problema es que el spamassassin guarda los ficheros resultado del entrenamiendo en el directorio $HOME/.spamassassin/ del usuario que llame al spamassassin. Es decir, al llamar al spamassassin globalmente, desde el postfix, ese entrenamiento será global para todo el sistema, lo cual te obligaría a revisar los correos de los usuarios para ver que es spam y que no: y eso podría ser hasta ilegal. Por tanto, ese entrenamiento lo debe hacer cada usario, por dos motivos: 1) Cada usuario tiene su propia definición de lo que considera SPAM. 2) Únicamente cada usuario está autorizado a leer su propio correo, y marcar algo como spam o como no spam. Problema: no tengo ni idea de como hacer una configuración global del spamassassin para que haga filtrado bayesiano, con ficheros de datos propios de cada usuario. La solución sería pasarle como parámetro al spamassassin, de alguna forma, el directorio donde deba guardar las bases de datos bayesianas cada vez que se le pasa un correo para filtrar. Y no existe esa posibilidad: spamc - client for spamd ... -u username This argument has been semi-obsoleted. To have spamd use per-user-config files, run spamc as the user whose config files spamd should load. If you're running spamc as some other user, though, (eg. root, mail, nobody, cyrus, etc.) then you can still use this flag. Observa que eso exige que el usuario exista localmente - que no es el caso. Quizás llamando a "spamassassin" directamente - lo cual es bastante más lento: -C path, --configpath=path, --config-file=path Path to standard configuration dir Claro, el demonio "spamd" también tiene un ajuste equivalente: -C path, --configpath=path Path for default config files Mmmmm... creo que podría ser factible... o si alguien modifica el spamc... ¡Contro! Oberva: -V, --virtual-config=dir Enable Virtual configs (needs -x) --virtual-config-dir=dir Enable pattern based Virtual configs (needs -x) -x, --nouser-config Disable user config files "Virtual configs" suena interesante... sigo leyendo... ¡BINGO! (lo siguiente es con Mail-SpamAssassin-2.63) --virtual-config-dir=pattern This option specifies where per-user preferences can be found for virtual users, for the -x switch. If this and the --virtual-config switch are both used, this will take precedence. The pattern is used as a base pattern for the directory name. Any of the following escapes can be used: %u -- replaced with the full name of the current user, as sent by spamc. %l -- replaced with the 'local part' of the current username. In other words, if the username is an email address, this is the part before the "@" sign. %d -- replaced with the 'domain' of the current username. In other words, if the username is an email address, this is the part after the "@" sign. So for example, if "/vhome/users/%u/spamassassin" is specified, and spamc sends a virtual username of "jm@example.com", the directory "/vhome/users/jm@exam­ ple.com/spamassassin" will be used. The set of characters allowed in the virtual username for this path are restricted to: A-Z a-z 0-9 - + _ . , @ = All others will be replaced by underscores ("_"). -> This path must be a writable directory. It will be created if -> it does not already exist. If a file called user_prefs exists -> in this directory, it will be loaded as the user's preferences. -> The auto-whitelist and/or Bayes databases for that user will be -> stored in this directory. Note that this requires that -x is used, and cannot be combinedwith SQL-based configuration. The pattern must expand to an absolute directory when spamd is running daemo­ nized (-d). -V=directory, --virtual-config=directory This option specifies where per-user preferences can be found for virtual users, for the -x switch. The files are in the format of username.prefs. A default.prefs file will be used if an individual user config is not found. The set of characters allowed in the virtual username for this path are restricted to: A-Z a-z 0-9 - + _ . , @ = All others will be replaced by underscores ("_"). Note that this requires that -x is used, and cannot be combined with SQL-based configuration. -> If a subdirectory is found in that directory, called username, -> and it is writable, it will be used to store auto-whitelist -> and/or Bayes databases for that user. -x, --nouser-config, --user-config Turn off(on) per-user config files. All users will just get the default con­ figuration. The default behaviour is for per-user configuration to be off. A ver, hipótesis. Prueba lo siguiente: En "/etc/sysconfig/spamd" tendrás probablemente: SPAMD_OPTS="-d -c" Pues pon: SPAMD_OPTS="-d -c -x --virtual-config-dir=/vhome/%l/spamassassin" (no estoy seguro de las comillas) (cambia %l por %u si tienes varios dominios) Y crea el directorio /vhome con permisos de escritura para el usuario que ejecute smpamd - en el mio es root. U otro directorio que se te ocurra, claro. Prueba eso y me cuentas, ardo de curiosidad por saber si funciona O:-) Ah, y si no quieren entrenarlo tus usuarios, que les den (morcillas, que están muy buenas, por cierto): tu no eres quien para leerte SUS correos :-P Vamos, que es su problema, no el tuyo. Allá ellos si quieren recibir spam.

...

Claro, eso en tu caso, con Cyrus, eso es muy inconveniente.

Sí, por eso me ha costado tanto instalarlo: pensaba que con Cyrus (al utilizar una base de usuarios propia) no se iba a llevar muy bien.

...

Hay algo que debieras leer en la documentación del spamassassin, el fichero "sql/README":

Using SpamAssassin With An SQL Database --------------------------------------- It is also quite common for users listed in /etc/passwd to not have a home directory, therefore, the only way to have their own local settings would be through an RDBMS system.

O sea, que recomiendan utilizar una base de datos relacional para los usuarios que no tienen cuenta local y poder así personalizar sus preferencias. Pero hay una pega (creo), y es que los usuarios no están en tampoco en /etc/passwd sino en sasl2.

Es para usuarios que no tienen cuenta local, o sea, que no están en el '/etc/passwd'. Pero no te puedo explicar como se haría: simplemente he leido ese "readme", y me ha llamado la atención.

...

Así mismo, en la web del spamassassin debiera haber más cosas sobre uso del spamassassin en un servidor de correo con filtrado bayesiano - porque lo de arriba es para guardar las preferencias de los usuarios, excepto precisamente los ficheros bayes_*

Vaya... :)

Sasto. Pero también es importante, porque si un usuario se queja de que no le llegan ciertos correos que quiere ver y que se marcan como spam, pues es precisamente ahí donde tiene que incluir sus propias entradas white/black list. -- Saludos Carlos Robinson

El 2004-06-07 a las 17:04 +0200, Camaleón escribió:

...

Pues la que dijieste que usas, la del:

spamassassin unix - n n - - pipeuser=nobody argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}

Bueno, eso es lo que pone en la documentación de SA.

Ya, ya, pero que no la conocía, y me gusta. Mejor que otros artificios que he visto, usando puertos e historias raras. Me parece bastante elegante. Tendré que volver a mirar la documentación. Ah, mira, lo he visto en otro sitio: www.postfix.org/FILTER_README.html Je, por cierto, mira lo que dice: * Create a dedicated local user account called "filter". This user handles all potentially dangerous mail content - that is why it should be a separate account. Do not use "nobody", and most certainly do not use "root" or "postfix". Así que la linea de antes debes cambiar lo de "nobody" por un usuario dedicado.

...

Ya les vale. ¡Pero si el IMAP es una maravilla! Es hasta parecido a la cosa esa del "exchange server", en el sentido de que puedes acceder a tus correos desde cualquier maquina de la red, con tus carpetitas y todo. Será posible... si no tienen más que donde pone pop3 cambiar a imap y listo, sanseacabó, transparente todo.

No creas. La máquina donde tengo a SuSE no es muy potente que digamos (Pentium III a 1 GHz. con 512 MB. de SD-RAM) y no mueve muy rápido los correos en las carpetas IMAP (le cuesta un poco) y la gente es muy "tiquismiquis" para esas cosas.

Bueno, claro, imap consume más recursos. O puede hacerlo.

...

postfix, ese entrenamiento será global para todo el sistema, lo cual te obligaría a revisar los correos de los usuarios para ver que es spam y que no: y eso podría ser hasta ilegal.

El entrenamiento lo estoy llevando a cabo (ya solucioné el problemilla) con correos enviados a mí, todavía no lo he puesto a funcionar para los demás. Primero quiero asegurarme al máximo de no tener falsos positivos.

Bueno, es una solución intermedia. Pero no te irá muy fino: el spam que recibe cada usuario dependerá de en que ambientes sea conocido su email por los spammers.

...

Prueba eso y me cuentas, ardo de curiosidad por saber si funciona O:-)

Te agradezco de veras la disertación que has hecho del SA, ¡menuda disección! :)

Me gusta investigar O:-)

Pero me instalé la versión 2.5 y luego SuSE me la actualizó a la 2.55. Como siempre estáis comentado que hay que instalar de los CD de SuSE (en este caso FTP)... Pues me bajé lo que SuSE me dio, por lo que no funcionaría lo de los "usuarios virtuales" (vhome).

No me acordaba de lo anticuado que puede estar el SA de SuSE. Si, el que yo tengo me lo traje de los fuentes y lo preparé. Se nota cuando lo haces, el spam que ha estado colandose por los resquicios cada vez un poquito más, de repente baja un montón al actualizar. Este paquete SuSE debiera hacer una excepción y actualizarlo, porque es un paquete de seguridad, al fin y al cabo.

...

Ah, y si no quieren entrenarlo tus usuarios, que les den (morcillas, que están muy buenas, por cierto): tu no eres quien para leerte SUS correos :-P

Vamos, que es su problema, no el tuyo. Allá ellos si quieren recibir spam.

Uhmm. Sí ya lo he pensado... más de una vez. Pero bueno, algo hay que hacer, y ya se sabe lo que le cuesta a la gente acostumbrarse a las cosas nuevas.

Ya; bueno, tu les pones el spamassassin, que por si mismo, filtra bastante. Y les dejas el bayesiano activado y preparado. Cuando protesten porque se les cuelan unos cuantos, pues se lo dices: "tienes que entrenar tu filtro; y yo no lo puedo hacer por tí, porque es ilegal que yo mire tu correo para decidir que es spam y que no". La cuestión es encontrar una manera "chorras", de pinchar con el ratón. A mi se me ocurre una, pero como no uso cyrus no tengo manera de examinarlo. La idea es que con imap puedes definir directorios remotos, y puedes mover correos de un directorio a otro con el ratón en el mozilla o en el outlook. Luego una tarea cron detecta que hay correo en esos directorios, y pasa el sa-learn. Necesitarían dos carpetas: una para ham y otra para spam no reconocido. -- Saludos Carlos Robinson

El 2004-06-08 a las 09:26 +0200, Camaleón escribió:

Carlos E. R. wrote:

...

www.postfix.org/FILTER_README.html

Je, por cierto, mira lo que dice:

* Create a dedicated local user account called "filter". This user handles all potentially dangerous mail content - that is why it should be a separate account. Do not use "nobody", and most certainly do not use "root" or "postfix".

Así que la linea de antes debes cambiar lo de "nobody" por un usuario dedicado.

Pero yo no estoy utilizando el servicio "spawn" ni utilizando el puerto 10025... No lo entiendo. :(

Pues precisamente que como tu no usas el puerto 10025, tu manera me parece más elegante :-p No he leido toda la documentación con atención, así que me puedo equivocar en algo.

...

No me acordaba de lo anticuado que puede estar el SA de SuSE. Si, el que yo tengo me lo traje de los fuentes y lo preparé. Se nota cuando lo haces, el spam que ha estado colandose por los resquicios cada vez un poquito más, de repente baja un montón al actualizar. Este paquete SuSE debiera hacer una excepción y actualizarlo, porque es un paquete de seguridad, al fin y al cabo.

Pues creo que me adelanté. En el man de spamd está lo que comentas (lo del --virtual_config_dir y --virtual_config), lo miraré a fondo este fin de semana y te cuento.

Anda, mejor.

...

La cuestión es encontrar una manera "chorras", de pinchar con el ratón. A mi se me ocurre una, pero como no uso cyrus no tengo manera de examinarlo. La idea es que con imap puedes definir directorios remotos, y puedes mover correos de un directorio a otro con el ratón en el mozilla o en el outlook. Luego una tarea cron detecta que hay correo en esos directorios, y pasa el sa-learn.

Necesitarían dos carpetas: una para ham y otra para spam no reconocido.

Este tema ya lo he decidido. A la primera queja, IMAP al canto y se acabó. Además, no hay otra solución, el IMAP permite tener directorios y es el único medio en este caso.

Si es que es lo mejor para intranets, da el mejor servicio.

Por cierto, me he dado cuenta de que el servicio spamd me aparece como "failed" al inicio del equipo. Pero una vez dentro, el vigilante del sistema me dice que está iniciado. ¿Puede deberse a que precisa que se inicie Postfix antes que él?

Tengo observado que a veces algunos servicios dicen fallar durante el arranque; o lo que es lo mismo, el inicio devuelve un retorno no nulo, no "0". Yo lo que sospecho es que da timeout antes de que el servicio termine de iniciarse, o que el iniciador arranca en background y cuando retorna todavía no ha terminado de arrancar. A mi me pasaba estos dias (hoy no) con sshd - el spamd no lo puedo mirar porque lo modifiqué. La manera general en la que los scripts de SuSE arrancan a los demonios es: startproc -f -p $SSHD_PIDFILE /usr/sbin/sshd $SSHD_OPTS \ -o "PidFile=$SSHD_PIDFILE" # Remember status and be verbose rc_status -v rc_status es una función (definida en '/etc/rc.status') que entre otras cosas pinta lo de "running", "failed", etc - ahí se podría españolizar si se quisiera. startproc (Start processes identified by path name) es un programa de SuSE, aunque ya pertenece a la LSB (Linux Standard Base) que se usa para arrancar demonios, con algunas comprobaciones: startproc and the LSB variant start_daemon check for all processes of the specified executable and starts it if no processes are found. Note that startproc is designed to start a daemon but not a kernel thread or a program which enables a kernel thread. Y devuelve algunos códigos de retorno: The exit codes have the following LSB conform conditions: 0 Success 1 Generic or unspecified error 2 Invalid or excess argument(s) 4 Insufficient privilege(s) 5 Program is not installed 7 Program is not running El script que se encarga de arrancar los diferentes servicios de cada nivel de ejecución es "/etc/init.d/rc". Dentro de un bucle for los va arrancando todos, y al terminar hace un listado de los que han fallado: echo -n "Master Resource Control: " echo -e "runlevel ${RUNLEVEL} has been ${stat}${extd}reached${norm}" if test -n "$failed" ; then n=$((${#failed} + 7)) echo -n "Failed services in runlevel ${RUNLEVEL}: " test $n -lt 47 && echo -en "\033[${COLUMNS}C\033[${n}D" echo -e "${warn}${failed}${norm}" fi ${warn} y ${norm} son simplemente los atributos de color. Bueno, pues en vez de eso, mi idea es que tendría que ejecutar de nuevo esos servicios "fallados" con "servicio status" para que cada uno informe de si realmente está ejecutándose o no. Así que, si hay voluntarios para modificar ese script, pues adelante ;-)

El servicio spamd lo he puesto en los niveles de ejecución 3 y 5. En /etc/init.d/ tengo en rc3.dy en rc5.d K08spamd (tipo de archivo desconocido) y S13spamd (también desconocido).

:-?

Son enlaces simbólicos a los ficheros reales: cer@nimrodel:~> file /etc/init.d/rc3.d/S13spamd /etc/init.d/rc3.d/S13spamd: symbolic link to ../spamd No se te ocurra crear esos enlaces simbólicos a mano, usa "chkconfig" - el yast los borra si no son los que él cree que deben ser. Mira en "man init.d" para una explicación de como funciona, y el capítulo "The SuSE boot concept" en el manual de administración de SuSE - está traducido al español. -- Saludos Carlos Robinson

José Rodríguez S. wrote:

Entonces se supone que debos guardar los mail spam para entrenar al SA, no?

Pues en teoría sí. En una carpeta (en mi caso IMAP porque no tengo usuarios creados en el sistema) donde se vayan acumulando los correos que decidas tratar como spam.

Es que leo las cabeceras de los mensajes spam y ninguno tiene la cabecera de spam status.

Se ve que no está pasando por el SA el correo pero he hecho todo lo que dice el tutorial de apache al respecto y se ve que hay algo mal.

Pues no se me ocurre nada más. Verifica que se esté ejecutando smapd, y bueno ¿puede ser que el firewall esté interfiriendo? Si lo utilizas con Procmail, deberías seguir los pasos de esta guía. Es posible que te haga falta algún script: http://wiki.apache.org/spamassassin/UsingProcmail Saludos, -- Camaleón