Faça da integração uma trilha de evidências, não um gerador de registros
Um serviço comercial aprovado não é automaticamente uma configuração de domínio aprovada. Uma equipe pode ter permissão para usar uma plataforma de e-mail e ainda precisar de decisões sobre qual inquilino, identidade do remetente, alterações DNS e destinos de compartilhamento de dados são apropriados. Um agente pode organizar esse trabalho, expor os pré-requisitos ausentes e preparar uma proposta de mudança precisa. Não deve transformar um nome familiar de fornecedor em permissão para modificar a produção.
Este é um fluxo de trabalho operacional proposto. Ele não afirma que EmailAuth implemente atualmente descoberta de serviço, aplicação de aprovação, conectores de provedor ou verificação automatizada. Essas capacidades exigem evidências atuais do produto. Nenhuma conta de serviço, zona DNS , fluxo de mensagens ou controle de aprovação foi inspecionada ou alterada para este artigo.
Identifique o serviço comercial e seu proprietário responsável
Comece com o objetivo comercial, a equipe responsável, a conta do fornecedor aprovado e as categorias de mensagens pretendidas. Registre o domínio ou subdomínio que o serviço pode usar, a população de destinatários esperada e a pessoa que pode aprovar esse escopo. A infraestrutura de um provedor pode ser compartilhada por muitos clientes; um IP ou nome de host visto em um relatório é uma pista para investigação, e não uma prova de que esta organização autorizou o remetente.
Um agente pode comparar um inventário aprovado com observações disponíveis e rotular uma possível correspondência. O proprietário deve resolver a ambiguidade sobre a instância de serviço real. Mantenha as evidências da partida separadas da pontuação de confiança. RFC 9990 relatórios agregados fornecem autenticação útil e informações de origem, mas seu conteúdo pode ser falso e não estabelecer de forma independente uma relação comercial. RFC 9990 , seções 3.1 e 8.2.
Monte pré-requisitos sem expandir o acesso
Colete as instruções atuais de configuração suportadas do provedor para essa instância de serviço, os requisitos do remetente da organização e a configuração existente relevante. Identifique quais partes podem ser lidas sob autorização existente e quais requerem um administrador. A preparação de um inventário não exige a coleta de senhas ou chaves privadas na conversa ou relatório de um agente.
O limite de acesso proposto deve permitir que o agente inspecione apenas o inquilino aprovado e os recursos necessários para a tarefa. Uma integração com amplos privilégios de gravação não se torna somente leitura apenas porque o prompt solicita análise. A orientação excessiva da agência OWASP recomenda limitar as funções da ferramenta e as permissões downstream. Verifique a aplicação real antes de usar um conector na produção. Agência Excessiva OWASP.
Visualize identidades e alterações juntas
A proposta deverá conectar o Domínio do Autor visível, SPF identidade, DKIM assinatura de domínio e conta de provedor. Um valor TXT gerado é apenas uma parte desse relacionamento. DMARC avalia identificadores autenticados qualificados e alinhamento com o Domínio do Autor; a assinatura padrão não relacionada de um provedor não é alinhada automaticamente. RFC 9989 , seção 4.4.
Mostre os nomes exatos dos proprietários propostos, tipos de registros e valores juntamente com o estado atual observado. Explique se uma alteração adiciona um registro com escopo restrito, altera uma autorização de remetente existente ou delega o controle por meio de um nome gerenciado pelo provedor. Não substitua silenciosamente um Registro SPF, ampliar uma delegação de domínio ou remover a delegação de outro remetente seletor para ajustar um novo serviço. Cada operação precisa de um aprovador responsável e de uma decisão de recuperação.
Mantenha o consentimento do relatório distinto do encaminhamento técnico
Se a integração propor um destino externo para relatórios agregados, identifique quem receberia os relatórios e por quê. RFC 9990 define uma verificação baseada em DNS de acordos de relatórios externos. Essa confirmação técnica estabelece a disposição do destino em receber relatórios no âmbito do protocolo; isso não substitui a aprovação da organização para compartilhar seus dados de relatórios com esse processador. RFC 9990 , seção 4.
A mesma distinção se aplica ao acesso do provedor. Um agente deve descrever uma permissão administrativa necessária antes que alguém a conceda. Uma aprovação para preparar documentação não autoriza acesso persistente à conta, criação de credenciais ou alterações entre locatários. Se o fluxo de trabalho suportado precisar de mais autoridade do que o agente possui, a preparação permanecerá útil enquanto a etapa de execução permanecer atribuída ao administrador autorizado.
Vincule a aprovação à proposta real
Uma aprovação útil identifica a instância de serviço, o locatário, o domínio, as alterações exatas e o instantâneo relevante do estado atual. Se esses fatos mudarem antes da execução, devolva a alteração afetada para revisão em vez de tratar uma aprovação antiga como uma licença geral. O mecanismo de execução deve verificar a autoridade do ator aprovador e o escopo solicitado independentemente da explicação do modelo. Folha de referências de autorização OWASP.
Considere um serviço de recibos fictício usando notices.example . O proprietário da empresa aprova os recebimentos dos clientes, enquanto o administrador DNS analisa um seletor proposto específico do provedor. Essa aprovação não cobriria a adição de outro inquilino, o redirecionamento de relatórios para uma agência ou a alteração da política DMARC do domínio pai. Este exemplo não contém valores reais de provedor e não demonstra que existe ou funciona um controle de aprovação.
Verifique uma mensagem real antes de entregar
O teste de aceitação planejado deve usar um destinatário autorizado e uma mensagem do serviço real, e não apenas um verificador DNS . Capture as identidades do remetente, a assinatura selecionada, os resultados confiáveis da autenticação adicionada pelo destinatário e a disposição de entrega observada. A evidência de autenticação deve ser interpretada dentro do limite de confiança do receptor, em vez de ser obtida de qualquer cabeçalho favorável fornecido com a mensagem. RFC 8601 , seção 7.
Uma aceitação SMTP final é uma transferência de transporte, e não uma prova de colocação na caixa de entrada ou de processamento comercial bem-sucedido. Mantenha esses resultados separados. A transferência deve identificar os proprietários da configuração, as evidências retidas, as dependências de mudança, a responsabilidade de monitoramento e a rota de recuperação aprovada. Um resultado de alinhamento não resolvido é um bloqueador do critério de aceitação declarado, e não um motivo para declarar a conclusão porque o valor DNS foi salvo. RFC 5321 , seção 4.2.5.
Evidência de comissionamento ainda necessária
Execute um serviço aprovado por meio de verificações de pré-requisitos, visualização de alterações, verificação e entrega. Este requisito exato permanece em aberto. O fluxo de trabalho e o mapa são preparação documental. A identidade real do serviço, a aplicabilidade atual do provedor, a aplicação da aprovação, a alteração executada, o resultado da mensagem real e as evidências de transferência devem ser coletadas antes de afirmar que a integração foi demonstrada.