[sisyphus] kuser

[Sergey Vlasov]

On Wed, 14 Mar 2001 01:15:17 +0200
Aleksandr Blohin <sass на uustoll.ee> wrote:

> On Wed, 14 Mar 2001 01:31:29 +0300
> Mikhail Zabaluev <mookid на sigent.ru> wrote:
> 
> MZ> Hello Sergey,
> MZ> 
> MZ> On Wed, Mar 14, 2001 at 00:02 +0300, Sergey Vlasov wrote:
> MZ> >
> MZ> > > А так -- хвосты...
> MZ> > > Ну не доделан он. Попробуйте Sylpheed. Ямамото -- очень
> грамотный
> MZ> > > программист. Это свидетельство Дмитрия Левина, а значит --
> MZ> действительно
> MZ> > > высокая оценка. Кстати, патч, закрывающий дырочку в security от
> MZ> Дмитрия
> MZ> > > японец принял с благодарностью.
> MZ> > 
> MZ> > Ну неужели еще никто не понял, откуда возникают эти хвосты и как с
> ними
> MZ> бороться? Это же просто попытка кривого декодера base64
> раскодировать
> MZ> строки, автоматически присоединяемые менеджером рассылки к каждому
> письму.
> MZ> Кто не верит - попробуйте взять этот хвост и напустить на него
> "uuencode
> MZ> -m" :-) .
> MZ> > 
> MZ> > Отсюда следует, что эти хвосты - проблема не того, кто послал
> MZ> изначальное сообщение, а того, кто их видит при чтении сообщения.
> MZ> Видимость хвостов означает, что программа пытается тупо
> раскодировать
> явно
> MZ> ошибочную последовательность base64. Вот у меня Sylpheed
> MZ> (sylpheed-0.4.62-ipl2, как и 0.4.62-ipl0.6) никаких хвостов не
> показывает,
> MZ> только орет в терминал "Bad BASE64 content". Так что авторам
> Stuphead
> надо
> MZ> бы разобраться с декодером. А то ведь от такого декодирования мусора
> MZ> недалеко и до дыр в стиле Аутглюка (кстати, а из него хвосты
> видны?).
> MZ> 
> MZ> У меня в mutt под gnome-terminal эта каша вызывает глюки в
> терминале,
> MZ> которые лечатся только его reset'ом. Не знаю, кого здесь винить - то
> ли
> MZ> mutt, который не заботится об escape-последовательностях, то ли всю
> MZ> систему терминального вывода с многообразными termcap и terminfo
> MZ> (горе вам, о поклонники stream-based интерфейсов в стиле Plan 9!).
> MZ> 
> MZ> Может быть, это Mailman добавляет текстовую подпись к телу письма,
> MZ> закодированному в base64?
> 
> Так и есть. Только косяк всё-равно Stuphead-овский и компания.
> В нем base64 не хочет как надо работать. Разработчики это и сами
> признают,
> только вот "гда собака порылась" пока найти не могут :(

Я не совсем понял, что означает "не хочет как надо работать"? Как должно выглядеть сообщение, закодированное в base64 без использования multipart? Если Content-Type: multipart/что-нибудь - тогда никаких проблем, в конце есть ограничитель. А если multipart нет, а, например, Content-Type: text/plain; Content-Transfer-Encoding: base64 - тогда явной строки-ограничителя вроде бы и нет. Если реализовывать RFC 2045 буква в букву - "All line breaks or other characters not found in Table 1 must be ignored by decoding software" в описании base64 - тогда мусора не избежать.

Кстати, Stuphead не один шлет такие сообщения. X-Mailer: Internet Mail Service (5.5.2653.19) - это что такое? Нарыл несколько таких писем в mandrake-russian - точно такой же эффект, как и от Stuphead: "Bad BASE64 content".

И еще есть такая гадость, как X-MIME-Autoconverted: from 8bit to base64, так что даже нормально посланное письмо может оказаться в base64. Правда, на это есть ответная мера - X-MIME-Autoconverted: from base64 to 8bit; именно так ведут себя почтовые серверы рассылок apache-talk, apache-rus и stuphead. Так что там им хвосты не грозят :-)

Выводы:

1. Кодировать текст сообщения в base64 вредно. Подавляющее большинство сообщений ходит в 8bit - и ходит нормально. (С вложениями проблем нет, поскольку в этом случае сверху будет multipart/mixed.)

2. На сервере с рассылкой неплохо бы сделать автоматическую перекодировку из base64 в 8bit. Опять же для архива полезно. Конечно, если завернули в multipart (например, с HTML), это не поможет, но хотя бы часть поймает.