видимо пора, хотя не я одна на двойке, и что - никто такого с 2.15 не наблюдал
--------
Обновила до 2.0.0.16
(от 15.07.2008 - выдали с интервалом 2 недели, исправлены 2 критич.уязвимости).
Не помогло.
Но заметила, что если в айпишнике первый октет три символа (больше 99.)- идет через прокси, если два или один символ - пилюет на прокси и ломится напрямую.
Прикол !
--------
Помогло - в настройках сети полностью стерла строку "не использовать прокси для:",
перезагрузила лису, вновь прописала ту же строчку.
И заработало!! Все адреса через прокси.
--------
Предположение - в строчку что-то дописалось через непечатный символ и было не видно при просмотре.

Установила на днях обновы: FF 2.0.0.15 и win XP SP3 (поверх SP2).

В FF появился глюк (после чего не поняла):
на любой адрес - указанный по айпишнику, например "http:\\4.23.54.124, http:\\66.55.192.61" лиса пытается выйти минуя прокси, хотя в настройках четко прописан прокси и "не использовать" только для локальных адресов (смотрю Active Ports) (в etc\hosts никаких левых затычек нет). В IE никаких глюков. Если по именам - вроде всегда через прокси. (адреса привела из замеченной непонятной сетевой активности)

Помогите понять - что сломалось?

Да, я его уже нашла. Залила с него вновь добавленные описания в preference.jar. В процессе сверки выплыла куча искажений в именах переменных,  типа потерянные ".", "_", слова, удвоение слов, запятые вместо ".".
Кроме этой чешуи, там есть еще такие глюки:
в исходном файле есть группы полностью описанные, но описание не видно. Если имя переменной исправить через FOO, все описания проявляются. Пример: группа capability.policy.default - полностью описана, но не видно. default заменить на FOO - все описания появятся.
---
Все равно много пустоты. Кто знает, где еще можно описания на русском взять?

ТВ 2.0.0.14 + Separate Reseipts 0.0.1 = полный бардак.
------
Это в качестве справки: для запросов уведомлений используются 3 поля заголовка:
(R) Return-Receipt-To - стандартный запрос Доставки, откликаются почтовые сервера и некоторые клиенты
(D) Disposition-Notification-To - стандартный запрос Прочтения, его шлют и на него откликаются все почтовые клиенты
(X) X-Confirm-Reading-To - нестандартный запрос Прочтения, не все клиенты его отправляют и не все на него реагируют
-------
Проверка на 3 клиентах:
Запрос доставки:    Бат, Аутлоок - шлют (R).
Запрос прочтения:  Бат - шлет 2 заголовка (D)+(X), Аутлоок - (D).
Реакция на запрос: Бат, Аутлоок - на (R) не реагируют, на (D) отвечают оба. На (X) отвечает только Бат.
-------
Птица - реакция на запросы: на (R) и (D) - одинаково "уведомит о прочтении", на (X) - не реагирует.
Формирование запросов зависит от receipt-настроек и наличия Separate Receipt (SR).
Причем с SR бардак получается полнейший:
- без SR, когда возможен только один запрос,