电子邮件有时会被扰乱

Question

伙计，

我有一个基于PHP的网站（使用QCubed framework）;作为网站的一部分，我有一个守护进程，每天发送几千封电子邮件（不，我不是垃圾邮件发送者，一切都是选择加入:)）。电子邮件通过自定义框架组件发送;该组件充当SMTP客户端。我正在使用DNSExit.com的付费SMTP网关来获取实际发送的电子邮件。

这些电子邮件是简单的基于HTML的电子邮件;他们里面只有简单的链接。

我的问题是这些链接有时（不一致！）在转换期间被扰乱。标签以某种方式混淆，一些链接在电子邮件中不起作用。所有已发送电子邮件中的一小部分都会出现此问题;它不一致（即，相同的确切源消息HTML可能会或可能不会导致转换中的加扰）。

有没有人见过这个？有关如何排除故障的任何想法？

Answer 1

您是否可能使用临时文件来创建电子邮件（或至少可以创建变量内容）？曾经做过一些模糊相似的事情。生成电子邮件文本并根据以秒为单位的确切时间将其写入临时文件。不幸的是，当每天发送数千个时，我们不止一次击中同一秒（因为只有86k秒可用）。这可能解释了a）小错误率和b）表观随机性。对于疑难解答，我只是看错误率是否会随着电子邮件数量的增加而增加。

Answer 2

我在运行sendmail的服务器上遇到了类似的问题。

我正在创建和测试一封有时会被大量邮寄的HTML电子邮件（当然是选择加入）。我有自己的电子邮件模板，任何html程序员都可以轻松阅读，但因此在空格上很重要，以便正确排列所有内容。我想，如果要通过大量的电子邮件发送，在渲染模板之后，我想我会最小化文件中的空白以节省空间！因此，我创建了一个精彩的正则表达式，以消除任何不必要的从呈现的电子邮件中发送空白。

当我向自己发送电子邮件时，我打开了电子邮件，当我看到一些css和html没有正确显示时，当我之前在我的regexp之前发送的电子邮件时，我感到很困惑。通过查看原始消息，我注意到每隔一段时间，感叹号（！）在整个消息中似乎随机出现，从而破坏了随机路径中的任何css和html。

事实证明，如果电子邮件中的一行没有换行，那么sendmail就不会喜欢它。当线路确实变得太长时，sendmail会插入一个感叹号，然后在那里插入换行符，只是为了混淆和混淆你。

为什么不选择单词之间的空格换行？为什么插入感叹号？问题我害怕，没有答案。

我的解决方案？

sudo apt-get remove sendmail
sudo apt-get install exim4

我遇到了sendmail的其他问题，比如花了整整60秒才发送电子邮件，exim4刚刚工作，我再也没有想过了。

如果您的邮件服务器正在使用sendmail，那么这很可能就是问题所在，如果没有，感谢您让我与您分享我的故事。我需要发泄。

Answer 3

当您发送电子邮件时，您应对其进行编码，以便邮件正文中的每一行不超过76个字符。您可以使用base64，但大多数系统使用 引用文本的可打印编码，因为它生成较小的消息。 Base64通常仅用于二进制数据。

Answer 4

问题是HTML与电子邮件不兼容。这就是我创建Mail Markup Language。

的原因

创建HTML是为了使用HTTP协议进行操作，因为这两种技术几乎同时由同一个人发明。不同之处在于HTTP是从服务器到客户端的单一会话单向传输。由于HTML文档始终在服务器上发送，因此不会发生变化，发送到请求客户端，一旦传输完成，客户端和服务器之间的连接就会被删除。

电子邮件不会以这种方式运行。在电子邮件中，通信始发于客户端，发送到一个或多个电子邮件服务，然后终止于远程客户端。然而，最大的区别在于文档不会像单个传输实例的终结一样死亡，就像HTTP上的文档传输一样。在SMTP中发送的文档可以被回复，转发或复制到多个未请求的用户。当考虑考虑电子邮件线程时，这一区别是深刻的。

问题是SMTP和HTTP是不同的，如前两段所示。这种差异更加复杂，因为SMTP和HTTP具有完全不同的格式化方法，用于创建标题数据。 HTML具有标头数据，旨在与HTTP传输的标头兼容，并且不提供对SMTP传输的遵从性。 HTML标头也没有考虑电子邮件线程的复杂性。

当电子邮件软件破坏HTML文档以添加必要的格式更改以适应该软件的符合要求并且还将标题数据直接写入文档时，就会举例说明该问题。当HTML电子邮件成为电子邮件线程时，此示例变得非常明显。由于HTML标题数据没有方法来解释电子邮件线程的复杂性，因此无法从传输文档的样式表中提供相关的表示定义。每次将HTML文档或具有HTML格式的文档从一个电子邮件软件发送到另一个电子邮件软件时，文档都会损坏，并且每个电子邮件软件设备都会破坏先前的损坏。电子邮件处理软件可能指的是肯定会损坏文档的电子邮件客户端或电子邮件服务器，它们可能只会破坏电子邮件文档。

问题的解决方案是创建一个标记语言约定，直接识别电子邮件标题数据的要求。这些要求在RFC 5321中针对SMTP协议定义，而RFC 5322针对客户端处理定义。正确扩展此解决方案以解决电子邮件线程的复杂性的唯一方法是为多代理DOM提供约定。

由于技术不准确以及术语多智能体DOM与编辑之前未提及的发明功能的性质之间存在差异而删除了段落。

编辑：多代理DOM应用某种程度的层次结构，这可能不是表示电子邮件线程所必需的。

Answer 5

电子邮件数据存在2个问题 - 通常是“？”符号不知何故进入了一些词，另一个是UTF和标题相关。首先通过更改托管服务提供商来“修复”（因此它与邮件服务器相关）第二个通过更改PHPmailer库得到修复。

尝试指定数据加密的准确程度。

Answer 6

您的链接中有任何特殊属性吗？里面没有转义引号可能是title属性？

这样的事情：<a href="http://some.site" title="My "correct" link">Link</a>