Escopo: Cloud Mail não é todo serviço Web.com
Este guia mantém o tópico de autenticação Web.com do catálogo, mas limita a implementação documentada ao Cloud Mail SPF. Não é um verificado DKIM guia de configuração para cada pacote de e-mail do Web.com. A orientação do provedor disponível é uma captura mais antiga do Cloud Mail, portanto, a aplicabilidade da conta atual deve ser confirmada antes de uma alteração. Um domínio adquirido do Web.com não identifica, apenas por esse fato, seu serviço de e-mail de saída. Comece com a assinatura e a rota de envio, em vez do logotipo do registrador.
A página Cloud Mail distingue seu produto de outros produtos de e-mail. Ele lista SPF como opcional em sua configuração geral DNS . Seu exemplo normal é v=spf1 include:spf.cloudus.oxcs.net ~all . Para um pacote de hospedagem ou formulário de contato de site, ele inclui spf.registeredsite.com e spf.cloudus.oxcs.net . Isso exige um Registro SPF. Estes são exemplos documentados, não valores verificados em relação a uma conta de cliente atual. Configurações DNS do Web.com Cloud Mail
Estabeleça a rota antes de escolher uma política
Crie um pequeno inventário de aplicativos produtores de mensagens. Distinguir uma pessoa que envia por meio de uma caixa de correio hospedada de um site que gera notificações, uma plataforma de marketing usando o mesmo endereço visível e um serviço de cobrança de terceiros. Para cada rota, identifique a equipe que pode confirmar sua configuração real. Registre a incerteza explicitamente. Um recibo de compra de um domínio ou site não é prova suficiente de que todos os aplicativos usam a mesma infraestrutura de saída.
Uma política SPF descreve a infraestrutura de envio autorizada para uma identidade SMTP . Ele não autentica simplesmente todas as mensagens cujo campo De visível contém o domínio. A identidade do envelope relevante pode diferir daquele campo visível. Isso é importante quando um site é enviado por meio de outro serviço ou quando um aplicativo usa um serviço controlado pelo provedor. endereço de devolução. Uma política pode ser sintaticamente correta, mas ser irrelevante para a identidade que está sendo avaliada. Identidades RFC 7208 , HELO e MAIL FROM
O inventário deve, portanto, distinguir factos conhecidos de questões que aguardam acesso à conta. Marque o domínio visível do autor, o domínio esperado do envelope, o caminho de envio pretendido e o proprietário do aplicativo. Deixe os valores desconhecidos em branco em vez de derivá-los de um endereço de webmail. Esta é uma proposta de plano de coleta de evidências, não um relatório de que alguma mensagem já foi inspecionada.
Preservar remetentes existentes ao preparar SPF
Antes de propor um recorde, reterá a resposta TXT oficial atual e seu tempo de coleta por meio de um processo de alteração autorizado. Identifique a política SPF única no nome do proprietário relevante. Outro Registros TXT podem coexistir com esse nome, mas múltiplas políticas SPF não podem ser resolvidas simplesmente escolhendo a mais recente. Várias cadeias de caracteres dentro de um registro de recurso TXT também são diferentes de vários registros de recursos. RFC 7208 , registros de recursos DNS e múltiplas strings
Prepare uma comparação antes e depois que preserve os remetentes ainda autorizados. Não substitua uma política de produção por um pequeno exemplo de fornecedor apenas porque o exemplo parece mais fácil de entender. O mecanismo final também expressa a intenção política. Uma amostra que termina em softfail não autoriza o enfraquecimento de uma política existente, e uma finalização mais estrita não completa um inventário de remetentes não revisado.
Revise o caminho de avaliação completo, incluindo inclusões aninhadas. O limite SPF diz respeito aos termos avaliados de consulta do DNS, não apenas ao número de palavras incluídas visíveis na string de nível superior. O cache não torna válida uma política excessiva. Capture a revisão de dependência proposta separadamente da afirmação de que uma avaliação ao vivo atual foi bem-sucedida. Nenhuma avaliação desse tipo é afirmada aqui. RFC 7208 , limites de pesquisa DNS e inclusão
Mantenha as alterações de roteamento e autenticação separadas
Uma alteração na autenticação não deve se tornar silenciosamente uma migração de caixa de correio. O proprietário da alteração deve explicar por que cada edição DNS proposta é necessária. Uma alteração no destino da caixa de correio tem consequências de serviço diferentes de uma alteração na autorização SPF . O plano de reversão deve ser específico para os registros realmente aprovados, em vez de uma instrução ampla para restaurar toda a zona de uma exportação antiga.
Essa separação também protege aplicativos não relacionados. Um domínio pode hospedar um site público, mensagens recebidas, registros de descoberta de serviços e serviços delegados de terceiros. Uma planilha de autenticação deve identificar o nome exato do proprietário, o tipo e o conteúdo pretendido. Não deve pedir a um operador que copie uma tabela DNS inteira do fornecedor sem compreender as consequências. A apresentação DNS pode usar nomes relativos ou absolutos dependendo do editor; o operador deve confirmar o nome do proprietário resultante em vez de assumir uma regra de interface universal. RFC 1035 , formato de arquivo mestre
DKIM e DMARC permanecem questões de aceitação separadas
O escopo SPF documentado não fornece um Cloud Mail verificado Seletor DKIM, chave pública ou procedimento de ativação de assinatura. Esses campos permanecem sem solução. Não invente um seletor padrão, peça emprestada uma chave de um produto de hospedagem diferente ou trate a existência de um SPF incluído como prova de que as mensagens estão assinadas. A verificação DKIM depende do domínio e seletor de assinatura da assinatura e da chave publicada correspondente. Não é estabelecido por uma afirmação genérica que a hospedagem oferece suporte a e-mail seguro. RFC 6376 , DKIM-Signature e armazenamento de chaves
DMARC requer um identificador autenticado de passagem com o relacionamento necessário com o domínio do autor visível. Passar SPF para um domínio de envelope não relacionado não é suficiente. Por outro lado, DKIM de passagem alinhado pode fornecer o caminho de autenticação qualificado mesmo quando SPF não está alinhado. A revisão operacional deverá registar qual o caminho que suporta cada rota real, em vez de exigir uma combinação universal inventada. A autenticação não garante o posicionamento na caixa de entrada nem prova que a solicitação comercial de uma mensagem é legítima. RFC 9989 , alinhamento e escopo do identificador
Diagnóstico ficcional: duas aplicações, um caminho presumido
Considere a organização fictícia Marlin Workshop. Seu administrador lista “Web.com” como proprietário dos e-mails da equipe e dos recibos do site. Uma alteração proposta copia o exemplo mais curto SPF e remove uma autorização existente sem verificar qual aplicativo ainda a utiliza. Este é um erro de planejamento fictício, não um incidente relatado ou um teste executado.
O revisor interrompe a alteração e separa as duas linhas do aplicativo. O proprietário da caixa de correio da equipe deve identificar o produto real. O proprietário do site deve estabelecer como os recibos são enviados. O operador DNS mantém a política existente e prepara uma comparação revisada somente depois que esses fatos estiverem disponíveis. Se as rotas forem diferentes, as suas evidências também devem ser diferentes. O diagnóstico é uma suposição não suportada sobre infra-estrutura partilhada, e não uma prova de que um determinado fornecedor não conseguiu autenticar o correio.
Planilha de aceitação em branco
Preencha esta planilha apenas com observações autorizadas. Células vazias significam evidências não resolvidas, e não um teste real que falhou.
- Evidência de produto e assinatura: ______
- Confirmação e data do provedor atual: ______
- Aplicativo e proprietário responsável: ______
- Domínio do autor visível: ______
- Identidade e evidências reais do envelope: ______
- Proprietário e valor autorizado atual SPF : ______
- Alteração proposta com remetentes retidos: ______
- Dependência aninhada e revisão de limite de pesquisa: ______
- Capacidade DKIM , seletor e evidência de ativação: ______
- Resultado real da autenticação alinhada: ______
- Janela de aprovação, reversão e observação de alterações: ______
Limite de liberação
Este manuscrito fornece um método de revisão de escopo, não uma configuração concluída. A aplicabilidade atual do produto, valores de conta gerados, publicação oficial, evidência de mensagem recebida, revisão de assuntos humanos, rotas de produção, acessibilidade visual e liberação do proprietário permanecem em aberto. O requisito mais amplo de evidências de implementação do catálogo permanece inalterado. Nenhuma edição DNS , solicitação de suporte, mensagem ou teste de locatário foi realizada para este rascunho.