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