Em meados dos anos 90, houve um famoso incidente em que um administrador de e-mails de uma universidade dos Estados Unidos recebeu o telefonema de um professor que estava reclamando que seu departamento só podia enviar e-mails para até 800 quilômetros de distância.

O professor explicou que sempre que tentavam mandar um e-mail para alguém mais distante, os envios falhavam, parecia bobagem, mas estava acontecendo de verdade.

Para entender o motivo, você precisa primeiro saber que a velocidade da luz realmente tem mais impacto sobre como a internet funciona do que se imagina. No caso do e-mail, o tempo limite para conexões foi definido para cerca de 6 milissegundos.

Se fizer as contas, é o tempo aproximado que a luz leva para viajar 800 quilômetros.

De maneira simplista, o tempo que leva para uma conexão de rede transferir seus dados à distância é chamado de latência, e a latência tem muitos papéis aqui.

A latência é um dos principais problemas que afeta a velocidade da Web e foi um dos principais motivos pelos quais a Google começou a inventar o HTTP/2.

Sem mais delongas, segue a conversa original da história postada publicamente:

E-mail De [email protected] Sex Nov 29 18:00:49 2002

Assunto: O caso dos e-mails de 800 quilômetros (era RE: [SAGE] Tarefa impossível favorita?)

Aqui está um problema que parece impossível… Eu quase me arrependo de postar tal história para um público tão amplo, porque parece um caso contado em um grupo de bêbados. :-) A história foi um pouco alterada para proteger o culpado, omitir detalhes irrelevantes e chatos, e de modo geral, tornar a coisa toda mais divertida.

Eu trabalhava administrando o sistema de e-mails do campus alguns anos atrás, quando recebi uma ligação do chefe do departamento de estatística.

— Estamos com problemas para enviar e-mails para fora do departamento.

— Qual é o problema? — perguntei.

— Não podemos enviar e-mails para mais longe que 800 quilômetros — explicou o chefe de departamento.

Eu engasguei com meu café com leite.

— Pode repetir?

— Não conseguimos enviar e-mails para distâncias acima de 800 quilômetros daqui. — repetiu ele. — Um pouco mais, na verdade. Digamos 835 quilômetros. Mas não mais longe.

— Hum… E-mails não costumam funcionar assim. — eu disse, tentando manter o pânico fora da minha voz. Não se demonstra pânico quando se fala com um chefe de departamento, mesmo de um departamento um tanto empobrecido como o de estatística. — O que faz você achar que não pode enviar e-mails para mais de 800 quilômetros?

— Eu não acho. — respondeu o chefe com irritação. — Veja, quando notamos que isso estava acontecendo há alguns dias…

— Você esperou alguns DIAS? — eu interrompi, um leve tremor na voz. — E não conseguiu enviar e-mail esse tempo todo?

— Conseguimos enviar e-mails. Apenas não foi possível para distâncias acima de…

— … 800 quilômetros, sim. — terminei por ele — Eu entendi. Mas por que você não ligou antes?

— Bem, nós não havíamos coletado dados suficientes para ter certeza do que estava acontecendo até agora.

Certo. Este é o chefe do departamento de “Estatística”.

— De qualquer maneira, eu pedi para um dos Geoestatísticos dar uma olhada…

— Geoestatísticos…

—… sim, e ela elaborou um mapa que mostra o raio dentro do qual podemos enviar um e-mail, um pouco mais de 800 quilômetros. Existem inúmeros destinatários dentro desse raio que não podemos contatar, ou contatar apenas de vez em quando, mas nunca conseguimos enviar e-mails para além desse raio.

— Entendo. — eu disse, e coloquei a cabeça entre as mãos. — Quando isso começou? Há alguns dias segundo você, mas alguma coisa foi modificada em seus sistemas nessa época?

— Bem, o especialista veio e fez correções no nosso servidor e o reiniciou. Mas liguei para ele que disse que não tocou no sistema de e-mails.

— Certo, vou dar uma olhada, e depois ligo de volta. — falei, mal acreditando que eu estava entrando no jogo. Não era primeiro de abril. Tentei me lembrar se alguém me devia uma pegadinha.

Entrei no servidor do departamento e enviei alguns e-mails de teste. Isso tudo aconteceu no Triângulo de Pesquisa da Carolina do Norte, e uma mensagem teste para meu próprio endereço foi entregue sem problemas. Idem para uma enviada para Richmond, e Atlanta e Washington. Outro para Princeton (640 quilômetros) chegou.

Mas, em seguida, tentei enviar para Memphis (965 quilômetros). Falhou. Boston falhou. Detroit falhou. Peguei minha lista de e-mails e comecei a tentar limitar o problema. Nova York (675 quilômetros) recebeu, mas Providence (930 quilômetros) falhou.

Estava começando a me perguntar se estava ficando louco. Tentei enviar um e-mail para amigo que morava na Carolina do Norte, mas cujo ISP estava em Seattle. Felizmente, falhou. Se o problema tivesse a ver com a geografia do destinatário humano e não seu servidor de e-mail, eu acho que teria chorado.

