伙计们，电子邮件有时会扰乱
我有一个基于PHP的网站（使用QCubed framework）;作为网站的一部分，我有一个每天发送数千封电子邮件的守护进程（不，我不是垃圾邮件发送者，所有内容都可以选择:)）。电子邮件通过自定义框架组件发送;该组件充当SMTP客户端。我正在使用来自DNSExit.com的付费SMTP网关来获取实际发送的电子邮件。
这些电子邮件是简单的基于HTML的电子邮件;他们里面真的只有简单的链接。
我的问题是，这些链接有时（不一致！）在转换过程中混乱。标签混淆不清，并且一些链接在电子邮件中不起作用。这个问题发生在所有发送的电子邮件中的一小部分;它是不一致的（即相同的确切的源信息HTML可能会或可能不会导致转换中的加扰）。
有没有人见过这个？有关如何解决问题的任何想法？
电子邮件数据有两个问题 - 通常是“？”符号不知怎么得到了一些单词，另一个是UTF和标题相关。首先通过更改托管提供商（因此它是与邮件服务器相关的）第二个通过更改PHPmailer库而得到修复。
尝试指定数据如何进行加扰。
是否有可能使用临时文件来创建电子邮件（或至少创建变量内容）？我曾经做过类似的事情。电子邮件文本是基于准确时间（以秒为单位）生成并写入临时文件。不幸的是，当每天发送数千个数据时，我们不止一次地发送同一个数据（因为只有86k秒可用）。这可能解释a）小错误率和b）表观随机性。对于故障排除，我只是看看错误率随着电子邮件的数量增加，并从那里去。
+1对随机因素进行评论 - 这通常被低估了 – hurikhan77
要解决这个问题，有一些函数可以创建具有唯一名称的临时文件。我很确定他们之前也检查过存在，所以也许尝试一下，而不是试图增加随机性。 –
你有什么特殊的属性在你的链接？可能是里面没有逃脱引号的标题属性？
事情是这样的：<a href="http://some.site" title="My "correct" link">Link</a>
我遇到了类似的问题在一个服务器上运行的sendmail。
我正在创建和测试一封有一天会被群发邮件的html电子邮件（当然是选择加入）。我为自己的电子邮件提供了一个模板，这对任何html程序员来说都很容易阅读，但是由于这样的话空间很大，所以一切正常。我想我自己，如果这将被群发邮件，模板渲染后，我想我会尽量减少文件中的空白，以节省空间！因此，我创建了一个精彩的正则表达式，以消除从呈现的电子邮件中不必要地发送空白。
当我发送电子邮件给自己的时候，当我看到一些css和html没有正确显示时，我打开电子邮件，并感到莫名其妙，当时我以前的电子邮件是在我的正则表达式之前。通过查看原始消息，我注意到每隔一段时间，感叹号（！）就会在整个消息中看似随机出现，从而打破了随机路径中出现的任何css和html。
原来，如果您的电子邮件中的某一行太长而没有换行符，sendmail不会喜欢它。当线路太长时，sendmail会在后面插入一个感叹号，然后是一个换行符，只是为了混淆和混淆你。
为什么不只是选择单词之间的空格来换行符？为什么插入感叹号？我害怕的问题，没有答案。
我的解决方案？
sudo apt-get remove sendmail
sudo apt-get install exim4
我有其他问题的sendmail喜欢它采取了整整60秒，发送电子邮件和exim4的只是工作，我从来没有再想想。
如果你的邮件服务器使用的是sendmail，这很好，可能是问题，如果没有，谢谢你让我与你分享我的故事。我需要发泄。
当您发送电子邮件时，您应该对其进行编码，以便邮件正文中的每一行不超过76个字符。您可以使用base64，但大多数系统使用 引用可打印的文本编码，因为它会生成较小的消息。 Base64通常只用于二进制数据。
问题是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应用某种程度的层次结构，这可能不需要表示电子邮件线程。
“（即完全相同的源消息HTML可能会或可能不会导致过渡扰）” 但是当他们造成过渡，其中邮件提供商你通常得到这个问题扰？ Hotmail的？ Gmail或任何其他？或者收件邮件是什么都没有关系？ –
我见过所有电子邮件提供商的问题。似乎并不特定于目标用户的提供者。 –
什么是编码？尝试base64，即使没有附件。这应该保持良好状态。 – dusoft