Não há razão para que você não possa escrevê-lo em PHP, embora eu não torná-lo parte de um processo webrequest/HTTP. Implementei com sucesso para dar ou receber 500.000 assinantes por correspondência (dependendo dos dados locais disponíveis, pois este era um projeto específico do local). Foi um projeto interno, então, infelizmente, nenhum código/pacote para você, mas algumas dicas que encontrei:

Configurando a entrega

• Começou com o próprio phpmailer, para cuidar da formatação, codificação de conteúdo e cabeçalhos, adição de anexos etc. Essa parte funciona bem, e eu não gostaria de escrever isso do zero.
• O 'envio' de um e-mail em si é apenas definir algum sinalizador em um banco de dados se / como / o que deve ser enviado para (uma parte) dos assinantes.
• Depois que este sinalizador for definido, ele será automaticamente selecionado por um cronjob, sem mais servidor da Web envolvido.
• Comecei com um banco de dados altamente poluído com milhões de endereços de e-mail, dos quais muito eram obviamente inválidos, então a primeira coisa era validar todos os endereços de e-mail para formato e depois para host:
  • filter_var($email, FILTER_VALIDATE_EMAIL); sobre os assinantes (e armazenando o resultado obviamente) se livrou das primeiras centenas de milhares de emails inválidos.
  • Dividir o host (e armazenar o nome do host) dos e-mails e validando isso (ele tem um registro MX ou pelo menos A no DNS, mas lembre-se:você pode enviar e-mail para um endereço IP [email protected][255.255.255.255] , então mantenha aqueles válidos)) se livrou de uma boa parte mais. Os endereços de e-mail aqui não permanentemente desativado, mas com um sinalizador de status que indica que eles estão desativados devido ao nome de domínio/ip.
  • Os scripts foram alterados para requerer endereços de e-mail válidos na assinatura / antes da inserção, esse absurdo de 'você não vai receber exemplo@ sqldat. com ' a poluição por assinatura no banco de dados era simplesmente ridícula.
• Agora acabei com uma lista de endereços de e-mail com potencial para serem válidos. Existem basicamente 3 maneiras de detectar endereços inválidos (lembre-se de que todos pode ser temporário):
  • Eles são negados imediatamente pelo servidor.
  • O servidor determinado anteriormente simplesmente não escuta o tráfego.
  • Eles são devolvidos muito depois de você pensar que os entregou.
• Estranho, as rejeições, para as quais todo servidor de e-mail parece ter outro formato e foram muito difíceis de analisar no início, acabaram sendo muito fáceis de capturar usando VERP . Em vez de analisar e-mails inteiros, um endereço de e-mail dedicado (vamos chamá-lo de [email protected] ) foi configurado para entregar na caixa de correio, para canalizá-lo por meio de um comando e se enviássemos um e-mail para [email protected] , o Return-Path foi definido para [email protected] . Facilmente analisado no recebimento e depois de quantas devoluções (caixa de correio não pode existir, a caixa de correio pode estar cheia (sim, ainda!), etc.), você declara um endereço de e-mail inutilizável.
• Agora, a negação direta pelo servidor. Provavelmente poderíamos ter configurado corretamente alguns MTA e/ou escrever plugins para eles, mas como os e-mails eram sensíveis ao tempo, e tínhamos que ter controle configurável absoluto por correspondência sobre o último tempo de entrega utilizável (após o qual o e-mail não era mais de interesse para o usuário), limitação por servidor receptor, e geralmente tudo, levaria quase o mesmo tempo para escrever um mailer em PHP que conhecíamos melhor, que usasse o protocolo SMTP diretamente no soquete 25 nos servidores receptores. Com um mínimo de esforço, a possibilidade de outro transporte, então as opções padrão no PHPMailer foram incorporadas. O protocolo SMTP é bastante simples, mas existem algumas ressalvas:
  • Muitos servidores de recebimento aplicam a Lista cinza:a maioria dos spambots não se importará se um e-mail específico chegar, eles apenas os despacharão. Portanto, se um remetente desconhecido/ainda não confiável enviar e-mail, ele será temporariamente rejeitado. Pegue isso (geralmente o código 451) e coloque o e-mail na fila para tentar novamente.
  • Um servidor de email, especialmente dos maiores ISPs e serviços gratuitos (gmail, hotmail/msn/live, etc.) tu. Mais sobre isso mais tarde.

