Executando verificação de segurança...
-5

🪲 O bug das 500 milhas

Decidi traduzir(ChatGPT 🙂) e compartilhar esta história que encontrei; é uma das histórias mais curiosas de um problema que já li. Créditos na fonte da postagem. Espero que gostem!


De: Trey Harris [email protected]

Aqui está um problema que parecia impossível... Eu quase lamento ter compartilhado a história com um público amplo, porque ela se torna uma ótima história para contar durante um happy hour em uma conferência. :-) A história foi ligeiramente alterada para proteger os culpados, omitir detalhes irrelevantes e chatos, e tornar o todo mais divertido.

Eu estava trabalhando em um emprego administrando o sistema de e-mail do campus alguns anos atrás quando recebi uma ligação do presidente do departamento de estatísticas.

"Estamos tendo um problema para enviar e-mails para fora do departamento."

"Qual é o problema?" Eu perguntei.

"Não podemos enviar e-mails a mais de 500 milhas", explicou o presidente.

Engasguei com meu café com leite. "Pode repetir?"

"Não podemos enviar e-mails a uma distância maior do que 500 milhas daqui", ele repetiu. "Um pouco mais, na verdade. Vamos chamar de 520 milhas. Mas não mais do que isso."

"Um... E-mail realmente não funciona dessa maneira, geralmente", eu disse, tentando manter o pânico fora da minha voz. Não se demonstra pânico ao falar com um presidente de departamento, mesmo que seja de um departamento relativamente empobrecido como estatísticas. "O que faz você pensar que não pode enviar e-mails a mais de 500 milhas?"

"Não é o que penso," respondeu o presidente com impaciência. "Você vê, quando percebemos isso acontecendo, alguns dias atrás..."

"Vocês esperaram alguns DIAS?" Eu interrompi, com um tremor na minha voz. "E vocês não conseguiram enviar e-mails durante todo esse tempo?"

"Nós conseguimos enviar e-mails. Só não mais do que..."

"--500 milhas, sim," eu terminei por ele, "Entendi isso. Mas por que vocês não ligaram mais cedo?"

"Bem, nós não tínhamos coletado dados suficientes para ter certeza do que estava acontecendo até agora." Certo. Este é o presidente de estatísticas. "De qualquer forma, pedi a uma das geoestatísticas para investigar..."

"Geoestatísticas..."

"--sim, e ela produziu um mapa mostrando o raio dentro do qual podemos enviar e-mails sendo um pouco mais de 500 milhas. Há vários destinos dentro desse raio que não podemos alcançar, ou alcançamos de forma esporádica, mas nunca conseguimos enviar e-mails mais longe do que esse raio."

"Entendi", eu disse e coloquei minha cabeça nas mãos. "Quando isso começou? Você disse alguns dias atrás, mas alguma coisa mudou em seus sistemas naquela época?"

"Bem, o consultor veio e atualizou nosso servidor e reiniciou-o. Mas eu o chamei e ele disse que não mexeu no sistema de e-mail."

"Ok, deixe-me dar uma olhada e eu vou ligar de volta", eu disse, mal acreditando que estava jogando junto. Não era Dia da Mentira. Tentei me lembrar se alguém me devia uma brincadeira.

Acessei o servidor do departamento e enviei alguns e-mails de teste. Isso estava no Triângulo de Pesquisa da Carolina do Norte, e um e-mail de teste para minha própria conta foi entregue sem problemas. O mesmo aconteceu com um enviado para Richmond, Atlanta e Washington. Outro para Princeton (400 milhas) funcionou.

Mas então eu tentei enviar um e-mail para Memphis (600 milhas). Falhou. Boston, falhou. Detroit, falhou. Peguei minha agenda de endereços e comecei a tentar encurtar isso. Nova York (420 milhas) funcionou, mas Providence (580 milhas) falhou.

