我已经成功编写了一个程序，用于发送编码为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文件需要分钟。在这段时间内，程序没有响应（我认为程序一直挂着，直到我查看日志）。
也许我应该问一个稍微不同的问题：为什么必须编码？
答案 0 :(得分：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千字节。如果您的DSL或ISDN连接速度非常慢，那么这也可以解释它。