Появилось несколько важных вопросов
- Очищаю один раз в 3 месяца почту "местной утилитой" очистки — сообщения удаляются физически, но заголовок остается в почтовой программе. Да, и еще — удаляет ли epurger папку domain\user\archive?
- Пользователь имеет папку удаленные, куда "перетекают" все удаленные письма пользователем в ручную, дак вот парадокс "Если пользователь удаляет сообщения из папку Удаленные (т.е как я понимаю посылает команду IMAP Delete) эти сообщения возвращаются обратно в папку удаленные — петля". Я их физически удалил из каталога пользователя, а заголовки опять появляются, сжать тоже не получается... Подскажите господа
- Epurger (или eachfile.exe?) удаляет то, что вы ему укажете удалять.
- В IMAP'е нет команды Delete. Есть команды "пометить к удалению" (ставится флажок "удалено") и "очистить помеченные". Почтовые клиенты обычно по умолчанию настроены обрабатывать удаление так: скопировать сообщение в папку "Удаленные" и пометить сообщение в исходной папке флажком "Удалено". Всё. Собственно удаление они не выполняют, а делают ровно наоборот — создают лишнюю копию
Чтобы удалить, нужно выполнить IMAP-команду EXPUNGE (в интерфейсе почтовых клиентов это называется "Очистить" или "Сжать"), либо поставить галочку в его настройках "Очищать при выходе".
Я рекомендую изначально настраивать почтовые клиенты так, чтобы видеть помеченные к удалению сообщения (чтобы при нажатии кнопки удаления они показывались зачеркнутыми), тогда точно не забудешь "Сжать", т.к. "недоудаленные" мешают работе. Также лучше отключить функцию "удаления в Удаленные".У пользователя с проблемной утечкой делаю: пометить на удаление\сжать\очистить письма исчезают, но при повторном запуске Mozilla Thunderbird сообщения "возрождаются". Далее, удалил сообщения физически из папки Trash, остались только возрождающиеся заголовки с телом сообщения "Оригинал сообщения отсутствует"... ( Мистика какая-то.
ред: 15.02.2011 15:49
Имейте ввиду, что удаляя физически "местной утилитой" очистки (типа epurger/eachfile) папки spam, архив или еще что-нибудь, индексы всех этих писем! не очищаются, поэтому использовать эти утили для работы с почтой в новой концепции Е4 нельзя! Я поднимал этот вопрос еще на заре Е4 ... но воз и ныне там
P.S. а проблемы в Е4 с "Оригинал сообщения отсутствует" имеют место быть не только при удалении/перемещении... не дай Вам (или вашим пользователям) бог перенести папку из inbox-a куда-нибудь во втутреннюю иерархию (многоуровневую), а затем просто переименовать один из каталогов иерархии (выше по уровню) и подключиться другим imap клиентом (или просто сбросить кэш старого) и проблема "Оригинал сообщения отсутствует" станет Вашей головной болью...
Верно. Не надо ничего (кроме спама) вручную или purger'ом удалять или перемещать. Используйте POP/IMAP, и вы никогда не получите "Оригинал сообщения отсутствует". То, что вы пытаетесь делать — это аналог ручной работы с секторами/кластерами диска вместо использования функций файловой системы, в этом случае тоже проблемы с целостностью файловой системы гарантированы.
Вы использовали acIMAP4 внутри PigMail'а, т.е. довольно экзотическую комбинацию. Возможно поэтому мне не удалось воспроизвести проблему по вашей инструкции. И больше никто не жаловался.
Dandy, специально для вас в acIMAP добавлена поддержка квот в IMAP-папках.
dima-irk38, настройте IMAP-клиент по указанным выше инструкциям, и ничего в папку Удаленные/Trash попадать не будет. А то, что там "возрождается" — это результат ручных манипуляций с содержимым папки. Не надо так делать. Удалять пуржером можно только спам (старые файлы в DATA\mail\spam) — там никто не будет переживать из-за "оригинал сообщения отсутствует". А то, что лежит у пользователя в папках — очевидно ему еще нужно. А что не нужно — он удалит и сожмёт, и всё ненужное исчезнет (из пользовательской папки) само без ручного вмешательства.
Вот я хочу избавиться от заголовков сообщений (Оригинал сообщения отсутствует), с сервера
Как я понял план дальнейшие действия следующие:
При сжатии папки удаляются [помеченные к удалению] записи в индексе, а также сами письма (eml-файлы), если они лежали у пользователя в папках, т.е. если он переносил их в свои локальные архивы. Если удаляемое письмо было не в локальном архиве, а в общем arc4, то оно там остаётся, т.к. нельзя точно определить, в скольких индексах на них ссылка. Если хотите сэкономить на arc4 (хотя много там не сэкономит), то можно удалять/архивировать там старые сообщения — старее года, допустим (это легко и без пуржера, т.к. там папки помесячные) — если пользователь за это время не сделал локальную копию, и письмо так и лежит в инбоксе, то наверное оно ему и не нужно...
Можно и так. Или настроить как на приведенных выше картинках. В этом случае "удалённые" сообщения показываются зачеркнутыми, и пользователь сам старается сжимать папку.
Если на сервере папка Trash удалена, а клиент продолжает показывать сообщения в папке "Удаленные", то сносить надо хранилище в почтовом клиенте, а не на сервере, т.к. серверу уже и так неоткуда "возрождать" эти сообщения.
Если папку Trash физически удалить, она восстановится?
ред: 15.02.2011 18:23
Если я правильно понимаю концепцию хранения почты в Е4 (если нет, то убедительно прошу поправить меня), то вся почта папки "Входящие" (inbox) у ВСЕХ пользователей физически лежит в одном каталоге, а у каждого пользователя (пользовательского почтового ящика) есть свой файл индексов по которому сервер выдает клиенту список писем данного конкретного пользователя. И в этом есть основное отличие от того, что было в Е3 (и есть у меня в моем гибриде Е4 + Pigmail for E3). Но при перемещении письма (внутри почтового клиента) в папку (в свою иерархию папок) из inbox-a, концепция Е4 и концепция Е3 становятся одинаковыми и тут уже ситуация на экзотическую никак не тянет. И вот тут проблема "Оригинал сообщения отсутствует" появится вновь во всей красе, так как внутри таблиц индексов путь к физическому файлу АБСОЛЮТНЫЙ
Если в Е3 для переноса почтовой базы на другое хранилище (другой диск, другую иерархию каталогов и т.п) достаточно было инструмента копирования, то в Е4 для этого нужны особые танцы с бубном — а именно копировать, потом удалять все db3 индексы, потом для каждого! каждого! пользователя запуска e4in (инжект) и вуаля .... только потом каждый! каждый! пользователь получит у себя весь свой почтовый ящик ... но только все письма будут непрочтенными. А если он еще и не сжимал удаленные, так и мертвые воскреснут. Тут, наверно, можно поизвращаться с выборочным удалением индексов, но ... например, меня на это уже не хватило.
Андрей, то что никто, кроме меня не жаловался — не есть показатель того, что проблемы нет... это так же, как то, что проблем совместимости концепции Е3 с бинарниками Е4 не должно было быть архитектурно, но тем не менее, мы 2 месяца с Вами и Игорем пилили, чтобы это все хоть как-то заработало. Да и iPhone-ов у народа, конечно нет, что проблема несовместимости с acIMAP всплыла, только когда 3GS активно продавался в России, а за бугром 4G вышел...
А тем более, что многие (даже на Е4) так с дедушки POP3 и не слезли... а проблемы, я уверен, есть только, к счастью, проявляются в редких случаях, а многие их списывают на "кривость" клиентов, пользователей и т.п.
А может быть на самом деле не так много тех, кто реально, активно и в достаточных количествах используют IMAP сервер в Е4? (ибо в Е3 IMAP можно было использовать только на ящиках в несколько сот мегабайт...) и об этом знали, но вот вопрос производительности поднимался не так часто? (не только на форуме, но и в HelpDesk-e еще от Битрикса на тот момент...)
Отлично, а ручки к нему когда-нибудь появятся?
Т.е. пускай файл индексов пухнет и пухнет?
А если вдруг, в один прекрасный момент нужно будет из него письмо легитимное достать или администратор решит на нем спам фильтр переобучить? Да любой! клиент умрет просто на приеме списка заголовков всего этого "богатства", хотя по факту 90% писем уже физически не существует, так как "Оригинал сообщения отсутствует"
P.S. я уже многие годы являюсь поклонником линейки Eserv по целому ряду причин, но мне странно видеть, что вместо того, чтобы отшлифовать базовый функционал — тот на который в Eserv всегда была сделана ставка в новых версиях предпринимаются попытки догнать и обогнать давно ушедший паровоз groupware серверов типа Exchange, Zimbra и других
В E4 по умолчанию относительный (от exe).
Обновляется. Мы с вами на эту тему несколько месяцев столько килобайт извели
Вы можете остаться на E3, если хотите (тем более, что E4 и не покупали, а получили бесплатно как соавтор Eserv
Давайте не будем перечислять все исправленные проблемы? Их много. И я даже знаю, что в том же iPhone их еще больше. У моего сына iPhone, и его апдейты рисуют самые толстые графики трафика в нашем домашнем Eproxy. Нет программ без ошибок — мы люди, а не машины. Долго ли вы мучались с той проблемой iPhone? День или два? Много ли у вас других поставщиков софта, которые так быстро исправляют проблемы совместимости?
ред: 15.02.2011 18:47
В мире виртуализации хранить контент вместе с программой, а не на отдельном хранилище, кажется мне не самым оптимальным. Но даже если так, то жаль, что разработчики не думают, что DATA может быть на отдельном логичеком/физическом/виртуальном диске, а значит "относительно от exe" == "абсолютному пути" (с указанием диска)
Да, вы правы! Но, увы, отказаться от того богатства функционала, доступного в Е3 (в версии Pig*) я уже никак не могу... но и оставаться на Е3 уже не мог, по причинам производительности, о которых Вам прекрасно известно.
Не знаю, что Игорь сделает под Е4 (и будет ли он что-то в этом направлении выпускать), но для меня идеальным сервером был бы старый-добрый Е3 (с поистине безграничными функциональными возможностями) и новым движком на базе БД (индексы или полное хранение уже не так принципиально), хотя, для меня почтовый сервер — это почтовый сервер, а groupware — нечто независимое, так сказать: "мухи отдельно, а котлеты отдельно", а вот сковородка общая!
Значит считайте меня первым, напильник в руки (и бинарники Е4) я взял не от хорошей жизни и огромного количества свободного времени!
Базовый функционал в основном отшлифован. Догнать и перегнать Exchange и Zimbra — такой задачи никогда не ставилось, это был бы большой РЕгресс
Вы упрекнули меня в том, что в Eserv абсолютные пути, я вас поправил, что по умолчанию не абсолютные. Больше ничего (хорошо или плохо) я не имел в виду. Вы отлично знаете, что в Eserv/3, т.е. с 2003 года, путь к DATA настраиваемый, т.е. вы можете указать там и абсолютные пути, в т.ч. и другие диски. Проблема при переносе писем была связана не с абсолютностью путей, а с "разнонаправленными" "/" и "\" в пути.
На практике вы заставили меня и Игоря взяться за напильники
Между прочим, вы тоже не адаптировали свои программы для E4. Хотя у вас, как и у всех, был целый год (2009) от начала открытого бета-тестирования до начала продаж. Да, я виноват, что не смог обеспечить 100% обратную совместимость. Если бы вы подключились к работе раньше — в январе 2009, как я к тому призывал — то было бы намного проще.
ред: 15.02.2011 22:41
Согласен, не адаптировал и только потому, что следую Вашему совету, который Вы как-то дали в одном из постов еще на заре Е3: по возможности обкатывать свои аддоны на себе (т.е. использовать продаваемые дополнение в реальных условиях), а как я могу использовать их реально, если:
а) Даже в прокси приемлемую прозрачную работу NTLM (чтобы пользователи AD создавались в базе Eserv-a, не плодились учетные записи и гости, браузеры вели себя в среднем "адекватно") удалось добиться только в последних бетах! А ведь поддержка NTLM "из коробки" была заявлена, как основная отличительная черта в прокси E4 от E3 и я искренне не понимаю, как другие покупатели Е4, кто реально используют NTLM в средних (и крупных?) сетях с доменной архитектурой не испытывали подобных проблем...
б) Про почту я все сказал выше, уже просто не представляю себе работу почтового сервера (тут я о больше SMTP) без тех опций, что реализовал Игорь
Может быть та проблема и была связана "разнонаправленными" "/" и "\" в пути и она, скорее всего, была успешно решена, но вот проблема с переименованием каталогов в иерархической структуре ну никак не связана с этими "/" и "\" (а если связана, то не исправлена), ибо воспроизводится все со 100% результатом с последними бинарниками acIMAP
Извините, я думал, что там и так понятно:
Удалите, она вам все равно не нужна
NTLM работает нормально еще с E3, реализовано весной 2008. Несовместимость с Firefox'ом появилась позже,
В январе 2009го, когда я предлагал подключаться к бетатестированию E4, речи о Eproxy/4 еще даже не шло. Eproxy/4 разрабатывался в 2010м году. Если вы не хотели тогда испытать на себе Eserv/4, то не надо теперь обижаться, что ваши (будущие) интересы могли быть не учтены. Если вы подходите к вопросу как покупатель, а не как разработчик, то и действовать надо соответственно: купили E3 — используйте E3, и вопросы задавайте по E3, купили PigMail — используйте его и вопросы к Игорю. А если вы разработчик — пишите свой компонент, испытывайте совместимость, указывайте на несовместимость и вносите предложения (в виде патчей) по устранению. Как мы раньше и работали.
Связана-связана. Тот UPDATE-запрос, который заменял в пути один подкаталог на другой (при перемещении), не работал только из-за того что он пытался заменить подстроку с единообразным наклоном слэша, т.к. сам их такими создает, и ничего другого не ожидает, а на практике в базе были "разнонаправленные" — в базовом пути (абсолютном пути к DATA у вас) в одну сторону, в остатке пути — в другую. Мы это обсуждали в переписке.
Гости размножались не зависимо от ОС