- El servidor de correo del departamento de Estadística de una universidad, a partir de cierto momento, no podía enviar emails a destinos ubicados a más de unas 500–520 millas, y el problema se reproducía según un radio geográfico.
- El director del departamento reunió datos durante varios días y encargó el análisis a un geoestadístico, quien mapeó el radio alcanzable y los destinos excepcionales dentro de ese radio.
- En las pruebas del administrador, desde el Research Triangle de North Carolina los envíos a Richmond, Atlanta, Washington, Princeton y New York funcionaban, pero fallaban a Memphis, Boston, Detroit y Providence, lo que reveló que el criterio era la ubicación del servidor de correo, no la del destinatario.
- La causa fue que, durante un parche del servidor, SunOS se actualizó y Sendmail 8 quedó en la práctica degradado a Sendmail 5; Sendmail 5 ignoraba los nombres largos de configuración del
sendmail.cfexistente para Sendmail 8. - Como resultado, el timeout de conexión quedó configurado en 0, y en esa máquina la conexión se cortaba después de unos 3 milisegundos, lo que coincidía con el valor observado de unas 559 millas según el cálculo con
units.
El reporte: “no se pueden enviar mails a más de 500 millas”
- Mientras administraba el sistema de email del campus, el director del departamento de Estadística se comunicó diciendo que “hay un problema para enviar emails fuera del departamento”.
- El punto central del problema era que “desde aquí no podemos enviar correo a lugares que estén a más de 500 millas”, y el director agregó que el límite real era “un poco más, unas 520 millas”.
- El administrador respondió que el email normalmente no funciona de esa manera, pero el director ya había reunido suficientes datos durante varios días antes de contactarlo.
- El departamento de Estadística le pidió a un geoestadístico que lo verificara, y se elaboró un mapa que mostraba que el rango al que se podía enviar correo era un radio apenas mayor a 500 millas.
- Incluso dentro del radio había destinos a los que no se podía llegar, o solo se llegaba de forma intermitente.
- Fuera del radio, los emails nunca se entregaban.
- En ese mismo período, un consultor había parchado y reiniciado el servidor, pero afirmó que no había tocado el sistema de correo.
Pruebas de reproducción y frontera geográfica
- Cuando el administrador inició sesión en el servidor del departamento y envió correos de prueba, el problema efectivamente era reproducible.
- La ubicación en ese momento era el Research Triangle, en North Carolina, y los destinos cercanos funcionaban con normalidad.
- El correo de prueba enviado a su propia cuenta se entregó correctamente.
- Los correos enviados a Richmond, Atlanta y Washington también tuvieron éxito.
- La prueba hasta Princeton, a unas 400 millas, también pasó.
- Con destinos más lejanos, las fallas continuaban.
- Memphis, a unas 600 millas, falló.
- Boston falló.
- Detroit falló.
- New York, a unas 420 millas, funcionó.
- Providence, a unas 580 millas, falló.
- El correo enviado a la cuenta de un amigo que vivía en North Carolina falló porque el ISP de esa cuenta estaba en Seattle.
- Se confirmó que el problema no estaba relacionado con la ubicación física de la persona, sino con la ubicación geográfica del servidor de correo.
La configuración de Sendmail que parecía normal
- El archivo
sendmail.cfparecía en general normal y era idéntico al archivo que el administrador había escrito anteriormente. - El administrador concluyó que no había activado ninguna opción como
FAIL_MAIL_OVER_500_MILES. - Al conectarse al puerto SMTP con
telnet, el servidor devolvió un banner de sendmail de SunOS. - En ese entonces, Sun distribuía el sistema operativo incluyendo Sendmail 5, mientras que Sendmail 8 ya estaba maduro.
- El administrador había estandarizado todo con Sendmail 8 y usaba un
sendmail.cfque empleaba los nombres largos, autodescriptivos, de opciones y variables de Sendmail 8.- Sendmail 5 usaba un código de configuración más antiguo, críptico y basado en signos de puntuación.
La actualización que produjo una degradación
- Cuando el consultor “parchó” el servidor, subió la versión de SunOS y, en el proceso, Sendmail bajó a Sendmail 5.
- La actualización del sistema operativo dejó intacto el
sendmail.cfexistente, pero ahora ese archivo ya no correspondía a la versión de Sendmail que se estaba ejecutando. - La versión de Sendmail 5 distribuida por Sun podía procesar muchas de las reglas del
sendmail.cfpara Sendmail 8.- En aquel momento, la mayoría de las reglas no habían cambiado demasiado.
- El problema eran las opciones largas de configuración de Sendmail 8, que Sendmail 5 veía como basura y omitía.
- El binario de Sendmail no traía compilados la mayoría de los valores predeterminados de esas opciones y, al no encontrarlos tampoco en el archivo de configuración, terminaron configurados en 0.
Timeout de 3 milisegundos y 558 millas
- Uno de los valores configurados en 0 era el timeout de conexión usado al conectarse a un servidor SMTP remoto.
- Los experimentos mostraron que, en esa máquina y bajo condiciones de carga normales, un timeout de 0 interrumpía la llamada
connectdespués de un poco más de 3 milisegundos. - En ese momento, la red del campus estaba conmutada al 100%.
- Los paquetes que salían al exterior no sufrían demoras de routers hasta llegar al POP y encontrarse con el router del otro lado.
- Para conectarse a un host remoto cercano en una red con poca carga, el tiempo estaba más influido por la distancia según la velocidad de la luz que por demoras incidentales de routers.
- Cuando el administrador convirtió
3 millilightsecondsamilesenunits, el resultado fue 558.84719 millas. - La observación del director —“500 millas, o un poco más”— coincidía casi exactamente con el resultado del cálculo.
1 comentarios
Opiniones de Hacker News
En 1998, cuando daba soporte de IT en una pequeña empresa de Australia, un empleado de una oficina remota llamó diciendo que “el protector de pantalla se cayó del monitor, presionó una tecla del teclado y la terminal quedó bloqueada”
Al principio pensé que no tenía sentido, pero resultó que llamaba “protector de pantalla” al filtro físico antirreflejo para CRT, común en esa época, y ese filtro se había caído dejando presionada la tecla Scroll Lock
https://dylbs6e8mhm2w.cloudfront.net/productimages/500x500/E...
Me encantan este tipo de cosas. Hay momentos en los que descubres que un fenómeno que estabas seguro de que era imposible en realidad ocurre por leyes físicas como la velocidad de la luz
En uno de mis primeros trabajos tuve un problema en el que un monitor CRT parpadeaba sutilmente; cambiamos el monitor, los cables, el cable de alimentación e incluso la computadora, y seguía igual
Al final pusimos la computadora y el monitor en un carrito y los sacamos al pasillo, y el problema desapareció; la causa era el mal apantallamiento eléctrico de esa oficina
Más tarde se descubrió que, después de comprar un televisor más grande y ponerlo demasiado cerca, se acumulaba electricidad estática y producía ese efecto. Parece que para cuando llegaba al taller ya se había descargado lo suficiente y funcionaba bien durante un tiempo
Le habíamos vendido una computadora, pero decía que le aparecía una pantalla azul al usarla; cuando la traíamos y la probábamos no había ningún problema, e incluso usándola juntos 30 minutos en la oficina todo iba bien
Pero en el momento en que esa persona tocó el mouse, la computadora mostró una pantalla azul, y el problema desapareció al cambiar el mouse
Cuando alguien encendía un regulador, los monitores CRT cercanos se deformaban y parpadeaban un momento, y los colores se veían mal. Los puestos junto a la pared se veían menos afectados, pero daban fuertes dolores de cabeza; solo aguanté 6 meses en esa empresa
La mejor parte de esta historia es que el consultor que parcheó el servidor está en Hacker News
Dejó un comentario aquí sobre la parte que le tocó: https://news.ycombinator.com/item?id=23775404
También lo puse en
/highlightspara quienes les pueda interesar: https://news.ycombinator.com/highlightsProbablemente esa sea la parte a la que se refiere con “cambié un poco la historia para proteger a los culpables”
Cada algunos años vuelve a aparecer esta historia, y siempre me saca una sonrisa
Los 3 milisegundos luz del final no pueden ser correctos porque son una distancia de ida
En 2007 trabajaba como técnico de soporte de segundo nivel para varios servicios en un ISP grande; ADSL todavía era común y, al estar basado en cobre, tenía una distancia máxima a la que podía funcionar de forma estable
Algunos clientes pagaban un plan especial para extender esa distancia unos 2 o 3 km más, pero en la práctica era bastante inestable y apenas servía para navegar un poco por la web
Un verano, un cliente consultó porque durante el día se le cortaba IPTV desde hacía casi un mes y a veces Internet se sentía lento como un glaciar. Al medir, vimos que estaba muy lejos de la central telefónica más cercana y concluimos que, durante los días calurosos, la línea se expandía y superaba apenas el límite de distancia, volviéndose inestable
Había muy poco que pudiéramos hacer, y no extraño las redes de cobre
Hace unos 15 o 20 años, cuando trabajaba en un taller de reparación, alguien trajo un televisor porque todos los días a las 5 de la tarde cambiaba a español
Veía televisión abierta, y en la configuración del televisor solo había idioma del menú, pero efectivamente a las 5 p. m. el audio del televisor cambiaba a español. Al mirar algunos canales más, casi todos estaban en español salvo uno o dos
Resultó que algunas emisoras transmiten audio en varios idiomas, y algunos televisores permiten cambiar el idioma preferido. Lamentablemente, el televisor usado que había comprado esa persona venía de un país hispanohablante, así que no había forma de cambiar esa preferencia
Hace unos días metí en casa una aspiradora robot fabricada y comprada en China, y apenas la encendí chocó contra el servidor y lo desenchufó
Así que no se puede descartar la posibilidad de un ciberataque patrocinado por un Estado
Es como la madre de todas las verdaderas abstracciones con fugas
En el momento de enviar un correo, quedó al descubierto el protocolo de transporte subyacente real del universo relativista
Justo hoy al mediodía hablé de Sendmail, y les aseguro que eso es bastante raro
Recordé cuando configuré Sendmail por primera vez, en 1991 o 1992; con el bat book pasé casi una semana arrancándome los pelos hasta lograr mi primera configuración
Más tarde llegué a entender y hasta a apreciar en cierta medida la configuración con m4, pero después de pasarme a qmail y postfix a mediados de los 90, nunca volví a mirar atrás
Creo que este texto debería marcarse como de 1997, no de 2002. Aunque parece que ni el propio Trey lo recuerda: https://www.ibiblio.org/harris/500milemail-faq.html
Publicaciones relacionadas. ¿Habrá más?
The case of the 500-mile email (2002) - https://news.ycombinator.com/item?id=29213064 - Nov 2021 (93 comentarios)
We can't send email more than 500 miles (2002) - https://news.ycombinator.com/item?id=23775404 - julio de 2020 (135 comentarios)
500 miles (2002) - https://news.ycombinator.com/item?id=18675375 - dic. de 2018 (32 comentarios)
The case of the 500-mile email (2002) - https://news.ycombinator.com/item?id=14676835 - julio de 2017 (56 comentarios)
The 500-mile email (2002) - https://news.ycombinator.com/item?id=9338708 - abril de 2015 (139 comentarios)
The case of the 500-mile email - https://news.ycombinator.com/item?id=2701063 - junio de 2011 (18 comentarios)
The case of the 500-mile email - https://news.ycombinator.com/item?id=1293652 - abril de 2010 (24 comentarios)
The case of the 500-mile email - https://news.ycombinator.com/item?id=385068 - dic. de 2008 (28 comentarios)
The case of the 500-mile email - https://news.ycombinator.com/item?id=123489 - feb. de 2008 (7 comentarios)