thunderbird+imap - странности [SOLVED]

сразу скажу, проблема очень странная, и может даже не связанная ни с thunderbird, ни с imap. :)
но - всё по порядку.

месяц назад мой домашний воркстейшн был на винде, сервер (тут же, под боком) - на asp linux 9.2. Стоял mozilla-thunderbird, сервером был какой-то imap сервер, сейчас уже не вспомню как назывался (rpm-пакет вроде так и назывался - imap-****.rpm). Работал через xinetd. Всё было нормально, никаких отклонений.

в конце декабря переставил рабочую машину на дженту. Поставил тот же thunderbird. Чтобы не маяться с настройками, профиль скопировал из винды. Всё заработало сразу и как надо.

неделей позже участь рабочей машины постигла сервер: заменил асп на дженту. Для imap-сервера выбрал courier-imap. Всё заработало, но почти сразу пошли неприятные баги: в процессе работы клиент неожиданно прекращал любое взаимодействие с сервером. Точнее, я далеко не сразу понял, что это именно так, т.к. баги были сильно странные, например - захожу в папку, клиент в статусбаре показывает, сколько в ней писем, но сами письма не показывает. Выделяю письмо, оно не отображается. Некоторые папки и письма открывались из кеша, меня это поначалу сбило с толку. Попытка перемещения писем ни к чему не приводила - письмо оставалось на месте. Клиент в статусбаре стабильно писал - "connected to server".

сначала я резко начал грешить на имап-сервер. Удалил, поставил другой. Ничего не изменилось. Т.к. courier-imap успел мне понравиться, вернул всё назад. :) и начал разбираться последовательно.

первая же проверка ethereal'ом (на клиенте) дала странный результат - когда коннект повисает, между сервером и клиентом начинается перекидывание пакетами SYN, SYN+ACK, FIN+ACK. Затем решил выяснить, чем это вызывается. Сначала обратил внимание, что последняя команда перед этим - IDLE. Подумал - мало ли, может из-за этого. Настроил клиент, чтобы не использовал IDLE. Оказалось, толчком служит открытие сравнительно большого письма - стало понятно, почему баг проявлял себя не сразу, а спустя какое-то время, в процессе работы. С третьей-четвертой попытки обнаружил еще кое-что: подобная активность иногда начинается с приема фрагментированного пакета, но не всегда. Т.е. явно что-то происходит при прохождении больших пакетов.

между сервером и клиентом - один свитч. Перезагрузил. Не помогло. Пробовал проверить ping'ом, игрался с размером пакета, фрагментацией - всё нормально, пакеты с размером 1500 вполне нормально отправляются/принимаются. В качестве теста установил MTU на сервере и клиенте 1400 - не помогло, вернул назад. Т.к. время было позднее, пришлось временно забить. Как обычно, нет ничего более постоянного, чем временное.:)

сегодня я вернулся к этой проблеме. Начал думать "с нуля". Потому как проблема проявляет себя только при соединениях imap (ничего подобного с другими сервисами замечено не было), логично предположить, что проблема связана с сервером или клиентом. Сервер менялся. Клиент - нет, но когда сервер был на асп, клиент работал нормально.

чтобы исключить проблемы с сетевыми картами / свитчем, решил поднять имап сервер локально. Указываю imap-сервер 127.0.0.1. И всё повторяется ! ethereal, слушающий lo, выдает абсолютно то же самое.

Одна из возможных, но маловероятных причин - что-то, связанное с ядром, с обработкой больших пакетов. Но это вообще последний вариант. Наиболее вероятна проблема клиента. Вспомнил, что профиль когда-то сдернул с виндовой машины. Переименовал папку, создался новый профиль, с ним всё точно так же. Перекомпилировал thunderbird - не помогает. Последний шаг для исключения проблемы клиента - это попробовать другой. В связи с чем прошу подсказать, какой клиент можно поставить для подобного теста.

Но в качестве клиента мне нужен именно thunderbird, что с ним делать - мягко говоря, не представляю. Я просто в замешательстве...