Сервер локальной сетевой почты (IMAP) для резервного копирования старых писем


0

Сначала немного контекста:

Я управляю бизнес-сетью с 30 рабочими станциями Windows, на каждой из которых установлен и настроен Outlook для учетной записи Exchange. Сервер Exchange предоставляет 4 ГБ пространства на учетную запись, но многие пользователи быстро заполняют это пространство. До сих пор решение было быстрым и грязным: локальный PST-архив, куда можно перенести все старые письма, чтобы освободить место для новых. Это работает, но это локальный архив, и необходимо регулярно выполнять резервное копирование, чтобы предотвратить потерю писем в случае проблем с ПК. Резервное копирование PST-файла ... сложно, так как Outlook необходимо закрыть, а большой файл необходимо скопировать по сети (даже 10 ГБ для некоторых пользователей) или с использованием некоторых инкрементных резервных копий, таких как rsync (боль в настройке). Вряд ли это может быть сделано автоматически (только потому, что Outlook должен быть закрыт), и не все пользователи могут / хотят.

--- конец контекста ---

Вчера у меня возникла идея: почему бы не настроить локальный почтовый сервер IMAP и настроить учетную запись IMAP вместо локального файла pst? Таким образом, все пользователи могут хранить свои старые электронные письма в этой локальной учетной записи, которые могут быть легко скопированы на сервере.

Но ... это кажется слишком легким ... и я не нахожу никаких ссылок на подобное решение до сих пор, поэтому мне было интересно:

в чем проблема? Что мне не хватает? Как вы думаете, это будет жизнеспособным решением?

ОБНОВИТЬ

Новые факты и проблемы:

  • IMAP - это двунаправленный протокол (он позволяет загружать электронные письма) *;
  • Outlook (и другие почтовые клиенты) заставит также настроить SMTP-сервер, это должно быть решено с использованием поддельного SMTP-сервера (необходимо проверить);
  • Загрузка электронной почты в учетную запись IMAP кажется медленным процессом (проверяется в локальной сети);
  • Этот метод мог бы работать, но все еще кажется излишним

*** Или использовать SMTP для загрузки?


Более простым решением было бы архивировать каждое полученное письмо. Таким образом, пользователям не нужно беспокоиться о резервном копировании электронной почты, если они этого не хотят. Есть коммерческие решения для этого.
— Ramhound

@Ramhound, это не очень хорошее решение, поскольку оно также будет архивировать нежелательные электронные письма, включая СПАМ, может также создавать неконтролируемые архивы конфиденциальных электронных писем.
— Джулиан Найт

@JulianKnight - у них есть решения, которые удаляют спам и шифруют оставшиеся электронные письма.
— Ramhound

Это не указано. Тем не менее, вы могли бы сделать это, но теперь это становится все более сложным, поскольку вы должны убедиться, что вы делаете вещи в правильном порядке. В любом случае, вы все еще слишком много архивируете, так как большинство писем могут быть удалены, но только пользователи знают, какие именно.
— Джулиан Найт

@Ramhound, Джулиан Найт прав, архивация всех электронных писем была бы слишком большой, и нет никакого способа установить автоматический фильтр (единственный, кто может сказать, нужно ли хранить почту, является пользователем)
— lelmarir

Ответы:


0

Вместо того, чтобы использовать локальный сервер IMAP, почему бы не создать надлежащий сервер IMAP и предоставить пользователям доступ в качестве дополнительных учетных записей?

Типичные IMAP-серверы будут хранить данные в формате, который очень легко создать резервную копию и восстановить.

Я думаю, что ответ @ thims может быть лучше, хотя :)

Одна небольшая проблема с любым из этих решений заключается в том, что я не думаю, что пользователи могут установить эти местоположения в качестве местоположения архива, чтобы они не могли использовать автоматическое архивирование Outlook. (Не уверен насчет этого - кто-нибудь еще может уточнить?)


Да, это именно то, что я имел в виду, под «локальным» я имел в виду только локальную сеть (и без возможности отправки / получения), просто чтобы не нужно было устанавливать статические публичные ip и dns. Я могу обойтись без автоматического архивирования, я представляю (из того, что я вижу, это работает только с pst файлами).
— Лельмарир

О хорошо Извините, что неправильно понял. В таком случае, это совершенно нормальная идея. Его преимущество в том, что он довольно прост в настройке (сервер IMAP является самой простой частью настройки почты с открытым исходным кодом), и его легко создать резервную копию.
— Джулиан Найт

0

Просто настройте общие папки Exchange, поместив базу данных на надежный жесткий диск и предоставив соответствующие разрешения для пользователей (скажем, по одному пользователю на папку). После этого каждый пользователь сможет выбрать свою общую папку для целей архивирования.


Я забыл упомянуть, что сервер Exchange не мой, и владелец будет взимать дополнительную плату, которую я бы попросил. Также я не могу настроить другой сервер Exchange (из-за цены).
— Лельмарир

Хорошо, тогда почему бы просто не разместить там архивные файлы PST прямо на вашем файловом сервере и подключить их по локальной сети? Это не лучшее решение для PST в работе, но может подойти для целей архивирования.
— thims

Некоторые рабочие станции являются ноутбуками, и даже для настольных ПК я бы не стал доверять локальному соединению для файла, который должен быть заблокирован Otlook, это наверняка рано или поздно приведет к повреждению. А когда ноутбук отключится, он потеряет архив, вместо этого imap сможет сохранить локальный кеш.
— Лельмарир

@ thims - НЕТ! Это не очень хорошая идея. Это рецепт для поврежденных файлов PST. Мало того, что MS не рекомендует это, я могу сказать из первых рук, что это очень хороший способ потерять большие объемы данных (хотя это уменьшает объем вашего архива!)
— Джулиан Найт,

@lelmarir: хотя использование PST по локальной сети не является хорошим решением, IMAP не будет работать вообще.
— thims
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.