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

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 :

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

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

2006/2/9, Camaleón :

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