Pergunta

Ao desenvolver um aplicativo que envia mensagens de e-mail de notificação, quais são as melhores práticas para

  1. não ser sinalizado como um spammer por sua empresa de hospedagem. (Tampa de qualquer :)
    • melhor técnica para não inundar um servidor de correio
    • melhores produtos de servidor de correio, se você tivesse que criar o seu próprio
    • envio de mensagens como se de um usuário específico, mas ainda claramente a partir da aplicação (para garantir reclamações, etc voltar para você) sem quebrar bom email etiqueta
    • quaisquer outras lições aprendidas
  2. não ficar marcada como spam por cliente do receptor? (Tampa de qualquer :)
    • configurar e utilizar o remetente-id,-chaves de domínio, SPF, reverse-dns, etc para garantir que seus e-mails são devidamente identificados
    • melhores técnicas de cabeçalho SMTP para evitar ficar marcada como spam ao enviar e-mails para os usuários (por exemplo, usando Sender e From cabeçalhos juntos)
    • quaisquer outras lições aprendidas

Um requisito adicional: esta aplicação seria enviar uma única mensagem para um único destinatário com base em um evento. Assim, as técnicas para enviar as mesmas mensagens para vários destinatários não será aplicada.

Foi útil?

Solução

melhor técnica para não inundar um servidor de correio

Não é muita coisa que você pode fazer sobre esta verificação além com o administrador do servidor de correio (se for uma conta de hospedagem compartilhada / não em seu controle). mas se a exigência é um e-mail para um único destinatário por evento, que não deve ser demasiado de um problema. as coisas que tendem a entupir os sistemas de correio são e-mails com centenas (ou mais) dos beneficiários.

Se você tem ignições fora o tempo todo, talvez, considerar consolidá-los e ter uma enviado um email que os resume periodicamente.

envio de mensagens como se de um usuário específico, mas ainda claramente a partir da aplicação (para garantir reclamações, etc voltar para você) sem quebrar bom email etiqueta

Você pode fazer isso usando o cabeçalho "Responder a", que terá, então, os clientes usam esse endereço em vez do endereço De quando uma mensagem de e-mail está sendo composta.

Você também deve definir o "Return-Path" cabeçalho de qualquer e-mail, como e-mail, sem esta, muitas vezes, se filtrado.

ex.

From: me@me.com
Return-Path: me@me.com
Reply-To: auto@myapp.com

configurar e utilizar remetente-id,-chaves de domínio, SPF, reverse-dns, etc para garantir que seus e-mails são devidamente identificados

tudo isso é altamente dependente de quanto propriedade você tem de seus servidores de correio e DNS. SPF / remetente-id etc ... são todos os problemas de DNS, assim que você precisa ter acesso ao DNS.

no seu exemplo isso poderia apresentar bastante o problema. como você está definindo mail para ser de um usuário específico, o usuário teria que ter SPF (por exemplo) set em seu DNS para permitir que o servidor de correio como um remetente válido. você pode imaginar como confuso (se não mesmo impossível) este iria ficar com um número de usuários com vários nomes de domínio.

como para DNS reverso e similares, ele realmente depende. de maior ISP do cliente, etc ... só vai verificar para ver se o DNS reverso está definido. (Ou seja, 1.2.3.4 resolve host.here.domain.com, mesmo que host.here.domain.com não resolver volta para 1.2.3.4). isto é devido à quantidade de hospedagem compartilhada lá fora (onde os servidores de e-mail, muitas vezes, relatam-se como nome de domínio do cliente, e não do servidor de correio real).

existem algumas redes rigorosos que exigem correspondência DNS reverso, mas isso requer que você tenha controle sobre o servidor de correio, se ele não corresponder, em primeiro lugar.

Se você pode ser um pouco mais específico i pode ser capaz de fornecer um pouco mais conselhos, mas em geral, para pessoas que precisam enviar e-mails de aplicativos, e não tem um monte de controle sobre seu ambiente, eu sugerem o seguinte:

  • Certifique-se de definir um "Return-Path"
  • É bom para adicionar seu aplicativo e informações abuso, bem como em cabeçalhos ou seja: "X-Mailer" e "X-Abuso-To" (estes são cabeçalhos personalizados, apenas para fins informativos realmente)
  • Certifique-se de DNS reverso é definido para o endereço IP do seu servidor de correio de saída

Outras dicas

primeiro uma correção rápida para o anterior

return-path: é um cabeçalho adicionado pelo sistema recebendo baseado no envelope-remetente da mensagem incomming

para SPF para trabalhar as necessidades de retorno path / envelope-remetente a yourapp@yourdomain.com

e garantir o registro SPF para yourdomain.com {ou se por usuário SPF} para yourapp@yourdomain.com permite mails para originar no servidor que hospeda o app / envia o e-mail

este envelope remetente é o endereço que receberá todas as rejeições / erros

Agora remetente-id é completamente diferente ele verifica o caminho de regresso / envelope remetente e a de: endereço {armazenado dentro a mensagem} se o envio de: hisname yourapp@yourdomain.com reply-to: hisname hisaddres@hisdomain.com

este será um non-issue se o envio de: hisname hisaddres@hisdomain.com

será e você deve adicionar um Ressentir-From: hisname yourapp@yourdomain.com como isto especifica a ignorar a partir de: para verificações de remetente-id usar isso em vez como ele foi enviado por você em seu nome

-se agora para os outros bits que valem a pena

ip é mencionado são os seus mailservers

a ter ponto ptr do seu ip para um nome que também resolve para o mesmo IP FQDNs

b ter o seu servidor helo / EHLO com whatever.domain.com onde domain.com é o mesmo que o domínio do nome na etapa A {não o mesmo nome para resons abaixo}

c têm que helo / EHLO servername também resolver para o ip do seu servidor

d adicione o seguinte registro SPF para que helo / EHLO nome "v = spf1 um -todos" {Significado permitir helo / EHLO com este nome de ip é isso aponta nome apenas}

e adicione as seguintes linhas remetente-id ao helo / EHLO nome {puramente para a integralidade "Spf2.0 / mfrom, pra -todos" {ou seja, não há usuários @ este domínio}

f adicione o seguinte SPF para os FQDNs-nome e quaisquer outros nomes de host para o seu servidor "V = spf1 -todos" {ou seja, sem máquinas nunca vai helo / EHLO como este nome e não os usuários @ this-domain}

{como o nome FQDNs pode ser determinado por bots / infecções seu melhor para nunca permitir que esse nome para ser usado em helo / EHLO saudações diretamente é suficiente para que ele ser do mesmo domínio que o helo / EHLO identidade para provar a validade de ambos}

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top