Испорченные письма

С сайта приходят уведомления вот такого вида:

— естественно, при таком раскладе, не работает восстановление пароля (ссылки битые, так как в них подставляются либо лишние символы, либо пробелы).

Например, ссылка на восстановление пароля:
http://site.ru/login/reminder/9ca8f8249f888ac9b9d510%0a2633ea0bd2/

— откуда-то взялось «%0a» в ссылке. После удаления этих символов, ссылка стала рабочей.

Или вот, тоже не рабочая ссылка, но уже с лишим пробелом:
http://site.ru/login/reminder/2648d9fd6edd9b8d4ea80baa4db 4fb2e

Ответа в поиске не нашел.

*Особености:
AltoCMS 1.0.8-dev
Шаблон Experience — лишние символы или пробелы в тексте ссылок и уведомлений.
Шаблон Start Kit — вроде бы лишних символов и пробелов именно только в ссылках на восстановление пароля — нет, но сами эти ссылки не кликабельны (что, собственно, не есть большая проблема). А вот в тексте и других ссылках — такая же галиматья как на картинке выше (пробелы, ромбы с вопросиками...).

P.S.: На github продублирую, но хотелось спросить и у всего сообщества — может такое только у меня?

Похожие статьи

  • Подписка на блог и уведомления на e-mail
    Предложение — почему бы в момент подписки на конкретный блог не сделать возможность выбора: получать уведомления о новых топиках в данном блоге на e-mail/просто следить за блогом в Ленте без писем на мыло.
  • Уведомления на почту
    Привет как отключить уведомления на почту о новых добавленных топиках?
  • Система уведомлений
    Знаю вопрос подымался на лайвстрите, но там капнули куда то далековато, необязательно моментальные уведомления, можно их наблюдать и после перезагрузки страницы. Очень удобно отслеживать любые действия, оценка,...

8 комментариев

+1
В версии 1.0.8-dev был добавлен выбор encoding писем, попробуйте его поменять на какой нибудь другой.
$config['sys']['mail']['encoding']         = 'quoted-printable';     // Какое кодирование использовать в письмах: 8bit, 7bit, binary, base64, quoted-printable
Но честно говоря никаких проблем быть не должно, они наоборот должны были уйти. А так чтобы лишние пробелы появлялись, ну это вообще странно
0
Спасибо! Теперь всё отлично.
Сменил quoted-printable на binary.
+1
Да, возможность смены кодировки писем сделали (спасибо Николаю aka Klaus ), но как и на что это может влиять, и почему с разных серверов с одной и той кодировкой уходят письма с разным результатом — в это не вникали. Надо «курить мануалы». Возможно, inliquid может прояснить — он, вроде, разбирался с этим.
+1
Описанная выше проблема наблюдается если в качестве Content-tranfer-encoding выбран 8bit. Причем может быть так что в 90% писем будет нормально, а в десятой части пара символов побьются. По спецификациям чтобы этой проблемы не было нужно задавать Content-tranfer-encoding: quoted-printable, или 64bit.

Я подозреваю что у orthograf была версия без этих изменений. Или новая версия но без параметра
$config['sys']['mail']['encoding']         = 'quoted-printable';
в конфиг файле.

Вот что пишут первоисточники:

The values «8bit», «7bit», and «binary» all imply that NO encoding has been performed. However, they are potentially useful as indications of the kind of data contained in the object, and therefore of the kind of encoding that might need to be performed for transmission in a given transport system. «7bit» means that the data is all represented as short lines of US-ASCII data. «8bit» means that the lines are short, but there may be non-ASCII characters (octets with the high-order bit set). «Binary» means that not only may non-ASCII characters be present, but also that the lines are not necessarily short enough for SMTP transport.

The difference between «8bit» (or any other conceivable bit-width token) and the «binary» token is that «binary» does not require adherence to any limits on line length or to the SMTP CRLF semantics, while the bit-width tokens do require such adherence. If the body contains data in any bit-width other than 7-bit, the appropriate bit-width Content-Transfer-Encoding token must be used (e.g., «8bit» for unencoded 8 bit wide data). If the body contains binary data, the «binary» Content-Transfer-Encoding token must be used.


А вот что касается quoted-printable:

The Quoted-Printable encoding is intended to represent data that largely consists of octets that correspond to printable characters in the ASCII character set. It encodes the data in such a way that the resulting octets are unlikely to be modified by mail transport. If the data being encoded are mostly ASCII text, the encoded form of the data remains largely recognizable by humans. A body which is entirely ASCII may also be encoded in Quoted-Printable to ensure the integrity of the data should the message pass through a character-translating, and/or line-wrapping gateway.

www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html

Короче binary — не правильно. В каких-то случаях это может сработать, в каких-то других будут другие еще большие проблемы.

А вот что сообщает microsoft:

Binary encoding is simply unencoded binary data. It has no line-length limitations. Binary encoded messages are not valid Internet messages.


