Le phénomène des e-mails impossibles à envoyer à plus de 500 miles (2002)

 (web.mit.edu)
2 points par GN⁺ 2023-09-20 | 1 commentaires | Partager sur WhatsApp
  • Sur le serveur de messagerie du département de statistique d’une université, il est devenu à partir d’un certain moment impossible d’envoyer des e-mails vers des destinations situées à plus de 500 à 520 miles environ, et le problème se reproduisait selon un rayon géographique
  • Le directeur du département a rassemblé des données pendant plusieurs jours puis a demandé à un géostatisticien de les analyser, en cartographiant le rayon atteignable ainsi que les destinations exceptionnelles à l’intérieur de ce rayon
  • Les tests de l’administrateur ont montré que, depuis le Research Triangle en Caroline du Nord, Richmond, Atlanta, Washington, Princeton et New York fonctionnaient, tandis que Memphis, Boston, Detroit et Providence échouaient, révélant que le critère était l’emplacement du serveur de messagerie, et non celui du destinataire
  • La cause venait d’une mise à jour du serveur : pendant le patch, SunOS a été mis à niveau, ce qui a en pratique rétrogradé Sendmail 8 vers Sendmail 5, et Sendmail 5 a ignoré les longs noms de configuration du sendmail.cf conçu pour Sendmail 8
  • Résultat : le délai d’expiration de connexion a été réglé à 0, et sur cette machine la connexion était coupée au bout d’environ 3 millisecondes, ce qui correspondait, selon le calcul units, à une valeur observée d’environ 559 miles

Signalement : « les mails ne partent pas au-delà de 500 miles »

  • Alors qu’il administrait le système de messagerie du campus, l’auteur a été contacté par le directeur du département de statistique, qui lui a indiqué qu’il y avait « un problème pour envoyer des e-mails en dehors du département »
  • Le cœur du problème était qu’« il était impossible d’envoyer du courrier à plus de 500 miles d’ici », le directeur ajoutant que la limite réelle était « un peu plus loin, autour de 520 miles »
  • L’administrateur a répondu que le courrier électronique ne fonctionnait normalement pas comme cela, mais le directeur l’appelait après avoir accumulé suffisamment de données pendant plusieurs jours
  • Le département de statistique a demandé à un géostatisticien de vérifier, et a produit une carte montrant que la zone d’envoi possible formait un rayon légèrement supérieur à 500 miles
    • Même à l’intérieur de ce rayon, certaines destinations étaient injoignables ou seulement atteignables de façon intermittente
    • Au-delà de ce rayon, les e-mails n’étaient jamais délivrés
  • Au même moment, un consultant avait patché puis redémarré le serveur, tout en affirmant n’avoir pas touché au système de messagerie

Tests de reproduction et frontière géographique

  • Quand l’administrateur s’est connecté au serveur du département pour envoyer des e-mails de test, le problème s’est avéré réellement reproductible
  • L’emplacement était alors le Research Triangle de Caroline du Nord, et les destinations proches fonctionnaient normalement
    • Les e-mails de test envoyés vers son propre compte arrivaient correctement
    • Les messages envoyés vers Richmond, Atlanta et Washington aboutissaient aussi
    • Le test jusqu’à Princeton, à environ 400 miles, passait également
  • Les destinations plus lointaines continuaient à échouer
    • Memphis, à environ 600 miles : échec
    • Boston : échec
    • Detroit : échec
    • New York, à environ 420 miles : succès
    • Providence, à environ 580 miles : échec
  • Un e-mail envoyé au compte d’un ami vivant en Caroline du Nord a échoué, car le FAI de ce compte se trouvait à Seattle
    • Cela a confirmé que le problème n’était pas lié à la position réelle de la personne, mais à la position géographique du serveur de messagerie

