如何每周发送 100,000 封电子邮件?

发布于 2024-09-27 06:45:21 字数 217 浏览 13 评论 0原文

如何使用 PHP 每周向 100,000 个用户发送一封电子邮件?这包括使用以下提供商发送给订阅者的邮件:

  • AOL
  • G-Mail
  • Hotmail
  • Yahoo

重要的是,所有电子邮件均应尽可能实际交付。显然,仅仅按照惯例发送邮件只会产生问题。

有没有 PHP 库可以让这件事变得更简单?

How can one send an email to 100,000 users on a weekly basis in PHP? This includes mail to subscribers using the following providers:

  • AOL
  • G-Mail
  • Hotmail
  • Yahoo

It is important that all e-mail actually be delivered, to the extent that it is possible. Obviously, just sending the mail conventionally would do nothing but create problems.

Is there a library for PHP that makes this simpler?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

愿与i 2024-10-04 06:45:21

简短回答:虽然从技术上讲,您自己每周发送 10 万封电子邮件是可能的,但最简单、最容易且最便宜的解决方案是外包给专门从事电子邮件发送的公司之一它(我确实说过“最便宜”:在尝试 DIY 时,您可以投入的开发时间(以及金钱)是没有限制的)。

长答案:如果您决定绝对想要自己做这件事,请做好迎接受伤世界的准备(毕竟,这是我们的电子邮件/电子邮件失败)正在谈论)。您需要:

  • 电子邮件内容不是垃圾邮件(否则您在每一步都会遇到额外的主要障碍,甚至法律后果)
  • 此外,您的内容应该易于与垃圾邮件区分开来 - 在某些情况下这可能有点困难(我听说某家制药公司不得不放弃电子邮件,因为他们的品牌名称在垃圾邮件中很常见)
  • 可配置的 SMTP 服务器你自己的,当你将 100k 电子邮件转储到它上面时不会崩溃(你的 ISP 的上游服务器在这里不够用,你会让 ISP 非常不高兴;我们使用了两个专用的盒子)
  • 一些邮件包装器(例如,PhpMailer(如果 PHP 是您选择的毒药;使用 PHP 的 mail() 本身就足够可怕了)
  • 您自己的发送器函数在循环中运行,创建邮件并将它们传递给包装器(请注意,您如果您的应用程序存在内存泄漏,则可能会遇到 PHP 的内存限制;您可能需要定期回收发送进程,或者更好的是,将“创建电子邮件”和“发送电子邮件”完全解耦)

令人惊讶的是,这就是简单的部分。困难的部分实际上是发送它:

  • 当您发送太多靠近在一起的邮件时,某些服务器会禁止您,因此您需要洗牌并观察您的队列(例如,将一封邮件发送到 [电子邮件受保护],然后三个到其他域,然后另一个到 [email protected]
  • 您需要拥有正确的 PTR、SPF、DKIM 记录
  • 处理远程服务器超时、配置错误的 DNS 记录和其他网络问题
  • 处理无效电子邮件(不,正则表达式是错误的工具
  • 处理取消订阅(许多合法的新闻通讯已被重新归类为垃圾邮件,因为许多沮丧的用户无法一步取消订阅,而是选择“标记为垃圾邮件” - 垃圾邮件过滤器一定要学习,特别是。与大型电子邮件提供商)
  • 处理退回邮件和拒绝(“没有这样的邮箱 [电子邮件受保护] ","邮箱[电子邮件受保护]完整")
  • 处理列入黑名单和从黑名单中删除(当然,您没有发送垃圾邮件。有些收件人不会那么确定 - 对于如此大的列表,无论您采取什么预防措施,有时都会发生这种情况。有些人(例如,不那么谨慎的竞争对手)甚至可能会错误地将您的邮件报告为垃圾邮件 - 平均确实会发生这种情况,您需要几周的时间才能将自己从黑名单中删除。

)最重要的是,您必须管理其中的法律部分(各种联邦、州和地方法律;甚至一旦您将其发送到美国境外,还要处理不同的法律问题(注意:您无法确定是否[email protected] 居住在西南埃尔伯尼亚,该国拥有世界上最严厉的反垃圾邮件法) )。

我很确定我错过了这个九头蛇的几个头 - 你仍然确定要自己做吗?如果是这样,将会出现另一波浪潮,这一次只是发送电子邮件固有的烦人问题。 (您看,SMTP 是一种存储转发协议,这意味着您的电子邮件将在 Internet 上的许多 SMTP 服务器上进行传输,希望下一封邮件更接近最终收件人。基本上,电子邮件被发送到 SMTP 服务器,该服务器将其放入转发队列,当时间到来时,它会将其进一步转发到不同的 SMTP 服务器,直到到达给定域的 SMTP 服务器。 ,或在几分钟内,或几小时内,或几天内,或永远不会。)因此,您将看到以下问题 - 其中大多数可能发生在途中以及目的地:

  • 远程 SMTP 服务器不希望与您的 SMTP 服务器对话,
  • 您的邮件被标记为垃圾邮件( 不是您的朋友, 也不是您的朋友)
  • 您的邮件晚了几天甚至几周才送达(与流行观点相反,SMTP 旨在尽最大努力在将来某个时间送达邮件 - 而不是现在送达)
  • 您的邮件根本没有送达(已经从 e 发送 ) -跃点 #4 上的邮件服务器,尚未从跃点 #5 上的服务器发送,当前保存消息的服务器崩溃,数据丢失)
  • 您的邮件在途中被某个脑残服务器破坏(这可以通过 Base64 编码解决) ,但随后大小增大,电子邮件看起来更加可疑)
  • 您的邮件已送达,但收件人似乎不想要它们(“我确定我没有注册此邮件,我清楚地记得一年前我所做的事情”(当然,您记得,先生))
  • 使用不同版本的 Microsoft Outlook 及其特殊互联网邮件向导
  • 学徒模式的用户(一种自我强化的积极反馈)循环 - 换句话说,自动电子邮件作为对自动电子邮件的回复作为对...的回复;你真的不想成为引发这种情况的人,因为你会激怒半个互联网的人)

,并且的工作就是解决问题并解决问题解决这个问题(提示:大多数情况下你不能)。经营合法群发邮件业务的人知道,最终你无法解决它,他们也无法解决它 - 并且他们对原因进行了充分研究、记录和概述(甚至可能作为 Powerpoint 演示文稿) - 配有声音和酷炫的过渡 - 您的老板可以理解),因为他们之前已经解释过这一点一百万次了。另外,对于真正可以解决的问题,他们非常清楚如何解决。

如果在完成这一切之后,您没有气馁并且仍然想这样做,那就继续吧:您甚至可能会找到更好的方法来做到这一点。只是要知道,前面的路并不容易——发送电子邮件是微不足道的,而送达它却很难。

Short answer: While it's technically possible to send 100k e-mails each week yourself, the simplest, easiest and cheapest solution is to outsource this to one of the companies that specialize in it (I did say "cheapest": there's no limit to the amount of development time (and therefore money) that you can sink into this when trying to DIY).

