夥計們，電子郵件有時會擾亂
我有一個基於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