Um código de status aprimorado é uma pista estruturada, não um relatório completo de incidente. “5.7.1” pode restringir a investigação em direção à segurança ou à política, mas não pode identificar o proprietário da política, a rota afetada ou corrigir a alteração de configuração por si só. Mantenha o diagnóstico completo ao lado do código durante a solução de problemas.
Leia todos os três componentes
RFC 3463 define códigos de status aprimorados com componentes de classe, assunto e detalhe. A classe distingue sucesso, falha transitória persistente e falha permanente. As categorias de assuntos distinguem áreas como endereçamento, estado da caixa de correio, roteamento e segurança ou política. O detalhe restringe a condição dentro daquele assunto. A resposta SMTP comum de três dígitos continua sendo parte da evidência. RFC 3463.
Não trate o número final como um identificador de erro global. O significado depende do código aprimorado completo e do registro aplicável ou da documentação do fornecedor. Um sistema receptor também pode retornar prosa útil sem um código aprimorado. Se as classes básicas e aprimoradas parecerem inconsistentes, preserve os bytes exatos e investigue o comportamento do provedor em vez de reescrever silenciosamente o log.
Separe as respostas SMTP dos relatórios de entrega
Uma resposta SMTP ocorre durante uma conversa. Uma notificação de status de entrega pode relatar resultados posteriormente e descrever vários destinatários. RFC 3464 define campos incluindo Destinatário Final, Ação, Status, MTA Remoto e Código de Diagnóstico. Leia os blocos por destinatário de forma independente; uma falha não prova que todos os destinatários falharam. RFC 3464 seção 2.
Ação e Status respondem a perguntas diferentes. Ação: falhou significa o relatório MTA interrompeu as tentativas para esse destinatário. Status: 4.2.2 ainda pode descrever a causa transitória da caixa de correio cheia após o esgotamento das novas tentativas; falhou mais um status 4.xx é válido em um DSN, não uma resposta SMTP inconsistente. Por exemplo, um item expirado com esses campos não será retomado automaticamente apenas porque a capacidade foi retornada. Verifique a fila real antes de autorizar qualquer substituição. Ver Seção 2.3.3 RFC 3464.
Um assunto de salto legível é útil para triagem, mas pode omitir os campos decisivos. Obtenha o relatório legível por máquina ou envie o log quando possível. Mantenha o servidor de relatórios separado do servidor remoto e diferencie o carimbo de data/hora de um relatório do carimbo de data/hora do comando SMTP com falha.
Leia um bloco de destinatário hipotético
Suponha que um log de envio registre RCPT TO para missing@example.test seguido por 550 5.1.1. Um bloco de destinatário DSN ilustrativo pode conter Destinatário Final: rfc822; missing@example.test , Ação: falhou, Status: 5.1.1, Remote-MTA: dns; mx.example .test e código de diagnóstico: smtp; 550 5.1.1 Esse usuário não existe. Estes são valores de campo inventados, não uma transação executada ou um relatório MIME completo.
A ação falhada é final para este destinatário, enquanto o diagnóstico aponta para o endereçamento. Não estabelece por que o endereço está indisponível ou o que aconteceu com outros destinatários. Obtenha essas respostas de seus próprios blocos e registros confiáveis. Destinatário Final, Ação e Status são campos obrigatórios por destinatário; Remote-MTA e Diagnostic-Code são condicionais ou opcionais. Sua ausência não é permissão para inventar um host rejeitador ou um texto de erro.
Para detalhes cadastrados desconhecidos, consulte o atual Registro de status aprimorado IANA e a especificação citada, depois a explicação atual do fornecedor. RFC 3463 fornece a estrutura, não uma lista exaustiva de todos os códigos posteriores.
Transforme o código em uma hipótese testável
Para um código de endereçamento, confirme o endereço pretendido e o comportamento do sistema receptor. Para obter um código de roteamento, inspecione a configuração do próximo salto e da rota com falha. Para um código de segurança ou de política, identifique o requisito nomeado e seu proprietário. Evite começar com uma alteração DNS preferencial e depois interpretar cada resposta como suporte para ela.
Registre uma hipótese, a evidência que ela prevê e o menor teste autorizado. Uma mensagem corrigida deve ser comparada com a original na rota relevante e na classe do destinatário. Preserve um resultado contraditório como evidência útil, em vez de forçá-lo na explicação original. Os pacotes de escalonamento devem incluir carimbos de data/hora, resposta exata, escopo afetado e alterações já testadas, com conteúdo de mensagem e dados pessoais minimizados. Uma pesquisa de código é o início do diagnóstico, não a sua conclusão.
Crie um pacote de escalonamento útil
- Identidade: retém os identificadores da mensagem e da fila, destinatário do envelope com falha e escopo afetado.
- Linha do tempo: envio de registro, tentativa fracassada e chegada de relatório separadamente.
- Diagnóstico: inclua a resposta SMTP exata, estágio de comando e campos DSN por destinatário.
- Propriedade: distinguir o sistema de notificação do sistema de rejeição, com evidências para cada um.
- Próximo passo: indicar uma causa testável, a menor verificação autorizada e qualquer evidência contraditória. Minimize os dados pessoais.