电子邮件附件和带宽使用
我正在开发一个模块，使我们的系统用户能够向申请人池中所有注册的活跃申请人发送批量电子邮件。目前，池中有超过 1000 万活跃申请人可以向其发送电子邮件。我正在考虑创建电子邮件块并等待几分钟，然后再发送各个块。我更关心的是执着。
由于每封电子邮件都可以包含附件（最大 2MB），因此即使电子邮件仅发送给 10,000 个申请人（2MB X 10,000 个申请人 = 约 20GB 带宽），也可能会消耗大量带宽。我的问题是：
既然每个附件都是MIME类型，那么电子邮件的大小是否会按照我上面计算的方式计算？或者在带宽使用方面有不同的机制？
您认为，如果我必须向数千人发送文档并且还想节省带宽，我有什么选择？我可以把文件放到服务器上，让大家下载，但是会不会消耗一些带宽呢？ （我不想走FTP路线）
有人说将这些类型的文档移动到云端？云技术是否提供了满足这种需求的解决方案？
非常感谢，
I am working on a module that enables our system users to send bulk emails to all the registered active applicants from the applicant pool. Currently, there are more than 10 million active applicants in the pool to which emails can be sent. I am thinking to create blocks of emails and wait for a few minutes before sending individual blocks. What I am more concerned about is the attachment.
Since every email can contain an attachment(max. 2MB), There is a possibility that a huge amount of bandwidth will be consumed, even if the email is sent to only 10,000 applicants (2MB X 10,000 applicants = 20GB bandwidth approximately). My questions are:
Since every attachment is a MIME type, will the size of the email be calculated the the way I have calculated above? Or there is a different mechanism specially in context of bandwidth usage?
In your opinion, what options do I have If I have to send a document to thousands of people and want to save the bandwidth as well? I can put the document on the server and let everybody download, but will it not consume the some amount of bandwidth? (I don't want to go down the FTP route)
Somebody was saying moving these kinds of documents to the cloud?? Does cloud technology offer solutions that cater for this kind of need?
Many thanks,
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
该附件会产生被标记为垃圾邮件的问题。如果可以的话最好避免它。
附件是 MIME 编码的，而不是 gzip 压缩的。这占用了1.5倍的带宽。
要查看附件是否已被打开并不容易，除非它有一些有效负载可以为您做到这一点 - 同样，这可能会被标记为垃圾邮件。
将这些文档放在常规网络服务器上是有意义的。您可以使用普通的 Google Analytics 来查看发生了什么。您还可以使用公共缓存来确保文档由 ISP 等缓存，从而减少下载量。该文档还可以使用 gzip 进行压缩，然后用浏览器打开，从而不引人注意地为收件人进行解压缩。
The attachment creates a problem of being flagged as spam. Best avoid it if you can.
The attachment is MIME encoded rather than gzip compressed. This takes up 1.5 times the bandwidth.
It is not easy to see if the attachment has been opened unless it has some payload that does that for you - again this could be flagged as spam.
Putting these documents on a regular web server will make sense. You can use normal Google Analytics to see what is going on. You can also use public caching to make sure that the document is cached by ISPs etc, thereby reducing your download. The document can also be compressed with gzip to be opened with a browser, unobtrusively doing the un-compressing for your recipients.