-----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