Escopo: identifique a implantação do Jive antes de editar DNS
As orientações de configuração da Jive separam as instalações na nuvem e hospedadas. Isso é SPF as instruções também distinguem as rotas de nuvem dos EUA e da UE. Trate essa ramificação como um pré-requisito: um nome de produto familiar não é suficiente para selecionar dados DNS . Esta revisão se refere ao e-mail de notificação do Jive, não a outro produto chamado Jive ou a um serviço geral de correio de saída. Configuração do Jive
O administrador deve primeiro descrever o evento de negócios que produz a mensagem. Uma notificação da comunidade, uma mensagem relacionada a senha e um resumo gerado pelo aplicativo podem ter diferentes dependências de configuração ou entrega. Registre a instalação exata, o proprietário do serviço, o domínio de envio e os destinatários esperados. Não infira o modelo de implantação a partir de um logotipo de e-mail ou da sede geográfica da organização. Obtenha uma descrição oficial da conta antes de escolher uma agência documentada.
Este é um método proposto de configuração e aceitação. Nenhuma conta Jive foi acessada, nenhum registro DNS foi alterado e nenhuma mensagem foi enviada para este artigo. A aplicabilidade atual a uma instalação específica permanece não verificada. A revisão da documentação não pode fornecer a evidência original da mensagem recebida necessária para a aceitação da implementação.
Obtenha o material correto gerado pelo fornecedor
O documentado DKIM fluxo de trabalho usa material público gerado pelo suporte: TXT para hospedado e CNAME registros para nuvem. O solicitado seletor deve ter exatamente três caracteres. Forneça o domínio do email; Os clientes da nuvem não podem acessar a configuração citada do Server Admin Email e devem informar o suporte. A Jive realiza sua parte de implementação e, em seguida, fornece as entradas DNS do cliente. Isso é DMARC a orientação de configuração atribui a responsabilidade à equipe de TI do cliente. Fluxo de trabalho do Jive
Prepare uma solicitação em vez de inventar uma chave ou seletor. A solicitação proposta deve identificar a instalação existente e a identidade de envio pretendida, perguntar qual ramificação de implantação se aplica e solicitar instruções completas DNS público. Nunca inclua uma chave de assinatura privada, senha de conta ou token de sessão em uma planilha de alteração. A assistência do provedor com assinatura não autoriza um administrador separado a alterar a política de todo o domínio da organização.
Mantenha o material fornecido anexado a uma versão de alteração específica. Se uma resposta de suporte alterar posteriormente o tipo de registro, proprietário ou destino, interrompa a aprovação pendente e reconcilie a diferença. Uma captura de tela anterior ainda pode parecer plausível ao descrever outra região, implantação ou geração de chave. O administrador DNS precisa de valores atuais completos, não de um padrão inferido montado a partir de exemplos não relacionados.
Preservar a política SPF existente
SPF avalia a identidade SMTP apropriada, e não simplesmente o endereço que uma pessoa vê na mensagem. Distinguir o CORREIO DE identidade desde o Identidade HELO ao registrar observações. Um resultado aprovado para um domínio de envelope controlado pelo provedor não estabelece por si só alinhamento com o domínio do autor visível. RFC 7208 , seções 2.3 e 2.4
Antes de propor uma edição, obtenha a política existente completa e identifique seu proprietário. Preserve remetentes aprovados que não estejam relacionados a esta implantação do Jive. Não crie uma segunda política SPF no mesmo proprietário para evitar a compreensão da primeira. Revise os caminhos de avaliação resultantes, incluindo dependências aninhadas: o limite de prazo de pesquisa do protocolo não é uma contagem de strings de inclusão visíveis ou pacotes de rede. O cache não fornece permissão para exceder esse limite. RFC 7208 , seções 3.2 e 4.6.4
A página Jive contém uma nota dependente da rota sobre a remoção de uma referência SendGrid após a configuração DKIM . Não aplique essa nota como uma instrução de remoção universal: estabeleça primeiro o caminho real do envelope e qualquer outra dependência do remetente. Orientação Jive SPF
Escreva a mudança pretendida como uma diferença em relação à linha de base aprovada. Registre o que é adicionado, o que é retido e o que é proposto para remoção. Se a propriedade de uma dependência existente for desconhecida, deixe essa questão sem solução em vez de excluí-la silenciosamente. Uma edição bem-sucedida em uma interface DNS é evidência de uma ação administrativa, e não evidência de que toda a população de mensagens ainda é autenticada.
Publique o proprietário exato e o valor público
Para cada registro proposto, registre o proprietário totalmente qualificado, independentemente da exibição do editor DNS . Alguns editores aceitam rótulos relativos, enquanto outros exibem nomes completos. Uma convenção de arquivo mestre não prova como uma interface gráfica específica trata o sufixo de domínio. Confirme o proprietário resultante usando as próprias regras do provedor DNS antes de salvar. RFC 1035 , seção 5.1
Guarde o tipo de registro das instruções aplicáveis do fornecedor. Não transforme uma delegação CNAME em uma chave TXT inventada localmente nem substitua uma chave pública fornecida por uma de um exemplo. Para dados TXT , diferencie cadeias de caracteres dentro de um único registro de recurso de registros de recursos separados. A divisão do texto de exibição deve preservar os bytes pretendidos; adicionar um registro independente é uma operação diferente. RFC 1035 , seção 3.3.14
Trate um seletor existente como uma dependência que requer investigação. Identifique o fluxo de assinatura atual antes de substituir qualquer coisa com esse nome. Uma reversão proposta deve explicar qual versão DNS pode ser restaurada e se o provedor já mudou seu assinante. Restaurar DNS antigo sem coordenar o lado da assinatura pode criar outra incompatibilidade, em vez de reparar a primeira.
Verifique a mensagem, não apenas o registro
A revisão de aceitação deve coletar uma mensagem autorizada do fluxo de trabalho real do aplicativo e preservar os resultados do receptor confiável. Registre seu domínio From visível, identidade de envelope, cada domínio e seletor de assinatura DKIM e os resultados de autenticação do destinatário. DKIM vincula uma assinatura a um domínio de assinatura e a dados de mensagens selecionados; a existência de uma chave DNS não demonstra que o aplicativo a utilizou. RFC 6376 , seções 3.5 e 3.6.2.2
Separe o sucesso da autenticação do alinhamento. DMARC pode ter sucesso por meio de um caminho SPF alinhado e qualificado ou de um caminho DKIM alinhado e qualificado. Nem esse sucesso nem a confirmação do provedor garantem a colocação na caixa de entrada ou provam que uma solicitação comercial em uma mensagem é segura. Avalie os identificadores reais de acordo com as regras de alinhamento aplicáveis, em vez de interpretar dois rótulos verdes do painel como evidência suficiente. RFC 9989 , seções 2.4 e 4.4
Se um intermediário alterar o caminho de entrega, diagnostique SPF e DKIM de forma independente. Um IP de conexão diferente pode afetar SPF , mas esse fato por si só não explica uma falha Assinatura DKIM. Examine a chave pública relevante, a assinatura e os dados assinados antes de atribuir a falha. Não responda ignorando amplamente a inspeção de segurança. Uma correção de rota aprovada de forma restrita requer sua própria evidência e decisão do proprietário.
Diagnóstico fictício: a planilha de implantação errada
Considere uma organização fictícia, Cedar Example, cujo administrador prepara uma planilha de chave TXT após ler as instruções destinadas a instalações hospedadas. O proprietário da conta produz então uma resposta de suporte do Cloud contendo entradas CNAME . Nenhuma alteração DNS foi aprovada ainda. A discrepância é um erro do ramo de implantação, e não uma prova de que qualquer um dos formatos de registro esteja universalmente errado.
A equipe de revisão retira a planilha incompleta, registra a rota confirmada da conta e pede ao proprietário DNS que avalie os nomes e alvos completos fornecidos. Ele deixa os registros do seletor existentes intactos até que seus proprietários sejam conhecidos. Somente após uma implementação autorizada separadamente a equipe reuniria uma mensagem recebida e compararia suas identidades com o plano aprovado. Este cenário foi inventado para ilustrar um processo de decisão; ele não contém nenhum resultado observado do inquilino ou valores executáveis do cliente.
Planilha de aceitação em branco e decisão de liberação
- Modelo de instalação e implantação: ______. Região e proprietário da evidência: ______.
- Fluxo de trabalho de notificação e visibilidade pretendida Do domínio: ______.
- Data atual das instruções de suporte e escopo do produto aplicável: ______.
- Confirmação do comprimento do seletor e revisão da dependência do seletor existente: ______.
- Proprietários de registros fornecidos, tipos e valores públicos completos: ______.
- Linha de base SPF existente e diferença de alteração aprovada: ______.
- Expectativa do domínio do envelope e revisão do caminho de pesquisa: ______.
- Comportamento de nomenclatura do editor DNS e evidência resultante do proprietário público: ______.
- Confirmação de implementação do lado do provedor: ______.
- Referência de mensagem autorizada e tabela de identidade de receptor confiável: ______.
- Resultado do alinhamento, falha restante e proprietário da reversão: ______.
- Revisor independente, proprietário da versão e data da revisão: ______.
Deixe um campo em branco quando faltar evidência. Um espaço em branco é um controle útil porque evita que a prontidão documental se torne uma reivindicação de conclusão operacional. Evidências originais, revisão humana das PME, aplicabilidade da fonte, rotas de produção, acessibilidade visual e liberação do proprietário permanecem em aberto para este rascunho. Revisite a avaliação quando a rota de implantação, as instruções do provedor, o material de assinatura ou a propriedade do domínio mudarem.