Hola, Tengo configurado QMAIL en suse y funcoina correctamente. El otro dia, al mandar un email a una direccion en concreto, no llegaban, pero tampoco recibia ningun email de error ni nada por el estilo. Desde otro email alternativo, si le llego el email. Pero con el mio, que funciona ben con el resto del mundo.. no le llegaban. Ayer recibi un email de error, aqui os lo pongo a ver si me podeis ayudar a saber por que puede ser que no lleguen los emails desde mi servidor al suyo. /Hi. This is the qmail-send program at ivico.net. / /I'm afraid I wasn't able to deliver your message to the following addresses. / /This is a permanent error; I've given up. Sorry it didn't work out. / // /<eduardo.garcia@ecr-pos.com>: / /130.117.162.10 does not like recipient. / /Remote host said: 451 DNS temporary failure (#4.3.0) / /Giving up on 130.117.162.10. / /I'm not going to try again; this message has been in the queue too long. / /--- Below this line is a copy of the message. / /Return-Path: <info@ivico.com> / /Received: (qmail 11805 invoked from network); 1 Feb 2006 12:42:48 -0000 / /Received: from unknown (HELO oficina) (192.168.1.15) / / by dns.ivico.net with SMTP; 1 Feb 2006 12:42:48 -0000 / /Message-ID: <002101c6272c$f771c330$0301a8c0@oficina> / /From: "IVICO" <info@ivico.com> / /To: <eduardo.garcia@ecr-pos.com> / /Subject: datos / /Date: Wed, 1 Feb 2006 13:42:04 +0100 / /MIME-Version: 1.0 / /Content-Type: multipart/mixed; / /boundary="----=_NextPart_000_001D_01C62735.49A81520" / /X-Priority: 1 / /X-MSMail-Priority: High / /X-Mailer: Microsoft Outlook Express 6.00.2900.2180 / /X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 .../ / / Espero que alguien me pueda ayudar. Un saludo y muchas gracias! Jorge
El 8/02/06, SAT Ivico escribió:
/<eduardo.garcia@ecr-pos.com>: / /130.117.162.10 does not like recipient. / /Remote host said: 451 DNS temporary failure (#4.3.0) / /Giving up on 130.117.162.10. / /I'm not going to try again; this message has been in the queue too long. /
Todo normal. El dominio del correo del usuario al que se le está intentando enviar un mensaje (ecr-pos.com) no se encontraba disponible (más bien no se podía resolver la dirección). Qmail ha hecho lo que tenía que hacer, guardar el mensaje en la cola e intentar enviarlo más tarde. Al final, lo devuelve al emisor si no puede conectar con el servidor externo. Prueba a enviarlo de nuevo, si vuelve a fallar, habrá que revisar la configuración de Qmail o la conexión que tengas. Saludos, -- Camaleón
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-08 a las 19:47 +0100, SAT Ivico escribió:
/<eduardo.garcia@ remoto >: / /130.*.*.* does not like recipient. / /Remote host said: 451 DNS temporary failure (#4.3.0) / /Giving up on 130.*.*.* / /I'm not going to try again; this message has been in the queue too long. /
Puesto que ese problema lo reporta el remoto, es que el problema está en tu lado - y así es: cer@nimrodel:~/Mail> host ivico.com ivico.com has address 213.*.*.* ;; connection timed out; no servers could be reached ;; connection timed out; no servers could be reached Tienes un problema con tu DNS, no tienes registro MX, y el servidor remoto espera encontrarlo. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD6l0WtTMYHG2NR9URAoiuAKCSYrGVV12czU9aI9k49tLJ2rh7EgCcD5NT rcFpC0ylkj3qy4Pi2c6D4PE= =T2W3 -----END PGP SIGNATURE-----
2006/2/8, Carlos E. R.:
Puesto que ese problema lo reporta el remoto, es que el problema está en tu lado - y así es:
Pero esa respuesta la recibe el usuario de ivico.com que ha enviado un correo a un servidor externo. Qmail le dice que no puede encontrar el servidor...
cer@nimrodel:~/Mail> host ivico.com ivico.com has address 213.*.*.* ;; connection timed out; no servers could be reached ;; connection timed out; no servers could be reached
Tienes un problema con tu DNS, no tienes registro MX, y el servidor remoto espera encontrarlo.
En ese caso sería el usuario remoto quien recibiría el correo, no el dominio con problemas... veamos: host -t mx ivico.com ivicom.com mail in handled by 10 mail.ivico.net Cuando mi servidor de correo falla, yo no recibo mensajes de servidores externos indicándome el error, que por otra parte no estaría nada mal... ;-) Saludos, -- Camaleón
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-08 a las 22:24 +0100, Camaleón escribió:
2006/2/8, Carlos E. R.:
Puesto que ese problema lo reporta el remoto, es que el problema está en tu lado - y así es:
Pero esa respuesta la recibe el usuario de ivico.com que ha enviado un correo a un servidor externo. Qmail le dice que no puede encontrar el servidor...
No, no, el qmail de ivico dice que el servidor de ecr-post le ha dicho que hay un fallo temporal de DNS. Lo de "does not like recipient" es la interpretación del qmail local (ivico) pero lo que dice el servidor destinatario es lo del error 451 del DNS - y eso se corresponde precisamente con el error que me da a mi al hacer una comprobación dns del remitente, ivico. A consecuencia de ese fallo temporal, el qmail local abandona y devuelve el correo, diciendo que ya ha estado demasiado tiempo en la cola y no va a seguir intentándolo. El comportamiento es correcto, y el problema es culpa del dns de ivico.
cer@nimrodel:~/Mail> host ivico.com ivico.com has address 213.*.*.* ;; connection timed out; no servers could be reached ;; connection timed out; no servers could be reached
Tienes un problema con tu DNS, no tienes registro MX, y el servidor remoto espera encontrarlo.
En ese caso sería el usuario remoto quien recibiría el correo, no el dominio con problemas... veamos:
No, nunca. El servidor de destino se niega a recibir el correo de un servidor que no tiene entrada mx en el dns. No tiene porqué mandar ningún correo a nadie informandole, de eso se encarga el MTA del remitente.
host -t mx ivico.com ivicom.com mail in handled by 10 mail.ivico.net
Eso es ahora, o en tu maquina, que quizás tenga ese dato cacheado; a mi me sigue dando error - y me acabo de conectar para comprobarlo: cer@nimrodel:~> host -t mx ivico.com ;; connection timed out; no servers could be reached Y si pruebo ese otro: cer@nimrodel:~> host -t mx ivicom.com ivicom.com mail is handled by 0 dev.null. lo cual es estar pidiendo a gritos que los listen en rfc-ignorant.
Cuando mi servidor de correo falla, yo no recibo mensajes de servidores externos indicándome el error, que por otra parte no estaría nada mal...
;-)
Pero es que no es eso lo que ha ocurrido. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD6qwDtTMYHG2NR9URAiiYAJ9gpDJ2NBO1X7P4qq633uGIrkGPKACbBjOJ dj4sNnSRIcNbMCxpbXP16lI= =8vLK -----END PGP SIGNATURE-----
El 8/02/06, Carlos E. R.<robin1.listas@tiscali.es> escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2006-02-08 a las 22:24 +0100, Camaleón escribió:
[...]
No, no, el qmail de ivico dice que el servidor de ecr-post le ha dicho que hay un fallo temporal de DNS. Lo de "does not like recipient" es la interpretación del qmail local (ivico) pero lo que dice el servidor destinatario es lo del error 451 del DNS - y eso se corresponde precisamente con el error que me da a mi al hacer una comprobación dns del remitente, ivico. A consecuencia de ese fallo temporal, el qmail local abandona y devuelve el correo, diciendo que ya ha estado demasiado tiempo en la cola y no va a seguir intentándolo.
El comportamiento es correcto, y el problema es culpa del dns de ivico.
asi es !!! tienen errores en todos los lados !!! - en el DNS padre (por aca nic.cl) tienes configurado que los dns para ivico.com son dns.ivico.net y dns2.ivico.net, pero el segundo no funciona para nada !! - en las zonas de ivico.com, configuraste que vuestros dns serian victor@vhs:~$ dig ivico.com ns +short servidor. dns2.ivico.net. pero como mencione antes, dns2.ivico.net no contesta a ninguna peticion y la maquina "servidor" NUNCA jamas sera encontrada desde la internet. - en el registro SOA tambien tiene malo configurado el servidor maestro. al menos esto fue lo que puede ver por aca con la poca informacion que me llego desde algunos servidores dns, que tenian la informacion en cache !!! [...]
cer@nimrodel:~> host -t mx ivicom.com ivicom.com mail is handled by 0 dev.null.
lo cual es estar pidiendo a gritos que los listen en rfc-ignorant.
mmmm... personalmente recomendaria, que el contratara alguna empresa que saiba configurar el DNS para arreglar el "cachito" que tienen.. o alternativamente quedar sin los servicios basicos de internet por unos varios dias hasta que lea y relea los manuales de DNS y intenda lo que esta haciendo !!! el lado positivo de todo esto, es que configuro la zona con un TTL (time to live) de 38400 segundos lo que es normal.. o sea, que despues que tenga todo arreglado y funcionando correctamente, los clientes/servidores de internet, solamente tendran que esperar 10,6 horas (38400 segundos / 3600 segundos) para que se expire la informacion en el cache y volvan a consultar al DNS de el !!!! ahora, preguntan el porque mencione que es positivo esto ??? porque ya me depare con errores semejante que la persona tenia configurado el TTL tan alto que tuveron que esperar como unos 13 dias para que todo volvera a funcionar correctamente. :-( suerte. -- -- Victor Hugo dos Santos Linux Counter #224399
El 9/02/06, Carlos E. R. escribió:
El comportamiento es correcto, y el problema es culpa del dns de ivico.
Pues sigo sin ver el error, salvo que haya sido algo temporal y específico, porque la configuración del dominio "ivico.com" no me reporta problemas, al menos desde dns tools: http://www.dnsstuff.com:8080/ Tiene entradas mx, el servidor dns responde y una conexión al puerto 25 del servidor de correo funciona... :-?
Eso es ahora, o en tu maquina, que quizás tenga ese dato cacheado; a mi me sigue dando error - y me acabo de conectar para comprobarlo:
cer@nimrodel:~> host -t mx ivico.com ;; connection timed out; no servers could be reached
Pues entonces debería tener problemas con todos los correos no sólo con uno, es bien extraño. Los errores (gazapos) en las entradas de los dns suelen llevar al menos 12 horas en corregirse... Saludos, -- Camaleón
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-09 a las 09:21 +0100, Camaleón escribió:
Pues sigo sin ver el error, salvo que haya sido algo temporal y específico, porque la configuración del dominio "ivico.com" no me reporta problemas, al menos desde dns tools:
Uso mi propio servidor dns y los comandos del linux para averiguar esas cosas ;-) Además, fíjate como Victor también ha encontrado los problemas, y más.
Tiene entradas mx, el servidor dns responde y una conexión al puerto 25 del servidor de correo funciona... :-?
Cacheados o corregidos, pero no actualizados en todas las cachés.
Eso es ahora, o en tu maquina, que quizás tenga ese dato cacheado; a mi me sigue dando error - y me acabo de conectar para comprobarlo:
cer@nimrodel:~> host -t mx ivico.com ;; connection timed out; no servers could be reached
Pues entonces debería tener problemas con todos los correos no sólo con uno, es bien extraño. Los errores (gazapos) en las entradas de los dns suelen llevar al menos 12 horas en corregirse...
No, porque no todos los servidores receptores están configurados para comprobar que el nombre del from resuelve (y posiblemente unos cuantos no miran el MX). Resulta alucinante que yo haya consiguido multiples veces enviar (por error o a propósito) correos como cer@nimrodel.valinor a servidores como terra o tiscali... Y estoy continuamente recibiendo en mis buzones pop correos con remite falso, que mi postfix rechaza, y casi invariablemente (99.999%) son spam. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD6yYmtTMYHG2NR9URAg5kAKCXGH4PVgmv7xy0ypfqtZga7BYFegCggCMR fDWUJK+8Xykteqcr5HvkPPM= =qg9L -----END PGP SIGNATURE-----
El 9/02/06, Carlos E. R. escribió:
No, porque no todos los servidores receptores están configurados para comprobar que el nombre del from resuelve (y posiblemente unos cuantos no miran el MX). Resulta alucinante que yo haya consiguido multiples veces enviar (por error o a propósito) correos como cer@nimrodel.valinor a servidores como terra o tiscali... Y estoy continuamente recibiendo en mis buzones pop correos con remite falso, que mi postfix rechaza, y casi invariablemente (99.999%) son spam.
No es tan alucinante, puesto que es un método más para evitar "en teoría" correos no válidos (spam, virus y demás), pero en realidad no es una medida muy eficiente, ya que los "from" se suelen falsear sin dificultad. Volviendo al tema del servidor dns de "ilvico.com", ahora me reporta que el servidor mx de ilvico.com es "nullmx.ilvico.com" que a su vez apunta a 127.0.0.1... también lo reporta "dnsstuff.com" por lo que ese dominio debe de estar perdiendo correos dirigidos a él. Anda... la web. :-O Saludos, -- Camaleón
2006/2/9, Camaleón:
Volviendo al tema del servidor dns de "ilvico.com", ahora me reporta que el servidor mx de ilvico.com es "nullmx.ilvico.com" que a su vez apunta a 127.0.0.1... también lo reporta "dnsstuff.com" por lo que ese dominio debe de estar perdiendo correos dirigidos a él.
Buf, ¡qué susto...! en vez de poner "ivico.com le puse una "L" de más. El dominio me sigue resolviendo como siempre, sin problemas... debo de tener un caché muy persistente. O:-)
Anda... la web. :-O
Y la web está correcta. :-D Saludos, -- Camaleón
2006/2/9, Camaleón <noelamac@gmail.com>:
2006/2/9, Camaleón:
Volviendo al tema del servidor dns de "ilvico.com", ahora me reporta que el servidor mx de ilvico.com es "nullmx.ilvico.com" que a su vez apunta a 127.0.0.1... también lo reporta "dnsstuff.com" por lo que ese dominio debe de estar perdiendo correos dirigidos a él.
Buf, ¡qué susto...! en vez de poner "ivico.com le puse una "L" de más. El dominio me sigue resolviendo como siempre, sin problemas... debo de tener un caché muy persistente. O:-)
hehehehe.... para evitar estes tipos de problemas (datos en cache al momento de hacer una depuracion) utilice dig (en verdad, no entiendo el porque ustedes aun utilizan host !!!) por ejemplo: $dig dominio.com te da informacion basica sobre un dominio, muy semejante a la salida de host $dig dominio.com [ns | mx | a | soa | any ] te da informacion sobre el registro requerido $dig @servidor_dns_a_consultar dominio.com [ns | mx | a | soa | any ] en este caso, no hara las consultas a mi DNS que tengo definido, pero si, a servidor_dns_a_consultar, logicamente en este otro servidor, debe de estar configurador para aceptar resolver los nombres a clientes externos (usted)... cosa que esta quedando dificil de encontrar ultimamente, ya que muchos DNS tienen esta restriccion activa. todo estas informaciones, son obtenidas del cache (caso esten).. ahora se quiero informacion sin cachear, puedo hacer: $dig dominio.com [ns | mx | a | soa | any ] +trace este parametro para mi es espetacular... con el usted puede observar por cuales servidores (desde los NS root/principales, hasta el destino) se estan pasando vuestras consultas, sin utilizar ninguna informacion del cache !!! y asi, poder depurar los datos y saber donde esta el problema !!! obs.: las veces es necesario repetir la misma consulta varias veces, ya que el mecanismo de los DNS es programado para realizar las consultas a servidores de manera aleatoria y ni siempre se consulta al servidor que le gustaria!!! :-(
Anda... la web. :-O
La vi... y me da aun mas errores que los que tenia encontrado a principio !!! :-( http://www.dnsreport.com/tools/dnsreport.ch?domain=ivico.com
Y la web está correcta. :-D
desde aca, me muestra varios errores.... muchos mismos !!!! -- -- Victor Hugo dos Santos Linux Counter #224399
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-09 a las 12:58 -0300, Victor Hugo dos Santos escribió:
hehehehe.... para evitar estes tipos de problemas (datos en cache al momento de hacer una depuracion) utilice dig (en verdad, no entiendo el porque ustedes aun utilizan host !!!)
Mi host da los mismos resultados que tu dig normal (cambió con no se que versión) - y más porque tira de mi dns local. El dig normalmente también tira del dns configurado: nimrodel:/etc/postfix # dig ivico.com ... ;; SERVER: 192.168.100.2#53(192.168.100.2)
$dig dominio.com [ns | mx | a | soa | any ] +trace
Ese es interesante. :-)
este parametro para mi es espetacular... con el usted puede observar por cuales servidores (desde los NS root/principales, hasta el destino) se estan pasando vuestras consultas, sin utilizar ninguna informacion del cache !!!
Si, usa la información del caché de los dns a los que pregunta. En el caso de ivico.com: ;; Received 436 bytes from 192.168.100.2#53(192.168.100.2) in 8 ms averigua los raiz del .com ;; Received 487 bytes from 128.*.*.90#53(D. ROOT-SERVERS. NET) in 171 ms averigua ivico.com ;; Received 105 bytes from 192.*.*.30#53(A. GTLD-SERVERS. NET) in 177 ms le pregunta al dns de ivico ;; Received 109 bytes from 213.*.*.68#53(dns. ivico. net) in 141 ms - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD6+yNtTMYHG2NR9URAjrZAJ9gAm57AU+ZrBl2fsLTtQ6IN6bTtgCeI26/ +1y6XtsHurvpuM4PD2F3llk= =cBMA -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-09 a las 15:09 +0100, Camaleón escribió:
No, porque no todos los servidores receptores están configurados para comprobar que el nombre del from resuelve (y posiblemente unos cuantos no miran el MX). Resulta alucinante que yo haya consiguido multiples veces enviar (por error o a propósito) correos como cer@nimrodel.valinor a servidores como terra o tiscali... Y estoy continuamente recibiendo en mis buzones pop correos con remite falso, que mi postfix rechaza, y casi invariablemente (99.999%) son spam.
No es tan alucinante, puesto que es un método más para evitar "en teoría" correos no válidos (spam, virus y demás), pero en realidad no es una medida muy eficiente, ya que los "from" se suelen falsear sin dificultad.
Lo alucinante es que servidores profesionales no comprueben el from. Es que si se produce un rebote, ¡no se puede rebotar! El problema es que sabiendo que el from se puede falsear, no rechacen los falsos. Es lo mínimo. Y, a todo esto, el señor "sat" no ha vuelto a contestar... me sospecho que ahora es él el que se ha quedado sin correo del todo: si ivico.com no tiene registro MX, en cuanto los cachés DNS se regeneran, suse no le envía correo. Ni nadie. El cache puede aguantar más tiempo si la consulta la haces a un servidor dns el cual lo consulta a otro más arriba... y yo sospecho que el qmail tiene su propio cache. En ciertas circunstancias, si no se solapan exactamente eso aumenta el intervalo hasta la desconexión. Eso es como cuando hace un par de meses el dominio tiscali.es desapareció del mapa. Yo no podía recoger el correo porque el fetchmail no sabía de donde, pero cuando conseguí saber la IP me di cuenta que la lista me había estado enviando correo durante más de un dia, hasta que se le borró la entrada de tiscali en la cache: en ese momento empezaron a rebotar los correos y yo me quedé sin recepción. Es que tiscali España desaparece, los clientes los pasan a Wanadoo. Puede que el dia que se enteraron los curritos alguien saboteara el dns :-P - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD61yntTMYHG2NR9URAvixAKCGJGOkJMWbPrxw3j+yhbSCHW+SaACfa+ch HSeIKwYz+nzi2+OC1YkQV8Q= =RT14 -----END PGP SIGNATURE-----
El 9/02/06, Carlos E. R. escribió:
Y, a todo esto, el señor "sat" no ha vuelto a contestar... me sospecho que ahora es él el que se ha quedado sin correo del todo: si ivico.com no tiene registro MX, en cuanto los cachés DNS se regeneran, suse no le envía correo. Ni nadie.
No me puedo creer que sea la única persona que puede resolver sin problemas ese dominio, conectarse con su servidor de correo, etc... ¿Nadie más puede resolver "ivico.com"? :-O Saludos, -- Camaleón
¿Nadie más puede resolver "ivico.com"?
:-O
S
Yo si puedo con DNSSTUFFy aunque da algunos fallos los registros MX estan correctamente configurados y responden, pero lo hacen con "220 Hola servidor.ivico ESMTP" y claro, "Hola" no es un nombre de host válido. De todas maneras no acepta correo porque dice: mail.ivico.net's postmaster@[213.96.133.68] response: >>> RCPT TO:<postmaster@[213.96.133.68]> <<< 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1) ... con lo cual pasa perfectamente el test de relay. :-) Mas Fallos. 1) El servidor de nombres 213.96.133.232 no responde 2) El nombre "servidor" no es un servidor de nombres válido y por eso esta desaparecido y no tiene NS y además no puede ser SOA. 3) dns.ivico.net no tiene registro NS. En resumen: que tiene un bonito lío. -- Salutacions - Saludos, Josep M. Queralt
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2006-02-09 a las 22:06 +0100, Camaleón escribió:
No me puedo creer que sea la única persona que puede resolver sin problemas ese dominio, conectarse con su servidor de correo, etc...
¿Nadie más puede resolver "ivico.com"?
:-O
Ahora mismo si resuelve, ha aparecido. - -- Saludos Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFD6+MRtTMYHG2NR9URApGUAJ9KQJKq268vpV9a1eISTV+b9GBLIQCcDkag ve0kt4ml4zApTP+wbGgTgTY= =ZBnY -----END PGP SIGNATURE-----
2006/2/9, Camaleón <noelamac@gmail.com>:
El 9/02/06, Carlos E. R. escribió:
No es tan alucinante, puesto que es un método más para evitar "en teoría" correos no válidos (spam, virus y demás), pero en realidad no es una medida muy eficiente, ya que los "from" se suelen falsear sin dificultad.
al menos para las falsificaciones de dominios existe SPF !!! que en pocas palabras impide que yo envie un correo a usted como "victorhugops@whitehouse.org". bye -- -- Victor Hugo dos Santos Linux Counter #224399
participants (5)
-
Camaleón -
Carlos E. R. -
Josep M. Queralt -
SAT Ivico -
Victor Hugo dos Santos