Un moyen sûr d'envoyer du courrier via PHP à de nombreux utilisateurs

Il n'y a aucune raison pour que vous ne puissiez pas l'écrire en PHP, même si je ne le ferais pas faites-en une partie d'un processus webrequest / HTTP. J'ai réussi à implémenter pour plus ou moins 500 000 abonnés par envoi (selon les données locales disponibles, car il s'agissait d'un projet spécifique à l'emplacement). C'était un projet interne, donc malheureusement pas de code/package pour vous, mais quelques pointeurs que j'ai rencontré :

Configuration de la livraison

J'ai commencé avec phpmailer lui-même, pour s'occuper du formatage, de l'encodage du contenu et des en-têtes, de l'ajout de pièces jointes, etc. Cette partie fonctionne bien, et je ne voudrais pas l'écrire à partir de zéro.
L'« envoi » d'un e-mail lui-même consiste simplement à définir un indicateur dans une base de données pour savoir si/comment/ce qui doit être envoyé à (une partie) des abonnés.
Une fois cet indicateur défini, il sera automatiquement récupéré par une tâche cron, plus aucun serveur Web n'est impliqué.
J'ai commencé avec une base de données fortement polluée avec des millions d'adresses e-mail, dont beaucoup n'étaient évidemment pas valides, donc la première chose était de valider toutes les adresses e-mail pour le format, puis pour l'hôte :
- filter_var($email, FILTER_VALIDATE_EMAIL); sur les abonnés (et en stockant le résultat évidemment) s'est débarrassé des premières centaines de milliers d'e-mails invalides.
- Diviser l'hôte (et stocker le nom d'hôte) à partir des e-mails, et en le validant (a-t-il un enregistrement MX ou au moins un enregistrement A dans le DNS, mais gardez à l'esprit :vous pouvez envoyer un e-mail à une adresse IP [email protected][255.255.255.255] , alors gardez-les valides)) débarrassez-vous d'une bonne partie de plus. Les adresses e-mail ici ne sont pas désactivé de façon permanente, mais avec un indicateur d'état qui indique qu'il est désactivé en raison du nom de domaine/IP.
- Les scripts ont été remplacés par require adresses e-mail valides lors de l'abonnement / avant l'insertion, ce non-sens de 'vous n'obtiendrez pas example@ sqldat.com ' la pollution des abonnements dans la base de données était tout simplement ridicule.
Maintenant, je me suis retrouvé avec une liste d'adresses e-mail susceptibles d'être valides. Il existe essentiellement 3 façons de détecter les adresses invalides (gardez à l'esprit que toutes peut être temporaire):
- Ils sont immédiatement refusés par le serveur.
- Le serveur déterminé précédemment n'écoute tout simplement pas le trafic.
- Ils sont renvoyés longtemps après que vous pensiez les avoir livrés.
Chose étrange, les rebonds, pour lesquels chaque serveur de messagerie semble avoir un autre format et étaient un enfer à analyser au début, se sont finalement avérés assez faciles à capturer en utilisant VERP . Plutôt que d'analyser des e-mails entiers, une adresse e-mail dédiée (appelons-la [email protected] ) a été configuré pour plutôt être livré à la boîte aux lettres, pour le diriger via une commande, et si nous avons envoyé un e-mail à [email protected] , le Return-Path a été défini pour [email protected] . Facilement analysé à la réception, et après combien de rebonds (la boîte aux lettres pourrait ne pas exister, la boîte aux lettres peut être pleine (oui, encore !), etc.) vous déclarez une adresse e-mail inutilisable, c'est à vous de décider.
Maintenant, le refus direct par le serveur. Nous aurions probablement pu configurer correctement certains MTA et/ou écrire des plugins pour ceux-ci, mais comme les e-mails étaient sensibles au temps, et nous devions avoir un contrôle configurable absolu par envoi sur le dernier délai de livraison utilisable (après quoi l'e-mail n'était plus d'intérêt pour l'utilisateur), throttling par serveur de réception, et généralement tout, cela prendrait à peu près le même temps d'écrire un mailer en PHP que nous connaissions mieux, qui utilisait le protocole SMTP directement au socket 25 sur les serveurs de réception. Avec un minimum d'effort, la possibilité d'un autre transport que les choix par défaut dans PHPMailer a été intégrée. Le protocole SMTP est en fait assez simple, mais il y a quelques mises en garde :
- De nombreux serveurs de réception appliquent la liste grise :la plupart des spambots ne se soucient pas vraiment de l'arrivée d'un e-mail spécifique, ils se contentent de le produire. Ainsi, si un expéditeur inconnu / pas encore fiable envoie un courrier, celui-ci sera temporairement rejeté. Attrapez-le (généralement le code 451) et placez l'e-mail dans la file d'attente pour une nouvelle tentative ultérieure.
- Un serveur de messagerie, en particulier des plus grands FAI et des services gratuits (gmail, hotmail/msn/live, etc.) ne supportera pas un torrent de courrier sans riposter :après les premières centaines/milliers, ils commencent à rejeter tu. Plus d'informations à ce sujet plus tard.

Gagner en vitesse

Maintenant, nous avions un système de livraison qui fonctionnait, mais il devait être rapide . Envoyer 10 000 e-mails en une heure est très bien si vous n'avez que 10 000 adresses à envoyer, mais le minimum requis était d'environ 200 000 par heure. Au départ, il s'agissait d'un serveur dédié (qui peut en fait être assez peu puissant, peu importe ce que vous faites, la plupart du temps consacré à la livraison des e-mails se fait sur le réseau, pas sur votre serveur).
Mise en cache des adresses IP :vous souvenez-vous de toutes les adresses IP que nous avons demandées aux noms d'hôte dans les adresses e-mail ? Nous les avons évidemment stockées, et rechercher encore et encore leurs adresses IP provoque un retard considérable. Cependant, les adresses IP peuvent changer :un enregistrement DNS là, un autre MX à un autre endroit... les données deviennent rapidement obsolètes. La plupart du temps, le serveur n'envoie rien (les newsletters d'abonnement arrivent évidemment en rafales), une tâche cron de faible priorité est en cours d'exécution en vérifiant tous les noms d'hôtes avec une adresse IP obsolète (nous avons choisi plus d'un jour comme étant obsolète) pour une adresse IP , y compris ceux qui n'en avaient pas auparavant (de nouveaux domaines sont enregistrés tout le temps, alors pourquoi un domaine ne deviendrait-il pas disponible le lendemain du jour où quelqu'un s'est déjà abonné avec enthousiasme avec sa toute nouvelle adresse e-mail ? Ou des problèmes de serveur avec certains domaines sont résolus, etc.). En fait, l'envoi des e-mails ne nécessitait plus de recherche de domaine.
Réutilisation de la connexion SMTP :la configuration d'une connexion à un serveur prend relativement beaucoup de temps pour envoyer un e-mail lorsque vous parlez directement au port 25. Vous n'avez pas besoin de configurer une nouvelle connexion pour chaque e-mail, vous pouvez simplement envoyer le suivant sur la même connexion. Un peu de piste et d'erreur a abouti à la définition de la valeur par défaut ici à environ 50 e-mails par connexion (en supposant que vous en ayez autant ou plus pour le domaine). Cependant, en cas d'échec d'une adresse e-mail, la fermeture et la réouverture de la connexion pour une nouvelle tentative ont parfois aidé. Dans l'ensemble, c'est vraiment a contribué à accélérer les choses.
Quelque chose d'évident, tellement évident que j'ai presque oublié de le mentionner :ce serait du gaspillage de devoir créer le corps de l'e-mail sur-le-champ :s'il s'agit d'un e-mail général, préparez le corps (j'ai quelque peu modifié PHPMailer pour être en mesure d'utiliser un e-mail en cache), éventuellement des jours avant (si vous savez vous allez envoyer un mail vendredi, et votre serveur tourne au ralenti, pourquoi ne pas les préparer déjà mercredi ? S'il est personnalisé, vous pouvez toujours le préparer à l'avance avec suffisamment de temps, sinon, au moins avoir les portions non personnalisées qui attendent d'être emportées.
Plusieurs processus. Ai-je mentionné qu'une grande partie du temps nécessaire à la livraison des e-mails est passée sur le réseau ? Un processus d'envoi ne tire pas le meilleur parti de votre serveur de messagerie, une charge à peine perceptible et les e-mails s'écoulent. Jouez avec un certain nombre de processus envoyant différentes parties de la file d'attente pour voir ce qui convient à votre serveur/connexion, mais souvenez-vous de 2 choses très importantes :
- Différents processus vous rendent très vulnérable aux conditions de concurrence :soyez superbement sûr vous avez un système à toute épreuve qui jamais envoyer le même courrier deux fois (trois fois, voire plus). Non seulement cela agace sérieusement les utilisateurs, mais votre spamrating monte d'un cran.
- Gardez les domaines ensemble dans la mesure du possible :en choisissant au hasard dans la file d'attente, vous perdrez l'avantage de conserver une connexion ouverte au serveur recevant les e-mails pour le domaine.

Éviter les rejets

Vous allez envoyer beaucoup de courrier. C'est exactement ce que font les spammeurs. Cependant, vous ne voulez pas être considéré comme un spammeur (après tout, vous ne l'êtes pas, n'est-ce pas) ? Il existe un certain nombre de mécanismes en place qui augmenteront considérablement votre fiabilité vis-à-vis des serveurs de réception :
Avoir un DNS inversé approprié :les processus vérifiant le DNS appartenant à l'adresse IP qui envoie l'e-mail l'aiment très beaucoup si les domaines de second niveau correspondent :envoyez-vous des e-mails au nom de example.com ? Assurez-vous que le DNS inversé de votre serveur est quelque chose comme somename.example.com .
Publier les enregistrements SPF pour votre domaine :indiquez explicitement que la machine utilisée pour envoyer vos e-mails en masse est autorisée et censée envoyer des e-mails avec ces en-têtes From/Return-Path.
se souvenir des rejets :les serveurs n'aiment pas qu'on vous répète sans cesse que différentes adresses e-mail n'existent pas. Des mécanismes automatisés, et même des administrateurs humains, ont bloqué notre serveur pendant que nous travaillions sur toutes les adresses e-mail non validées qui n'existaient (plus). Nous n'avons utilisé un double opt-in que plus tard, de sorte que la base de données a été polluée par des fautes de frappe, des personnes changeant d'adresse IP et donc d'adresse e-mail, d'adresses e-mail farfelues, etc. Assurez-vous de capturer ces invalides, et compte tenu de suffisamment ou de plusieurs échecs, désinscrivez-les . Ils ne vous font aucun bien, ils accaparent les ressources, et s'ils veulent vraiment que vous receviez du courrier et que la boîte aux lettres devienne disponible plus tard, ils n'auront qu'à se réabonner.
DKIM est un autre mécanisme qui peut augmenter votre fiabilité, mais comme nous ne l'avons pas (encore) mis en œuvre, je ne peux pas vous en dire plus.
Enregistrements MX :certains serveurs apprécient toujours que votre serveur d'envoi soit également le serveur de réception du domaine. Comme c'était le cas à l'époque, nous n'avions que 1 MX, et comme le serveur de messagerie n'était pas encore très occupé, nous l'avons surnommé le serveur MX de secours pour le domaine. Le serveur MX normal n'était pas le serveur envoyant les abonnements, car il est très irritant d'être temporairement bloqué par un serveur auquel vous essayez d'envoyer un e-mail important (clients, etc.) car vous avez déjà envoyé une charge d'e-mails moins importants. Il a la préférence la plus élevée pour recevoir MX, mais en cas d'échec, nous avions le joli bonus que notre serveur d'envoi d'abonnement serait toujours de secours pour la livraison, donc en cas de crise, nous pourrions toujours y accéder, empêchant les rebonds gênants pour les clients essayant pour nous joindre.
Parlez-leur de vous. Sérieusement. De nombreux acteurs majeurs des adresses e-mail gratuites comme live.com vous offrent la possibilité de vous inscrire d'une manière ou d'une autre, ou d'avoir un point de contact vers lequel vous tourner pour obtenir de l'aide et de l'assistance si vos e-mails sont rejetés. Si vous avez une raison légitime d'envoyer autant d'e-mails et qu'il est probable que vous ayez autant d'abonnés, il y a de fortes chances qu'ils augmentent sérieusement le nombre d'e-mails que vous pouvez envoyer à leur serveur par heure. Un maigre 1 000 peut devenir quelque part dans les dix mille ou même plus si vous êtes suffisamment persuasif et honnête. Il peut y avoir des contrats, des exigences que vous devez remplir et des promesses que vous devez faire (et tenir) pour y être autorisé. Les FAI sont une marque à part, et tous les autres joueurs sont différents. Ne vous embêtez pas à les appeler habituellement, car 99% du temps, les seuls numéros que vous pouvez trouver n'auront que des personnes disposées à dépanner votre connexion Internet, qui ne comprennent (ou ne sont autorisées) que peu de choses. Un [email protected] L'adresse e-mail est un bon point de départ, mais voyez si vous pouvez trouver une adresse e-mail plus précise à partir de quelque part. Soyez précis, honnête et complet :environ combien d'abonnés parmi vous ont une adresse e-mail auprès de ce FAI, à quelle fréquence essayez-vous de leur envoyer des e-mails, quelles sont les erreurs ou les refus que vous recevez, à quoi ressemble le processus d'abonnement et de désabonnement, et quel est le service que vous fournissez réellement à leurs clients. Aussi, soyez gentil :à quel point l'envoi de ces e-mails peut être vital pour votre entreprise, paniquer à ce sujet et réclamer de terribles pertes ne les concerne pas. Une déclaration polie des faits et des souhaits, et demander s'ils peuvent aider plutôt que d'exiger une solution va un très long chemin.
Throttling :autant que vous avez essayé, certains serveurs n'accepteront qu'une certaine quantité de courrier par heure et/ou par jour de votre part. Apprenez ces chiffres (nous enregistrons de toute façon les succès et les échecs), définissez-les sur une valeur par défaut raisonnable pour les domaines normaux, définissez-les sur des limites convenues pour les plus gros joueurs.

Éviter d'être marqué comme spam

Première règle :ne spammez pas !
Deuxième règle :jamais ! Pas un "une fois", pas un "ils ne se sont pas abonnés mais cela peut être l'affaire d'une vie pour eux", pas avec les meilleures intentions, les gens ont dû demander vos e-mails.
Évidemment, mettez en place un mécanisme d'abonnement double opt-in correct.
PHPMailer définit lui-même les en-têtes appropriés,
Mettre en place un mécanisme de désabonnement facile, par le Web (inclure un lien vers celui-ci dans chaque mail), éventuellement aussi par e-mail et service client si vous l'avez. Assurez-vous que le service client peut désabonner directement les personnes.
Comme dit précédemment :la désinscription (excessive) échoue et rebondit.
Évitez les formulations spammées "l'affaire d'une vie".
Utilisez les URL dans vos e-mails avec parcimonie.
Évitez d'ajouter des liens vers des domaines hors de votre contrôle, sauf si vous êtes absolument sûr de pouvoir leur faire confiance ne pas spammer, même alors...
Fournit de la valeur à l'utilisateur :être marqué comme spam par l'interaction de l'utilisateur dans les clients de messagerie Web google/yahoo/live nuit gravement aux succès futurs (sur une note de site :si vous vous inscrivez, live/msn/hotmail transférera tous mail que vous envoyez par votre domaine et qui est marqué comme spam par les utilisateurs. Apprenez à l'aimer, et comme toujours :désabonnez-les, ils ne veulent clairement pas de votre mail et nuisent à votre classement spam).
Surveillez les listes noires de votre adresse IP. Si vous apparaissez sur l'un d'entre eux, c'est au revoir, alors action immédiate pour effacer votre nom et déterminer le cas est nécessaire.

Mesurer le taux de réussite

Avec l'ensemble du processus sous votre contrôle, vous êtes raisonnablement sûr que l'e-mail s'est retrouvé quelque part (bien qu'il puisse s'agir du bitbucket du MX ou d'un dossier de spam), ou vous avez enregistré un échec et la raison. Cela prend en charge les nombres "réellement livrés".
Certaines personnes essaieront de vous convaincre d'ajouter des liens vers des images en ligne à vos e-mails (soit réels, soit le fameux gif transparent 1x1) pour mesurer combien de personnes lisent réellement votre e-mail. Comme un pourcentage élevé bloque ces images, ces chiffres sont au mieux fragiles, et nous pensons que nous ne devrions pas nous en soucier, car leurs chiffres ne sont absolument pas fiables.
Votre meilleur pari pour mesurer le taux de réussite réel est beaucoup plus facile si vous voulez que les utilisateurs fassent quelque chose. Ajoutez des paramètres aux liens dans l'e-mail, afin de pouvoir mesurer le nombre d'utilisateurs qui arrivent sur le site que vous avez lié, s'ils ont effectué les actions souhaitées (regardé une vidéo, laissé un commentaire, acheté des biens).

Dans l'ensemble, avec toute la journalisation, l'interface utilisateur, les paramètres configurables par domaine / e-mail / utilisateur, etc. Il nous a fallu environ 1,5 homme-mois pour créer et corriger les bizarreries. Cela peut représenter un investissement considérable par rapport à l'externalisation des e-mails, mais ce n'est peut-être pas le cas, tout dépend du volume et de l'activité elle-même.

Maintenant, laissez le flamboiement commencer que j'étais un imbécile pour écrire un MTA en PHP, pour ma part, j'ai vraiment apprécié (ce qui est l'une des raisons pour lesquelles j'ai écrit cette énorme quantité de texte), et les capacités de journalisation et de paramètres extrêmement polyvalentes, par hôte les alertes basées sur le pourcentage d'échec, etc. rendent la vie si facile ;)