El caso del correo electrónico de las 500 millas
<http://www.microsiervos.com/archivo/ordenadores/email-500-millas.html>
Todos los que en nuestro trabajo tenemos que solucionar problemas de los usuarios con sus ordenadores o con la
informática en general estamos más que acostumbrados a que de vez en cuando nos lleguen mensajes o peticiones sin
demasiado sentido que hay que interpretar para ver qué es lo que realmente quieren decir.
Así que no es nada raro que cuando a Trey Harris uno de sus usuarios vino a decirle que no podían enviar correos
electrónicos a más de 500 millas su primera reacción fuera la de contarle que el correo electrónico en realidad no
funciona así y preguntarle que por qué pensaba que no podían enviar correos a más de 500 millas.
El usuario, que resultaba ser el jefe del departamento de estadística, le contestó que no es que pensara que no
podían enviar correos a más de 500 millas, sino que lo sabía a ciencia cierta, ya que llevaban varios días recogiendo
datos al respecto, lo que le permitía asegurar que no podían enviar correos a más de 500 millas -algo más en
realidad- y a veces, ni siquiera a distancias menores.
Esto captó definitivamente la atención de Trey -no es buena idea tener a un jefe de departamento varios días sin
correo electrónico- así que se puso manos a la tarea -aparentemente imposible- de solucionar un problema imposible.
La primera pregunta, naturalmente, fue si alguien había tocado algo, y resultó que en efecto uno de los consultores
con los que trabajaba el departamento había venido a parchear el servidor y que lo había reiniciado, pero ya habían
hablado con él y aseguraba no haber tocado nada del servidor de correo.
Así que Trey se rindió, se conectó al servidor de correo en cuestión y empezó a hacer algunas pruebas. Correos
enviados a Richmond, Atlanta, Washington y Princeton, todos a menos de 400 millas funcionaron sin problemas. Pero
entonces un correo enviado a alguien en Memphis, a 600 millas, falló. Boston y Detroit también fallaron. Más pruebas
revelaron que Nueva York, a 420 millas, funcionaba, pero Providence, a 580, no.
A esas alturas Trey ya estaba empezando a dudar de su propia cordura, así que intentó enviar un correo a un amigo
que vivía en Carolina del Norte pero cuyo proveedor de acceso a Internet estaba en Seattle. Afortunadamente el correo
falló, con lo que empezó a quedarle claro que el problema estaba relacionado con la ubicación geográfica del servidor
de correo del usuario y no con la de este.
Convencido ya de que el problema existía tal y como se lo habían descrito Trey le echó un vistazo al fichero de
configuración del servidor de correo, que no parecía tener ningún fallo, aunque para asegurarse de ello lo comparó
con una copia de seguridad almacenada en su máquina, comparación que no reveló ninguna diferencia.
Sin saber ya muy bien qué hacer a esas alturas, decidió hacer telnet al servidor de correo para ver si estaba
funcionando correctamente, y allí se encontró con que el servidor que le saludaba era la versión 5 de Sendmail
<http://es.wikipedia.org/wiki/Sendmail>, cuando él había instalado la versión 8.
Y resulta que la versión 5 no reconocía todas las opciones del fichero de configuración que Trey había creado para
la versión 8 del servidor de correo, con lo que algunos ajustes habían quedado a cero, entre ellos el del tiempo que
el servidor esperaba a conectarse a otro servidor de correo antes de dar un mensaje de error.
Tras unas cuantas horas más haciendo pruebas Trey determinó que un valor de cero en ese parámetro bajo las
condiciones de trabajo típicas de esa máquina y de la red de la universidad en la que estaba instalada provocaba un
corte en la conexión con el otro servidor en unos 3 milisegundos, y que estos son
$ units
1311 units, 63 prefixes
You have: 3 millilightseconds
You want: miles
* 558.84719
/ 0.0017893979
Algo más de 500 millas.
La historia completa está en The case of the 500-mile email <http://www.ibiblio.org/harris/500milemail.html> y con
más detalle en el FAQ on the 500-mile email <http://www.ibiblio.org/harris/500milemail-faq.html>.
Y la moraleja del caso, que de vez en cuando, aunque sólo muy de vez en cuando, los usuarios tienen razón en lo que
dicen por muy descabellado que suene.