Resumo

  • A RFC 1204 recomendava 250 para um USER sintaticamente correto mesmo quando o posting server não reconhecia o nome. A resposta evitava enumeração; não confirmava a existência da conta.
  • PASS 250 representava outra decisão: a senha tinha sido verificada como associada ao nome anterior. DATA 354 abria a entrada do texto e o 250 após o corpo comprovava apenas a fila local.
  • NOOP 250 descrevia a condição interna da sessão no servidor de postagem. O código isolado não distingue privacidade, autenticação, custódia nem saúde operacional.

A resposta uniforme protegia um inventário invisível

A RFC 1204 foi publicada em fevereiro de 1991 para propor um Message Posting Protocol entre PCs e um host de correio. No comando USER, o cliente informava o nome de quem pretendia submeter uma mensagem. A lista de respostas dizia que 250 aceitava o username.

Logo depois, o documento retirava a interpretação mais óbvia. Se o nome tivesse sintaxe correta, o servidor deveria responder 250 mesmo sem reconhecê-lo. Assim o cliente não poderia perguntar, por tentativa, quais usuários existiam na base.

Uma conta cadastrada e uma conta ausente compartilhavam a mesma aparência externa. A incerteza era deliberada. O posting server aceitava o argumento como passo da conversa, mas não divulgava o resultado da pesquisa no cadastro. Um painel que transforme esse evento em “conta válida” converte proteção contra enumeração em vazamento.

O registro do RFC Editor confirma sua classificação Experimental. O IETF Datatracker hoje o apresenta como RFC do fluxo Legacy, anterior ao registro de fonte formal, sem endosso do IETF nem posição formal no processo atual. A fonte prova o desenho proposto; não prova adoção, escala ou recomendação presente.

O agente local ficava entre o PC e a entrega

O diagnóstico original dizia que sistemas operacionais de computadores pessoais não ofereciam autenticação de usuário, embora o correio precisasse reduzir falsificação de remetente. A solução era um agente no host de serviço: o message posting server autenticaria a pessoa que usava o PC e enviaria a mensagem ao sistema de entrega, como Sendmail ou MMDF, em seu nome.

Esse intermediário possuía só parte da cadeia. O cliente apresentava nomes, senha e mensagem. O posting server controlava a verificação local e a fila. O delivery system controlava a tentativa posterior. Netix MPP usava TCP na porta 218 e aproveitava a estrutura de comandos e replies de SMTP e FTP.

A RFC 821 descrevia o SMTP em etapas: um comando, uma resposta, a próxima ação. RFC 1204 reutilizou DATA, o terminador com ponto e códigos familiares, mas aplicou-os ao limite entre estação de trabalho e agente de postagem. A herança da sintaxe não tornou os significados universais.

A associação com a senha era uma segunda decisão

Depois de USER 250, o protocolo permitia PASS. Nesse contexto, 250 afirmava que a senha fora aceita e verificada como corretamente associada ao username fornecido antes. Uma relação incorreta produzia 530; erros de forma, sequência ou servidor tinham respostas próprias.

O primeiro sucesso escondia reconhecimento. O segundo registrava comparação de credenciais. Preservar a diferença era necessário para obter duas coisas ao mesmo tempo: não publicar o catálogo de usuários e ainda exigir uma prova secreta antes de receber a mensagem.

Mesmo o segundo resultado não era identidade civil, autoria ou permissão geral. Ele pertencia ao banco de credenciais e à política do servidor. Não dizia quem estava fisicamente diante do PC, se o conteúdo era verdadeiro ou se qualquer destinatário devia aceitá-lo.

Muito depois, a RFC 4954 definiu SMTP AUTH com negociação SASL e respostas específicas. Também exigiu que uma implementação pudesse proibir mecanismos de senha em texto claro quando não houvesse TLS ou proteção equivalente. Essa norma posterior não deve ser lida para dentro de MPP. Ela delimita os mecanismos de segurança que RFC 1204 não forneceu.

Preparar a entrada não significava possuir o corpo

Com a senha aceita, DATA podia receber 354. A resposta mudava o estado do parser: o servidor estava pronto para tratar os próximos octetos como mensagem. Ainda faltavam o conteúdo completo e o terminador.

Depois que o cliente terminava o texto, outro 250 assumia um terceiro papel. Agora significava que a mensagem fora colocada com sucesso na fila de entrega. Se uma falha interna impedisse a fila, 451 informava que o objeto não tinha sido enfileirado.

A fila produzia evidência de custódia local. Não produzia entrega. A RFC orientava o posting server a tentar submeter rapidamente as mensagens aceitas ao delivery system. Em seguida, atribuía ao sistema de entrega o tratamento de falhas e dizia que o posting server não deveria interferir.

Essa divisão impede que a fila fale pelo próximo componente. Ela não prova relay, armazenamento no mailbox, apresentação no aplicativo, leitura nem efeito institucional. O agente podia concluir corretamente seu trabalho sem observar o fim da viagem.

Até a luz de saúde usava 250

NOOP não executava ação sobre uma mensagem. Seu 250 dizia apenas que o posting server não tinha encontrado erro interno na sessão. Nada ali testava o delivery system.

Em quatro contextos, a mesma sequência de dígitos podia representar:

  • nome bem formado, com reconhecimento deliberadamente oculto;
  • senha verificada contra o nome anterior;
  • corpo completo sob custódia da fila local;
  • servidor de postagem sem erro interno conhecido na sessão.

Guardar apenas 250/sucesso apaga o objeto e a autoridade. O registro útil precisa do protocolo, conexão, comando, ordem, estado anterior e posterior, componente que respondeu e fato que ele tinha competência para observar.

O padrão posterior de submission preservou a separação

A RFC 6409 formalizou message submission na porta 587. Um Message Submission Agent aceita mensagens do programa do usuário e pode entregá-las ou encaminhá-las a um Message Transfer Agent. A separação permite políticas e segurança diferentes para submissão e relay.

Essa comparação não prova descendência direta nem sobrevivência do protocolo Netix. Ela apenas mostra por que os papéis precisam ter nomes. O componente que conhece a credencial e recebe a mensagem pode não conhecer a entrega. Seu 250 continua verdadeiro justamente porque é menor que uma promessa de ponta a ponta.

A contribuição histórica de RFC 1204 está nessa precisão. Em vez de responder toda pergunta cedo demais, ela escondia a existência da conta no primeiro passo, fazia uma verificação separada, distinguia abertura do corpo de custódia e entregava o resultado posterior a outro sistema.

Fontes