Resumo

  • O RFC 821 oferecia três comandos opcionais que faziam da apresentação no terminal, do depósito na caixa ou de ambos uma semântica da transação SMTP.
  • O sucesso variava: SEND dependia do terminal, SOML aceitava qualquer um dos destinos e SAML dependia da caixa mesmo quando também tentava a tela.
  • Um MX podia conhecer o caminho do correio sem controlar o terminal do usuário; versões posteriores do SMTP tornaram esses comandos obsoletos e mantiveram apenas compatibilidade estreita.

Escolher o tipo de chegada antes do conteúdo

Em um host compartilhado de 1982, o destinatário podia estar conectado e disposto a receber mensagens diretamente no terminal. O cliente SMTP remoto abria a sessão e, em vez de começar com MAIL, escolhia entre três verbos.

SEND exigia entrega ao terminal. Se o usuário estivesse inativo ou recusasse esse tipo de mensagem, o servidor podia responder com falha temporária para o destinatário. SOML, Send Or MaiL, tentava o terminal e recorria à caixa postal quando ele não estivesse disponível. SAML, Send And MaiL, tentava a tela e, em qualquer caso, armazenava uma cópia na caixa.

No RFC 821, não eram preferências decorativas. Cada comando iniciava a transação antes de RCPT e DATA. O remetente escolhia a natureza da entrega antes de apresentar os destinatários e o corpo.

O protocolo, portanto, precisava lidar com presença, consentimento para interrupção e duas formas de resultado: uma aparição transitória e uma cópia guardada.

Cada verbo dava outro sentido ao sucesso

SEND só tinha sucesso quando os dados chegavam ao terminal; não criava automaticamente uma cópia na caixa. Em SOML, terminal e caixa eram alternativas e qualquer uma bastava. Em SAML, a caixa era obrigatória e a tela adicional; o critério de sucesso era o depósito durável.

Assim, um SEND aceito podia não deixar registro persistente. Um SOML aceito podia não revelar qual caminho terminou. Um SAML aceito comprovava a caixa, não que o usuário tinha visto a apresentação.

A gramática distinguia atenção de custódia com surpreendente clareza. A tensão estava na autoridade: o remetente escolhia o verbo, enquanto o destinatário sofria a interrupção e o servidor receptor carregava a obrigação técnica.

Presença não era atributo do endereço

O RFC 821 condicionava a entrega no terminal ao usuário estar ativo naquele host e aceitar mensagens de terminal. Esses fatos pertenciam a uma sessão local e a um instante, não ao endereço de e-mail.

O endereço permanecia igual quando a pessoa saía, mudava de máquina ou bloqueava interrupções. A rota continuava válida quando o host receptor já não controlava a interface interativa. Até dentro de uma transação, o estado podia mudar entre a resposta a RCPT e o fim de DATA.

O cliente tinha poder para pedir SEND, não para declarar o destinatário presente. A publicidade do comando em EHLO demonstrava que o servidor conhecia a sintaxe; não demonstrava disponibilidade nem consentimento individual.

O MX separou encaminhamento de apresentação

O RFC 1123 tornou opcional implementar os três comandos, tanto no remetente quanto no receptor. A discussão sobre MX expôs a fratura.

Um Mail Exchanger podia aceitar em nome de um domínio e saber como encaminhar a mensagem, sem poder escrever diretamente no terminal do usuário. Diante de um destinatário após SEND, podia responder 251 User Not Local e alertar para possível atraso.

Havia duas alcançabilidades. A de rota permitia assumir e continuar o correio. A de apresentação exigia controle da sessão em que o usuário estava ativo. Um relay podia ter a primeira sem a segunda.

O armazenamento e encaminhamento distribuídos transferiam responsabilidade pelo conteúdo. Não distribuíam, por si sós, poder sobre a atenção humana.

EHLO descobria gramática, não gente

Ao introduzir extensões SMTP, o RFC 1425 incluiu os comandos como serviços opcionais no registro inicial e usou seus nomes como palavras-chave EHLO.

Isso permitia saber se o servidor reconhecia o verbo. Não informava se o destinatário estava conectado, se aceitava interrupções, se aquele era o host final ou se a exibição ocorreria.

Uma capacidade técnica pode virar um botão verde e, depois, uma promessa indevida. EHLO anunciava uma linguagem implementada. Não era um serviço de presença.

A compatibilidade ficou; a autoridade diminuiu

Em 2001, o RFC 2821 já chamava SEND, SAML e SOML de obsoletos. Eles tinham sido raramente implementados, e mudanças nas estações de trabalho e a chegada de outros protocolos podiam tê-los tornado desnecessários.

O padrão não apagou clientes antigos. Clientes não deveriam oferecer os serviços; servidores ainda podiam implementá-los, desde que respeitassem o modelo do RFC 821 e anunciassem os nomes em EHLO.

O RFC 5321 conserva esse acordo. Os verbos antigos continuam reconhecíveis, mas o SMTP comum se organiza em torno de MAIL e da transferência formal de responsabilidade quando o servidor aceita os dados.

Essa custódia é auditável: aceitar implica continuar a entrega ou comunicar falha. Não exige afirmar que alguém olhou para uma tela em determinado segundo. A obsolescência reduziu o alcance da promessa sem quebrar toda compatibilidade.

IANA registra palavras, não presença

Os registros SMTP da IANA ainda contêm SEND, SOML e SAML, a referência ao RFC 821, a observação de obsolescência e a regra MUST NOT para Message Submission.

O registro preserva vocabulário interoperável. Não mede uso atual, configuração de destinatário ou sucesso de exibição. Uma linha de registro não devolve ao transporte o conhecimento social que o comando pressupunha.

Capacidade, presença, consentimento, apresentação, armazenamento e responsabilidade são fatos separados. O SMTP inicial reuniu vários deles na escolha da transação. O SMTP posterior não resolveu a atenção humana; deixou de prometê-la como parte central do transporte.

Chegar primeiro não era chegar melhor

Os comandos eram razoáveis em um conjunto pequeno de hosts próximos. SOML fornecia uma alternativa elegante; SAML mantinha a cópia durável. Os projetistas reconheceram uma diferença real entre mostrar e guardar.

A escala mudou a camada adequada. Com relays, estações heterogêneas e agentes de usuário independentes, o transporte podia controlar filas e custódia, mas não a tela atual nem a vontade de ser interrompido.

Uma tela pode acender imediatamente e não deixar vestígio. Uma caixa silenciosa pode ser aberta depois e conservar uma obrigação. A mensagem que chegou antes da caixa venceu o tempo; não necessariamente encontrou um lugar para ficar.

Fontes