Uma mensagem pode usar um endereço De familiar enquanto direciona as respostas para outro lugar. Essa diferença pode ser legítima, como um serviço de emissão de tickets, ou pode redirecionar uma conversa delicada. Investigue os campos reais e o limite de confiança de recebimento antes de chamar a incompatibilidade de ataque ou tratar a autenticação como aprovação do destino da resposta.
Entenda o papel do campo
RFC 5322 descreve Reply-To como a caixa de correio ou caixas de correio para as quais o autor sugere que as respostas sejam enviadas. Na sua ausência, as respostas normalmente vão para a caixa de correio De. Esta é uma instrução em formato de mensagem, distinta da entrega de envelope SMTP e distinta de uma decisão de aprovação humana. Os clientes e as ferramentas de fluxo de trabalho podem aplicar seu próprio comportamento de resposta, portanto, inspecione o destinatário real antes de enviar uma resposta confidencial. Seção 3.6.2 RFC 5322.
DMARC usa o domínio do autor, não o campo Responder para, para seu relacionamento de identidade. Portanto, uma passagem não estabelece que um domínio Reply-To diferente pertença à mesma organização. Um válido Assinatura DKIM pode abranger Reply-To quando esse campo estiver incluído na lista de cabeçalhos assinados da assinatura, mas a integridade de um valor não é permissão para usá-lo para correspondência confidencial. DMARC e DKIM.
Anote o original em vez de uma captura de tela
Retenha bytes de mensagens brutas. Crie uma anotação separada mostrando De, Responder para, Return-Path, DKIM d= and h= values, and the receiving system that produced Authentication-Results. Marque De e Responder para como campos fornecidos pelo remetente, a assinatura DKIM como uma declaração que requer verificação e os resultados de autenticação como confiáveis somente quando sua procedência for estabelecida. RFC 8601.
Não presuma que uma linha Authentication-Results copiada seja genuína. Da mesma forma, um campo Return-Path em um arquivo de texto salvo arbitrariamente não prova independentemente o envelope SMTP . Correlacione com logs de recebimento autorizados quando necessário.
Compare três cenários de cabeçalho escrito
Suponha que seja visível de billing@supplier.example.test em cada caso. A identidade do envelope, os valores DKIM d= e h=, as assinaturas reais e os resultados do receptor confiável não são fornecidos. Uma asserção de passagem copiada não pode preencher essas lacunas.
- Rota inesperada: Responder para case@support.example.test ; nenhuma aprovação de fluxo de trabalho fornecida. Sinalize o domínio exato diferente para revisão, retenha respostas confidenciais e pergunte ao proprietário do serviço por meio de um canal conhecido.
- Rota do mesmo domínio: Responder para help@supplier.example.test . Uma regra de incompatibilidade de domínio exato não sinalizaria isso, mas isso não prova que a caixa de correio ou as informações solicitadas estejam autorizadas.
- Exceção com escopo definido: Responder para case@tickets.example.test ; suponha que um inventário fictício permita esse serviço apenas para tickets de suporte de rotina. Trate-o conforme esperado para esse fim, e não permissão para alterações de pagamento ou documentos confidenciais.
Esses exemplos são valores e decisões escritos, não um arquivo .eml incluído, execução do analisador ou resultado de autenticação real. Nenhuma assinatura DKIM é fabricada. O proprietário do serviço proposto verifica as informações do destinatário e permitidas antes de uma resposta real; o investigador de correio obtém separadamente bytes originais e evidências de autenticação confiáveis.
Verifique o destino da resposta em relação ao fluxo de trabalho
Pergunte ao proprietário do serviço se o destino externo é esperado para este tipo de mensagem e se é apropriado para as informações propostas. Uma caixa de correio de suporte pode ser legitimamente diferente de um remetente de cobrança, mas ainda assim ser inadequada para instruções de pagamento ou anexos confidenciais. A aprovação deve corresponder à finalidade e não apenas à existência do domínio.
Para solicitações inesperadas, entre em contato com o suposto remetente por meio de um canal independente conhecido. Não teste um destino questionável enviando material confidencial por e-mail. Se um cliente preencher automaticamente Responder para, cancele o rascunho até que o destino seja verificado.
Fechar a pergunta no nível do campo
Registre se a incompatibilidade era esperada, não autorizada ou não resolvida e quais evidências apoiam essa conclusão. Mantenha os resultados da autenticação como uma observação separada. Isto preserva uma distinção útil: uma mensagem pode estar intacta e autenticada pelo domínio, enquanto a rota de resposta sugerida é inadequada para a ação comercial.