Письма иногда зашифрованы - PullRequest
6 голосов
/ 10 марта 2010

Народ,

У меня есть сайт на основе PHP (используется QCubed framework ); как часть сайта, у меня есть демон, который отправляет несколько тысяч электронных писем в день (нет, я не спамер, все подписывается :)). Письма отправляются через пользовательский компонент инфраструктуры; этот компонент служит SMTP-клиентом. Я использую платный SMTP-шлюз от DNSExit.com для получения фактически доставленных писем.

Эти письма являются простыми письмами на основе HTML; у них действительно есть простые ссылки внутри.

Моя проблема в том, что эти ссылки иногда (не всегда!) Зашифровываются во время перехода. Тэги как-то перепутаны, а некоторые ссылки не работают в электронном письме. Проблема возникает на небольшом проценте всех отправленных писем; оно не согласовано (то есть одно и то же точное исходное сообщение HTML может вызывать или не вызывать скремблирование при переходе).

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

Ответы [ 6 ]

3 голосов
/ 15 марта 2010

Возможно ли использование временных файлов для создания электронных писем (или как минимум для создания переменного содержимого)? Я делал что-то неопределенно похожее однажды. Текст электронного письма был сгенерирован и записан во временный файл на основе точного времени в секундах. К сожалению, при отправке тысяч в день мы ударяли одну и ту же секунду более одного раза (поскольку доступно всего 86 тыс. Секунд). Это может объяснить а) небольшую частоту ошибок и б) кажущуюся случайность. Для устранения неполадок, я бы просто посмотрел, увеличивается ли ошибка rate с количеством писем и оттуда.

1 голос
/ 21 марта 2010

Проблема в том, что 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 с несколькими агентами применяет некоторую степень иерархии, которая может не потребоваться для представления потока электронной почты.

1 голос
/ 20 марта 2010

Когда вы отправляете электронное письмо, вы должны закодировать его, чтобы каждая строка в теле сообщения не превышала 76 символов. Вы можете использовать base64 для этого, но большинство систем используют цитируемая для печати кодировка текста, поскольку она генерирует меньшие сообщения. Base64 обычно используется только для двоичных данных.

1 голос
/ 19 марта 2010

Я столкнулся с подобной проблемой на сервере, на котором запущен sendmail.

Я создавал и тестировал html-письмо, которое в один прекрасный день будет отправлено по почте (конечно же, с согласия). У меня был шаблон электронной почты, который было легко прочитать любому html-программисту, но, как таковой, он занимал много места, чтобы правильно выстроить все строки. Я подумал, что если это будет массовое электронное письмо, то после рендеринга шаблона, я думаю, я минимизирую пробелы в файле, чтобы сэкономить место! Поэтому я создал блестящее регулярное выражение, чтобы избавить от ненужных отправлений пробелов из обработанного электронного письма.

При отправке письма себе, я открыл письмо и был озадачен, когда увидел, что некоторые из CSS и HTML не отображаются правильно, когда мои предыдущие письма до моего регулярного выражения были. Просматривая исходное сообщение, я заметил, что время от времени восклицательный знак (!) Появлялся, казалось бы, случайным образом по всему сообщению, тем самым нарушая любые CSS и HTML, которые попадали на его случайный путь.

Оказывается, что sendmail не нравится, если строка в вашей электронной почте становится слишком длинной без разрыва строки. Когда строка становится слишком длинной, sendmail вставит восклицательный знак, за которым следует разрыв строки прямо там и сейчас, просто чтобы сбить вас с толку.

Почему он не просто выбрал пробел между словами для перевода строки? Зачем вставлять восклицательный знак? Вопросы боюсь, без ответов.

Мое решение?

sudo apt-get remove sendmail
sudo apt-get install exim4

У меня были другие проблемы с sendmail, такие как отправка электронной почты в течение полных 60 секунд, и exim4 просто работал, и мне больше никогда не приходилось об этом думать.

Если ваш почтовый сервер использует sendmail, это может быть проблемой, если нет, спасибо, что позволили мне поделиться с вами моей историей. Мне нужно было вентилировать.

0 голосов
/ 19 марта 2010

Есть ли у вас какие-либо специальные атрибуты в ваших ссылках? Может быть атрибут заголовка с не экранированными кавычками внутри?

Примерно так: <a href="http://some.site" title="My "correct" link">Link</a>

0 голосов
/ 10 марта 2010

Было 2 проблемы с данными электронной почты - обычно "?" символ каким-то образом попал внутрь одних слов, другое было UTF и название связано. Первый из них был «исправлен» путем смены хостинг-провайдера (так что это было связано с почтовым сервером), второй был исправлен путем изменения библиотеки PHPmailer.

Попробуйте указать, как именно данные шифруются.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...