接收郵件服務器在每個新行之前插入空格，打破多部分/備選

我正在使用PHP按需向客戶端發送電子郵件。我有一個腳本，在測試中看起來相當健壯，生成具有文本和html版本的MIME-1.0兼容多部分/替代電子郵件。電子郵件作爲base64編碼的字符串發送，以保留國際字符（消息文本通常是德文）。接收郵件服務器在每個新行之前插入空格，打破多部分/備選

但是，似乎某些服務器在收到郵件後，會在每個CR-LF序列之前插入一個空格（0x20）。當然，這並不會破壞base64，但是由於它分解了從消息中分離頭部的CR-LF-CR-LF序列，所以消息沒有被正確解析（或者實際上，由於次要頭部是從未見過停止）。

這裏是生成的示例消息：

From: [email protected] 
To: [email protected] 
Subject: Test Message 
MIME-Version: 1.0 
Content-Type: multipart/alternative; boundary="{$boundary}" 

This is a multipart Message in MIME Format 
--{$boundary} 
MIME-Version: 1.0 
Content-ID: <{$content_id}> 
Content-Type: text/plain; charset="utf-8" 
Content-Disposition: inline 
Content-Transfer-Encoding: base64 
Content-Length: {$objlen} 

UkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVE 
QUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNU 
RUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQg 
UkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVE 
QUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNU 
RUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQg 
UkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVE 
QUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNU 
RUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQg 
UkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVE 
QUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNU 
RUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQg 
UkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVE 
QUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNU 
RUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQg 
UkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQgUkVEQUNURUQ= 
--{$boundary} 
MIME-Version: 1.0 
Content-ID: <{$content_id}> 
Content-Type: text/html; charset="utf-8" 
Content-Disposition: inline 
Content-Transfer-Encoding: base64 
Content-Length: {$objlen} 

REVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVU 
Q0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FE 
RVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIg 
REVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVU 
Q0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FE 
RVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIg 
REVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVU 
Q0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FE 
RVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIg 
REVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVU 
Q0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FE 
RVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIg 
REVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVU 
Q0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FE 
RVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIg 
REVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVIgREVUQ0FERVI= 
--{$boundary}--

是有一些方法，以防止郵件服務器從添加這些空間？

來源

2011-04-09 Dereleased

這個問題有一定的電子郵件服務器做（如t-online.de）治療CRLF換行符序列比LF少纔有效換行。當換行符從CRLF更改爲LF時，一切正常。一方面，我認爲這是對RFC中規定的標準的公然蔑視，但另一方面，自從做出更改以來，我對這些消息沒有任何問題，所以無論是（a ）沒關係，或者（b）關於我不知道的變化，這總是可能的。

在任何情況下，總是隻以LF結尾，我猜如果您打算髮送multipart/*消息。

來源

2011-04-11 05:46:17 Dereleased

問題是你沒有用引用的可打印編碼格式發送你的電子郵件。我倒是強烈考慮使用一個庫來發送電子郵件，爲您避免所有這些問題： Email Quoted Printable Encoding

來源

2011-04-09 04:47:22 Wes

我非常懷疑這個問題與7位，8位和base64 Content-Transfer-Encodings出於某種原因而不能發送引用的電子郵件有關。再說一遍，我什麼都不知道，所以我測試了這個理論，不，事實並非如此。事實上，這個問題主要與一些服務器有關（例如：'t-online.de'），而不是RFC中指定的CRLF序列。糾正這個問題後，一切工作得很好。無論如何，謝謝你的回答。 – Dereleased 2011-04-11 05:43:49

接收郵件服務器在每個新行之前插入空格，打破多部分/備選

回答

相關問題