Uma universidade pode ter correspondência saudável da equipe central, enquanto um despachante de ex-alunos ou uma lista departamental falha no destinatário. Essas rotas alteram diferentes partes de uma mensagem. Um despachante altera o caminho de entrega e pode fazer SPF inadequado para o domínio original; uma lista pode adicionar um rodapé ou reescrever um assunto, potencialmente quebrando uma assinatura. Diagnosticar a transformação real em vez de conceder ampla autoridade a cada retransmissor de campus.
Siga três rotas acadêmicas
Atribua a inscrição do corpo docente à TI do corpo docente, o encaminhador de ex-alunos ao líder de serviço de ex-alunos e a lista departamental ao administrador da lista. Registre o domínio do autor original, o domínio do envelope de saída, o domínio de assinatura, o host intermediário e o destinatário final. Capture uma mensagem original e uma cópia pós-intermediária para o mesmo aviso de evento fictício. Retenha os resultados de autenticação confiável do destinatário final, quando disponíveis, e não um cabeçalho copiado de uma mensagem upstream não confiável.
Para uma aplicação docente, teste o próprio sistema em vez de enviar uma mensagem manual da caixa de correio do professor. Inclui automação no início do semestre e contas de serviço. Para ex-alunos, teste tanto a entrega direta quanto o encaminhamento para uma conta controlada pela equipe de teste. Para obter uma lista, compare uma postagem não modificada com uma postagem que recebe o rodapé configurado. Não desative a funcionalidade útil da lista sem verificar as expectativas dos membros e as necessidades de acessibilidade.
Explique o caminho de autenticação sobrevivente
Um alinhamento preservado Assinatura DKIM pode continuar a apoiar DMARC após o encaminhamento, mesmo quando SPF não funciona mais. Se o encaminhador alterar um corpo ou cabeçalho assinado, essa assinatura específica poderá falhar. O sucesso SPF para um envelope de encaminhador reescrito não se alinha automaticamente com o domínio De do autor original. RFC 7960 documenta questões de correspondência indireta. ARC , definido na RFC 8617, pode realizar avaliações de autenticação entre intermediários, mas a aceitação depende da avaliação e da confiança do receptor; não é uma substituição universal.
Para o caso de rodapé escrito abaixo, suponha que a assinatura original cubra todo o corpo sem um limite l=, e o rodapé não vazio adicionado altera os bytes assinados canonizados. Sob essas suposições, o original hash de corpo não corresponde mais. Este é um raciocínio de protocolo, não um teste de assinatura executado; alterações somente com espaços em branco podem se comportar de maneira diferente em canonização.
Escolha uma mitigação para cada rota
Sempre que possível, preserve o conteúdo assinado por meio de encaminhamento simples. Se uma lista precisar transformar a mensagem, avalie o comportamento da lista compatível, incluindo uma identidade De pertencente à lista e um arranjo Responder para apropriado. Essa reescrita altera a identidade visível aos leitores, portanto teste as respostas, a moderação, os arquivos e a acessibilidade antes de adotá-la. Não falsifique a assinatura de um autor original nem presuma que uma entrada SPF em toda a universidade corrige a modificação da lista.
Registre uma exceção com o proprietário, a data da revisão e a população receptora afetada se uma rota suportada ainda não puder atender à política pretendida. Monitore as falhas reais separadamente da correspondência direta do corpo docente. O acesso aos dados de alunos e ex-alunos, a retenção de registros e as regras de consentimento permanecem uma análise institucional separada; a validação do protocolo não é conformidade legal ou com políticas educacionais.
Compare três estados de encaminhamento
Estas são premissas escritas para reviewer@recipient.test , não mensagens ou testes enviados. Todos os domínios e proprietários são fictícios.
- Rota direta do corpo docente: De college.campus.test, CORREIO DE faculdade.campus.teste, DKIM d=faculty.campus.test with seletor demonstração1; assuma a passagem DKIM . SPF desconhecido. O caminho DKIM estipulado se alinha exatamente. A Faculdade de TI possui o teste de aplicação real.
- Alumni em diante: De alumni.campus.test permanece inalterado; final-hop MAIL FROM torna-se relay.forwarder.test com aprovação SPF estipulada. DKIM original d=alumni.campus.test, seletor demo1, está estipulado para permanecer válido. SPF reescrito não está relacionado a From, mas o DKIM alinhado preservado ainda fornece um caminho de mecanismo. O serviço Alumni possui configuração de observação e encaminhamento de salto final.
- Lista de departamentos: De faculdade.campus.test, DKIM original d=faculty.campus.test, seletor demo1; assuma assinatura de corpo inteiro sem l= e um rodapé que altera os bytes canônicos. Espera-se que essa assinatura original falhe. MAIL FROM relay.list.test é aprovado no SPF e não está relacionado a From. Outras assinaturas e ARC as evidências são desconhecidas, portanto não infira a decisão completa do receptor. O proprietário da lista deve inspecionar as transformações suportadas e os resultados finais confiáveis.
Nenhuma pesquisa real de política, validação de chave, cadeia ARC ou observação de destinatário é fornecida. Uma cadeia ARC válida, se obtida posteriormente, ainda exigiria uma avaliação de confiança do receptor, em vez de restaurar automaticamente a assinatura DKIM original.
Escolha uma decisão de mitigação limitada
Para a lista fictícia EDU-01, compare a preservação do conteúdo assinado com uma reescrita From de propriedade da lista suportada. Reescrever para lists.campus.test requer um caminho de autenticação real alinhado para essa nova identidade e verificações separadas para respostas, moderação, arquivos e acessibilidade. Uma nova assinatura para a mensagem reescrita não repara a assinatura original. Na ausência da evidência do destinatário, rotule a proposta como não verificada e mantenha o proprietário e a data de revisão; não reivindique uma solução para todo o campus.
Mantenha os limites das evidências explícitos
RFC 9989 As seções 4.4 e 5.3.5 distinguem autenticação e alinhamento; A Seção 5.4 deixa o tratamento de mensagens para a política do receptor. A Seção 7.4 exige DKIM válido em vez de SPF apenas para publicação de domínios p=reject e alerta contra a rejeição de domínios cujos usuários postam em listas de discussão da Internet. Os bytes canônicos cobertos determinam a integridade DKIM nas seções 3.4–3.7 e 6.1 RFC 6376 . Nenhum dos mecanismos valida autoridade clínica, educacional ou legal. Coletar evidências atuais autorizadas para uma implantação real; as listas de verificação operacionais aqui são recomendações e não uma avaliação de conformidade específica da jurisdição.