debugsql El curioso caso del correo de las 500 millas – Mexcoder

El curioso caso del correo de las 500 millas

Esta historia es una traducción de un correo enviado a la mailing list de los miembros de sage.org en noviembre de 2012, el original (en ingles) lo pueden encontrar aqui.

Fecha: Sabado 24 de Noviembre, 2002 21:03:02 -0500 (EST)
De: Trey Harris ( trey [at] sage.org )
Para: sage-members [at] sage.org
Tema: El caso del correo de las 500 millas (antes RE: [SAGE] ¿Cual es su tarea imposible favorita?)

Aquí hay un problema que *sonaba* imposible… casi me arrepiento de enviar esto a una audiencia amplia por que es una excelente historia para contar entre tragos o en una conferencia. 🙂 La historia ha sido levemente alterada para proteger a los culpables, omitir los detalles aburrido e irrelevantes y en general hacerla mas interesante.

Hace algunos años estaba trabajando como administrador del sistema de email del campus cuando recibí una llamada del presidente del departamento de estadística.

-Estamos teniendo un problema para enviar correos fuera del departamento.

-Cual es el problema – Pregunte.

-No podemos enviar correos a una distancia mayor de 500 millas ( N. del T.: unos 800 kilómetros) – Explico el Presidente.

– Casi me ahogo con mi café. – ¿Como dice?

-No podemos enviar correos mas allá de las 500 millas de aquí – repitió -Un poco mas para ser exactos, digamos unas 520 millas pero no mas.

-umm generalmente el correo electrónico no funciona así- dije, tratando de no mostrar alarma en mi voz, uno no debe mostrar pánico cuando habla con el presidente de un departamento, incluso uno relativamente empobrecido como el de estadística. – ¿Que les hace pensar que no pueden enviar correos mas allá de las 500 millas?

-No es lo que yo *piense* – contesto con irritación el presidente – veras, cuando nos dimos cuenta hace algunos días —

-Espero algunos DÍAS – lo interrumpí con un temblor en mi voz  – Y todo este tiempo no ha podido enviar correos?

-Podemos enviar correos, solamente a no mas de – –

— 500 millas, si – termine por el – Entiendo eso, pero, ¿por que no lo reportaron antes?

-Bueno, no habíamos podido recolectar suficientes datos para estar seguros de lo que esta sucediendo, hasta ahora; de cualquier manara le pregunte a una de las geoestadistas que le echara un ojo  – –

-Geoestadistas…

–Si, y elaboro un mapa mostrando el radio dentro del cual podemos enviar correos, el cual es un poco mas de 500 millas. También hay diversos lugares dentro del radio a las cuales tampoco podemos enviar correos o podemos hacerlo esporádicamente, pero fuera de este radio nunca podemos enviar ningún correo.

-Ya veo – dije mientras ponia mi cabeza entre mis manos – ¿Cuando comenzó esto?, me dice que hace algunos días, pero algo cambio en sus sistemas antes de que comenzara?

-Bueno. el consultor vino para actualizar y reiniciar el servidor. Pero ya le llamamos y dijo que no toco el sistema de correo electrónico.

-Esta bien, déjeme revisar y le devuelvo la llamada. – dije, apenas creyendo que les estaba siguiendo la corriente. No era día de los inocentes. Intente recordar si le debía una broma a alguien.

Ingrese en el servidor del departamento y envié algunos correos de prueba. estábamos en el triangulo de investigación de carolina del norte y un mensaje de prueba a mi propia cuenta fue entregado sin problema, igual para uno enviado a Richmond, Atlanta, Washington y uno mas a Princeton (400 millas).

Entonces  intente enviar uno a Memphis (600 millas), fallo. Boston, fallo. Detroit, fallo. saque mi libreta de direcciones y empece a reducir las posibilidades. Nueva York (420 millas) funciono, pero Providence (580 millas) fallo.

Comencé a preguntarme si me estaba volviendo loco. Intente enviar un correo a un amigo que vivía en Carolina del norte, pero su ISP estaba ubicado en Seattle. Gracias a Dios fallo. Si el problema tuviera que ver con la ubicación física del del humano destinatario y no la de su servidor de correos hubiera roto en llanto.

Habiendo establecido que – increíblemente – el problema reportado era verdadero y repetible, Revise el archivo «sendmail.cf». Se veía muy normal, de hecho, familiar.

busque diferencias con mi propio archivo «sendmail.cf». no había sido alterado, era el mismo archivo «sendmail.cf» que yo había escrito. y estaba muy seguro que no había activado la opción «FALLAR_DESPUÉS_DE_500_MILLAS». perplejo hice telnet al servidor en el puerto SMTP; el servidor felizmente respondo con el banner de identificación del sendmail de SunOS.

Espera un momento… ¿Un banner del sendmail de SunOS? En esos tiempos Sun aun estaba incluyendo Sendmail 5 con su sistema operativo, incluso cuando Sendmail 8 estaba en un estado de desarrollo bastante bueno. Y también siendo un buen administrador de sistemas, había escrito el sendmail.cf con las opciones largas autodocumentables y nombres de variables disponibles en Sendmail 8 en lugar de las versiones cripticas de Sendmail 5.

Todas las piezas encajaron, y casi me hago de nuevo en mi ahora frió café. Cuando el consultor actualizo el servidor, instala la nueva versión de SunOS y haciendo eso *desactualizo* Sendmail. Por fortuna la actualización no toco el archivo de configuración, aunque ahora era la versión incorrecta.

Al parece Sendmail 5 – al menos la versión incluida en SunOS, que había sido modificaciones – podía leer el archivo de Sendmail 8, muchas de las reglas no habían sido modificadas, pero las nuevas configuraciones largas – esas que detecto como basura, fueron ignoradas y como el binario no tenia opciones por defecto compiladas para algunas opciones, estas fueron puestas a 0.

Una de las opciones puestas a 0 fue el tiempo de desconeccion al servidor SMTP remoto (N. del T.: timeout, tiempo al cual el servidor cierra la conexión si no hay respuesta). Algunos experimentos establecieron que en este sistema con la carga típica , un timeout de 0 abortaría la conexión en aproximadamente 3 millisegundos.

Algo especial de la red del campus en ese tiempo es que estaba 100% conmutada. un paquete saliente no tendría ningún retraso hasta que llegara al router fuera de la red interna. entonces el tiempo para conectar a un servidor remoto con poca carga en una red cercana seria dictado aproximadamente por la velocidad de la luz y la distancia al destino en lugar del retraso provocado por los routers.

sintiéndome un poco mareado, escribí en mi consola:

$ units

1311 units, 63 prefixes

Tiene: 3 millilightseconds

Desea: millas

* 558.84719
/ 0.0017893979

«500 millas mas o menos»

Trey harris.