Блог

Главная - Вопросы по программированию - Принимающий почтовый сервер вставляет пробел перед каждой новой строкой, нарушая составную / альтернативную

Принимающий почтовый сервер вставляет пробел перед каждой новой строкой, нарушая составную / альтернативную

#php #email #multipart-alternative

#php #Адрес электронной почты #составная часть-альтернатива

Вопрос:

Я использую PHP для отправки электронных писем клиентам по запросу. У меня есть скрипт, который показался довольно надежным при тестировании, генерирующий MIME-1.0 совместимые составные / альтернативные электронные письма, которые имели текстовую и 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}--

Есть ли какой-нибудь способ запретить почтовому серверу добавлять эти пробелы?

Ответ №1:

Проблема в том, что вы отправляете свое электронное письмо не в формате, доступном для печати в кавычках. Я бы настоятельно рекомендовал использовать библиотеку для отправки вам электронного письма, чтобы избежать всех этих проблем: Кодировка для печати в кавычках по электронной почте

Комментарии:

1. Я сильно сомневался, что проблема связана с тем, что электронное письмо не отправляется в виде котировок для печати, когда 7-битные, 8-битные и base64 Content-Transfer-Encodings существуют по какой-то причине. Опять же, я не знаю всего, поэтому я проверил эту теорию, и нет, это был не тот случай. Фактически, проблема была связана с тем, что несколько серверов, в частности (например: t-online.de ), предпочитали новые строки только LF вместо последовательностей CRLF, указанных в RFC. После исправления этой проблемы все работало очень хорошо. В любом случае спасибо вам за ваш ответ.

Ответ №2:

Проблема связана с тем, что некоторые почтовые серверы (например, t-online.de ) рассматривают CRLF последовательности перевода строки как менее допустимые, чем LF только новые строки. Когда новые строки были изменены с CRLF на LF , все работало нормально.

С одной стороны, я бы подумал, что это вопиющее пренебрежение стандартами, изложенными в RFC, но с другой стороны, у меня не было проблем с этими сообщениями с момента внесения изменений, так что либо (а) это не имеет значения, либо (б) произошли изменения, о которых я не знаю, что всегда возможно.

В любом случае, я полагаю, всегда заканчивайте на LF only, если вы собираетесь отправлять multipart/* сообщения.