El Servidor que NO enviaba Mails a más de 500 millas

Llega un momento en tu carrera como Computologo en la que debes decidir si empezar por ser Admin o Programador, y la verdad es que ambas son interesantes la primera por el factor humano y la segunda por superar los retos profesionales. De ambas formas siempre es intrigante la solución o el diagnostico del , te pones en papel de Dr. House o Sherlock Holmes: Inferir, deducir, crear hipótesis, etc. y lo disfrutas; esto es lo que le da el sabor a nuestra profesión.

¿Que es tan divertido como resolver un problema complicado? Pues conocer cómo se resuelve un caso tan curioso como el del que no enviaba correos a más allá de las 500 millas al principio parece algo irracional pero conforme se llega al desenlace de la historia todo tiene sentido. Esta historia es antigua, lo suficiente para que los pupilos de este siglo no la conozcan, justo la encontré en el blog de un maldito nerd y me fascino. A disfrutar:

Aquí tenéis un problema que os sonará imposible.. Casi me da pena contarlo a una audiencia más amplia; era una buena anécdota para contar en conferencias 🙂 La historia ha sido alterada ligeramente para proteger a los culpables, ignorar detalles irrelevantes y hacerla en general más amena.

Me encontraba trabajando como administrador de los sistemas de correo de un campus universitario hace algunos años cuando recibí una llamada del encargado del departamento de estadística.

“Estamos teniendo un problema para enviar emails fuera del departamento.”

“¿Cuál es el problema?” pregunté yo

“No podemos enviar emails más allá de 500 millas” explicó el jefe de departamento.

Me atraganté con el café. “¿Podrías repetirlo?”

“No podemos enviar emails a más de 500 millas del departamenteo” repitió. “En realidad un poco más, unas 520 millas pero no más.”

“Um… El correo electrónico no funciona de esa forma, generalmente.” dije tratando de no dejar entrever pánico en mi voz. Uno no debe mostrar pánico cuando está hablando con un jefe de departamento, incluso aunque sea de un departamento tan pobre como el de estadística. “¿Qué te hace pensar que no puedes enviar emails a más de 500 millas?

“No es lo que *yo piense*” repitio testarudamente. “Mira, cuando nos dimos cuenta por primera vez hace unos días..”

“¿Esperasteis unos DÍAS?” interrumpí con un ligero temblor en mi voz. “Y no habéis podido enviar emails en todo este tiempo”

“No hemos podido enviar emails a más de..”

“500 millas, sí.” acabé su frase. “Lo entiendo. Pero por qué no avisasteis antes?”

“Bueno, no habíamos recopilado suficientes datos como para estar seguros de lo que estaba ocurriendo hasta ahora.” Lógico, estoy hablando con el jefe del departamento de *estadística*. “Además, le pregunté a uno de los geostadísticos para que lo investigasen..”

“Geostadísticos..”

“.. Sí, y ha elaborado un mapa que muestra que el radio dentro del cual podemos enviar emails es justo de un poco más de 500 millas. Hay algunos destinos dentro de ese radio a los que no llegamos o a los que llegamos esporádicamente, pero no podemos llegar más allá de ese radio.”

“Ya veo”, dije y puse la cabeza entre mis manos. “¿Cuándo empezó todo esto? Hace unos días has dicho, ¿cambió algo en vuestros sistemas en ese momento?”

“Bueno, el consultor vino, parcheó nuestro servidor y lo reinició. Pero le llamé y me dijo que no había tocado nada del sistema de correo.”

“De acuerdo, déjame echarle un vistazo y te llamaré más tarde”, dije, sin creerme que le estaba siguiendo la corriente. No era el día de los inocentes. Intenté recordar si alguien me debía alguna broma pesada.

Inicié sesión en el servidor de su departamento y envié algunos emails de prueba. Estábamos en el Triángulo de Investigación del Norte de Carolina, y un email de prueba a mi propia cuenta llegaba sin problemas. Lo mismo con uno enviado a Richmond, Atlanta y Washington. Otro enviado a Princetown (400 millas) funcionó igualmente.

Pero cuando intentaba enviar un email a Memphis (600 millas) fallaba. Boston, fallaba. Detroit, fallaba. Saqué mi libreta de direcciones y empecé a afinar. New York (420 millas) funcionaba, pero Providence (580 millas) fallaba.

Estaba empezando a pensar si había perdido el juicio. Intenté enviar un email a un amigo que vivía en Carolina del Norte pero cuyo ISP estaba en Seattle. Gracias a dios, fallaba. Si el problema hubiese tenido que ver con la localización del recipiente humano y no con el del servidor creo que me habría echado a llorar.

Después de haber establecido –incrédulamente– que la incidencia reportada era cierta y reproducible me puse a mirar el sendmail.cf. Parecía bastante normal, de hecho me resultaba familiar.

Lo comparé con el sendmail.cf de mi directorio home. No había sido alterado; era el sendmail.cf que yo había escrito. Y estaba bastante seguro de no haber activado la opción “FALLAR_EMAIL_500_MILLAS”. Como último recurso conecté por telnet al puerto SMTP. El servidor me respondió alegremente con un banner de sendmail de SunOS.

