Melhores práticas para evitar que você pareça um spammer

Question

Gostaria de me sentir mais confiante ao configurar e-mails para meus clientes em relação a falsos positivos. Aqui está o que eu sei:

1. Os registros SPF são bons, mas nem todo serviço/software de filtro de spam (SFSS) os utiliza.

2. registros DNS reverso (PTR) são praticamente uma necessidade.

3. Relés abertos são ruins.

   (Aqui estão "outras dicas" que li):

4. a pesquisa reversa do endereço IP do seu servidor de e-mail deve resolver o domínio do qual você está enviando e-mails.

5. seu servidor deve dizer HELO FQDN.of.your.mail.server.com ao falar com outros servidores de e-mail.

6. os registros de host A nos registros MX devem ser (ou resolver para o endereço IP) seu FQDN.of.your.mail.server.com

Sinto-me muito bem com 1 e 3. É aqui que gostaria de alguns esclarecimentos/sugestões:

2 e 4: Pesquisei muito e isso parece incorreto, pois a maioria dos filtros de spam está procurando um PTR emem gerale aquele que não é atribuído genericamente pelo ISP; não parece que o domínio para o qual você envia e-mails tenha algo a ver com isso (ou seja, se você possuísse dois domínios usados ​​para e-mail, precisaria enviar de dois endereços IP com PTRs para cada um?)

5. Isso faz sentido, mas importa o que o FQDN resolve? Deveria resolver para o endereço IP que está enviando o HELO?

6. Novamente, outro de várias pesquisas no Google; não vejo como isso funcionaria se você usasse o Postini como seu serviço de gateway (ou qualquer outro smarthost).

E que tal enviar em nome de outro domínio para o qual você não tem autoridade? Tenho alguns clientes (some.branchdomain.tld) ​​que são obrigados a enviar e-mails como @some.corporatedomain.tld, mesmo que a referida sede corporativa não configure um relé/smarthost para eles usarem. corporatedomain.tld pode criar registros SPF para mostrar que some.branchdomain.tld tem permissão para enviar e-mails, mas isso ainda seria considerado "falsificação", especialmente se o referido SFSS não verifica os registros SPF? Devo me preocupar com isso?

Answer 1

Posso garantir que o número 2 (PTR reverso) é importante, mas não o número 4 (domínio do servidor de e-mail correspondente a "de"). Configuramos servidores de e-mail o tempo todo, e a maioria dos hosts de e-mail nem se importa com o número 2.

O principal problema é sempre a AOL, e eles listampadrõesvocê pode marcar.

Answer 2

Além da string HELO e dos registros DNS PTR mencionados, a maior parte das coisas que ajudarão estarão relacionadas ao conteúdo, e não ao servidor de envio.

• Não envie e-mails em HTML se puder evitá-los.
• Não inclua frases suspeitas ("clique para cancelar", "privacidade é importante" e similares)
• Não use cabeçalhos "resposta para", envie do endereço para o qual deseja que as respostas sejam enviadas
• ...e mais. Leia o conjunto de regras do SpamAssassin para mais bons exemplos.

Quanto à sua pergunta "se importa com o que o FQDN resolve?", isso depende inteiramente do que o servidor de e-mail de recebimento faz e, é claro, pode variar, mas normalmente você não encontrará muitos servidores de e-mail dependendo do A pesquisa de FQDN é uma regra rígida e rápida, pois é possível ter várias máquinas configuradas em uma configuração round-robin.

Answer 3

Que tal diretrizes de conteúdo? Manter o e-mail sensato ajudará a evitar que você seja sinalizado como produtor de spam em vários sistemas. Treine seus clientes para evitar encaminhar "coisas engraçadas" para todos em sua lista de contatos, não se inscrever para receber resumos de e-mail ou boletins informativos e usar mecanismos sensatos de proteção contra malware para evitar se tornarem parte de uma botnet de spam...

Answer 4

4 é na verdade totalmente falso. Você pode estar pensando mais na linha deEstrutura de política do remetente, em que o DNS de um domínio contém um registro que indica quais servidores SMTP têm permissão para enviar mensagens com um cabeçalho From: com esse nome de domínio. Mas o fato é que os domínios hospedados geralmente têm servidores de e-mail de saída que sãonãoo mesmo que o nome de domínio, mas o ISP do remetente. Por exemplo, se você tiver myvanitydomain.com e o endereço de e-mail[e-mail protegido], mas você usa o Sprint como seu provedor de Internet, geralmente precisa usar o servidor de saída de e-mail da Sprint para enviar e-mails. Existem maneiras de contornar isso (como webmail ou autenticação POP e SMTP), mas esse é um bom exemplo.

Quanto a "como fazer com que o e-mail não pareça spam", bem... você não faz com que pareça spam, é claro. O fato de você considerar usar um relé aberto parece... suspeito. Não consigo pensar em uma única razão legítima para vocêquererpara, quando todo ISP possui um servidor SMTP. Se você está pagando pela hospedagem do servidor a partir do qual envia e-mails, a maneira de não obter seu endereço IP listado por várias autoridades é não enviando spam.