Resumo

  • 251 encerra positivamente o destinatário original e transfere ao servidor a obrigação de encaminhar; 551 rejeita esse destinatário e deixa a nova tentativa ou a falha com o cliente.
  • Um servidor pode preservar a mesma responsabilidade sem expor o destino: 250 para encaminhamento silencioso e 550 para recusa sem endereço substituto.
  • A rota corrigida não autentica a pessoa nem renomeia a identidade. Escrevê-la em contatos futuros exige origem confiável e outra autorização.

A diferença estava antes do texto

Dois servidores recebem o mesmo RCPT TO obsoleto. Ambos sabem para onde o usuário se mudou. A resposta 251 pertence à classe de sucesso: o servidor aceitou a responsabilidade pelo destinatário e fará o restante. 551 pertence à classe de falha permanente: ele não aceitou, mesmo quando a frase contém uma alternativa.

Se um cliente enxergar apenas “endereço mudou”, abre duas falhas. Reenviar após 251 pode produzir duplicidade, pois a primeira cópia já está sob custódia. Encerrar como sucesso após 551 abandona uma mensagem que ninguém assumiu. O caminho novo informa; o código distribui trabalho.

A escolha original do SMTP

RFC 821 definiu os dois resultados em 1982. Quando o forward-path estava errado, mas o SMTP receptor sabia o destino, host, usuário ou ambos podiam ser corrigidos.

251 User not local; will forward oferecia o caminho para uso futuro e declarava que o receptor assumira a entrega atual. 551 User not local; please try recusava o usuário; o emissor precisava redirecionar conforme a informação ou devolver erro ao originador.

A especificação não criou um comando de mudança de nome. Criou uma bifurcação de custódia no passo do destinatário. O cliente podia respeitar a transação sem alterar uma única linha da agenda.

O agora e o próximo envio

Após 251, o endereço antigo está aceito nesta transação, ainda que o cliente ignore a correção. Após 551, uma tentativa no endereço sugerido é outra decisão, com outro RCPT TO e seu próprio resultado. Mostrar a sugestão, guardá-la temporariamente e substituir um contato são ações diferentes.

RFC 5321 diz que o servidor não deve presumir que o cliente atualizará os dados ou sequer mostrará o novo endereço ao usuário. Isso impede que uma resposta transitória reivindique escrita automática sobre bases mantidas por outras instituições.

Encaminhar sem abrir o mapa

Quando RFC 2821 consolidou o SMTP em 2001, o encaminhamento silencioso já era comum. Uma empresa podia manter um endereço público estável e ocultar o destino interno; um usuário podia redirecionar para uma conta privada. A caixa final talvez nem fosse alcançável diretamente pelo remetente.

Assim, responsabilidade e divulgação ficaram independentes. Quem aceita pode retornar 251 com atualização ou 250 sem revelá-la. Quem recusa pode emitir 551 com indicação ou 550 sem informação específica. RFC 5321 mantém as opções e recomenda controles para restringir respostas que exponham o destino.

Ocultar não precisa corromper o resultado. 250 continua aceitação; 550 continua recusa. Só a visibilidade do próximo salto mudou.

Mudou, mas não há endereço público

RFC 3463 definiu X.1.6: caixa de destino movida, sem endereço de encaminhamento. O atual registro IANA de códigos SMTP aprimorados preserva esse estado como falha permanente.

Pode não existir substituto, o servidor pode não conhecê-lo, a política pode proibir divulgação ou o destino pode funcionar somente dentro do encaminhador. A migração não dá ao cliente autorização para deduzir uma caixa a partir de cabeçalhos antigos ou diretórios de terceiros.

RFC 3464 chega ao mesmo limite pelas notificações de entrega. DSNs podem ser forjadas como qualquer email, e usuários podem encaminhar sem desejar que a caixa final seja revelada. Implementações devem oferecer proteção dessa confidencialidade. A mensagem continua; o mapa completo não precisa voltar.

Um dado analisável por máquina virou risco durável

Em geral, clientes SMTP agem pelo número e podem ignorar a frase livre. O forward-path de 251 e 551 é exceção: para ser usado, precisa ser interpretado por software. A conveniência também cria uma entrada de reroteamento.

RFC 5321 alerta que, antes de atualizar comportamento futuro — como uma agenda —, o cliente deveria ter certeza da autenticidade do servidor. Um intermediário que substitua a caixa desvia a mensagem atual; se a correção persistir, desvia todas as seguintes.

Autenticidade não é identidade completa. Ela atribui a declaração ao servidor, mas não prova que a caixa pertence à mesma pessoa, que a mudança é eterna ou que aquele operador administra o registro canônico do contato. Procedência confiável é requisito, não autorização universal.

O alias muda o envelope

RFC 5598 distingue relé de alias. Um MTA comum aproxima a mensagem sem trocar os endereços do envelope. Um alias, controlado pelo destinatário, reapresenta a mensagem a um ou mais destinos, preservando conteúdo e geralmente o MailFrom.

Mudar apenas RCPT TO parece pequeno, mas significa que o destinatário indicado escolheu outro. Se o próximo trecho falhar, o relatório pode voltar ao autor original, que desconhece a regra. O encaminhamento redistribui responsabilidade sem reescrever To, Message-ID ou autoria.

Por isso a correção SMTP não era uma renomeação global. Era a declaração local de um servidor sobre um destinatário de envelope e sobre o trabalho que aceitaria.

Quatro decisões em vez de uma

A arquitetura separou aceitar, encaminhar, divulgar e memorizar. Os padrões posteriores reduziram a exposição sem perder a precisão da custódia. O endereço sugerido permaneceu evidência contextual, não verdade obrigatória em toda base remota.

O SMTP conseguiu acompanhar a mudança de uma caixa sem afirmar que a Internet havia mudado o nome da pessoa. Essa modéstia permitiu que o encaminhamento sobrevivesse mesmo quando o destino final precisava ficar oculto.