Une configuration Sendmail qui semblait normale

  • Le fichier sendmail.cf paraissait globalement normal, et il était identique à celui que l’administrateur avait rédigé auparavant
  • L’administrateur a conclu qu’il n’avait jamais activé une option du type FAIL_MAIL_OVER_500_MILES
  • En se connectant en telnet au port SMTP, le serveur renvoyait une bannière sendmail SunOS
  • À l’époque, Sun distribuait Sendmail 5 avec son système d’exploitation, alors que Sendmail 8 était déjà bien mature
  • L’administrateur avait standardisé l’infrastructure sur Sendmail 8 et utilisait un sendmail.cf reposant sur les longs noms d’options et de variables auto-explicatifs de Sendmail 8
    • Sendmail 5 utilisait au contraire un ancien style de configuration, fondé sur une syntaxe ésotérique centrée sur la ponctuation

Une mise à niveau qui a créé une rétrogradation

  • En « patchant » le serveur, le consultant a mis à jour la version de SunOS et, au passage, Sendmail a été ramené à Sendmail 5
  • La mise à niveau du système d’exploitation a conservé le sendmail.cf existant, mais ce fichier n’était désormais plus compatible avec la version de Sendmail réellement exécutée
  • La version de Sendmail 5 distribuée par Sun pouvait traiter un grand nombre de règles du sendmail.cf prévu pour Sendmail 8
    • À l’époque, la plupart des règles n’avaient pas beaucoup changé
  • Le problème venait des longues options de configuration de Sendmail 8, que Sendmail 5 considérait comme des valeurs parasites et ignorait
  • Comme la plupart des valeurs par défaut de ces options n’étaient pas compilées dans le binaire Sendmail, et qu’aucune valeur valide n’était trouvée dans le fichier de configuration, elles se retrouvaient au final réglées à 0

Un timeout de 3 millisecondes et 558 miles

  • L’une des valeurs passées à 0 était le délai d’expiration de connexion utilisé pour se connecter à un serveur SMTP distant
  • Les expériences ont montré que, sur cette machine et sous une charge normale, un timeout à 0 interrompait l’appel connect au bout d’un peu plus de 3 millisecondes
  • À l’époque, le réseau du campus était entièrement commuté
    • Les paquets sortants ne subissaient pas de délai de routeur avant d’atteindre le POP et de rencontrer le routeur distant
    • Pour se connecter à des hôtes distants peu chargés sur des réseaux proches, le temps de connexion dépendait davantage de la distance liée à la vitesse de la lumière que des délais supplémentaires dus aux routeurs
  • Quand l’administrateur a converti 3 millilightseconds en miles avec units, il a obtenu 558.84719 miles
  • Le « 500 miles, ou un peu plus » évoqué par le directeur correspondait donc presque exactement au résultat du calcul

À lire aussi

