Письма иногда зашифрованы
Folks,
У меня есть сайт на основе PHP (с использованием фреймворка QCubed); как часть сайта, у меня есть демон, который рассылает несколько тысяч электронных писем в день (нет, я не спамер, все подписывается:)). Письма отправляются через пользовательский компонент инфраструктуры; этот компонент служит SMTP-клиентом. Я использую платный SMTP-шлюз от DNSExit.com для получения фактически доставленных писем.
Эти письма являются простыми письмами на основе HTML; они действительно имеют простые ссылки внутри.
Моя проблема в том, что эти ссылки иногда (не последовательно!) Зашифровываются во время перехода. Тэги как-то перепутаны, а некоторые ссылки не работают в электронном письме. Эта проблема возникает в небольшом проценте всех отправленных писем; это не согласовано (то есть одно и то же точное исходное сообщение HTML может вызвать или не вызвать скремблирование при переходе).
Кто-нибудь из вас видел это? Есть мысли о том, как устранить неполадки?
6 ответов
Возможно ли, что вы используете временные файлы для создания электронных писем (или как минимум для создания переменного содержимого)? Я делал что-то неопределенно похожее однажды. Текст электронного письма был сгенерирован и записан во временный файл на основе точного времени в секундах. К сожалению, при отправке тысяч в день мы ударяли одну и ту же секунду более одного раза (поскольку доступно всего 86 тысяч секунд). Это может объяснить а) небольшую частоту ошибок и б) кажущуюся случайность. Для устранения неполадок, я просто посмотрю, увеличивается ли количество ошибок с количеством писем и оттуда.
Проблема в том, что HTML не совместим с электронной почтой. Вот почему я создал язык разметки почты.
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 с несколькими агентами применяет некоторую степень иерархии, которая может не потребоваться для представления потока электронной почты.
При отправке электронного письма вы должны его кодировать, чтобы каждая строка в теле сообщения не превышала 76 символов. Вы можете использовать base64 для этого, но большинство систем используют кодируемую для печати кодировку текста, поскольку она генерирует меньшие сообщения. Base64 обычно используется только для двоичных данных.
Я столкнулся с подобной проблемой на сервере, на котором запущен sendmail.
Я создавал и тестировал электронную почту в формате html, которая в один прекрасный день будет отправлена по почте (конечно, подписаться). У меня был шаблон электронной почты, который было легко прочитать любому html-программисту, но, как таковой, он занимал много места для правильного выравнивания. Я подумал про себя: если это будет массовое электронное письмо, после рендеринга шаблона, я думаю, я минимизирую пробелы в файле, чтобы сэкономить место! Поэтому я создал блестящее регулярное выражение, чтобы избавить себя от необходимости отправлять пробелы из отрисованного электронного письма.
Отправив письмо самому себе, я открыл письмо и был озадачен, когда увидел, что некоторые из CSS и HTML не отображаются правильно, когда мои предыдущие электронные письма до моего регулярного выражения были. Просматривая исходное сообщение, я заметил, что время от времени восклицательный знак (!) Появлялся, по-видимому, случайным образом по всему сообщению, тем самым нарушая любые CSS и HTML, которые попадали на его случайный путь.
Оказывается, что sendmail не нравится, если строка в вашей электронной почте становится слишком длинной без разрыва строки. Когда строка становится слишком длинной, sendmail вставит восклицательный знак, за которым следует разрыв строки прямо здесь и сейчас, просто чтобы сбить вас с толку.
Почему он не просто выбрал пробел между словами для перевода строки? Зачем вставлять восклицательный знак? Вопросы боюсь, без ответов.
Мое решение?
sudo apt-get remove sendmail
sudo apt-get install exim4
У меня были другие проблемы с sendmail, такие как отправка электронной почты в течение полных 60 секунд, и exim4 просто работал, и мне никогда не приходилось думать об этом снова.
Если ваш почтовый сервер использует sendmail, это может быть проблемой, если нет, спасибо, что позволили мне поделиться с вами моей историей. Мне нужно было дать волю.
Было 2 проблемы с данными электронной почты - обычно "?" Символ каким-то образом попал в некоторые слова, другое было UTF и название, связанное. Первый был "исправлен" путем смены хостинг-провайдера (так что это было связано с почтовым сервером), второй был исправлен путем изменения библиотеки PHPmailer.
Попробуйте указать, как именно данные шифруются.
У вас есть какие-то особые атрибуты в ваших ссылках? Может быть атрибут заголовка с не экранированными кавычками внутри?
Что-то вроде этого: <a href="http://some.site" title="My "correct" link">Link</a>