при расшифровке текста каждый символ CR (конец абзаца) удваивается (Thunderbird/Enigmail/GnuPG)
Использую связку Thunderbird 7.1/Enigmail/GnuPG. При ответе на любое зашифрованное сообщение в цитируемом тексте после каждой строки зачем-то добавляется еще один дополнительный символ CR (конец абзаца), то есть, после каждой строки текста добавляется одна пустая строка.
Причем интересно, что сам Thunderbird в окне составления ответного сообщения эти лишние CR (пустые строки) почему-то не отображает, то есть, сам я при составлении ответа цитируемый текст корректно. Чтобы увидеть лишние CR, надо скопировать текст из TB в адекватный текстовый редактор.
Но когда я отошлю свой ответ вместе с этим входящим сообщением, особенно если у адресата стоит не Thunerbird, а другой почтовый клиент, то он увидит предыдущую цитируемую переписку со всеми лишними CR – и отошлет ее мне обратно, а потом при расшифровке каждый CR опять удвоится, и так до полной потери читабельности.
Проверял несколько раз, проблема именно в том, как сообщение расшифровывается в Thunderbird 7.1/Enigmail/GnuPG. Если просто скопировать текст входящего зашифрованного сообщения и расшифровать в PGP Desktop, то никаких лишних CR не добавляется. То есть, само сообщение нормальное, а глючит механизм расшифровки.
комментариев: 6 документов: 4 редакций: 0
И что из этого следует?? Если это намек, то моих мозгов, к сожалению, не хватает, чтобы правильно его истолковать.
На всякий случай уточню, что у меня – Windows XP, соответственно, используются версии Thunderbird и GnuPG для Windows. Кстати, у отправителя, насколько я знаю, тоже Windows.
комментариев: 6 документов: 4 редакций: 0
Напрашивается предположение, что это баг самого Thunderbird, никак не связанный с шифрованием и GnuPG. Однако это все же не так: ведь при ответе с цитированием на обычные незашифрованные сообщения не добавляется лишних CR.
P.S.
Можно каждый раз расшифровывать входящие сообщения в отдельном окне, копировать оттуда в буфер обмена, потом вызывать форму ответа и вручную вставлять туда ранее расшифрованный текст в качестве цитаты... Но удобным такой способ не назовешь.
комментариев: 11558 документов: 1036 редакций: 4118
Я бы сказал, что это баг Enigmail при работе с данной версией Thunderbird. Для начала обновитесь до актуальных версий (TB, скажем, уже есть 8.0) и если проблема сохранится, то отправьте багрепорт разработчикам Enigmail.
комментариев: 6 документов: 4 редакций: 0
А у других этот баг тоже проявляется или только у меня?
AFAIK Между последними версиями Thunderbird нет существенной разницы в механизмах обработки почты.
А Enigmail у меня как раз самая последняя, так как плагины обновляются автоматически.
комментариев: 11558 документов: 1036 редакций: 4118
По крайней мере, у меня на Линуксе в TB 8.0 с Enigmail 1.3.3 такой проблемы нет.
комментариев: 1060 документов: 16 редакций: 32
В Enigmail явно что-то в обработке концов строк поломано. Например, RFC-3156 требует, чтобы подписи в PGP/MIME генерировались по тексту, в котором используются cr-lf концы строк, т.е нужно делать преобразование, если концы строк юниксовые. Ну и при проверке, соответственно, тоже такое преобразование должно делаться. По крайней мере нестабильная ветка 1.4 такой проверки не делает, и в результате подписи от клиентов, следующих RFC-3156, получаются неверными. Возможно, эта проблема как-то связана с обсуждаемой здесь.