msdn.microsoft.com/en-us/library/ms527563%28v=exchg.10%29.aspx
0
Я подозреваю что у orthograf была версия без этих изменений. Или новая версия но без параметра 'quoted-printable'
Да нет, тут как раз всё именно так и было. Конфиг с параметром:
$config['sys']['mail']['encoding']  = 'quoted-printable';

— и именно это и не работало
Короче binary — не правильно.
Нет, ну я всё понимаю..., а как быть — если мои пользователи при этих изменениях получают письма с сайта нормального вида с рабочими ссылками?
… или 64bit.
Такого параметра в конфиге в качестве возможного — не указано.
Есть — «base64». Поставил его (раз на «binary» так ругаются) — полет нормальный, письма читабельные, ссылки кликабельные :)
0
Тьфу, конечно base64. Чтобы понять почему такая проблема возникла с quoted-printable — нужно анализировать исходные (реально отправленные после обработки почтовым демоном)/конечные сообщения. В почте очень много посредников, проблема может быть где угодно, начиная с настроек sendmail`а…

Кодировка стоит UTF-8?
$config['sys']['mail']['charset']          = 'UTF-8';


В адимнке этот параметр может быть перебит настройками в БД.

Нет, ну я всё понимаю..., а как быть — если мои пользователи при этих изменениях получают письма с сайта нормального вида с рабочими ссылками?
Все 100%? Я говорю о том, что какие-то могут получать в нормальном виде, а какие-то в ненормальном. За всеми не уследить. Завтра кто-то перейдет с gmail на yandex, или rambler и привет.

Быстрое решение, чтоб не разбираться — base64. Но честно говоря ума не приложу как можно побить quoted-printable.....?

To: user1 <user1@user.com>
Subject: =?UTF-8?B?0KDQtdCz0LjRgdGC0YDQsNGG0LjRjw==?=
X-PHP-Originating-Script: 0:class.phpmailer.php
Date: Wed, 24 Sep 2014 18:03:06 +0400
Return-Path: <admin@admin.adm>
From: =?UTF-8?B?0JTQvdC10LLQvdC40LrQuCBhcnRkYXkuY2x1Yg==?= <admin@admin.adm>
Message-ID: <c7609c6c0eb21eb1ec26d9fef957df67@localhost>
X-Priority: 3
X-Mailer: PHPMailer 5.2.6 (https://github.com/PHPMailer/PHPMailer/)
MIME-Version: 1.0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=D0=92=D1=8B =D0=B7=D0=B0=D1=80=D0=B5=D0=B3=D0=B8=D1=81=D1=82=D1=80=D0=
=B8=D1=80=D0=BE=D0=B2=D0=B0=D0=BB=D0=B8=D1=81=D1=8C =D0=BD=D0=B0 =D1=81=
=D0=B0=D0=B9=D1=82=D0=B5 <a href=3D"http://localhost/">=D0=94=D0=BD=D0=
=B5=D0=B2=D0=BD=D0=B8=D0=BA=D0=B8 example.com</a>
=D0=92=D0=B0=D1=88=D0=B8 =D1=80=D0=B5=D0=B3=D0=B8=D1=81=D1=82=D1=80=D0=
=B0=D1=86=D0=B8=D0=BE=D0=BD=D0=BD=D1=8B=D0=B5 =D0=B4=D0=B0=D0=BD=D0=BD=
=D1=8B=D0=B5:
   =D0=BB=D0=BE=D0=B3=D0=B8=D0=BD: <b>user1</b>
   =D0=BF=D0=B0=D1=80=D0=BE=D0=BB=D1=8C: <b>user1</b>


=D0=A1 =D1=83=D0=B2=D0=B0=D0=B6=D0=B5=D0=BD=D0=B8=D0=B5=D0=BC, =D0=B0=D0=
=B4=D0=BC=D0=B8=D0=BD=D0=B8=D1=81=D1=82=D1=80=D0=B0=D1=86=D0=B8=D1=8F =
=D1=81=D0=B0=D0=B9=D1=82=D0=B0 <a href=3D"http://localhost/">=D0=94=D0=
=BD=D0=B5=D0=B2=D0=BD=D0=B8=D0=BA=D0=B8 example.com</a>
Отредактирован:
0
Кодировка стоит UTF-8?
Да, разумеется.
Все 100%?
Не знаю :)
Но те, которые жаловались — теперь довольны.
X-Mailer: PHPMailer 5.2.6
Кстати, а сама версия PHP не может влиять на это?
0
Это врядли. Я выше скопировал пример такого письма в quoted-printable. Его вот так побить можно только если реально отправляется снова 8bit. Например, так если пофантазтировать, если почтовый демон настроен как-то хитро что он все перекодирует обратно в 8bit, и уже 8bit отдает почтовому шлюзу. Может и на стороне шлюза глюк, надо смотреть.

Или если какой-то форвардинг а на стороне пользователя кривой…
Отредактирован:
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.