Resumo

  • O SMTP original oferecia VRFY e EXPN como instrumentos de diagnóstico. Uma resposta positiva podia revelar uma caixa postal ou enumerar todos os integrantes de uma lista.
  • O código 252 criou um terceiro estado honesto: o servidor não verifica o usuário, mas pode aceitar a mensagem e tentar entregá-la. Exposição de diretório, responsabilidade de transporte e entrega final passam a ser fatos diferentes.

Quando o servidor de e-mail respondia como um diretório

A RFC 821 descreveu uma conversa concreta. O cliente enviava VRFY Smith; o servidor podia responder 250 com o nome completo de Fred Smith e sua caixa postal. Se conhecesse um encaminhamento, indicava o novo destino. Se o nome não correspondesse a ninguém, informava a falha. Se houvesse mais de um Smith, devia responder 553 User ambiguous.

O comando vizinho EXPN abria ainda mais o diretório. Dado o nome de uma lista, uma resposta positiva em várias linhas podia enumerar suas caixas postais, uma por linha. A especificação não tratava os dados como meras sugestões: um sucesso de VRFY tinha de incluir a caixa do usuário; um sucesso de EXPN, os endereços da lista. Conhecimento local se transformava em evidência protocolar disponível a um interlocutor remoto.

Isso resolvia problemas reais. Um nome digitado errado podia ser descoberto antes do envio. Um encaminhamento ficava visível. Expansões aninhadas podiam ser seguidas até um ciclo. Como diretório e entrega dependiam do mesmo conhecimento, manter a consulta no SMTP parecia eficiente.

O custo oculto era deixar a janela de diagnóstico no mesmo serviço que escutava a Internet inteira.

A resposta útil ganhou outro público

Em 1989, a RFC 1123 tornou VRFY obrigatório no receptor e recomendou EXPN, mas permitiu que uma instalação desativasse ambos ou fechasse listas específicas. O texto registrou a tensão: administradores recorriam aos comandos para entender falhas de entrega e ciclos em listas multinível, enquanto a expansão podia expor privacidade e segurança.

Com o spam, a interface passou a servir a outro objetivo. VRFY testava nomes prováveis; EXPN convertia um identificador conhecido em muitos endereços. A RFC 2505 recomendou que o MTA controlasse os solicitantes por chave geral ou listas de acesso. Para VRFY bloqueado ou desligado, 252 deveria ser a resposta padrão; EXPN deveria começar desligado.

O diagnóstico não perdeu sua legitimidade. O que mudou foi a necessidade de distinguir quem pergunta. Um administrador que audita encaminhamentos internos e um coletor anônimo conseguem enviar os mesmos caracteres. O direito à resposta nasce da identidade e do escopo administrativo, não da sintaxe do comando.

Uma terceira resposta verdadeira

Com apenas “sim” e “não”, o servidor seria forçado a inventar conhecimento. Responder 250 após verificar somente a sintaxe fabrica uma confirmação. Responder sempre 550 fabrica uma inexistência. A RFC 5321 considera os dois comportamentos incompatíveis com a norma.

252 escapa dessa falsa escolha: “Não é possível VRFY o usuário, mas a mensagem será aceita e a entrega será tentada”. Isso não prova que a caixa existe. Não garante que um futuro RCPT TO será aceito em qualquer contexto. Muito menos confirma que a mensagem chegou a uma pessoa. A resposta apenas recusa a afirmação de diretório e mantém aberta a rotina normal de transporte.

Um MX que recebe por outro domínio pode reconhecer a sintaxe e saber que atende aquele domínio, sem ter acesso instantâneo ao cadastro final de caixas. 252 conserva o limite do que ele sabe, em vez de converter plausibilidade em certeza.

A política de segurança usa a mesma semântica. A RFC 5321 exige 252 quando um site desativa os comandos por segurança, evitando um código confundível com verificação positiva ou negativa. Não revelar não é afirmar ausência.

Verificar, aceitar e entregar geram registros distintos

Sistemas de e-mail frequentemente comprimem estados próximos. Sintaxe válida vira “endereço verificado”. Um 250 em um salto vira “entregue”. Consulta bloqueada vira “caixa inválida”. Cada atalho amplia a autoridade de uma observação parcial.

Ao menos três fatos precisam permanecer separados. Verificação de diretório indica que o servidor realmente confirmou uma caixa ou expansão. Aceite transacional registra que uma máquina assumiu responsabilidade em determinado ponto. Entrega final depende de roteamento posterior, filas, encaminhamentos e processamento do destinatário. 252 fica deliberadamente antes desses resultados.

Por isso, um painel não deve convertê-lo em selo verde de verificação nem em invalidez definitiva. O estado correto é incerteza explícita com uma rota de transporte possível. Uma transação posterior poderá acrescentar evidência; a consulta não pode antecipá-la.

Fechar uma janela pode deixar outra aberta

Desativar VRFY não elimina todo sinal sobre destinatários. A RFC 5321 observa que respostas a RCPT às vezes fornecem a mesma informação. Em outros sistemas, a validação é adiada até depois de DATA, e RCPT quase nada revela. O ganho de segurança depende de toda a cadeia de aceite.

Logo, não basta declarar vitória porque um verbo retorna 252. A política remove a consulta mais barata e direta, mas tempos de resposta, códigos diferentes, domínios pega-tudo, rejeições posteriores e relatórios de entrega ainda podem produzir pistas. A superfície composta precisa ser medida.

Também não vale o argumento inverso. A existência de outros métodos de coleta não justifica EXPN público. Retirar a rota mais barata e autoritativa aumenta o custo e reduz a confiança do coletor. Segurança muitas vezes significa controlar preço e qualidade da evidência, não prometer segredo absoluto.

O diagnóstico sobreviveu dentro de uma fronteira

A RFC 5321 preserva um papel para os dois comandos. Usuários autenticados e administradores dentro do mesmo domínio podem auditar rotas, detectar encaminhamento automático de mensagens sensíveis e examinar listas. Um site pode restringi-los a solicitantes autenticados. A capacidade permanece; o suposto direito do anônimo desaparece.

O registro SMTP atual da IANA conserva outra fronteira. O suporte a VRFY continua obrigatório em servidores, mas sua aparição na lista EHLO é opcional. VRFY e EXPN aparecem como MUST NOT para Message Submission. Autenticar-se para enviar o próprio correio não concede acesso automático ao diretório do recebedor.

O SMTP não aprendeu a evitar a pergunta com mentira ou silêncio total. Aprendeu a responder uma pergunta menor com precisão. O servidor podia recusar a certificação de uma pessoa, manter a possibilidade de transportar a mensagem e reservar o diagnóstico rico a uma relação que o justificasse. Em um protocolo construído de respostas, 252 limitou aquilo que uma resposta tinha autoridade para dizer que sabia.

Fontes