Mailinglist Archive: opensuse-es (865 mails)
| < Previous | Next > |
Re: [suse-linux-s] OT: SpamAssassin + Amavis: activar dos directivas
- From: "Carlos E. R." <robin.listas@xxxxxxxxxxxxxx>
- Date: Wed, 12 Jul 2006 21:35:26 +0200 (CEST)
- Message-id: <Pine.LNX.4.64.0607122053000.3991@xxxxxxxxxxxxxxxx>
-----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:
> <usuario1@xxxxxxxxxxxx>: 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:
>
> <usuariox@xxxxxxxxxxxxx>: 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@xxxxxxxx
Para obtener el resto de direcciones-comando, mande
un mensaje a:
suse-linux-s-help@xxxxxxxx
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:
> <usuario1@xxxxxxxxxxxx>: 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:
>
> <usuariox@xxxxxxxxxxxxx>: 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@xxxxxxxx
Para obtener el resto de direcciones-comando, mande
un mensaje a:
suse-linux-s-help@xxxxxxxx
| < Previous | Next > |