1

我已经成功编写了一个程序，它可以发送编码为 UTF-8 的希伯来语 HTML 电子邮件以及嵌入的图片和附件。

我注意到虽然带有 JPG 或 TXT 类型附件的电子邮件可以快速发送，但带有 PDF 附件的电子邮件需要很长时间（一分钟）才能发送。我安排了一个 tmemo 组件从 SMTP 组件的 OnStatus 事件中接收 AStatusText 字符串，并看到该程序正在对文本（正确）和附件（不正确）进行编码。

如何防止附件被编码，从而更快地发送电子邮件？

这是显示时间的 SMTP 组件的日志

18:44:01 smtp: Connected.
18:44:04 smtp: Encoding text
18:44:04 smtp: Encoding attachment
18:44:04 smtp: Encoding attachment
18:45:05 smtp: Disconnecting.
18:45:05 smtp: Disconnected.
18:45:05 disconnected

需要一分钟来编码一个 491KB 大小的 PDF 文件。在此期间程序没有响应（我认为程序挂起，直到我查看日志）。

也许我应该问一个稍微不同的问题：为什么必须对其进行编码？

4

1 回答 1

0

所有附件始终使用 MIME64 编码，否则您的电子邮件将无法被除您之外的任何人阅读。改变互联网电子邮件的工作方式不是您的工作。

您延迟的原因可能是您的托管公司正在对 PDF 进行“病毒扫描”，或者另一方面，如果您要附加一个巨大的 PDF，并且需要一分钟来对其进行编码，我并不感到惊讶一个巨大的 PDF 文件，当转换为 MIME64 时，这不是您可以跳过的步骤，需要很长时间。但是你的 PDF 是 491 KB，这是微不足道的，所以延迟可能在服务器端，它可能正在扫描你的 PDF。请记住，SMTP 过程是您的一方发送，然后另一方响应的对话。在对方响应之前的延迟不是您在不了解延迟发生原因的情况下可以解决的问题。您的“无编码”想法是不合理的。

但是，病毒/垃圾邮件扫描是一个合理的假设，这可能会使您已经 30 秒的正常传输时间增加 30 秒。要验证该假设，请将您的 pdf 从“test.pdf”重命名为“test.p@d@f$”，然后查看传输时间是否从 60 秒下降到大约 30 秒。您还没有说明您的互联网管道有多快，或者您认为 MIME64 编码的 EMAIL 可能有多大，但它可能比您的 PDF 大 1.5 倍，因此大约 600 到 800 KB。如果您的 DSL 或 ISDN 连接速度非常慢，那么这也可以解释。

于 2013-01-17T18:14:21.890 回答