Resumo

  • A RFC 1425 criou em EHLO um ponto comum para descobrir extensões SMTP. A resposta positiva descrevia apenas a sessão presente e não podia ser armazenada para a seguinte.
  • O recuo pressupunha que o servidor antigo rejeitaria EHLO, preservaria conexão e estado e deixaria o cliente voltar a HELO. A RFC 1651 documentou implementações que desconectavam ou recusavam a segunda saudação.
  • Extensão registrada, capacidade anunciada, recuo executável, comando aceito, transação concluída e entrega são evidências separadas.

Fazer o correio eletrônico evoluir sem uma migração mundial coordenada exigia uma forma de testar o futuro e ainda conversar com o passado.

SMTP havia se espalhado por manter o diálogo simples: conexão, saudação, HELO, envelope e conteúdo. Em 1993, novas necessidades pressionavam esse formato. Negociações improvisadas para cada recurso poderiam transformar uma língua comum em dialetos privados.

A RFC 1425 definiu um núcleo pequeno. O cliente estendido começava com EHLO; o servidor anunciava palavras-chave registradas e parâmetros; cada extensão mantinha sua semântica em RFC própria. O padrão coordenava descoberta, não decretava adoção.

A promessa valia por uma sessão

O cliente que precisasse das capacidades estendidas deveria enviar EHLO no início de cada sessão SMTP. A informação obtida num sucesso não podia ser colocada em cache.

Assim, uma observação antiga não virava atributo permanente. O mesmo nome de host poderia apontar para processo, configuração, rota ou estado de manutenção diferentes. A declaração precisava nascer dentro do canal em que seria usada.

Uma resposta 250 bem-sucedida também indicava estado inicial: nenhuma transação estava ativa, tabelas e buffers estavam limpos. As linhas seguintes podiam enumerar palavras-chave. As públicas sem X correspondiam a extensões registradas; o prefixo X marcava acordos locais segundo a convenção daquele período.

O anúncio não era execução. O cliente ainda escolheria uma extensão, enviaria a sintaxe definida para ela e receberia a resposta daquela operação.

A RFC 1426 mostra a ordem: encontrar 8BITMIME na resposta a EHLO; depois pedir BODY=8BITMIME em MAIL FROM; só depois, com aceite, transmitir DATA. A mecânica dos oito bits não pertence a este artigo. A separação entre anúncio e uso, sim.

O caminho elegante dependia do estado real

Um cliente novo ainda precisava falar com um servidor limitado à RFC 821. Pela RFC 1425, o servidor desconheceria EHLO, retornaria erro e manteria o canal. O cliente poderia redefinir o estado ou usar HELO e prosseguir pelo SMTP antigo.

Era uma compatibilidade sem punição: recusar a novidade apenas selecionava o menor conjunto comum.

Mas a seta do diagrama escondia condições. O canal deveria continuar aberto. O comando desconhecido não poderia corromper o autômato. RSET e HELO precisariam chegar ao estado previsto.

O texto definia o comportamento válido. Não comprovava que o software instalado o executava.

A revisão trouxe o chão de fábrica

Em julho de 1994, a RFC 1651 substituiu a RFC 1425 e incluiu uma seção sobre servidores implementados incorretamente.

Alguns fechavam o canal SMTP ao receber EHLO, antes ou depois de responder. Isso contrariava a regra da RFC 821 de fechar normalmente após QUIT, mas citar a regra não preservava a conexão.

O cliente passou a ter de observar o próprio canal. Se houvesse fechamento, deveria decidir se a operação podia terminar sem extensões. Em caso positivo, abriria outra conexão e usaria HELO. A nova tentativa não era continuidade: tinha novo canal, novo estado e novo resultado.

Outros servidores permaneciam conectados, mas recusavam HELO depois de rejeitar EHLO. Inserir RSET resolvia alguns casos. Ainda assim, várias implementações devolviam 503 Bad sequence of commands ao reset; a RFC permitia ignorar esse código no contexto estreito da recuperação.

A RFC 1869, de 1995, preservou a advertência. A incompatibilidade observada ganhou lugar na memória da norma.

Isso não diminui o valor da especificação. A revisão separou o que o estado deveria ser do que o parque instalado fazia. Código em operação corrigiu a descrição do caminho.

“Recuo bem-sucedido” pode conter duas conexões

Um resumo desse tipo apaga a sequência.

Conectar, receber 220, enviar EHLO, obter resposta ou fechamento, enviar RSET, tentar HELO, aceitar envelope, aceitar DATA, assumir custódia e entregar são eventos diferentes. O sucesso no segundo canal não restaura o primeiro. Uma palavra-chave não garante seu comando. Aceitar conteúdo não comprova leitura.

A proibição do cache protege exatamente esse limite. Capacidade não era etiqueta permanente de inventário. Era afirmação localizada numa sessão. Quando o canal acabava, o contexto também acabava.

A camada fina transferiu a dívida

A RFC 1425 advertiu que protocolos com poucas opções tendem à ubiquidade, enquanto opções demais tendem à obscuridade. Manteve pequena a superfície comum e entregou os detalhes a RFCs separadas.

Servidores antigos não precisavam de uma virada simultânea. Clientes interessados em alcance amplo absorviam respostas multilinha, capacidade vencida, fechamento, reconexão e exceções.

O registro dava significado à palavra, não instalava a função. O servidor escolhia o que executar; o cliente escolhia o caminho compatível anunciado. A adoção era local. A interoperabilidade precisava acontecer no fio.

O desenho inicia a investigação. A sessão observada decide se a seta existiu.