Especifique qual mensagem o banner muda
Uma isenção de responsabilidade legal de saída, um banner de aviso de entrada e uma marca de classificação somente no cabeçalho podem ser chamados de banner de correio. Eles não têm o mesmo efeito na autenticação. Identifique a direção, o ponto de inserção e a representação exata que está sendo alterada antes de interpretar um DKIM resultado. Uma verificação aprovada no ingresso pode coexistir com uma falha posterior após uma modificação interna do corpo.
Esta é uma avaliação proposta, sem alterações nas regras de transporte ou mensagens enviadas. Porta de evidências original: amostras de entrega direta e indireta com rota, envelope, assinaturas e resultados confiáveis comparados. Os casos fictícios ilustram limites; não são observações de um inquilino cliente.
Separe a correspondência de regras da transformação de conteúdo
Uma regra de isenção de responsabilidade precisa de uma condição que selecione mensagens e de uma ação que as altere. A documentação Exchange Online da Microsoft descreve adições na parte superior ou inferior das mensagens e condições para limitá-las a emails de saída. Esses recursos documentados não identificam as regras instaladas em uma organização específica. Registre o escopo, as exceções e a prioridade reais de uma revisão de configuração autorizada antes de prever os resultados. Regras de isenção de responsabilidade da Microsoft
Distinguir uma correspondência de regra registrada de uma mensagem transformada real. A Microsoft afirma que o Teste sem dicas de política registra os resultados sem adicionar a isenção de responsabilidade. Esse modo pode ajudar a avaliar a seleção, mas não pode, por si só, demonstrar se o conteúdo inserido sobreviveria à verificação DKIM ou seria renderizado corretamente. Planeje uma transformação de mensagem controlada autorizada separadamente quando for necessária evidência desses efeitos. Modo de regra da Microsoft
Compare as entradas assinadas em vez do rótulo
A verificação DKIM depende das instâncias de cabeçalho selecionadas e da cobertura canônica do corpo. Adicionar um rótulo visual não sinalizado na interface de um aplicativo de correio não é necessariamente uma alteração na mensagem armazenada. Inserir texto de aviso HTML em uma parte MIME é uma alteração de mensagem. Um cabeçalho adicionado fora da cobertura de assinatura selecionada pode ter um resultado diferente da edição de um campo Assunto assinado. Seções 3.4–3.5 e 5.4 RFC 6376
Não afirme que toda modificação de conteúdo inevitavelmente quebra DKIM . Algumas diferenças desaparecem sob o configurado canonização, e a cobertura pode ser afetada pela seleção do cabeçalho ou l=. Para uma assinatura que cobre todo o corpo, um aviso de isenção comum que adiciona texto sem espaços em branco altera a entrada canônica e invalida essa assinatura, assumindo que ela foi verificada previamente. A canonização relaxada não é permissão para anexar texto arbitrário. Seções 3.4 e 3.5 RFC 6376
Coloque os resultados da autenticação na linha do tempo de processamento
Para mensagens de entrada, um gateway confiável identificado pode autenticar a mensagem original antes de adicionar um aviso para leitores internos. Um sistema posterior pode então ver os bytes modificados e obter um resultado diferente. Preservar tanto o tempo de avaliação como a representação avaliada. Authentication-Results é útil apenas dentro de um modelo de confiança estabelecido; um campo não confiável alegando sucesso não estabelece o que o gateway realmente verificou. RFC 8601 seção 7
Para o correio de saída da própria organização, considere se a isenção de responsabilidade pretendida é aplicada antes do seu signatário alinhado autorizado. Um salto externo final que acrescenta texto após a assinatura pode prejudicar essa assinatura. Não infira a ordem real apenas a partir da prioridade da regra quando o signatário e o mecanismo de regras pertencem a serviços diferentes. Capture o caminho real e o arranjo de processamento suportado antes de propor uma alteração no pedido. RFC 6376 seção 5.1
Acompanhe dois casos de banners fictícios
No caso fictício um, example.com assina uma mensagem de corpo inteiro e, em seguida, uma retransmissão de saída anexa “Somente para uso comercial”. Suponha que a assinatura seja verificada antes do revezamento e que as novas palavras apareçam dentro de sua cobertura corporal canonizada. A representação final não é mais verificada sob a assinatura original. Um segundo caminho autenticado alinhado precisaria de avaliação separada; uma falha DKIM não é automaticamente uma decisão final DMARC falha. Seção 5.3 RFC 9989
No caso fictício dois, o ingresso confiável de uma organização receptora registra uma assinatura original válida e, em seguida, insere um banner de advertência interno. A avaliação de ingresso preservada e uma falha de verificação posterior podem ser consistentes com o histórico de processamento. Nenhum dos casos prova como funciona qualquer gateway real. A questão da solução é diferente: corrigir a ordem de assinatura de saída no primeiro caso e preservar com precisão os limites de avaliação no segundo.
Trate o empacotamento como uma estrutura de mensagem diferente
Quando uma isenção de responsabilidade não pode ser inserida, as opções de substituição documentadas da Microsoft incluem agrupar o original como um anexo dentro de uma nova mensagem. A documentação também descreve regras subsequentes que examinam a nova mensagem externa. Uma assinatura retida em um original anexado não deve ser confundida com uma assinatura que autentica a mensagem externa que contém a isenção de responsabilidade. Inspecione ambas as camadas se esse substituto for realmente usado. Opções alternativas da Microsoft
A Microsoft proíbe especificamente regras Wrap in que afetem mensagens recebidas de remetentes externos porque interferem na verificação de Anexos Seguros. Para essas regras, a Microsoft diz para usar Reject; esse substituto retorna a mensagem original ao remetente em um relatório de falha na entrega. Esta restrição específica do produto não é autorização para alterar uma regra e nenhuma ação de Rejeitar foi configurada ou executada aqui. Restrição de mensagens recebidas da Microsoft
O empacotamento também altera a experiência do destinatário e o processamento posterior. O plano de aceitação deve incluir a abertura do anexo, comportamento de resposta, requisitos de digitalização e qualquer conteúdo que deva permanecer visível. Não selecione um substituto apenas porque evita um indicador de autenticação. O conteúdo criptografado ou não modificável precisa de uma decisão de tratamento aprovada pelo proprietário, em vez de uma suposta exceção universal.
Mantenha os avisos e as decisões de entrega separados
Um aviso de isenção de responsabilidade não autentica seu autor e um banner de aviso não prova que a mensagem falhou DMARC . DMARC avalia o domínio do autor em relação a identificadores autenticados alinhados; a disposição da mensagem também reflete a política do receptor e outros sinais. Descreva a regra real e o resultado da autenticação de forma independente, especialmente quando um banner é baseado em origem externa e não em uma falha de autenticação. Seções 4.1 e 5.3 RFC 9989
Feche uma avaliação aprovada com amostras de mensagens brutas diretas e indiretas, evidências de correspondência de regras, cópias transformadas e resultados por assinatura. Inclua mensagens que devem ou não corresponder, texto simples e HTML quando relevante, e repita o tratamento que possa duplicar uma isenção de responsabilidade. Nenhuma dessas verificações ao vivo ocorreu aqui, então a renderização, o comportamento do inquilino e a entrega real permanecem abertas.