Tendo estabelecido que, por mais inacreditável que seja, o problema relatado era verdadeiro, e recorrente. Dei uma olhada no arquivo sendmail.cf. Parecia bastante normal. Na verdade, parecia familiar.

Eu o comparei ao arquivo sendmail.cf no meu diretório residente. Não tinha sido alterado, era o sendmail.cf que eu havia escrito. E eu estava bastante certo de que eu não havia ativado a opção “FAIL_MAIL_OVER_500_MILES”. Perdido, eu emulei a porta SMTP via telnet. O servidor respondeu “alegremente” com um banner do Sendmail do SunOS.

Espere um minuto… um banner do Sendmail do SunOS? Na época, a Sun ainda enviava o Sendmail 5 com seu sistema operacional, embora o Sendmail 8 já estivesse bastante aperfeiçoado. Sendo um bom administrador de sistemas, eu tinha padronizado o Sendmail 8. E também por ser um bom administrador de sistemas, eu escrevi um sendmail.cf que usava a opção de autodocumentar sempre nomes variáveis disponíveis no Sendmail 8 em vez dos códigos encriptados utilizados no Sendmail 5.

As peças se encaixaram de uma só vez, e eu de novo engasguei com os resquícios do meu café com leite já gelado. Quando o especialista “corrigiu o servidor”, ele ao que parecia, atualizou a versão do SunOS, e ao fazê-lo “rebaixou” a versão do Sendmail. A atualização deixou o sendmail.cf intacto, embora agora fosse a versão errada.

Acontece que o Sendmail 5, pelo menos, a versão que a Sun enviava, que tinha alguns ajustes – poderia lidar com o sendmail.cf do Sendmail 8, já que a maioria das disposições nesse sentido permaneceu inalterada. Mas as novas e intermináveis opções de configuração, aquelas consideradas lixo, foram ignoradas. E o binário do Sendmail não possuía nenhum padrão elaborado para a maioria destes, portanto, ao não encontrar qualquer configuração adequada no arquivo sendmail.cf, a configuração foi acertada em zero.

Uma das configurações definidas como zero foi o tempo limite para se conectar ao servidor SMTP remoto. Alguma experimentação estabeleceu que nesta máquina em particular, em seu carregamento típico, um tempo limite zero interromperia a conexão em pouco mais de três milissegundos.

Uma característica ímpar da nossa rede no campus na época era que ela era 100% comutada. Um pacote de saída não incorreria em um atraso do roteador até atingir o POP e chegar a um roteador do outro lado. Então, o tempo de conexão com um host remoto de carregamento leve em uma rede próxima seria em grande parte governado pela razão velocidade da luz x distância até o destinatário, em vez de atrasos casuais do roteador.

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

$ units
1311 units, 63 prefixos
Você tem: 3 milissegundos-luz
Você quer: milhas
* 558.84719
/ 0,0017893979
“500 milhas, 800km, ou um pouco mais.”

FAQ com respostas sobre os e-mails de 800 quilômetros

Além do documento público, o autor ainda criou um FAQ com as toneladas de dúvidas que recebeu; segue principais respostas traduzidas.

Isso de fato aconteceu, ou estava apenas inventando uma história?

Sim, aconteceu. Na época, eu administrava o sistema centralizado de e-mails do campus, Isis, na Universidade da Carolina do Norte em Chapel Hill. Eu fui informalmente responsável por alguns aspectos dos sistemas de correio eletrônico em departamentos que optaram por executar seus próprios sistemas independentes.

O mais importante para esta história, é que eu escrevi os arquivos sendmail.cf (Configuração Sendmail) que foram usados ​​na maioria dos servidores de e-mail do campus.

Quando foi isso?

Entre 1994 e 1997. Quando o Sendmail 8 estava “bastante aperfeiçoado”, mas a Sun ainda enviava o Sendmail 5? Eric Allman mencionou em uma conversa pessoal que o Sendmail 5 em questão pode ter feito backport de recursos do Sendmail V8, de modo que podemos restringir. Se você tiver algum dado que possa ajudar a estabelecer um cronograma, eu agradeceria se compartilhasse.

Esse tempo de três milissegundos não faz sentido como tempo limite para uma chamada de conexão

É, eu sei. E não era o tempo limite de verdade. Na história, parece que foram necessários apenas dez minutos para tomar conhecimento do limite de 800 quilômetros para os e-mails e identificar o problema com os 3 milissegundos-luz.

Na verdade, essa identificação levou várias horas e um bom trabalho de detetive. O ponto é, no fim, eu cheguei a esse valor, calculei as units e engasguei com meu café com leite. (Tenho certeza de que era um café diferente daquele com o qual eu comecei.)

O Sendmail 5 não aceitaria um arquivo cf Sendmail 8.

Mas aceitou. Me disseram que o Sendmail 5 disponível na internet não teria aceitado. Portanto, sou forçado a concluir que o arquivo enviado pela Sun junto ao Solaris sofreu modificações para permitir isso.

Conclusão

Não importa o quão absurdo seja, sempre dê um pouco de crêdito ao usuário que relata problemas que normalmente julgamos impossíveis!