Obtendo velocidade

• Agora, tínhamos um sistema de entrega que funcionava, mas precisava ser rápido . Enviar 10.000 e-mails em uma hora é bom se você tiver apenas 10.000 endereços para enviar, mas o mínimo que exigimos foi de cerca de 200.000 por hora. No começo, era um servidor dedicado (que pode realmente ter pouca energia, não importa o que você faça, a maior parte do tempo gasto na entrega de e-mail está na rede, não no seu servidor).
• Caching de IPs:lembra de todos aqueles IPs que solicitamos de nomes de host em endereços de e-mail? Nós os armazenamos, obviamente, e procurar seus IPs repetidas vezes causa um atraso considerável. No entanto, os IPs podem mudar:um registro DNS lá, outro MX em outro local... os dados ficam obsoletos rapidamente. Na maioria das vezes, o servidor não está realmente enviando nada (newsletters de assinatura vêm em rajadas obviamente), um cronjob de baixa prioridade está sendo executado verificando todos os nomes de host com um IP antigo (escolhemos mais de 1 dia como obsoleto) para um endereço IP , incluindo aqueles que anteriormente não tinham nenhum (novos domínios são registrados o tempo todo, então por que um domínio não deveria ser disponibilizado no dia seguinte a alguém já se inscreveu com entusiasmo com seu novo endereço de e-mail? Ou problemas de servidor com algum domínio são resolvidos, etc.). Na verdade, o envio dos e-mails agora não exige mais pesquisas de domínio.
• Reutilização da conexão SMTP:configurar uma conexão com um servidor leva uma parte relativamente grande do tempo para entregar um e-mail quando você está falando diretamente com a porta 25. Você não precisa configurar uma nova conexão para cada e-mail, você pode simplesmente enviar o próximo pela mesma conexão. Um pouco de rastro e erro resultou na configuração do padrão aqui para cerca de 50 e-mails por conexão (supondo que você tenha muitos ou mais para o domínio). No entanto, na falha de um endereço de e-mail, fechar e reabrir a conexão para uma nova tentativa às vezes ajudava. Em suma, isso realmente ajudou a acelerar as coisas.
• Algum óbvio, tão óbvio que quase esqueci de mencionar:seria um desperdício ter que criar o corpo do email na hora:se for um email geral, tenha o corpo pronto (alterei um pouco o PHPMailer para poder usar um e-mail em cache), possivelmente dias antes (se você saber você vai enviar um e-mail na sexta-feira e seu servidor está ocioso, por que não prepará-los na quarta-feira já? Se for personalizado, você ainda pode prepará-lo com antecedência, com tempo suficiente, se não, pelo menos, deixe as porções não personalizadas esperando para ir.
• Vários processos. Eu mencionei que grande parte do tempo que leva para entregar e-mail é gasto na rede? Um processo de envio de e-mails não está obtendo o máximo do seu servidor de e-mail, a carga quase imperceptível e os e-mails estão vazando. Brinque com vários processos enviando diferentes partes da fila para ver o que é certo para o seu servidor/conexão, mas lembre-se de 2 coisas muito importantes:
  • Diferentes processos tornam você muito vulnerável às condições da corrida:tenha certeza absoluta você tem um sistema completo que nunca enviar o mesmo e-mail duas vezes (três vezes, ou ainda mais). Além de irritar seriamente os usuários, sua spamração aumenta um pouco.
  • Mantenha os domínios juntos sempre que possível:escolhendo aleatoriamente na fila, você perderá a vantagem de manter uma conexão aberta com o servidor que recebe o e-mail do domínio.

Evitando rejeições

• Você vai enviar muitos e-mails. Isso é exatamente o que os spammers fazem. No entanto, você não quer ser visto como um spammer (afinal, você não é, não é)? Existem vários mecanismos em vigor que aumentarão completamente sua confiabilidade para receber os servidores:
• Ter um DNS reverso adequado:processa a verificação do DNS pertencente ao IP que está enviando o e-mail como muito muito se os domínios de segundo nível corresponderem:você está enviando e-mails em nome de example.com ? Verifique se o DNS reverso do seu servidor é algo como somename.example.com .
• Publique registros SPF para seu domínio:indique explicitamente que a máquina usada para enviar seu e-mail em massa tem permissão e espera-se que envie e-mails com os cabeçalhos From / Return-Path.
• lembre-se de rejeições :os servidores não gostam de lhe dizer repetidamente que não existem endereços de e-mail diferentes. Mecanismos automatizados e até administradores humanos bloquearam nosso servidor enquanto trabalhávamos em todos os endereços de e-mail não validados que (não mais) existiam. Nós não empregamos um duplo opt-in até mais tarde, então o banco de dados estava poluído com erros de digitação, pessoas trocando IPs e, portanto, endereço de e-mail, endereços de e-mail de brincadeira e assim por diante. Certifique-se de capturar esses inválidos e, se houver falhas suficientes ou suficientes, cancelar a inscrição . Eles não estão fazendo nenhum bem a você, estão monopolizando recursos e, se realmente quiserem que você envie e-mails e a caixa de correio ficar disponível mais tarde, eles terão que se inscrever novamente.
• O DKIM é outro mecanismo que pode aumentar sua confiabilidade, mas como ainda não o implementamos, não posso falar muito sobre isso.
• Registros MX:alguns servidores ainda gostam se seu servidor de envio também for o servidor de recebimento do domínio. Como era na época, tínhamos apenas 1 MX, e como o servidor de mailing ainda não estava muito ocupado, nós o apelidamos de servidor MX de fallback para o domínio. O servidor MX normal não o servidor que envia as assinaturas, pois é muito irritante ser bloqueado temporariamente por um servidor para o qual você está tentando enviar um e-mail importante (clientes etc.) porque você já enviou uma carga de e-mails menos importantes. Ele tem a maior preferência como recebimento de MX, mas no caso de falhar, tivemos o bom bônus de que nosso servidor de envio de assinatura ainda seria substituto para entrega, portanto, em crise, ainda poderíamos alcançá-lo, evitando devoluções desajeitadas para clientes tentando para chegar até nós.
• Fale sobre você. Seriamente. Muitos dos principais players de endereços de e-mail gratuitos, como live.com, oferecem a oportunidade de se inscrever de alguma forma ou ter algum ponto de contato para obter ajuda e suporte se seus e-mails forem rejeitados. Se você tem uma razão legítima para enviar tantos e-mails, e é crível que você tenha tantos assinantes, é provável que eles aumentem seriamente o número de e-mails que você pode enviar para o servidor por hora. Um mísero 1.000 pode se tornar algo entre as dez mil ou até mais se você for persuasivo e honesto o suficiente. Pode haver contratos, requisitos que você precisa cumprir e promessas que você deve fazer (e manter) para permitir isso. Os ISPs são uma marca à parte, e todos os outros players são diferentes. Não se preocupe em ligar para eles normalmente, porque 99% das vezes os únicos números que você pode encontrar só terão pessoas dispostas a solucionar problemas de sua conexão com a internet, que entendem (ou são permitidas) pouco mais. Um [email protected] endereço de e-mail é um bom lugar para começar, mas veja se você pode descobrir um endereço de e-mail mais direto de algum lugar. Seja preciso, honesto e completo:aproximadamente quantos assinantes de vocês têm um endereço de e-mail com esse ISP, com que frequência você está tentando enviá-los, quais são os erros ou negações que você recebe, como é o processo de inscrição e cancelamento de inscrição e o que é o serviço que você realmente fornece aos seus clientes. Além disso, seja legal:como o envio desses e-mails pode ser vital para o seu negócio, entrar em pânico e alegar perdas terríveis não os preocupa. Uma declaração educada de fatos e desejos e perguntando se eles podem ajudar em vez de exigir uma solução é muito importante.
• Limitação:por mais que você tente, alguns servidores aceitarão apenas uma certa quantidade de e-mails por hora e/ou dia de você. Aprenda esses números (estamos registrando sucessos e falhas de qualquer maneira), defina-os para um padrão razoável para os domínios normais, defina-os para limites acordados para jogadores maiores.

Evitando ser marcado como spam

• Primeira regra:não faça spam!
• Segunda regra:sempre! Não um 'uma vez', não um 'eles não se inscreveram, mas isso pode ser o negócio de uma vida para eles', não com as melhores intenções, as pessoas tiveram que pedir seus e-mails.
• Obviamente, configure um mecanismo correto de inscrição de dupla aceitação.
• O PHPMailer define os cabeçalhos adequados por conta própria,
• Configure um mecanismo fácil de cancelamento de inscrição pela web (inclua um link para ele em cada mail), possivelmente também e-mail e atendimento ao cliente, se você o tiver. Certifique-se de que o atendimento ao cliente pode cancelar a inscrição de pessoas diretamente.
• Como dito anteriormente:o cancelamento de inscrição (excessivo) falha e é rejeitado.
• Evite frases de "acordo para toda a vida" com spam.
• Use URLs em seus e-mails com moderação.
• Evite adicionar links para domínios fora de seu controle, a menos que tenha certeza absoluta de que pode confiar eles não para spam, se mesmo assim...
• Forneça valor ao usuário:ser marcado como spam pela interação do usuário em clientes de webmail do google/yahoo/live prejudica seriamente sucessos futuros (em uma nota do site:se você se inscrever, live/msn/hotmail encaminhará todos e-mails para você enviados pelo seu domínio que são marcados como spam pelos usuários. Aprenda a amá-los e, como sempre:cancele sua inscrição, eles claramente não querem seu shopping e estão prejudicando sua classificação de spam).
• Monitore as listas negras do seu IP. Se você aparecer em um desses, é tchau, então aja imediatamente para limpar seu nome e é necessário determinar o caso.

Medindo a taxa de sucesso

• Com todo o processo sob seu controle, você tem certeza de que o e-mail acabou em algum lugar (embora possa ser o bitbucket do MX ou uma pasta de spam), ou você registrou uma falha e o motivo. Isso cuida dos números 'realmente entregues'.
• Algumas pessoas tentarão convencê-lo a adicionar links para imagens online em seus e-mails (tanto reais quanto os famosos gifs transparentes 1x1) para medir quantas pessoas realmente leem seu e-mail. Como uma alta porcentagem bloqueia essas imagens, esses números são, na melhor das hipóteses, instáveis, e acreditamos que não devemos nos preocupar com eles, seus números não são totalmente confiáveis.
• Sua melhor aposta para medir a taxa de sucesso real é muito mais fácil se você quiser que os usuários façam algo. Adicione parâmetros aos links no e-mail, para que você possa medir quantos usuários chegam ao site que você vinculou, se eles realizaram as ações desejadas (assistiram a um vídeo, deixaram um comentário, compraram produtos).

Ao todo, com todo o registro, a interface do usuário, configurações configuráveis ​​por domínio / e-mail / usuário etc. Levamos cerca de 1,5 homem-mês para construir e resolver as peculiaridades. Isso pode ser um investimento e tanto comparado a terceirizar os e-mails, pode não ser, tudo depende do volume e do próprio negócio.

Agora, que comece a flaming que eu era um tolo para escrever um MTA em PHP, eu, pelo menos, gostei muito (que é uma das razões pelas quais escrevi essa enorme quantidade de texto), e os recursos de log e configurações extremamente versáteis, por host alertas baseados na porcentagem de falhas etc. estão tornando a transmissão ao vivo tão fácil;)