Я использую PHP для отправки писем по требованию клиентам. У меня есть сценарий, который казался довольно надежным в тестировании, создавая MIME-1.0 Compatible multipart / alternative emails, у которых была текстовая и html-версия. Письма отправляются как закодированные строки base64 для сохранения международных символов (текст сообщения обычно находится на немецком языке).
Однако кажется, что некоторые серверы, получив почту, вставляют пробел ( 0x20 ) непосредственно перед каждой последовательностью CR-LF. Конечно, это не разрушает base64, но поскольку он разбивает последовательность CR-LF-CR-LF, которая отделяет заголовки от сообщений, сообщения не обрабатываются должным образом (или, вообще-то, на самом деле, поскольку вторичные заголовки никогда не видел, чтобы остановить).
Вот пример сообщения, сгенерированного:
From: example@example.com To: example@example.org 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}--
Есть ли способ предотвратить добавление этих пространств почтовым сервером?
Проблема в том, что вы не отправляете свою электронную почту в закодированном формате для печати. Я бы настоятельно рекомендовал использовать библиотеку для отправки электронной почты для вас, чтобы избежать всех этих проблем: Email Quoted Printable Encoding
Проблема связана с некоторыми серверами электронной почты (например, t-online.de ), рассматривая последовательности строк новой строки CRLF как менее достоверные, чем LF только новые строки. Когда новые строки были изменены с CRLF на LF , все работало нормально.
С одной стороны, я думаю, что это было вопиющее пренебрежение стандартами, изложенными в RFC, но, с другой стороны, у меня не было проблем с этими сообщениями после внесения изменений, поэтому либо (а) или (б) произошли изменения, о которых я не знаю, что всегда возможно.
В любом случае, всегда заканчивайтесь только LF , я думаю, если вы собираетесь отправлять сообщения multipart/* .