2006/11/24, Juan Carlos Bravo Celis:

Esa es una duda que no me he puesto a investigar aun, por que no usar spamd si se usa Amavis-new...?

Yo tampoco lo sabía, creo que me lo comentó Carlos. Solía utilizar SA junto con spamd / spamc porque era la opción más sencilla para procesar los correos (Postfix llama directamente a SA), pero no es la mejor opción ya que los demonios spamd/spamc suelen fallar a menudo y los correos quedan encolados. Al instalar en los servidores el antivirus ClamAV opté por Amavisd-new para unir a los dos programas (SA y ClamAV). Ahora Postfix llama a Amavisd-new y éste al resto, luego los demonios spamd / spamc ya no hacen falta. Las descripciones de ambos, en la documentación de SA: http://spamassassin.apache.org/full/3.1.x/doc/spamd.html http://spamassassin.apache.org/full/3.1.x/doc/spamc.html Saludos, -- Camaleón --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@suse.com

Nov 23 12:12:24 puma.unam.mx http://pumas.iingen.unam.mx/ amavisd[8461]: (08461-09) SA TIMED OUT, backtrace: at /usr/lib/perl5/site_perl/5.8.3> /Mail/SpamAssassin/EvalTests.pm

Hola a todos... Por lo que leo, acabo de aprender algo interesante, si usas amavisd-new no neceistas spamd ahora todo lo veo mas claro :) Acabo de hacer una prueba en mi server, puma: # ps -fea | grep spam root 1866 1 0 10:44 ? 00:00:02 /usr/bin/perl -T -w /usr/sbin/spamd -d -D root 1867 1866 0 10:44 ? 00:00:00 spamd child root 1868 1866 0 10:44 ? 00:00:00 spamd child root 9995 8197 0 12:57 pts/8 00:00:00 grep spam puma: # /etc/init.d/spamd stop Shutting down spamd done puma: # ps -fea | grep spam root 10098 8197 0 12:58 pts/8 00:00:00 grep spam Tenia la idea que se necesitaba tener levantado spamd junto con el amavis, pro no es necesario.... acabo de matar el proceso y el servidor de correo opera de forma habitual y la bitacora del amavislog esta arrojando las calificaciones a los mensajes de forma habitual. al reiniciar amavis aparece esta linea, la cual me imagino indica que amavis utliza un modulo de spamassasin el cual es empelado de forma directa sin necesidad de spamd Nov 24 13:02:49 puma.unam.mx amavisd[10435]: Module Mail::SpamAssassin 3.001007 Pero ahora me surge una duda... Si modifico reglas de mi spamassasin como por ejemplo agragendo una nueva regla en local.cf como hacer para que esta tenga efecto en mi sistema.... tenia la idea que habia que reiniciar spamd para esto... pero por lo que veo ahora, pienso que es necesario reiniciar amavis por que de otra formo como le hacemos para que carguen la nuevas reglas ???... lo que he realizado para ver si mis reglas no tiene problemas es el ejecutar el comando "spamassassin -D --lint" con esto puedo ver el debug del spamassassin y alertame ante una mala configuración de reglas y demas... Pero bueno... ahora viene la respuesta al problema que se presento en mi server, el error era: line 980\n\teval {...} called at /usr/lib/perl5/site_perl/5.8.3/Mail/SpamAssassin/EvalTests.pm line >

980\n\tMail::SpamAssassin::PerMsgStatus::_check_whitelist ('Mail::SpamAssassin::PerMsgStatus=HASH(0x55f30220)','HASH(0x8ccb370)',' owner-risk-and-decision@JISCMAIL.AC.UK') called at /usr/lib/perl5/site_perl/5.8.3/Mail/SpamAssassin/EvalTests.pm line 1138\n\tMail::SpamAssassin::PerMsgStatus::check_from_in _blacklist('Mail::SpamAssassin::PerMsgStatus=HASH(0x55f30220)') called at /usr/lib/perl5/site_perl/5.8.3/Mail/SpamAssassin/PerMsgStatus.pm line 2638\n\teval {...} called at /usr/lib/perl5/site_perl/5.8.3 /Mail/SpamAssassin/PerMsgStatus.pm line 2637\n\tMail::SpamAssassin: :PerMsgStatus::run_eval_tests('Mail::SpamAssassin::PerMsgStat us=HASH(0x55f30220)','HASH(0xb4b1e64)','') called at /usr/lib/perl5/site_perl/5.8.3/...

Suce que hace más de una semana se agregaron reglasal spamassassin que verificaban las listas negras y las uris en aquel momento solo reiniciamos el demonio de spamd (pensando que eso era correcto) y vimos que el sistema de correo operaba de forma habitual, vimo el debug del spamassassin y no aparecieron errores... en fin que nos quedamos tranquilos y dijimos vamos a ver como trabaja... Hasta el día de ayer que se reinicio el demonio del amavisd aparecienton los problemas 1. El amavis arrojo los errores antes mencionados en el amavislog 2. El postfix por consiguiente marcaba error de conexion al localhost[ 127.0.0.1] 3. El correo se estaba encolando de forma exponencial La pista de que algo andaba mal y la cual puse atención fue que al ejecutar el "spamassassin -D --lint" este se tardaba casi un minuto es terminar el debug, pero nunca endicaba errores lo terminaba de forma exitosa.... Despues de lo anterior... concluimos que las reglas de listas negras y uris al parecer no estaban operando hasta que se reinicio el amavisd, la base de datos que generaban estas reglas era de 17 Mb dudo que fuera eso, en todo caso la forma en que operaban estas reglas ocasionaron una lentitud en el analisis de los mensajes esta operación excedia el tiempo limite del spamassasssin, razon por la cual arrojaba el mensaje de tiempo excedido. Solución: Ubicar y eliminar las reglas que fueron creadas, el sistema empezo a trabajar de forma habitual :) Nos tardamos en ubicar el problema debido a que no recordabamos que las reglas de rbls y uris fuesen la causa pues segun nosotros ya tenian casi mas de una semana operando el server sin problemas... Agradezco a todos su ayuda. Saludos On 12/24/06, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

El 2006-11-24 a las 10:02 -0500, Juan Carlos Bravo Celis escribió:

...

...

Si usas Amavisd-new no necesitas spamd.

Esa es una duda que no me he puesto a investigar aun, por que no usar spamd si se usa Amavis-new...?

Se puede hacer si quieres, pero entonces hazlo con conocimiento de causa.

- Para empezar, el amavis-new no usa el spamd/spamc. Llama al spamassassin como subprograma, librería, o como se llame eso en perl. Por tanto, arrancar el spamd no le afecta en nada, pero pierdes algunos recursos del sistema (memoria).

- Puedes, sin embargo, decirle al amavis-new que no mire el spam, que de eso ya nos encargaremos nosotros, que sólo mire los virus. En ese caso, seríamos nosotros por nuestra cuenta quienes usaríamos el spamc/spamd.

- Lo que si es un desperdicio es dejar que el amavis mire el spam, y luego encima volver a revisar el correo con spamc/spamd. Ya gasta bastante cpu la historia como para encima hacerlo doble.

- -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76

iD8DBQFFjrbgtTMYHG2NR9URAkObAJ9pAkJ6bxz8JK7VP1hioF3qhLLM0QCeLDcZ 7qJs5V4CMfoFUon949eG1Tc= =emqK -----END PGP SIGNATURE-----

-- Instituto de Ingeniería de la UNAM Coordinación de Sistemas de Cómputo Área de Sistemas Unix/Linux