-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-07-10 a las 13:23 +0200, Camaleón escribió:

El 10/07/06, Antonio> escribió:

...

El caso es que me gustaria activar las directivas ok_locales y ok_languages(detectan idioma del email), ya que todavia me entra bastante spam, a pesar de tener activos los filtros bayesianos (tal vez

¿Como consigues que el SA usado a través del amavis use filtros bayesianos? Porque eso, por defecto, y al menos en SuSE, no lo hace. O no como se supone que debe ser. No es tan obvio.

...

no haya aprendido de suficiente spam/ham...) y como todos o casi todos los mensajes de spam son en ingles o ruso, creo que activando esas dos directivas me funcionaria bastante mejor.

Revisa dos cosas:

- Que al tener Amavis junto con SA éste busque el fichero de configuración de SA en otro directorio del habitual (por ejemplo, dentro de /etc/amavis/*)

- Que SA esté en ejecución (en SuSE ejecuta rcspamd status)

No, el sa llamado por el amavis no usa el spamd, lo llama como subrutina o como rayos se haga en perl. Hay por ahí en la documentación una parrafada complejilla que dice que configuración usa para cada cosa en ese caso. No cuento como lo hace porque ahora mismo no lo recuerdo. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEstxatTMYHG2NR9URArKfAKCDhqpCuWsSvM/QTg5gZgNk+zw0BACgieJX OV5axH+/roW4RdMjfzDrRNk= =XfWL -----END PGP SIGNATURE----- -- Para dar de baja la suscripci�n, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com

Josep M. Queralt escribió:

El 10/07/2006 13:15:50 Antonio escribió:

toni_olmos> toni_olmos> En /etc/spamassassin/local.cf, tengo: toni_olmos> toni_olmos> ok_languages es toni_olmos> ok_locales es

Has probado con poner "sp" sin las comillas ?

Acabo de ponerlo, pero no creo que funcione....porque estoy casi seguro que el problema es que ese archivo de configuracion no lo usa el SpamAssassin en mi servidor. Camaleón escribió:

El 11/07/06, Carlos E. R. escribió:

...

¿Como consigues que el SA usado a través del amavis use filtros bayesianos? Porque eso, por defecto, y al menos en SuSE, no lo hace. O no como se supone que debe ser.

Supongo que utilizará el filtro bayesiano de forma global para todos los usuarios, eso no creo que de problemas. Exacto. Para las necesidades de mi empresa, asi esta perfecto.

...

No, el sa llamado por el amavis no usa el spamd, lo llama como subrutina o como rayos se haga en perl.

Hum. Entonces, si spamd no está en ejecución, ¿puede Amavis conectar con SA? ¿Cómo se inician las instancias de SA para que vaya más suelto, lo hace cada vez que lo llama Amavis? Es como dice Carlos. Amavis llama a SA una vez por mensaje, a traves del modulo de perl Mail::SpamAssassin. Respecto al rendimiento, te copio exactamente lo que lei en un manual:

"Amavisd-new se beneficia del uso del modulo de Perl Net::Server, el cuál ofrece un rapido entorno multihilo". Gracias a todos. Saludos. -- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com

Camaleón escribió:

Revisa dos cosas:

- Que al tener Amavis junto con SA éste busque el fichero de configuración de SA en otro directorio del habitual (por ejemplo, dentro de /etc/amavis/*) Me ha costado averiguarlo, pero creo que lo he conseguido... con la instruccion "amavisd-new debug-sa" he sacado esto:

[20503] dbg: generic: SpamAssassin version 3.1.0 [20503] dbg: config: score set 0 chosen. [20503] dbg: util: running in taint mode? yes [20503] dbg: util: taint mode: deleting unsafe environment variables, resetting PATH [20503] dbg: util: PATH included '/usr/local/sbin', keeping [20503] dbg: util: PATH included '/usr/local/bin', keeping [20503] dbg: util: PATH included '/usr/sbin', keeping [20503] dbg: util: PATH included '/sbin', keeping [20503] dbg: util: PATH included '/usr/bin', keeping [20503] dbg: util: PATH included '/bin', keeping [20503] dbg: util: final PATH set to: /usr/local/sbin:/usr/local/bin:/usr/sbin:/ sbin:/usr/bin:/bin [20503] dbg: dns: is Net::DNS::Resolver available? no [20503] dbg: ignore: test message to precompile patterns and load modules [20503] dbg: config: using "/etc/mail/spamassassin" for site rules pre files [20503] dbg: config: read file /etc/mail/spamassassin/init.pre [20503] dbg: config: read file /etc/mail/spamassassin/v310.pre [20503] dbg: config: using "/usr/share/spamassassin" for sys rules pre files [20503] dbg: config: using "/usr/share/spamassassin" for default rules dir [20503] dbg: config: read file /usr/share/spamassassin/10_misc.cf [20503] dbg: config: read file /usr/share/spamassassin/20_advance_fee.cf [20503] dbg: config: read file /usr/share/spamassassin/20_anti_ratware.cf [20503] dbg: config: read file /usr/share/spamassassin/20_body_tests.cf [20503] dbg: config: read file /usr/share/spamassassin/20_compensate.cf .... [20503] dbg: config: using "/etc/mail/spamassassin" for site rules dir [20503] dbg: config: read file /etc/mail/spamassassin/local.cf [20503] dbg: config: using "/var/lib/amavis/.spamassassin/user_prefs" for user p refs file [20503] dbg: plugin: loading Mail::SpamAssassin::Plugin::URIDNSBL from @INC [20503] dbg: plugin: registered Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x9cd4 5cc) .... [20503] info: config: failed to parse, now a plugin, skipping: ok_languages es c a Al parecer, si que leia la configuracion de local.cf, e investigando un poco sobre esta ultima linea, he descubierto que el problema era que faltaba activar el pluggin TextCat en el archivo v310.pre. Una vez activado el pluggin, parece que ya funciona lo del idioma, en la cabecera de algun mensaje de spam ha puesto UNWANTED_LANGUAGE_BODY=x.x Eso si, no es la panacea....solo detecta el idioma en unos pocos mensajes...pero algo ayuda con el spam. Ahora solo me falta resolver un problema con postfix que me surgio ayer, se fue la luz en el hosting y cuando se volvio a encender el ordenador, casi todos los usuarios recibieron correos de "Undelivered Mail Returned to Sender", porque "Host or domain name not found". Esto no seria un problema si no fuera porque alguno de esos mensajes eran de hacia 2 meses, y algunos de ellos eran urgentes... no entiendo porque no habia retornado esos emails antes ya que maximal_queue_lifetime esta por defecto, es decir, 5 dias. Imaginad q necesitas avisar a alguien con urgencia, el servidor destino esta caido, o lo que sea, y no te avisa de ello...con lo que te crees que el destinatario esta avisado... Bueno, gracias por la ayuda! Saludos. -- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com

Carlos E. R. escribió:

El 2006-07-11 a las 16:13 +0200, Antonio escribió:

...

Ahora solo me falta resolver un problema con postfix que me surgio ayer, se fue la luz en el hosting y cuando se volvio a encender el ordenador, casi todos los usuarios recibieron correos de "Undelivered Mail Returned to Sender", porque "Host or domain name not found".

Esos correos no debieran haberse devuelto, sino haberse retrasado para reintentar. Un fallo de nombre no existente se considera fallo temporal, no definitivo.

Y asi es...la cuestion es que, en principio, Postfix por defecto lo reintenta hasta un maximo de 5 dias(ahora lo puse a 5 horas), y si no lo consigue pasado ese tiempo, lo devuelve, pero habian correos de hacia 2 meses...

...

Esto no seria un problema si no fuera porque alguno de esos mensajes eran de hacia 2 meses, y algunos de ellos eran urgentes... no entiendo porque no habia retornado esos emails antes ya que maximal_queue_lifetime esta por defecto, es decir, 5 dias.

Pero, ¿donde estaban parados, en tu postfix, o en el hosting? Habría que saber además el motivo de la retención.

En mi servidor: This is the Postfix program at host mi.servidor.com. I'm sorry to have to inform you that your message could not be be delivered to one or more recipients. Y aqui los fallos: : delivery temporarily suspended: Host or domain name not found. Name service error for name=destino1.org type=MX: Host not found, try again : delivery temporarily suspended: Host or domain name not found. Name service error for name=destino1.org type=MX: Host not found, try again

Para eso sirven las confirmaciones de envío.

Desgraciadamente, el postfix no las soporta (el sendmail si), con lo cual sólo quedan las confirmaciones de usuario, las del programa cliente de correo: y estas no funcionan más que con algunos programas, y en algunos casos sólo si el destinatario quiere.

Algunos de esos correos se enviaban a varias personas, tal vez 15 o mas... por lo que en segun que casos la confirmacion de envio no seria una solucion. Es mas efectivo que te digan quienes no lo han recibido. Lo que me preocupa es que mi propio servidor se quede con mensajes en la cola para reintentar enviar durante dos meses . Ademas, un usuario me ha mostrado un par de correos tambien devueltos el mismo dia con un error que me deja todavia mas desconcertado: : connect to /var/run/cyrus/socket/lmtp[/var/run/cyrus/socket/lmtp]: No such file or directory. Ha sido un error puntual...aunque no se por que. El usuario destino(de mi propio servidor) es correcto. El usuario me asegura que ese correo no llego a su destino y ademas, fue enviado hace dos semanas...no tiene sentido. Parece que estuvieran en la cola, pero sin intentar reenviar... encontre esto en el man de postsuper: while mail is "on hold" it will not expire when its time in the queue exceeds the *maxi http://www.postfix.org/postconf.5.html#maximal_queue_lifetime-* *mal_queue_lifetime http://www.postfix.org/postconf.5.html#maximal_queue_lifetime* or *bounce_queue_lifetime http://www.postfix.org/postconf.5.html#bounce_queue_lifetime* set- ting. It becomes subject to expiration after it is released from "hold". Buscare mas informacion sobre ese "estado" hold, a ver si logro averiguar la razon por la cual no se devolvieron esos mensajes despues de 2 meses, ademas de que seguramente tampoco se intentaron reenviar.

Ejecutar el comando "mailq" de vez en cuando puede ser util. Hasta ayer, no conocia de su existencia... use postqueue -p, que parece que da la misma salida que mailq, con postqueue -f en principio los devuelve pero me parece que solo los del usuario que lo ejecute, por tanto, no me sirve, ahora estoy con postsuper, que puede borrarlos todos de la cola con "postsuper -d ALL", pero yo no quiero borrarlos, quiero devolverlos. Sigo investigando...

-- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-07-12 a las 10:53 +0200, Antonio escribió:

...

Esos correos no debieran haberse devuelto, sino haberse retrasado para reintentar. Un fallo de nombre no existente se considera fallo temporal, no definitivo.

Y asi es...la cuestion es que, en principio, Postfix por defecto lo reintenta hasta un maximo de 5 dias(ahora lo puse a 5 horas), y si no lo consigue pasado ese tiempo, lo devuelve, pero habian correos de hacia 2 meses...

Teniendo el "Message-ID" de los correos en cuestión (en las cabeceras), puedes buscarlo en el log con: zgrep -e "Message-ID" /var/log/mail*gz | less -S obviamente, tienes que tener guardados los logs de varios meses, lo cual es una buena idea, en mi opinión.

Y aqui los fallos: : delivery temporarily suspended: Host or domain name not found. Name service error for name=destino1.org type=MX: Host not found, try again

Son fallos temporales.

...

Para eso sirven las confirmaciones de envío.

Desgraciadamente, el postfix no las soporta (el sendmail si), con lo cual sólo quedan las confirmaciones de usuario, las del programa cliente de correo: y estas no funcionan más que con algunos programas, y en algunos casos sólo si el destinatario quiere.

Algunos de esos correos se enviaban a varias personas, tal vez 15 o mas... por lo que en segun que casos la confirmacion de envio no seria una solucion. Es mas efectivo que te digan quienes no lo han recibido.

Existe la "confirmación negativa de envío", es decir, de avisar si no se puede. Observa las opciones del Pine: Send message (filtered thru "pgp4pine", DSN requested[FDS-Full])? ? Help Y [Yes] ^P Prev Filter ^W Verbose D NoDelay X NoErrRets ^C Cancel N No ^N Next Filter ^R Background S NoSuccess H RetHdrs Te copio la ayuda del pine al respecto, que es muy informativa; fíjate que uno de los avisos es por retraso en la entrega: FEATURE: Enable-Delivery-Status-Notification This feature affects the behavior of Pine's mail sending. If set, this feature enables a subcommand in the composer's "Send?" confirmation prompt. The subcommand allows you to tell Pine to request the type of Delivery Status Notification (DSN) which you would like. Most users will be happy with the default, and need not enable this feature. If the feature "Send-Without-Confirm" is set, then this feature has no effect and the type of DSN is not selectable. Turning on this feature and then turning on the DSNOpts from the send prompt reveals four on-off toggles at the bottom of the screen. The "X" command toggles between NoErrRets and ErrRets. NoErrRets requests that no notification be returned to you, even if there is a delivery failure. The "D" key toggles between Delay and NoDelay. This tells the server that you are willing (or not) to receive delay notifications, which happen when there is an unusual delay at some mail server (in that mail server's opinion). The "S" key toggles between Success and NoSuccess. Success requests that you be sent a DSN message when the message is successfully delivered to the recipients mailbox. Setting NoErrRets will automatically turn off Delay and Success notification, and will flip the toggles to show that. Similarly, turning on Delay and/or Success will automatically toggle the "X" key to ErrRets. The fourth command, the "H" key, toggles between RetHdrs and RetFull. RetFull requests that the full message be returned in any failed DSN. RetHdrs requests that only the headers be returned in any failed DSN. Notice that this command applies only to failed delivery status reports. For delay or success reports, the full message is never returned, only the headers are returned. If you don't enable the DSN feature or if you don't turn it on for a particular message, the default is that you will be notified about failures, you might be notified about delays, and you won't be notified about successes. You will usually receive the full message back when there is a failure. If you turn on the DSNOpts the default is to return as much information as possible to you. That is, by default, the Success and Delay options are turned on and the full message will be returned on failure. The sending prompt will display the current DSN request (if any) in a shorthand form. It will be: [Never] if you have requested NoErrRets. Otherwise, it will look something like: [FDS-Hdrs] The "F" will always be there, indicating that you will be notified of failures. (Pine doesn't provide a way to request no failure notification and at the same time request either success or delay notification. The only way to request no failure notifications is to request no notifications at all with NoErrRets.) The "D" and/or "S" will be present if you have requested Delay and/or Success notification. If one of those is missing, that means you are requesting no notification of the corresponding type. After the dash it will say either Hdrs or Full. Hdrs means to return only the headers and Full means to return the full message (applies to failure notifications only). NOTE: This feature relies on your system's mail transport agent or configured "SMTP-Server" having the negotiation mechanism introduced in "Extended SMTP" (ESMTP) and the specific extension called "Delivery Status Notification" (DSN). If the mail tranport agent you are using doesn't support DSN, a short warning will be shown to you on the message line at the bottom of the screen after you send your message, but your message will have been sent anyway. Note that DSNs don't provide a mechanism to request read receipts. That is, if you request notification on success you are notified when the message is delivered to the mailbox, not when the message is read. ESMTP allows for graceful migration to upgraded mail transfer agents, but it is possible that this feature might cause problems for some servers. <End of help on this topic> Lo voy a probar otra vez, pero el postfix no lo soportaba, el sendmail si (porque el postfix no es monolítico, no hay un programa que tenga conocimiento de todo el procedimiento referido a un correo determinado no hace seguimiento).

Lo que me preocupa es que mi propio servidor se quede con mensajes en la cola para reintentar enviar durante dos meses

Es extraño. Habría que mirar el log. Sólo se explicaría si estuviera en "hold".

Ademas, un usuario me ha mostrado un par de correos tambien devueltos el mismo dia con un error que me deja todavia mas desconcertado:

: connect to /var/run/cyrus/socket/lmtp[/var/run/cyrus/socket/lmtp]: No such file or directory.

lmtp es un protocolo interno de transferencia de correos, en lugar de usar smtp internamente. Se usa, por ejemplo, para transferir correos entre el postfix y los filtros de contenido o virus, como el amavis. Pero la política del postfix creo que era no reportar esos problemas al usuario... no tiene sentido.

Ha sido un error puntual...aunque no se por que. El usuario destino(de mi propio servidor) es correcto. El usuario me asegura que ese correo no llego a su destino y ademas, fue enviado hace dos semanas...no tiene sentido.

¿Puede suceder que al encontrar un problema gordo, con otro programa "externo" al postfix, el correo quede en hold?

Parece que estuvieran en la cola, pero sin intentar reenviar... encontre esto en el man de postsuper:

while mail is "on hold" it will not expire when its time in the queue exceeds the *maxi http://www.postfix.org/postconf.5.html#maximal_queue_lifetime-* *mal_queue_lifetime http://www.postfix.org/postconf.5.html#maximal_queue_lifetime* or *bounce_queue_lifetime http://www.postfix.org/postconf.5.html#bounce_queue_lifetime* set- ting. It becomes subject to expiration after it is released from "hold".

Buscare mas informacion sobre ese "estado" hold, a ver si logro averiguar la razon por la cual no se devolvieron esos mensajes despues de 2 meses, ademas de que seguramente tampoco se intentaron reenviar.

En "hold" no se intenta enviar ni hacer nada. Se guardan ahí hasta que tu le digas algo, si no, se calla y espera con la infinita paciencia de las computadoras.

...

Ejecutar el comando "mailq" de vez en cuando puede ser util.

Hasta ayer, no conocia de su existencia... use postqueue -p, que parece que da la misma salida que mailq,

Si, es lo mismo. Es que mailq es facil de recordar para mi, viene del sendmail.

con postqueue -f en principio los devuelve pero me parece que solo los del usuario que lo ejecute,

Si es root, todos. Creo.

por tanto, no me sirve, ahora estoy con postsuper, que puede borrarlos todos de la cola con "postsuper -d ALL", pero yo no quiero borrarlos, quiero devolverlos. Sigo investigando...

Los que están en hold se liberan con "postsuper -H queue_id". Con -r se encolan de nuevo. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEtU8ItTMYHG2NR9URAmktAJ9p/yzxJBkFbaesz+U6JZrcIcZ1oACfUpFH NeA++JcwSTpvWnj/Bm6bTno= =3EVv -----END PGP SIGNATURE----- -- Para dar de baja la suscripci�n, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com

Carlos E. R. escribió:

Teniendo el "Message-ID" de los correos en cuestión (en las cabeceras), puedes buscarlo en el log con:

zgrep -e "Message-ID" /var/log/mail*gz | less -S

obviamente, tienes que tener guardados los logs de varios meses, lo cual es una buena idea, en mi opinión.

Tengo guardados los logs de hace tiempo. No conocia zgrep, interesante.

Es extraño. Habría que mirar el log. Sólo se explicaría si estuviera en "hold".

Busque un par de mensajes, pero no vi hold por ningun lado, no vi nada raro... tal vez siga mirando los demas, cuando tenga mas tiempo.

¿Puede suceder que al encontrar un problema gordo, con otro programa "externo" al postfix, el correo quede en hold?

No lo se, pero ahora que se que puedo ver las colas, estare mas atento... Por cierto, he probado pfqueue para la visualizacion y gestion de las colas. Solo decir que es muy sencillo y util. Muchas gracias a todos, y especialmente a Carlos, he aprendido unas cuantas cosas en este hilo. Seguire investigando el tema, mas poco a poco, ya que el viernes me surgieron nuevos problemnas en el servidor, debido a unos cortes de luz se me dañaron sectores del disco, en consecuencia se me estropearon algunas aplicaciones, y creo que lo proximo que hare sera hacer una instalacion nueva y limpia en otro disco duro... Como podeis ver, he tenido una semana que da asco xD Saludos... -- Para dar de baja la suscripción, mande un mensaje a: suse-linux-s-unsubscribe@suse.com Para obtener el resto de direcciones-comando, mande un mensaje a: suse-linux-s-help@suse.com