Eu estava começando a me perguntar se tinha perdido a sanidade. Tentei enviar um e-mail para um amigo que morava na Carolina do Norte, mas cujo provedor de serviços de internet estava em Seattle. Felizmente, falhou. Se o problema tivesse a ver com a geografia do destinatário humano e não com seu servidor de e-mail, acho que teria desabado em lágrimas.

Tendo estabelecido que - incrivelmente - o problema relatado era verdadeiro e repetível, dei uma olhada no arquivo sendmail.cf. Parecia bastante normal. Na verdade, parecia familiar.

Eu comparei com o sendmail.cf no meu diretório pessoal. Não tinha sido alterado - era um sendmail.cf que eu tinha escrito. E eu tinha bastante certeza de que não tinha ativado a opção "FAIL_MAIL_OVER_500_MILES". Sem saber o que fazer, telnetei para a porta SMTP. O servidor respondeu feliz com um banner do Sendmail do SunOS.

Espere um minuto... um banner do Sendmail do SunOS? Na época, a Sun ainda estava enviando o Sendmail 5 com seu sistema operacional, embora o Sendmail 8 estivesse bastante maduro. Sendo um bom administrador de sistema, eu tinha padronizado no Sendmail 8. E também sendo um bom administrador de sistema, eu tinha escrito um sendmail.cf que usava as opções e variáveis longas e autoexplicativas disponíveis no Sendmail 8, em vez dos códigos de pontuação criptográficos que eram usados no Sendmail 5.

As peças se encaixaram de uma vez, e eu engasguei novamente com o resto do meu latte agora frio. Quando o consultor "atualizou o servidor", ele aparentemente fez um upgrade na versão do SunOS e, ao fazer isso, rebaixou o Sendmail. A atualização deixou o sendmail.cf intacto, mesmo que agora fosse a versão errada.

Acontece que o Sendmail 5 - pelo menos a versão que a Sun enviava, que tinha algumas alterações - conseguia lidar com o sendmail.cf do Sendmail 8, já que a maioria das regras naquele ponto permanecera inalterada. Mas as novas opções de configuração longas - essas ele via como lixo e ignorava. E o binário do sendmail não tinha valores padrão compilados para a maioria delas, então, não encontrando configurações adequadas no arquivo sendmail.cf, elas foram definidas como zero.

Uma das configurações que foi definida como zero era o tempo limite para se conectar ao servidor SMTP remoto. Alguma experimentação estabeleceu que, nesta máquina em particular com sua carga típica, um tempo limite zero abortaria uma chamada de conexão em pouco mais de três milissegundos.

Um recurso estranho de nossa rede no campus na época era que ela era 100% comutada. Um pacote de saída não sofreria um atraso do roteador até atingir o POP e chegar a um roteador no lado oposto. Portanto, o tempo para se conectar a um host remoto com carga leve em uma rede próxima realmente seria governado principalmente pela distância da velocidade da luz até o destino, em vez de atrasos incidentais do roteador.

Sentindo-me um pouco tonto, digitei no meu shell:

$ units
1311 units, 63 prefixes

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

"500 milhas, ou um pouco mais."

Trey Harris


Agradeço por ter chegado até aqui! Não se esqueça de verificar o post original na fonte abaixo.

Carregando publicação patrocinada...
2
1

O usuário muitas vezes é leigo, e sua explicação do problema foi até bastante detalhada, mas deixou a sacada escondida em uma constatação maluca.

Uma história com um título excelente😂! Também é muito boa, obrigado por compartilhar.

2

A primeira vez que eu ouvi essa história foi por um vídeo do Filipe: O Mistério do Email Que Não Ultrapassava 800km de Distância (História Incrível).

Tem certos bugs que realmente são complexos de descobrir o motivo, e um que eu tenho acompanhado é o problema de desempenho no React Native (aparentemente surgiu na versão 0.68). Essa issue já está com mais de 120 comentários, e apesar da equipe do React Native estar participando, ninguém ainda conseguiu encontrar a causa raiz do problema.

1