Resumo

  • Segundo o relato publicado por Eric Allman em 1994, o trabalho principal no Sendmail parou depois de fevereiro de 1987 e foi retomado em julho de 1991, quando variantes de fornecedores e colaboradores já haviam se acumulado.
  • Allman apontou vários motivos para voltar: mudanças na Berkeley, versões divergentes e extensões SMTP que, em sua avaliação, não chegavam à maioria das implementações.
  • O Sendmail 8.6.6 oferecia algumas extensões e tinha limitações em outras. Uma versão pública tornou esse limite verificável, mas não provou adoção nem conformidade integral.

Uma pausa longa virou um problema de versões

O Sendmail já fazia parte do ambiente Unix da Berkeley antes de se tornar produto de uma empresa ou símbolo nas discussões sobre a economia do software aberto. A biografia da Internet Hall of Fame diz que Eric Allman desenvolveu delivermail e Sendmail na Universidade da Califórnia em Berkeley enquanto trabalhava no INGRES; os dois foram distribuídos com o BSD. Esse contexto ajuda a explicar a importância do código público: quem montava sistemas podia examinar e compilar o roteador de e-mail em seu próprio ambiente.

O artigo de Allman de 1994, “Changes in Sendmail Version 8”, detalha o período seguinte. O trabalho principal no Sendmail praticamente parou depois de fevereiro de 1987 e só foi retomado ativamente em julho de 1991. Outras pessoas mantiveram um suporte mínimo nesse intervalo, enquanto fornecedores e colaboradores externos criaram variantes. Allman cita várias razões para voltar: a Berkeley precisava de mudanças de correio para sua estrutura de subdomínios e para o 4.4BSD; ele havia resenhado o livro Sendmail, de Bryan Costales; as versões divergentes precisavam ser reunidas; e os padrões SMTP haviam mudado.

Foi uma combinação de motivos, não uma conversão causada por um único fator. O código precisava acompanhar uma nova versão do BSD, reconciliar ramificações e responder à evolução do protocolo. Allman escreveu que o IDA-Sendmail havia passado de arquivos de configuração para um conjunto considerável de patches e era muito usado por pessoas que compilavam o próprio código-fonte. Ele também afirmou que o grupo IDA e a maioria dos fornecedores não estavam incorporando as novas clarificações e extensões SMTP. Essa é a avaliação retrospectiva dele em 1994, não um levantamento independente de todos os fornecedores ou instalações.

A distinção importa. Um padrão pode ser publicado enquanto o software efetivamente executado preserva pressupostos antigos. Quando a implementação é privada, fragmentada ou difícil de obter, o operador pode não ter um caminho prático entre o documento e uma substituição que consiga testar. Uma versão pública pode reduzir essa distância ao tornar mudanças e limitações visíveis. Ela não obriga um fornecedor a entregar a atualização, um administrador a instalá-la nem um servidor remoto a aceitá-la.

A versão 8 deixou os limites explícitos

Allman usa o Sendmail 8.6.6 para mostrar que compatibilidade não é uma propriedade binária. O artigo descreve o ESMTP básico do RFC 1425, a extensão de tamanho de mensagem do RFC 1427 e o suporte limitado ao parâmetro BODY do RFC 1426. Também diz que essa versão não anunciava 8BITMIME e não convertia corretamente uma mensagem para um par SMTP sem suporte a dados de 8 bits.

Esses detalhes são mais precisos do que dizer que “o Sendmail 8 suportava os novos padrões SMTP”. Eles vinculam recursos a uma versão concreta. O RFC 1425 define a troca de capacidades ESMTP por EHLO; o RFC 1427 define SIZE; o RFC 1426 descreve a extensão BODY associada mais tarde ao 8BITMIME. O que o par anuncia, a escolha do remetente e o comportamento do destinatário afetam a transferência. O artigo não mostra quando as instalações fizeram a atualização nem com que frequência esses caminhos apareciam em produção.

Outra página de mudanças do Sendmail Version 8 descreve o software como “condicionalmente conforme” ao RFC 1123 e relaciona tanto os requisitos atendidos quanto as ressalvas. Essa página cita números de RFC de extensões posteriores aos discutidos no artigo de 1994. Os dois registros não devem ser misturados em uma lista única de recursos. Juntos, mostram que uma afirmação de conformidade precisa indicar versão, especificação e exceções.

A contribuição de Allman, portanto, não foi apenas lançar um novo número de versão principal. Seu artigo tornou o limite da implementação legível: qual extensão estava presente, qual era parcial e onde a conversão ainda falhava. O salto para a versão 8 teve uma explicação prosaica: os arquivos da distribuição 4.4BSD já eram numerados como 8.1. Isso não significava que todos os problemas de protocolo tivessem sido resolvidos.

O código público deu aos operadores algo que podiam verificar

A Nota 65 de Heng Lu oferece uma lente editorial útil: uma norma publicada e o código em execução respondem a perguntas diferentes. A nota não é evidência sobre as motivações de Allman nem sobre a história do Sendmail. Aqui, a distinção é prática. Um padrão diz o que os sistemas deveriam conseguir fazer; uma versão de código-fonte permite examinar uma implementação; um teste e uma troca real mostram o que um par específico de sistemas fez.

O código público também distribui o trabalho. Os mantenedores podem publicar uma mudança comum, os fornecedores podem incorporar patches e os operadores podem comparar o comportamento local com o código disponível. Ao mesmo tempo, diferenças de configuração, patches privados e pacotes antigos podem manter a divergência após a publicação. Tornar o código público cria uma opção de inspeção e reparo; não elimina o custo da manutenção.

A conclusão deve ser delimitada. No relato de Allman, a pausa do Sendmail ampliou a distância entre documentos SMTP em evolução e implementações acessíveis a muitos usuários. A versão 8 ofereceu uma referência pública e incorporou algumas extensões recentes, mas o exemplo da 8.6.6 também registra limites claros. Nem a publicação de um padrão nem a do código provam implantação universal. A pergunta útil é se o operador consegue identificar a versão exata, testar seu comportamento e escolher um caminho mantido quando a implementação não atende.

Fontes