Comment envoyer 100 000 e-mails par semaine? [fermé]
Comment envoyer un e-mail à 100.000 utilisateurs sur une base hebdomadaire en PHP? Cela inclut le courrier envoyé aux abonnés par les fournisseurs suivants:
- AOL
- G-Mail
- Hotmail
- Yahoo
il est important que tous les courriels soient effectivement transmis, dans la mesure du possible. De toute évidence, envoyer le courrier de manière conventionnelle ne ferait que créer problème.
y a-t-il une bibliothèque pour PHP qui simplifie cela?
3 réponses
brève réponse: alors qu'il est techniquement possible d'envoyer des e-mails De 100k chaque semaine vous-même, la solution la plus simple, la plus facile et la moins chère est de externaliser ce à l'une des entreprises qui se spécialisent en elle (I did say "bon marché": il n'y a aucune limite à la quantité de temps de développement (et donc d'argent) que vous pouvez sombrer dans cela en essayant de bricolage).
longue réponse: si vous décidez que vous voulez absolument pour le faire vous-même, préparez-vous pour un monde de mal (après tout, c'est e-mail/e-fail dont nous parlons). Vous aurez besoin de:
- e-mail contenu que" 15198090920 "n'est pas spam (autrement, vous allez rencontrer des obstacles supplémentaires majeurs à chaque étape, même des répercussions juridiques)
- en outre, votre contenu doit être facile à distinguer de spam-qui peut être un peu difficile à faire dans certains cas (j'ai entendu dire qu'une certaine compagnie pharmaceutique a dû tout sauf abandonner e-mail, que leurs noms de marque sont assez communs dans les spams)
- un serveur SMTP configurable par vous-même, un qui ne fléchira pas lorsque vous y déverserez 100k e-mails (le serveur amont de votre FAI ne sera pas suffisant ici et vous rendrez le FAI violemment malheureux; nous avons utilisé deux boîtes dédiées)
- certains emballages de courrier (par exemple PhpMailer si PHP est votre poison de choix; Utiliser
mail()
de PHP est assez horrible en soi) - votre propre fonction d'expéditeur pour exécuter dans une boucle, créer les mails et les passer au wrapper (notez que vous pouvez courir dans les limites de mémoire de PHP si votre application a une fuite de mémoire; vous pouvez avoir besoin de recycler le processus d'envoi périodiquement, ou même mieux, découpler la "création d'e-mails" et "l'envoi d'e-mails" tout à fait)
étonnamment, c'était la partie la plus facile. Le plus dur, c'est de l'envoyer:
- certains serveurs vous interdiront lorsque vous envoyez trop de mails en même temps, vous devez donc mélanger et surveiller votre file d'attente (par exemple, envoyer un mail à joe@example.com, puis trois à d'autres domaines, seulement alors un autre à otheraddress@example.com)
- vous devez avoir correct PTR, SPF, DKIM records
- gestion des temps morts du serveur distant, mal configuré enregistrements DNS et d'autres paramètres réseau plaisanteries
- traitement des e-mails invalides (et non, regex est le mauvais outil pour que )
- traitement des désinscriptions (de nombreux bulletins d'information légitimes ont été reclassés comme spam en raison de nombreux utilisateurs frustrés qui ne pouvaient pas se désabonner en une seule étape et ont plutôt choisi de "marquer comme spam" - les filtres de spam ne apprendre, en particulier. avec de grands fournisseurs de courrier électronique)
- manipulation rebonds et rebuts ("no such mailbox ojhn@example.com", "Boîte aux lettres john@example.com full")
- gérer liste noire et retrait des listes noires (bien sûr, vous n'envoyez pas de spam. Certains destinataires ne seront pas si sûr - avec une si grande liste, il va se produire parfois, peu importe les précautions que vous prenez. Certaines personnes (par exemple vos concurrents pas-si-scrupuleux) pourraient même aller aussi loin pour rapporter faussement vos mailings en tant que spam - il se produit. On moyenne , il faut des semaines pour se faire retirer d'une liste noire.)
et pour couronner le tout, vous devrez gérer la partie juridique de celui-ci (diverses lois fédérales, d'état et locales; et même différents enchevêtrements de lois une fois que vous envoyez hors des États-Unis (note: vous n'avez aucun moyen de trouver si joe@hotmail.com vit dans le sud-ouest de L'Elbonie, le pays aux lois antispam les plus draconiennes du monde)).
je suis presque sûr que j'ai manqué quelques têtes de cette hydra - êtes-vous toujours sûr que vous voulez le faire vous-même? Si oui, il y aura une autre vague, cette fois simplement ennuyeux problèmes inhérents à l'envoi d'un e-mail. (Vous voyez, SMTP est un protocole de stockage et de transfert, ce qui signifie que votre e-mail sera mélangé sur de nombreux serveurs SMTP autour de L'Internet, dans l'espoir que le prochain est un peu plus proche du destinataire final. Fondamentalement, l'e-mail est envoyé à un serveur SMTP, ce qui le place dans sa file d'attente forward; quand le temps viendra, il le fera suivre suite à un serveur SMTP différent, jusqu'à ce qu'il atteigne le serveur SMTP pour le domaine donné. Cela pourrait se produire immédiatement ou en quelques minutes, ou heures, ou jours, ou jamais.) Ainsi, vous verrez les problèmes suivants - dont la plupart pourraient se produire en route aussi bien qu'à destination:
- les serveurs SMTP distants ne veulent pas parler à votre serveur SMTP
- vos mails sont marqués comme spam (
<blink>
n'est pas votre ami ici, pas plus que<font color=...>
) - vos mails sont livrés jours, voire des semaines de retard (contrairement à l'opinion populaire, SMTP est conçu pour faire un meilleur effort pour remettre le message dans le courant de l'avenir de ne pas le remettre maintenant)
- vos e-mails ne sont pas livrés du tout (déjà envoyés depuis le serveur e-mail sur hop #4, pas encore envoyés depuis le serveur sur hop #5, le serveur qui détient actuellement le message s'écrase, les données sont perdues)
- vos mails sont mutilé par un serveur de braindead en route (celui-ci est quelque peu soluble avec l'encodage base64, mais alors la taille augmente et l'e-mail semble plus suspect)
- vos mails sont livrés et les destinataires semblent ne pas les vouloir ("je suis sûr que je ne me suis pas engagé pour cela, je me souviens exactement de ce que j'ai fait il y a un an" (bien sûr que vous le faites, Monsieur))
- utilisateurs avec diverses versions de Microsoft Outlook et son spécial traitement du courrier sur Internet
- assistant apprenti mode (un auto-renforcement de la boucle de rétroaction positive - en d'autres termes, automated e-mails comme des réponses aux automated e-mails comme des réponses...; vous vraiment ne veulent pas être le seul à le définir, comme vous pouvez vous en colère de la moitié de l'internet, à vous-même)
et il va être votre emploi afin d'identifier et de résoudre ce (astuce: vous ne pouvez pas, la plupart du temps). Le les gens qui dirigent des entreprises légales de mailing de masse savent qu'à la fin vous ne pouvez pas le résoudre, et qu'ils ne peuvent pas le résoudre non plus - et ils ont les raisons bien étudiées, documentées et esquissées (peut - être même comme une présentation Powerpoint - complète avec des sons et des transitions cool-que vos patrons peuvent comprendre), comme ils ont dû l'expliquer un million de fois avant. De Plus, pour les problèmes qui sont réellement solvables, ils savent très bien comment les résoudre.
si, après tout cela, vous n'êtes pas découragés et vous voulez toujours le faire, allez-y: il est même possible que vous trouviez une meilleure façon de le faire. Sachez juste que la route ne sera pas facile - l'envoi d'e-mail est trivial, il est livré dur.
les gens ont recommandé MailChimp qui est un bon vendeur pour le courrier électronique en vrac. Si vous êtes à la recherche d'un bon fournisseur pour le courriel transactionnel, je pourrais être en mesure d'aider.
au cours des 6 derniers mois, nous avons utilisé quatre fournisseurs SMTP différents dans le but de déterminer lequel était le meilleur.
Voici un résumé de ce que nous avons trouvé...
- les moins chers
- Aucune analyse/reporting
- Pas de suivi pour ouvre et clique sur
- légère hésitation sur certaines envoie
- Très bon marché, mais pas aussi bon marché que AuthSMTP
- beau cpanel mais pas de suivi sur s'ouvre / clics
- suivi des activités au niveau de L'envoi afin que vous puissiez ouvrir un seul e-mail ça a été envoyé et regardez à quoi ça ressemblait et les données de livraison.
- doit utiliser L'API. L'envoi par SMTP a été introduit récemment mais il est buggy. Par exemple, nous avons remarqué que les citations (") dans la ligne d'objet sont dépouillées.
- ne peut pas envoyer de pièce jointe. Doit être approuvée la liste des types de fichiers et sous une certaine taille. (10 MB je pense)
- nécessite une liste de noms/adresses.
- cher par rapport aux autres – plus de 10 fois dans certains cas
- Laid cpanel, mais grande de suivi sur l'ouvre et clique avec le courrier électronique-niveau de détail
- hésitait parfois lors de l'envoi. À deux reprises, les envois ont pris une heure pour être livré
- Nécessite une liste de nom, adresses.
- Pas tout à fait un bon marché que AuthSMTP mais encore très bon marché. De nombreux clients peuvent exister sur 200 envois gratuits par jour.
- Décent cpanel, mais pas en profondeur les détails sur open/cliquez sur "suivi 1519120920"
- beaucoup D'options API. Options (ouvrir/cliquez sur le suivi, etc) peuvent être personnalisées sur un e-mail par e-mail. Les e-mails entrants (en réponse) peuvent être envoyés à notre point D'arrivée HTTP.
- Absolument aucune hésitation sur l'envoie. Chaque courriel envoyé atterrissait presque immédiatement dans la boîte de réception.
- peut envoyer de n'importe quel de nom/adresse.
Conclusion
SendGrid était le meilleur avec le cachet de la poste à la deuxième place. Nous n'avons jamais vu aucune hésitation dans send times avec l'un ou l'autre de ces deux - dans certains cas, nous avons envoyé plusieurs centaines d'e - mails à la fois-et ils ont tous les deux le meilleur retour sur investissement, compte tenu d'un solide featureset.
voici ce que j'ai fait récemment en PHP sur un de mes plus grands systèmes:
-
l'utilisateur entre le texte du bulletin et sélectionne les destinataires (ce qui génère une requête pour récupérer les adresses email pour plus tard).
-
ajouter le texte du bulletin et la requête des destinataires à une ligne dans la table mysql appelée * email_queue*
- (le tableau email_queue a les colonnes "à" "Sujet" "corps" "la priorité")
-
j'ai créé un autre script, qui tourne chaque minute comme un travail cron. Il utilise la classe SwiftMailer . Ce script simplement:
-
pendant les heures de bureau, envoie tous les courriels avec priorité == 0
-
après les heures de bureau, envoyer d'autres e-mails par priorité
-
en fonction des paramètres de l'hôte, je peux maintenant l'activer à l'aide de plugins swiftmailers standard comme antiflood et throttle...
$mailer->registerPlugin(new Swift_Plugins_AntiFloodPlugin(50, 30));
et
$mailer->registerPlugin(new Swift_Plugins_ThrottlerPlugin( 100, Swift_Plugins_ThrottlerPlugin::MESSAGES_PER_MINUTE ));
etc, etc..
Je l'ai étendu bien au-delà de ce pseudo, avec des pièces jointes, et de nombreux autres paramètres configurables, mais il fonctionne très bien tant que votre serveur est configuré correctement pour envoyer des e-mails. (Ne fonctionne probablement pas sur l'hébergement partagé, mais en la théorie elle devrait...) Swiftmailer a même un paramètre
$message->setReturnPath
que j'utilise maintenant pour suivre les rebonds...
Happy Trails! (Heureux E-Mails?)