С некоторых пор перестал работать сервис "Показывать только новые письма на сервере", хотя птичка с "Показывать все письма" снята. Сервер - редакционный, но вряд ли что-то перенастроил наш администратор. Или все же это он помешал Бату?
Марк.
С некоторых пор перестал работать сервис "Показывать только новые письма на сервере", хотя птичка с "Показывать все письма" снята. Сервер - редакционный, но вряд ли что-то перенастроил наш администратор. Или все же это он помешал Бату?
Марк.
Что за сервис такой? Это Вы про диспетчер или про что?
Виноват: слишком лапидарно изложил проблему. Да, речь идет о Mail Dispatcher. Версия 1.62 Beta 7. Кстати, вот идея появилась (вспомнил другие постинги в этом форуме): не баг ли "сработал" именно в этой версии? Перешел на нее недавно. Рекомендацию "пользоваться релизами, а не бетами" стоит, пожалуй, принять - и проблема снимется. Верно?
Хм, тут всякое может быть. К счастью, проверить очень просто. Посмотрите в своей почтовой директории (в типичном случае
c:\program files\the bat!\mail\accountname) файл account.m_r. Откройте его notepad'ом, хотя бы. Если он пуст, то виноват Бат и Вам предлагается обновиться до версии 1.62 (благо она вышла уже, см. раздел объявлений форума). Если же там есть что-то, то виноват скорее всего админ и общаться надо с ним. Кодовое слово UIDL.
Содержимое файла ACCOUNT.M_R ненулевое (т.е. надо к своему админу обращаться), но оно такое странное, что и Бат можно заподозрить:
1 %YN"!iVH!![#^!!](n"!
2 k+`!!9fQ"!^Mf!!fCC"!
и т.д., всего 12 строк.
На моей машине есть еще несколько экаунтов: кое-где указанный файл нулевой длины, а есть и с подобным (но более внятным) содержимым:
11679 100399011022590
11679 100430608773202
11679 100433305240423
11679 100437024659715
(всего 50 строк). Но эти экаунты я давно не использую.
Я попробовал запустить TheBat.exe от версии 1.61: результат тот же. Несмотря на то, что я вручную (Ctrl+1) ставлю метки "Прочтено" на всех письмах на сервере, в следующем сеансе этих меток нет, и все письма видны.
Все же придется ждать понедельника и спрашивать админа?
Содержимое файла таким и должно быть. Тут фокус в том, что всякое письмо на сервере идентифицируется уникальной строкой (UIDL). Это тот единственный способ, по которому Бат опознает письмо, собственно. То есть при получении письма Бат записывает его UIDL в тот файл, а в следующую сессию приема почты "видит", что это письмо уже было получено, и не берет его. Так это работает в теории -- Вам остается узнать, что там сломалось на практике
Наш админ уверяет, что ничего не менял. Я же обратил внимание еще на одну грабельку: по Ctrl+1 можно изменить флаг "Прочитанные", и по умолчанию он у меня снятым оказывается, когда я захожу за почтой. Ставлю. Снимаю все остальные флаги (Ctrl+2 и Ctrl+3) и жму F2 (исполняй). По идее, все письма на сервере должны получить метку "прочтены", и при следующме заходе не показываться. Дудки!
Пробовал разные сочетания переключателей(программеры Бата могли перепутать положения вкл/выкл) - не помогает. Поставил полноценный 1.62 (не бету) - не помогло. Снести что ли вообще и заново поставить? Благо есть на этом сайте совет, как сохранить настройки (не читал пока его).
Когда у нас на сервере работал telnet, я через pine очень быстро удалял письма, кое-что читая - одновременно и "читанность" оставшихся писем менялась. Но было то давно. Неужели админ что-то тронул - и не заметил?
Вдогонку: подозрительно все же выглядит содержимое ACCOUNT.M_R:
1 %YN"!iVH!![#^!!](n"!
и т.п.
Особенно по сравнению с бэушными экаунтами:
11679 100399011022590
Сможет ли наш админ под FreeBSD как-то обнулить эти UIDL, чтобы они начали генериться заново? В других ситуациях подобные действия помогают: запортился обновляемый файл - удалить его, и новый создастся вполне здоровым.
По-видимому, у вас там на сервере qpopper стоит. Это можно проверить, сделав telnet на 110-тый порт. Читабельность в этом случае можно повысить, перекомпилив qpopper с опцией "old-style-uidls" или что-то в этом духе, но проблемы это не решит: я только что проверил работу 1.62 с qpopper, никаких проблем у меня не видно.
ЕСЛИ это qpopper, у Вас должны быть такие примерно строки в хедерах писем:
X-UIDL: (i0!!G=A"!p(e"!GM?"!
Попробуйте поставить флажок "прочтено" на одно из писем в диспетчере (предварительно записав его UIDL из хедеров), жмите do it, потом поглядите, появился ли этот uidl в Вашем файле account.m_r. Если нет, рекомендую попробовать удалить этот файл. При следующих операциях с диспетчером он должен воссоздаться автоматом.
Победа!!!
Причина нашлась на той же закладке "Управление почтой": если выбрано "Удалять письма с сервера" (у меня так и стояло), то Бат, видимо, считает, что _все_ письма новые, и снятие опции "Показывать все письма на сервере" не учитывается. При этом содержимое файла ACCOUNT.M_R имеет именно такой шифрованный (?) вид:
1 K^3"!S5b"!=am"!?K("!
и т.п.
Если же выбрать "Оставлять письма на сервере", то содержимое становится более приличным:
11679 100399011022590
Это может служить косвенным признаком (для Мастеров\консультантов типа Вас) состояния опции "Удалять/оставлять письма на сервере".
Эксперимент мой был не очень чистым: сначала я, по Вашему совету, удалил ACCOUNT.M_R, и только потом сообразил сменить свое решение относительно оставления писем на сервере. Надеюсь, однако, что результат был бы тем же и без удаления файла.
Не возьмете ли на себя труд проверить вышеуказанное решение, и если оно окажется верным - известить разработчиков Бата, что влияние одной опции на другую без отображения этой связи - не есть хорошо.
Формально они правы: если решено удалять письма на сервере - все они новые. Но при включенном диспетчере писем абонент может изменить свое решение - и письмо оставить; такое письмо не должно полагаться новым.