1 commentaires

 
GN⁺ 2023-09-20
Avis de Hacker News

  • En 1998, quand je faisais du support IT dans une petite entreprise en Australie, un employé d’un bureau distant a appelé en disant que « l’économiseur d’écran était tombé du moniteur, avait appuyé sur une touche du clavier et le terminal s’était verrouillé ».
    Au début, j’ai pensé que ça n’avait aucun sens, mais il s’est avéré qu’il appelait « économiseur d’écran » un filtre anti-reflets CRT physique, courant à l’époque, et que ce filtre était tombé en maintenant Scroll Lock enfoncée.
    https://dylbs6e8mhm2w.cloudfront.net/productimages/500x500/E...

  • J’aime ce genre d’histoires. Il y a ce moment où l’on découvre qu’un phénomène dont on était sûr qu’il ne pouvait absolument pas se produire est en fait causé par des lois physiques, comme la vitesse de la lumière.
    Dans l’un de mes premiers emplois, j’ai eu un problème de très léger scintillement sur un moniteur CRT ; même en remplaçant le moniteur, le câble, le cordon d’alimentation et l’ordinateur, rien ne changeait.
    Finalement, on a mis l’ordinateur et l’écran sur un chariot et on les a sortis dans le couloir : le problème a disparu. La cause était un mauvais blindage électrique dans ce bureau.

    • Un Commodore 64 s’est mis à « taper » tout seul, et on l’a envoyé deux fois en réparation, mais chez le réparateur il fonctionnait toujours normalement.
      On a découvert plus tard que l’arrivée d’un téléviseur plus grand, placé trop près, provoquait une accumulation d’électricité statique qui produisait cet effet. Le temps qu’il arrive chez le réparateur, il s’était sans doute suffisamment déchargé pour fonctionner correctement pendant un moment.
    • Ça me rappelle un utilisateur « maudit » que j’aidais au milieu des années 90.
      On lui avait vendu un ordinateur, et il disait qu’il affichait un écran bleu quand il l’utilisait ; quand on le rapportait pour le tester, aucun problème, et même en l’utilisant avec lui pendant 30 minutes au bureau, tout allait bien.
      Mais dès que cette personne touchait la souris, l’ordinateur affichait un écran bleu, et le remplacement de la souris a fait disparaître le problème.
    • Dans un labo, tous les ordinateurs avaient un stabilisateur de tension, mais ils étaient de si mauvaise qualité qu’ils faisaient probablement plus de mal que de bien.
      Quand quelqu’un allumait un stabilisateur, les moniteurs CRT à proximité se déformaient brièvement, scintillaient et les couleurs se dégradaient. Les postes près du mur étaient moins touchés, mais les maux de tête étaient sévères ; je n’ai tenu que six mois dans cette entreprise.
    • Ça me fait penser à l’interrupteur « magique » du MIT AI Lab : http://www.catb.org/jargon/html/magic-story.html

  • Le meilleur dans cette histoire, c’est que le consultant qui a patché le serveur est sur Hacker News.
    Il a laissé ici un commentaire sur la partie dont il s’était occupé : https://news.ycombinator.com/item?id=23775404

    • J’avais oublié ça. La partie pertinente du fil commence ici : https://news.ycombinator.com/item?id=23777700
      Je l’ai aussi mis dans /highlights pour ceux que ça intéresse : https://news.ycombinator.com/highlights
    • L’article dit que le consultant a patché puis redémarré le serveur, mais qu’il n’a pas touché au système mail ; dans le commentaire, il est dit que, puisque la réinitialisation suivie d’une réinstallation n’a pas été acceptée, il a évidemment fait une mise à jour de sendmail.
      C’est probablement à cela que correspond le passage disant que « l’histoire a été légèrement modifiée pour protéger les coupables ».

  • Cette histoire remonte tous les quelques années, et elle me fait sourire à chaque fois.

    • Elle me fait penser aussi à celle de la voiture qui ne démarre pas après avoir acheté de la glace à la vanille.
    • Je pense que cette histoire aurait été meilleure si elle avait gardé les vrais chiffres. On dirait qu’on y a ajouté de faux nombres plus tard ; peut-être que personne ne les avait notés, ou que les vrais ont été oubliés.
      Les 3 millisecondes-lumière à la fin ne peuvent pas être correctes, puisqu’il s’agit d’une distance aller simple.
    • Il y a sans doute quelqu’un qui s’est mis un rappel annuel pour la poster et récolter du karma. Peut-être même que c’est déjà le cas.
    • Il semble que le moment soit venu, une fois de plus, de raconter cette histoire à la génération suivante.

  • En 2007, quand je travaillais chez un grand FAI comme technicien support de niveau 2 pour plusieurs services, l’ADSL était encore très répandu et, comme il reposait sur des lignes en cuivre, il y avait une distance maximale à partir de laquelle il pouvait fonctionner de façon stable.
    Certains clients avaient une offre spéciale qui essayait d’étendre cette distance d’environ 2 à 3 km, mais en pratique c’était assez instable et à peine suffisant pour un peu de navigation web.
    Un été, un client nous a signalé que son IPTV se coupait pendant la journée depuis près d’un mois et qu’Internet devenait parfois lent comme un glacier. Les mesures ont montré qu’il était très loin du central téléphonique le plus proche, et nous avons conclu que, lors des chaudes journées, la ligne se dilatait et dépassait légèrement la limite de distance, ce qui la rendait instable.
    Il n’y avait presque rien à faire pour l’aider, et le réseau cuivre ne me manque pas.

    • Est-ce que mieux isoler le câble entre le poteau téléphonique et la maison aurait aidé ?

  • Il y a 15 à 20 ans, quand je travaillais dans un atelier de réparation, quelqu’un a apporté une télé en disant qu’à 17 h tous les jours, elle passait en espagnol.
    Il regardait la télévision hertzienne, et dans les réglages il n’y avait que la langue des menus, mais effectivement, à 17 h, le son de la télé passait en espagnol. En regardant quelques chaînes de plus, on a vu qu’elles étaient presque toutes en espagnol, sauf une ou deux.
    Il s’est avéré que certaines chaînes diffusaient l’audio en plusieurs langues, et que certains téléviseurs permettaient de changer la langue préférée. Malheureusement, le téléviseur d’occasion qu’il avait acheté venait d’un pays hispanophone, et il n’y avait aucun moyen de modifier cette préférence.

    • Mon enceinte Bluetooth est passée en chinois après quelques années d’utilisation. Je ne sais pas comment c’est arrivé, ni comment revenir en arrière, et ce n’est pas dans le manuel.
      Il y a quelques jours, j’ai fait entrer chez moi un aspirateur robot fabriqué et acheté en Chine ; dès son premier allumage, il a foncé dans le serveur et l’a débranché.
      Je ne peux donc pas exclure la possibilité d’une cyberattaque par un acteur étatique.
    • Quelle était la cause du basculement à 17 h ?

  • C’est vraiment un cas qui pourrait être la mère de toutes les abstractions qui fuient.
    Au moment d’envoyer un e-mail, le protocole de transport sous-jacent réel de l’univers relativiste s’est révélé.

  • Justement, à midi aujourd’hui, on parlait de Sendmail, et je peux vous garantir que ce n’est pas très fréquent.
    Je me suis souvenu de la première fois où j’ai configuré Sendmail, en 1991 ou 1992, et d’une semaine passée à m’arracher les cheveux avec le bat book pour réussir ma première configuration.
    Plus tard, j’ai fini par comprendre la configuration m4 et même par l’apprécier dans une certaine mesure, mais après être passé à qmail et postfix au milieu des années 90, je ne me suis jamais retourné.

  • Ce genre de texte devrait sans doute être daté de 1997 plutôt que de 2002. Cela dit, Trey lui-même ne semble pas s’en souvenir : https://www.ibiblio.org/harris/500milemail-faq.html

  • Articles connexes. Y en a-t-il d’autres ?
    The case of the 500-mile email (2002) - https://news.ycombinator.com/item?id=29213064 - nov. 2021 (93 commentaires)
    We can't send email more than 500 miles (2002) - https://news.ycombinator.com/item?id=23775404 - juillet 2020 (135 commentaires)
    500 miles (2002) - https://news.ycombinator.com/item?id=18675375 - déc. 2018 (32 commentaires)
    The case of the 500-mile email (2002) - https://news.ycombinator.com/item?id=14676835 - juillet 2017 (56 commentaires)
    The 500-mile email (2002) - https://news.ycombinator.com/item?id=9338708 - avril 2015 (139 commentaires)
    The case of the 500-mile email - https://news.ycombinator.com/item?id=2701063 - juin 2011 (18 commentaires)
    The case of the 500-mile email - https://news.ycombinator.com/item?id=1293652 - avril 2010 (24 commentaires)
    The case of the 500-mile email - https://news.ycombinator.com/item?id=385068 - déc. 2008 (28 commentaires)
    The case of the 500-mile email - https://news.ycombinator.com/item?id=123489 - févr. 2008 (7 commentaires)

    • Les soumissions avec le même lien cessent-elles d’être « reliées » entre elles au bout d’environ un an ?
    • Existe-t-il un script qui fait ce travail à la place ?