- O servidor de e-mail do departamento de estatística de uma universidade, a partir de certo momento, passou a não conseguir enviar e-mails para destinos a mais de cerca de 500 a 520 milhas de distância, e o problema podia ser reproduzido por raio geográfico
- O chefe do departamento reuniu dados por vários dias e pediu a um geoestatístico que os analisasse, mapeando o raio alcançável e os destinos excepcionais dentro desse raio
- Nos testes do administrador, a partir do Research Triangle, na Carolina do Norte, Richmond, Atlanta, Washington, Princeton e New York funcionavam, mas Memphis, Boston, Detroit e Providence falhavam, revelando que o critério era a localização do servidor de e-mail, não a do destinatário
- A causa foi que, durante um patch no servidor, o SunOS foi atualizado e o Sendmail 8 acabou sendo efetivamente rebaixado para Sendmail 5, enquanto o Sendmail 5 ignorava os nomes longos de configuração do
sendmail.cfexistente, feito para Sendmail 8 - Como resultado, o timeout de conexão foi definido como 0 e, nessa máquina, a conexão era encerrada após cerca de 3 milissegundos, o que batia com a observação de aproximadamente 559 milhas no cálculo com
units
Relato de que “o e-mail não vai além de 500 milhas”
- Enquanto operava o sistema de e-mail do campus, o administrador foi contatado pelo chefe do departamento de estatística, dizendo que “havia um problema para enviar e-mail para fora do departamento”
- O ponto central do problema era que “não dava para enviar e-mail daqui para lugares a mais de 500 milhas”, e o chefe acrescentou que o limite real era “um pouco mais, cerca de 520 milhas”
- O administrador respondeu que e-mail normalmente não funciona desse jeito, mas o chefe do departamento já o procurava depois de reunir dados suficientes ao longo de vários dias
- O departamento de estatística pediu a um geoestatístico que verificasse o caso, e ele produziu um mapa mostrando que a área para a qual era possível enviar e-mail formava um raio um pouco maior que 500 milhas
- Mesmo dentro do raio, havia destinos que não eram alcançáveis ou só eram alcançados de forma intermitente
- Fora do raio, os e-mails jamais eram entregues
- Na mesma época, um consultor havia aplicado patches no servidor e o reiniciado, mas afirmou que não tinha mexido no sistema de e-mail
Testes de reprodução e limite geográfico
- Quando o administrador entrou no servidor do departamento e enviou e-mails de teste, o problema realmente era reproduzível
- A localização na época era o Research Triangle, na Carolina do Norte, e os destinos próximos funcionavam normalmente
- O e-mail de teste enviado para a própria conta dele foi entregue normalmente
- Os e-mails enviados para Richmond, Atlanta e Washington também tiveram sucesso
- O teste até Princeton, a cerca de 400 milhas, também passou
- Os destinos mais distantes continuavam falhando
- Memphis, cerca de 600 milhas, falhou
- Boston falhou
- Detroit falhou
- New York, cerca de 420 milhas, funcionou
- Providence, cerca de 580 milhas, falhou
- Um e-mail enviado para a conta de um amigo que morava na Carolina do Norte falhou, porque o ISP dessa conta ficava em Seattle
- Confirmou-se que o problema estava ligado à localização geográfica do servidor de e-mail, e não à localização real da pessoa
Uma configuração do Sendmail que parecia normal
- O arquivo
sendmail.cfparecia, em geral, normal, e era idêntico ao que o administrador havia escrito antes - O administrador concluiu que nunca havia ativado alguma opção como
FAIL_MAIL_OVER_500_MILES - Ao acessar a porta SMTP com
telnet, o servidor retornou um banner do sendmail do SunOS - Na época, a Sun distribuía o sistema operacional com Sendmail 5 incluído, embora o Sendmail 8 já estivesse bem maduro
- O administrador havia padronizado tudo em Sendmail 8 e escrevia um
sendmail.cfusando os nomes longos e autoexplicativos de opções e variáveis do Sendmail 8- O Sendmail 5 usava o estilo mais antigo, parecido com código cifrado cheio de pontuação, para a configuração
O upgrade que criou um downgrade
- Ao “aplicar patch” no servidor, o consultor elevou a versão do SunOS e, nesse processo, o Sendmail acabou voltando para o Sendmail 5
- O upgrade do sistema operacional manteve o
sendmail.cfexistente, mas ele passou a ser incompatível com a versão do Sendmail em execução - A versão de Sendmail 5 distribuída pela Sun ainda conseguia processar muitas regras de um
sendmail.cffeito para Sendmail 8- Na época, a maioria das regras ainda não tinha mudado tanto
- O problema eram as opções longas de configuração do Sendmail 8, que o Sendmail 5 via como lixo e simplesmente ignorava
- No binário do Sendmail, os valores padrão da maioria dessas opções não estavam compilados e, como o programa também não os encontrava no arquivo de configuração, o resultado final era que ficavam definidos como 0
Timeout de 3 milissegundos e 558 milhas
- Um dos valores definidos como 0 era o timeout de conexão usado ao se conectar a um servidor SMTP remoto
- Em experimentos, nessa máquina e sob condições normais de carga, um timeout de 0 fazia a chamada
connectser interrompida após pouco mais de 3 milissegundos - A rede do campus, na época, era 100% comutada
- Os pacotes que saíam para fora não sofriam atraso de roteador até chegarem ao POP e encontrarem o roteador do outro lado
- O tempo de conexão com hosts remotos pouco carregados em redes próximas era mais afetado pela distância na velocidade da luz do que por atrasos incidentais de roteadores
- Quando o administrador converteu
3 millilightsecondsemmilesnounits, o resultado foi 558.84719 milhas - A observação do chefe do departamento — “500 milhas, ou um pouco mais” — batia quase exatamente com o valor calculado
1 comentários
Comentários no Hacker News
Em 1998, quando eu trabalhava com suporte de TI em uma pequena empresa na Austrália, um funcionário de um escritório remoto ligou dizendo que “o protetor de tela caiu do monitor, apertou uma tecla do teclado e o terminal travou”
No começo achei que não fazia sentido, mas descobri que ele chamava de “protetor de tela” aquele filtro físico antirreflexo para CRT, comum na época, e que o filtro tinha caído e deixado a tecla Scroll Lock pressionada
https://dylbs6e8mhm2w.cloudfront.net/productimages/500x500/E...
Gosto desse tipo de coisa. Há momentos em que você descobre que um fenômeno do qual tinha certeza de que jamais poderia acontecer na verdade ocorre por causa de leis físicas, como a velocidade da luz
Em um dos meus primeiros empregos, tive um problema em que um monitor CRT piscava sutilmente; mesmo trocando monitor, cabo, cabo de energia e computador, continuava igual
Por fim, colocamos o computador e o monitor em um carrinho e os levamos para o corredor, e o problema desapareceu; a causa era blindagem elétrica ruim naquele escritório
Mais tarde, descobriu-se que o efeito era causado pelo acúmulo de eletricidade estática porque uma TV maior tinha sido colocada perto demais. Ao chegar à assistência, ele provavelmente já tinha descarregado o suficiente para funcionar bem por um tempo
Vendemos um computador para ele, mas ele dizia que dava tela azul ao usar; quando o trazíamos para testar, não havia problema nenhum, e usando juntos no escritório por 30 minutos também ficava tudo bem
Mas, no instante em que ele tocava no mouse, o computador dava tela azul, e o problema desapareceu com a troca do mouse
Quando alguém ligava um estabilizador, os monitores CRT por perto distorciam por um instante, piscavam e perdiam qualidade de cor. Os lugares junto à parede eram menos afetados, mas as dores de cabeça eram fortes, e só aguentei 6 meses naquela empresa
A melhor parte dessa história é que o consultor que aplicou o patch no servidor está no Hacker News
Ele comentou aqui sobre a parte pela qual foi responsável: https://news.ycombinator.com/item?id=23775404
Também coloquei em
/highlightspara quem tiver interesse: https://news.ycombinator.com/highlightsTalvez seja essa a parte em que “a história foi levemente alterada para proteger os culpados”
A cada poucos anos essa história aparece de novo, e sempre me faz sorrir
Os 3 milissegundos-luz no final não podem estar certos, porque são uma distância só de ida
Em 2007, quando eu trabalhava como técnico de suporte de segundo nível para vários serviços em um grande ISP, ADSL ainda era comum e, por ser baseado em fios de cobre, havia uma distância máxima em que podia funcionar de forma estável
Alguns clientes usavam um plano especial que tentava estender essa distância em uns 2 a 3 km, mas na prática era bastante instável e mal dava para navegar na web
Em um verão, um cliente entrou em contato dizendo que a IPTV caía durante o dia havia quase um mês e que a internet às vezes ficava lenta como uma geleira. Medindo, vimos que ele ficava muito longe da central telefônica mais próxima, e concluímos que, nas tardes quentes, os fios se expandiam e passavam ligeiramente do limite de distância, causando instabilidade
Havia pouquíssimo que pudéssemos fazer, e não sinto saudade da rede de cobre
Cerca de 15 a 20 anos atrás, quando eu trabalhava em uma assistência, uma pessoa trouxe uma TV dizendo que todos os dias às 17h ela mudava para espanhol
Ela assistia TV aberta, e nas configurações da TV só havia idioma do menu, mas, de fato, às 17h o áudio da TV mudava para espanhol. Depois de olhar mais alguns canais, quase todos estavam em espanhol, exceto um ou dois
Descobrimos que algumas emissoras transmitiam áudio em vários idiomas, e algumas TVs permitiam mudar o idioma preferido. Infelizmente, a TV usada que a pessoa comprou era de um país de língua espanhola, e não havia como alterar essa preferência
Alguns dias atrás, coloquei em casa um robô aspirador fabricado e comprado na China e, assim que foi ligado pela primeira vez, ele bateu no servidor e arrancou o cabo de energia
Portanto, não dá para descartar a possibilidade de um ataque cibernético patrocinado por Estado
É o tipo de caso que parece a mãe de todas as verdadeiras abstrações vazantes
No momento em que você tenta enviar um e-mail, o protocolo de transporte subjacente real do universo relativístico aparece
Por acaso, hoje no almoço eu falei de Sendmail, e garanto que isso é bem raro
Lembrei da primeira vez que configurei o Sendmail, em 1991 ou 1992, e de como passei uma semana praticamente arrancando os cabelos com o bat book até finalmente conseguir fazer a primeira configuração funcionar
Mais tarde entendi a configuração em m4 e passei a respeitá-la em certa medida, mas, depois que migrei para qmail e postfix em meados dos anos 90, nunca mais olhei para trás
Acho que um texto como este deveria ser marcado como de 1997, não de 2002. Mas parece que nem o próprio Trey se lembra: https://www.ibiblio.org/harris/500milemail-faq.html
Textos relacionados. Será que há mais?
The case of the 500-mile email (2002) - https://news.ycombinator.com/item?id=29213064 - nov. 2021 (93 comentários)
We can't send email more than 500 miles (2002) - https://news.ycombinator.com/item?id=23775404 - jul. 2020 (135 comentários)
500 miles (2002) - https://news.ycombinator.com/item?id=18675375 - dez. 2018 (32 comentários)
The case of the 500-mile email (2002) - https://news.ycombinator.com/item?id=14676835 - jul. 2017 (56 comentários)
The 500-mile email (2002) - https://news.ycombinator.com/item?id=9338708 - abr. 2015 (139 comentários)
The case of the 500-mile email - https://news.ycombinator.com/item?id=2701063 - jun. 2011 (18 comentários)
The case of the 500-mile email - https://news.ycombinator.com/item?id=1293652 - abr. 2010 (24 comentários)
The case of the 500-mile email - https://news.ycombinator.com/item?id=385068 - dez. 2008 (28 comentários)
The case of the 500-mile email - https://news.ycombinator.com/item?id=123489 - fev. 2008 (7 comentários)