Espera un minuto, ¿un banner de sendmail de SunOS? En ese momento Sun todavía distribuía Sendmail 5 junto al sistema operativo aunque Sendmail 8 ya era bastante estable. Siendo como soy un buen administrador de sistemas había estandarizado la red en Sendmail 8. Y también como buen administrador que soy había escrito un sendmail.cf que usaba los agradables y descriptivos nombres de variables y de opciones que estaban disponibles en Sendmail 8 en lugar de los códigos de puntuación crípticos que se usaban en
Sendmail 5.

Todas las piezas encajaron de golpe y me atraganté de nuevo con el café que ya estaba frío. Cuando el consultor actualizó la versión de SunOS rebajó la versión de Sendmail. La actualización dejó el sendmail.cf tranquilo aunque ahora fuese para otra versión.

Lo que ocurría era que Sendmail 5 — o al menos la versión que distribuía Sun tenía algunas modificaciones — podía trabajar con archivos de configuración de Sendmail 8 ya que todas las reglas se habían mantenido inalteradas. Pero las nuevas opciones con nombres largos las veía como basura y las ignoraba. Y el ejecutable de sendmail no traía valores por defecto compilados así que todas las variables para las que no encontraba una declaración explícita y válida en el sendmail.cf se ponían a 0.

Una de las opciones que se puso a 0 fue el tiempo de espera para conectar a un servidor SMTP remoto. Experimentaciones con esta máquina en particular con su carga típica daban que un timeout de 0 abortaría una conexión en aproximadamente 3 ms.

Una extraña característica de la red de nuestro campus es que estaba 100% switcheada. Un paquete saliente no se retrasaría hasta llegar al router del lado opuesto al que conectase. Así que el tiempo de conexión para un host remoto ligeramente cargado en una red cercana estaría determinado por la velocidad de la luz en lugar de por retrasos incidentales del router.

Sintiendo un ligero mareo escribí en mi :

$ units
1311 units, 63 prefixes

You have: 3 millilightseconds
You want: miles
* 558.84719
/ 0.0017893979

“500 millas, o un poco más.”

Solo por estas experiencias se vive de esta actividad. ¿Tienes alguna similar? No dudes en compartirla.

Comparte con otros

12 pensamientos en “El Servidor que NO enviaba Mails a más de 500 millas”

  1. Que yo sepa los pecados mas grandes en desarrollo que e echo es confundir las variables, o querer montar una unidad externa que no esta conectada.Muy interesante el post lo tomare cuenta cuando actualice algún programa, Gracias

  2. Espero no te moleste que responda dsd un S.O. privativo es solo que al parece el SO de linux que ocupo (Ubuntu 10.4) no me quiere, ó simplemente los controladores de la tarjeta de red no son compatibles U_U pero bueno.

    no termine de leer la historia, pero lo haré. Me gusta como hablas de nuestra carrera y la conbinas con ejemplos como dr house y sherloc (a mi me gusta la serie de dr house =D ) es cierto tiene esos como enigmas que tienesque resolver con una parte de tu cuerpo que si bien no nacistes con ella, ahora es parte de ti… “la computadora “_:)

  3. Una vez estaba ayudando por teléfono a un conocido a conctar su PSP a internet, me ofreci a ayudarle por que no es nada dificil, pero el sujeto desconocia el proceso, pero en fin, le di las instrucciones lo más claras posibles, pero por más que lo intentabamos no pidia conectar, y por falta de conocimento de la persona a la que ayudaba, no me era tan facil descubrir por teléfono cual paso fallaba, hasta que me desespere y fui personalmente a su casa, despues de dar una revisada rápida encontre el problema…..

    NO tenia conectado el modem, el pobre chavo se moria de pena cuando encontre el problema

  4. Muy buena la historia.

    Supera en calidad (no en humor) a la del operador del servicio técnico que después de dar mil vueltas al problema del propietario del pc éste le confiesa que dejó de funcionar desde que hubo un apagón, claro que la corriente todavía no estaba restablecidad cuando llamó.

  5. Fantástica anécdota, muy divertida y didáctica. Al final, al administrador le queda una sensación genial de “trabajo bien hecho”, sobre todo cuando ha costado un poco.
    Es similar a cuando nosotros, usuarios de GNU/Linux, conseguimos configurar una wifi, instalar una distro difícil en un portátil, etc.
    Muy buen post.

      1. Ok, lo busco.

        De paso te saludo por tu excelente blog, lo descubrí hace poco y estoy encontrando montones de cosas interesantes!!

        Congratz y esperame seguido por acá!!

  6. Genial, lo “bueno” es que en el trabajo usamos VPN’s y carriers internacionales, por lo que los timeout’s y tiempos de sesion son importantes, asi que si se presenta un problema parecido creo que se pensaria en la latencia de la red, y si esos parches como nos hacen sufrir.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *