А как смотрели - запуском через LC_ALL=ru_RU.CP1251 при основной локали ru_RU.KOI8-R?  Если так, то причина в другом:

1) Кодировка текста в списке сообщений обновляется только для новых сообщений, либо по команде \"Вид/Обновить список сообщений\".

2) В области просмотра шрифт выбирается криво :-(

Как раз в версии 0.8.6 в оригинале была напрочь сломана работа с однобайтовыми кодировками, поэтому в 0.8.6-alt1 был хитрый патч по этому поводу. Потом большую часть этих изменений убрали (там хотели сделать workaround для людей с криво настроенной локалью - сделали неправильно; теперь это действует только при LC_CTYPE=C), патч из последующих версий тоже исчез.

Проблема в следующем: там делается попытка использовать gdk_font_load вместо gdk_fontset_load для однобайтовых кодировок (насколько я понял, основная цель этого - сделать нормальное отображение iso8859-1 в японских локалях). При этом перестает работать механизм выбора правильной кодировки шрифта, а в имени там по умолчанию кодировка *-*; в результате обычно выбирается шрифт в той кодировке, которая была указана как основная при установке системы, независимо от LC_CTYPE. Сделать это, пользуясь только средствами GTK+, невозможно - в том патче делалась попытка разбора переданного шаблона имени шрифта, но это неправильно. В принципе можно действовать в обход GTK+ (напрямую вызвать XListFonts и выбрать нужный шрифт), но это тоже некрасиво.

Можно явно указать кодировку в именах шрифтов в ~/.sylpheed/sylpheedrc.

А как смотрели - запуском через LC_ALL=ru_RU.CP1251 при основной локали ru_RU.KOI8-R?  Если так, то причина в другом:

1) Кодировка текста в списке сообщений обновляется только для новых сообщений, либо по команде \"Вид/Обновить список сообщений\".

2) В области просмотра шрифт выбирается криво :-(

Как раз в версии 0.8.6 в оригинале была напрочь сломана работа с однобайтовыми кодировками, поэтому в 0.8.6-alt1 был хитрый патч по этому поводу. Потом большую часть этих изменений убрали (там хотели сделать workaround для людей с криво настроенной локалью - сделали неправильно; теперь это действует только при LC_CTYPE=C), патч из последующих версий тоже исчез.

Проблема в следующем: там делается попытка использовать gdk_font_load вместо gdk_fontset_load для однобайтовых кодировок (насколько я понял, основная цель этого - сделать нормальное отображение iso8859-1 в японских локалях). При этом перестает работать механизм выбора правильной кодировки шрифта, а в имени там по умолчанию кодировка *-*; в результате обычно выбирается шрифт в той кодировке, которая была указана как основная при установке системы, независимо от LC_CTYPE. Сделать это, пользуясь только средствами GTK+, невозможно - в том патче делалась попытка разбора переданного шаблона имени шрифта, но это неправильно. В принципе можно действовать в обход GTK+ (напрямую вызвать XListFonts и выбрать нужный шрифт), но это тоже некрасиво.

Можно явно указать кодировку в именах шрифтов в ~/.sylpheed/sylpheedrc.

Виноват. Этот эффект проявлялся при удалённом запуске в виде \"X :1 -query host\". На машине, с которой запускалась команда, xfs настроен на шрифты KOI8-R. Видимо, из-за этого приоритетными были шрифты KOI8-R и в приложениях на удалённой машине. Изменив настройки на локальной машине, получаем корректное отображение на удалённой. Непосредственно на удалённой машине, если сесть за неё, всё отображается как надо. Данная ситуация мне кажется нелогичной, однако к sylpheed претензий нет.

Виноват. Этот эффект проявлялся при удалённом запуске в виде \"X :1 -query host\". На машине, с которой запускалась команда, xfs настроен на шрифты KOI8-R. Видимо, из-за этого приоритетными были шрифты KOI8-R и в приложениях на удалённой машине. Изменив настройки на локальной машине, получаем корректное отображение на удалённой. Непосредственно на удалённой машине, если сесть за неё, всё отображается как надо. Данная ситуация мне кажется нелогичной, однако к sylpheed претензий нет.