Resumo

  • A revisão de agosto de 1982 definiu SMTP como uma conversa confiável em fluxo, capaz de retransmitir e-mail mesmo quando as pontas não compartilhavam o mesmo serviço de transporte.
  • MAIL informava o caminho de retorno e RCPT um ou mais caminhos de destinatário; a RFC 822 tratava à parte do formato textual, portanto uma sessão aceita não prova que a mensagem chegou à caixa ou foi lida.

Um e-mail pode cruzar uma fronteira de rede sem que o texto da mensagem saiba por onde passou. Esse é o problema de projeto visível no Simple Mail Transfer Protocol que Jonathan B. Postel publicou em agosto de 1982. A RFC 821 não exigia um subsistema específico de transmissão. Exigia um fluxo confiável e ordenado e definia como processos SMTP trocariam comandos e respostas nesse canal.

O relé fazia parte do modelo. Se o host de origem e o destino compartilhassem um serviço de transporte, o emissor poderia alcançar diretamente o SMTP receptor. Caso contrário, um ou mais servidores intermediários poderiam ligar ambientes de transporte distintos. Postel foi preciso sobre a escala: um serviço podia cobrir uma rede, várias redes ou apenas parte de uma delas. “Rede” e “ambiente de transporte” não eram caixas equivalentes.

A transação tornava a transferência observável. O emissor abria um canal bidirecional e o receptor respondia. MAIL iniciava a transação com um caminho reverso, útil para retornar avisos de não entrega. Cada RCPT indicava um caminho de destinatário e podia se repetir. Depois, DATA levava a mensagem. Os códigos numéricos mostravam se cada comando fora aceito. O envelope SMTP carregava instruções de entrega diferentes do texto apresentado ao leitor.

A RFC 822, publicada no mesmo mês, ajuda a separar as funções. Ela padronizou o formato das mensagens de texto da ARPA Internet; a RFC 821 descreveu a conversa de transferência. O cabeçalho From: pertencia à representação da mensagem, enquanto MAIL FROM era parte da transação SMTP. Confundi-los transforma um endereço escrito no texto em suposta prova de rota ou de decisão de entrega, algo que as especificações não garantem.

A RFC 821 era uma revisão, não a certidão de nascimento do SMTP. Seu cabeçalho substitui as RFCs 788, 780 e 772; a RFC 788, de novembro de 1981, já especificava SMTP. O plano de transição RFC 801 menciona o serviço no contexto da mudança de rede, mas não fornece números de adoção nem mede a entrega ao usuário. A data de uma revisão não informa quando todos os hosts a implementaram.

O modelo tampouco era exclusivo do TCP. Os apêndices da RFC 821 descrevem serviços como NCP, TCP e NITS; o apêndice de TCP atribui ao SMTP o socket 25. Isso concretiza o protocolo sem fazer de uma porta aberta prova de serviço ativo. Ainda são necessários um processo receptor em funcionamento, comandos aceitos, caminhos válidos, conclusão de DATA e tratamento local depois do canal.

A contribuição histórica foi uma fronteira de serviço reutilizável. SMTP definiu uma conversa comum para mover e-mail e permitiu que relés conectassem ambientes de transporte diferentes; formato do texto e comportamento da caixa local continuaram sendo questões distintas. Pela lente da Nota 64 de Heng Lu, o desenho mostra como uma especificação comum pode cobrir a interoperabilidade necessária e deixar transporte e implantação para os sistemas que a executam. Essa é uma interpretação posterior, não uma afirmação sobre a intenção de Postel.

Sources