Long answer: If you decide that you absolutely want to do this yourself, prepare for a world of hurt (after all, this is e-mail/e-fail we're talking about). You'll need:

  • e-mail content that is not spam (otherwise you'll run into additional major roadblocks on every step, even legal repercussions)
  • in addition, your content should be easy to distinguish from spam - that may be a bit hard to do in some cases (I heard that a certain pharmaceutical company had to all but abandon e-mail, as their brand names are quite common in spams)
  • a configurable SMTP server of your own, one which won't buckle when you dump 100k e-mails onto it (your ISP's upstream server won't be sufficient here and you'll make the ISP violently unhappy; we used two dedicated boxes)
  • some mail wrapper (e.g. PhpMailer if PHP's your poison of choice; using PHP's mail() is horrible enough by itself)
  • your own sender function to run in a loop, create the mails and pass them to the wrapper (note that you may run into PHP's memory limits if your app has a memory leak; you may need to recycle the sending process periodically, or even better, decouple the "creating e-mails" and "sending e-mails" altogether)

Surprisingly, that was the easy part. The hard part is actually sending it:

  • some servers will ban you when you send too many mails close together, so you need to shuffle and watch your queue (e.g. send one mail to [email protected], then three to other domains, only then another to [email protected])
  • you need to have correct PTR, SPF, DKIM records
  • handling remote server timeouts, misconfigured DNS records and other network pleasantries
  • handling invalid e-mails (and no, regex is the wrong tool for that)
  • handling unsubscriptions (many legitimate newsletters have been reclassified as spam due to many frustrated users who couldn't unsubscribe in one step and instead chose to "mark as spam" - the spam filters do learn, esp. with large e-mail providers)
  • handling bounces and rejects ("no such mailbox [email protected]","mailbox [email protected] full")
  • handling blacklisting and removal from blacklists (Sure, you're not sending spam. Some recipients won't be so sure - with such large list, it will happen sometimes, no matter what precautions you take. Some people (e.g. your not-so-scrupulous competitors) might even go as far to falsely report your mailings as spam - it does happen. On average, it takes weeks to get yourself removed from a blacklist.)

And to top it off, you'll have to manage the legal part of it (various federal, state, and local laws; and even different tangles of laws once you send outside the U.S. (note: you have no way of finding if [email protected] lives in Southwest Elbonia, the country with world's most draconian antispam laws)).

I'm pretty sure I missed a few heads of this hydra - are you still sure you want to do this yourself? If so, there'll be another wave, this time merely the annoying problems inherent in sending an e-mail. (You see, SMTP is a store-and-forward protocol, which means that your e-mail will be shuffled across many SMTP servers around the Internet, in the hope that the next one is a bit closer to the final recipient. Basically, the e-mail is sent to an SMTP server, which puts it into its forward queue; when time comes, it will forward it further to a different SMTP server, until it reaches the SMTP server for the given domain. This forward could happen immediately, or in a few minutes, or hours, or days, or never.) Thus, you'll see the following issues - most of which could happen en route as well as at the destination:

  • the remote SMTP servers don't want to talk to your SMTP server
  • your mails are getting marked as spam (<blink> is not your friend here, nor is <font color=...>)
  • your mails are delivered days, even weeks late (contrary to popular opinion, SMTP is designed to make a best effort to deliver the message sometime in the future - not to deliver it now)
  • your mails are not delivered at all (already sent from e-mail server on hop #4, not sent yet from server on hop #5, the server that currently holds the message crashes, data is lost)
  • your mails are mangled by some braindead server en route (this one is somewhat solvable with base64 encoding, but then the size goes up and the e-mail looks more suspicious)
  • your mails are delivered and the recipients seem not to want them ("I'm sure I didn't sign up for this, I remember exactly what I did a year ago" (of course you do, sir))
  • users with various versions of Microsoft Outlook and its special handling of Internet mail
  • wizard's apprentice mode (a self-reinforcing positive feedback loop - in other words, automated e-mails as replies to automated e-mails as replies to...; you really don't want to be the one to set this off, as you'd anger half the internet at yourself)

and it'll be your job to troubleshoot and solve this (hint: you can't, mostly). The people who run a legit mass-mailing businesses know that in the end you can't solve it, and that they can't solve it either - and they have the reasons well researched, documented and outlined (maybe even as a Powerpoint presentation - complete with sounds and cool transitions - that your bosses can understand), as they've had to explain this a million times before. Plus, for the problems that are actually solvable, they know very well how to solve them.

If, after all this, you are not discouraged and still want to do this, go right ahead: it's even possible that you'll find a better way to do this. Just know that the road ahead won't be easy - sending e-mail is trivial, getting it delivered is hard.

日裸衫吸 2024-10-04 06:45:21

人们推荐了 MailChimp,它是批量电子邮件的优秀供应商。如果您正在寻找优秀的交易电子邮件供应商,我也许可以提供帮助。

在过去 6 个月中,我们使用了四个不同的 SMTP 供应商,目的是找出最好的一个。

以下是我们发现的摘要...

AuthSMTP

  • 最便宜
  • 没有分析/报告
  • 没有打开/点击跟踪
  • 有在某些发送上略有犹豫

邮戳

  • 非常便宜,但不如 AuthSMTP
  • 便宜 漂亮的 cpanel,但没有打开/点击跟踪
  • 发送-级别活动跟踪,以便您可以打开已发送的一封电子邮件并查看其外观和发送数据。
  • 必须使用API​​。最近推出了通过 SMTP 发送的功能,但它存在缺陷。例如,我们注意到主题行中的引号 (") 被删除。
  • 无法发送您想要的任何附件。必须位于已批准的文件类型列表中且大小低于特定大小。(我认为是 10 MB)
  • 需要一组来自名称/地址。

JangoSMTP

  • 相对于其他的昂贵 - 在某些情况下超过 10 倍
  • 丑陋的 cpanel 但很好的跟踪 邮件
  • 发送时有时会犹豫,需要一个小时才能

发送 com/" rel="nofollow">SendGrid

  • 不像 AuthSMTP 那样便宜,但仍然非常便宜。许多客户可以每天免费发送 200 次。cpanel
  • ,但没有关于打开/点击跟踪的深入细节
  • 不错 API 选项(打开/点击跟踪等)可以在逐个电子邮件的基础上进行自定义。入站(回复)电子邮件可以发送到我们的 HTTP 端点
  • 。每封发送的电子邮件几乎都会立即到达收件箱。
  • 可以从任何姓名/地址发送。

结论

SendGrid 是最好的,Postmark 位居第二。我们从来没有看到这两者在发送时间上有任何犹豫——在某些情况下,我们一次发送了数百封电子邮件——而且它们都具有最佳的投资回报率,因为它们具有可靠的功能集。

People have recommended MailChimp which is a good vendor for bulk email. If you're looking for a good vendor for transactional email, I might be able to help.

Over the past 6 months, we used four different SMTP vendors with the goal of figuring out which was the best one.

Here's a summary of what we found...

AuthSMTP

  • Cheapest around
  • No analysis/reporting
  • No tracking for opens/clicks
  • Had slight hesitation on some sends

Postmark

  • Very cheap, but not as cheap as AuthSMTP
  • Beautiful cpanel but no tracking on opens/clicks
  • Send-level activity tracking so you can open a single email that was sent and look at how it looked and the delivery data.
  • Have to use API. Sending by SMTP was recently introduced but it's buggy. For instance, we noticed that quotes (") in the subject line are stripped.
  • Cannot send any attachment you want. Must be on approved list of file types and under a certain size. (10 MB I think)
  • Requires a set list of from names/addresses.

JangoSMTP

  • Expensive in relation to the others – more than 10 times in some cases
  • Ugly cpanel but great tracking on opens/clicks with email-level detail
  • Had hesitation, at times, when sending. On two occasions, sends took an hour to be delivered
  • Requires a set list of from name/addresses.

SendGrid

  • Not quite a cheap as AuthSMTP but still very cheap. Many customers can exist on 200 free sends per day.
  • Decent cpanel but no in-depth detail on open/click tracking
  • Lots of API options. Options (open/click tracking, etc) can be custom defined on an email-by-email basis. Inbound (reply) email can be posted to our HTTP end point.
  • Absolutely zero hesitation on sends. Every email sent landed in the inbox almost immediately.
  • Can send from any from name/address.

Conclusion

SendGrid was the best with Postmark coming in second place. We never saw any hesitation in send times with either of those two - in some cases we sent several hundred emails at once - and they both have the best ROI, given a solid featureset.

别闹i 2024-10-04 06:45:21

以下是我最近在一个较大的系统上使用 PHP 所做的事情:

  1. 用户输入新闻通讯文本并选择收件人(生成一个查询以检索电子邮件地址供以后使用)。

  2. 将新闻通讯文本和收件人查询添加到名为 *email_queue* 的 mysql 表中的行

    • (表 email_queue 具有“收件人”“主题”“正文”“优先级”列)
  3. 我创建了另一个脚本,其中作为 cron 作业每分钟运行一次。它使用 SwiftMailer 类。这个脚本很简单:

    • 在工作时间内,发送优先级为 == 0 的所有电子邮件

    • 下班后,按优先级发送其他电子邮件

根据主机设置,我现在可以使用标准的 swiftmailers 插件(例如 antiflood 和throttle...

$mailer->registerPlugin(new Swift_Plugins_AntiFloodPlugin(50, 30));

并且

$mailer->registerPlugin(new Swift_Plugins_ThrottlerPlugin( 100, Swift_Plugins_ThrottlerPlugin::MESSAGES_PER_MINUTE ));

等等)对其进行节流。

我已经将其扩展到了这个伪代码之外,带有附件, 许多其他可配置的设置,但只要您的服务器设置正确以发送电子邮件,它就可以很好地工作。 (可能不会在共享主机上工作,但理论上它应该......) Swiftmailer 甚至有一个设置

$message->setReturnPath

,我现在用它来跟踪退回......

快乐的踪迹! (快乐的电子邮件?)

Here is what I did recently in PHP on one of my bigger systems:

  1. User inputs newsletter text and selects the recipients (which generates a query to retrieve the email addresses for later).

  2. Add the newsletter text and recipients query to a row in mysql table called *email_queue*

    • (The table email_queue has the columns "to" "subject" "body" "priority")
  3. I created another script, which runs every minute as a cron job. It uses the SwiftMailer class. This script simply:

    • during business hours, sends all email with priority == 0

    • after hours, send other emails by priority

Depending on the hosts settings, I can now have it throttle using standard swiftmailers plugins like antiflood and throttle...

$mailer->registerPlugin(new Swift_Plugins_AntiFloodPlugin(50, 30));

and

$mailer->registerPlugin(new Swift_Plugins_ThrottlerPlugin( 100, Swift_Plugins_ThrottlerPlugin::MESSAGES_PER_MINUTE ));

etc, etc..

I have expanded it way beyond this pseudocode, with attachments, and many other configurable settings, but it works very well as long as your server is setup correctly to send email. (Probably wont work on shared hosting, but in theory it should...) Swiftmailer even has a setting

$message->setReturnPath

Which I now use to track bounces...

Happy Trails! (Happy Emails?)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文