Sim. Eu não chamaria isso de subjetivo porque há um claro consenso; use o SPF .
A implementação é muito fácil e é uma coisa boa para a internet como um todo.
Foi feita uma solicitação por um desenvolvedor da web para que nossos registros DNS de domínio incluam registros SPF TXT. Eu encontrei opiniões diferentes sobre isso lá fora ...
Quaisquer comentários ou ideias que você possa oferecer serão muito apreciados. Eu sei que isso não é uma questão empírica em si - mas eu apreciaria suas ofertas subjetivas, no entanto ... Especialmente se eles viessem com referências que eu poderia procurar em posts na web ou documentos on-line, etc.
Sim. Eu não chamaria isso de subjetivo porque há um claro consenso; use o SPF .
A implementação é muito fácil e é uma coisa boa para a internet como um todo.
Você provavelmente está vendo referências datadas. Com base na porcentagem de emails válidos que meu servidor recebe de servidores usando SPF, o consenso é usar SPF.
Eu recomendo vivamente a criação de SPF. Configure registros para o seu MX permitindo que ele envie e-mails, bem como para o domínio que você usa nos endereços de e-mail. Para domínios que não enviam SPF de configuração de email para indicar isso.
Acho os registros SPF para o servidor de e-mail mais úteis e confiáveis no bloqueio de Spam do que aqueles para o endereço de e-mail do remetente.
Se o seu servidor suportar registros SPF, configure-os além dos registros TXT. Se você alterar sua configuração, poderá haver um pouco de sobrecarga para manter os registros em sincronia, mas muitos sistemas podem configurar seu SPF para que ele se ajuste automaticamente às alterações de MX e endereço.
Você pode querer rever o meu post em Protegendo sua Reputação de E-mail com SPF . Minha primeira implementação do SPF foi bloquear um spammer que estava forjando um domínio para o qual eu fornecia serviços de email. Apesar da relativamente baixa penetração de SPF, foi muito eficaz em desligá-los. No entanto, ainda recebemos spam no endereço falsificado que eles criaram. (É uma ótima maneira de verificar os spammers, pois somente os spammers usariam esse endereço.)
Eu acredito que a penetração do SPF no lado do recebimento é provavelmente maior do que no lado da publicação.
EDIT: Se você usar registros SPF, verifique se as pessoas que entregam correspondências automatizadas estão cientes da necessidade de adicionar seus servidores. (O servidor deve ser totalmente verificado, pois os sistemas automatizados geralmente são mal configurados e podem ter um perfil semelhante a um spambot. Não é tão difícil configurar o servidor corretamente.)
Definitivamente, configure o SPF - não deve haver desvantagem (contanto que seja configurado corretamente e testado), mas evitará que outros sites se disfarçam como você e enviem spam em seu nome. O motivo é que você está claramente na lista de permissões de determinados servidores / IPs que podem enviar e-mails para seu domínio.
Eu acho que a melhor prova de que é uma coisa boa é olhar para alguns grandes serviços de e-mail. Basta procurar os cabeçalhos 'Recebidos-SPF' no email original para ver se o SPF está marcado. Por exemplo:
Yahoo Mail:
Received-SPF: pass (domain of example.com designates xxx.xxx.xxx.xxx as permitted sender)
Gmail:
Received-SPF: pass (google.com: domain of [email protected] designates xxx.xx.xx.xx as permitted sender) client-ip=xxx.xx.xx.xx;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of [email protected] designates xxx.xx.xx.xx as permitted sender) [email protected]
O Hotmail também verifica o SPF (embora eu acredite que ele seja chamado de Sender-ID). No geral, é uma adição fácil que pode fazer muito bem - tanto para o seu domínio como para a Internet como um todo.
Como os outros entrevistados (até agora), recomendo implementar o SPF.
Algumas das outras postagens mencionaram que isso torna mais difícil para outras pessoas se passarem por você (mas isso não significa que o SPF seja a base para non-repudiation ). Mesmo que o impacto direto de tal evento seja muito baixo, isso ajuda a reduzir o o back-scatter .
No entanto, outra razão muito importante é que ela melhora a capacidade de entrega para os destinatários cujos fornecedores implementam o SPF.
Eu certamente ficaria muito interessado em saber quais são as desvantagens do SPF. Atualmente, tudo que eu sei é:
os usuários devem rotear seus e-mails enviados por servidores nomeados - embora o controle do seu e-mail de saída tenha benefícios óbvios, isso pode adicionar algumas complicações se você tiver usuários remotos - você precisará configurar a autenticação SMTP ou uma VPN
problema com algum encaminhamento - qual IME é muito raro
O grande problema que vejo com o SPF é que ele é redirecionado. Esta é a partir de hoje apenas brevemente mencionada na entrada da Wikipédia do SPF . E é também a razão pela qual eu não configuro o SPF no meu servidor de e-mail.
Considere A com o endereço [email protected] (que é o MX implementa o SPF) envia um e-mail para B com o endereço [email protected] que configurou esse endereço para encaminhar os e-mails para [email protected] . O MX para reallyb.org , em seguida, vê o e-mail de A originado do MX de b.org e, portanto, é permitido jogar fora a mensagem.
Então, se você quiser continuar enviando e-mails para pessoas que usam o encaminhamento como costumava trabalhar nas décadas anteriores à criação do SPF, pelo menos não use -all .
Isso poderia ser corrigido se o MX de b.org usasse SRS ou se o MX para reallyb.org de emails de lista branca vindo de b.org . De acordo com minha opinião sobre a realidade, a maioria dos forwarders não faz nenhum desses dois. E como você está na posição de A se pensa em implementar o SPF em seu servidor, isso é algo que você não pode controlar em geral.
Tags email domain-name-system spf