Проблема обозначена, надо решать. Путь напролом – закупить железо ещё мощнее – не в моём вкусе, да и бюджет не резиновый. Очевидный вариант: квоты. Но на практике это не слишком помогает. Клятвенные заверения «я всё почистил» при ближайшем рассмотрении превращаются в котиков, смешные картинки и семейные фотоархивы (в корпоративной почте, да). А количество криков «у меня срочно горит не работает сделайте немедленно» возрастает на порядок. Так недолго и веру в людей потерять.
К счастью, я не психолог, не тренер и не наставник. Моё дело – техника. Вот и подойдём с технической стороны.
Первое, что подумалось – самоуничтожающиеся сообщения. Грубо говоря, всё без отметки «важное» удаляется через N дней. На мой вкус, это должно быть «вшито» в стандарты электропочтового хранения. Но пока этого нет, а реализация показалась мне уж слишком масштабной.
Второй мыслью были копии. Знаете, эти сообщения, где вы не основной адресат. Приходит вам просто для сведения. Часть таких сообщений можно было бы удалять автоматически. Но, внезапно, тут пользователи разделились на два лагеря: «они все нужны вы что» и «а что это такое». Алгоритм автоматической сортировки с такими условиями я не осилил.
Что ж, не удалять, так копировать! Возьмём все копии и сделаем символические ссылки. Беглый анализ показал: даже обработка таким образом только ПОЛНЫХ дубликатов позволяет сэкономить ТРЕТЬ хранилища. Но, но, но. К сожалению, путь это тупиковый ввиду множества технических ограничений.
— ПО сервера местами сходит с ума;
— сложности орг. характера и прав доступа.
К слову, в моём почтовом сервере настройки и общих бэкапов, и архивного хранения для пользователей – очень куцые. Так что пространство для манёвра было невелико.
Что же остаётся? С грустью глядел я на котиков
и прикидывал уже простенькую нейросеть, которая бы чистила почту за юзера. И тут… Позвольте, позвольте, а что вообще котики делают в письме? Помнится, письмо с вложением весит чуть не на треть больше одного вложения! А не переместить ли вложение?..
Так начался путь, где было «много открытий чудных». Знал бы я… Ну, вы понимаете. Капля неведения и отвага ведут нас к победам!
Итак: делаем хранение вложений отдельно от писем.
Главная ошибка, которую можно тут совершить – это открыть eml-файл в текстовом редакторе и решить, что там простой текст. Так я и поступил. И обрадовался. Щас батник напишу. Утилит командной строки для извлечения вложений полно: github.com/erikvdv1/eml-attachments или github.com/maiken2051/uudeview, навскидку. Есть проблемы с кодировками, но это не самое главное.
Самое главное: вынуть файл и создать на него ссылку – дело плёвое. А вот впихнуть эту ссылку в оригинальное письмо… Потому что там не текст. Там MIME.
Опытный читатель, конечно, посмеивается сейчас над незадачливым автором. Автор же открывал для себя прелести «стандарта». Самое главное, что я понял: для впадения в берсерка мухоморы не обязательны.
charset=UTF-8
charset = «UTF-8»
charset=«UTF-8»
charset=UTF-8;
charset=«UTF-8»;
charset = «UTF-8»;
Это вот у них одно и то же.
Разрывы строк посреди потока Base64. Откуда берутся – для меня до сих пор загадка.
И наоборот: отсутствие \r\n\r\n после заголовочной части.
В самом заголовке порядок полей по желанию левой пятки.
Старые письма допускают длину строки не более 80 символов, включая служебные.
В именах файлов могут быть разрывы строк (в теле письма, а не в самом имени).
Вообще разрывы строк могут быть где угодно, это при том, что в стандарте разрыв строки заявлен как конец текущего параметра.
Сам текст письма кодирован. Как конкретно он кодирован, остаётся на совести конкретного сервера, вариантов там куча (смердячая).
А, и в письме почти всегда есть и html-часть. То есть, если шлёшь «Привет» и там есть тэг br или p, то в письме всегда будет ДВЕ секции: с просто текстом и с тэгами. И текст задублирован. А вот здесь они «сэкономили» вычислительные мощности… Просто какой-то зверинец с Франкенштейном.
Имя файлов у них бывают так: filename="=?encoding?type?; а бывает так: filename*0*=encoding'' (ШТА??!!). Второе – это более новый стандарт, RFC5987. В стандарте прямо указано, что filename*0*=ENC и filename="=? одно и тоже. На этом месте я окончательно убедился, что они издеваются. Как это можно нормально обрабатывать, я не знаю.
Отдельно, как водится, отличился Apple. У них вообще какой-то свой стандарт. Забегая вперёд, долгие попытки обработать их код привели к единственно верному решению: «Error: Apple mail is not supported.»
Хотя Thunderbird справляется. С горя я полез в его исходники, но найти нужную секцию в полутора гигабайтах кода на смеси питона и диалектов явы не смог. Полез в их IRC, где мне любезно подсказали, где искать, но всё равно не нашёл.
Но унывать не стал. Документацию не читай@код пиши, и готово. Нет, серьёзно, я что-то должен был сделать, чтобы приблизить конец MIME.
Batch-скриптом не обошлось. Получилась утилита командной строки на C# и dotNet.
Утилита обладает двумя режимами работы:
Первый: просто извлекает вложения. При этом корректно работает с кодировками под Windows.
Второй: и тут главное веселье. Теперь мы таки можем хранить почтовые вложения отдельно от почты! Утилита создаёт новое письмо взамен старого: вложение вырезается, письмо переформатируется в простой HTML с кодировкой UTF без ограничения длины строки. За основу берётся секция text/plain. Если в секции html есть таблицы, то переносит их с сохранением форматирования внутри таблицы, но этот функционал работает так себе. В конец текста текущего письма (если это ответ или форвард) вставляются ссылки на сетевые ресурсы с путём к извлечённым файлам, в форматах file:/// и ftp://.
Система протестирована на 10000+ письмах и развёрнута на действующей инфраструктуре.
Выявленные плюсы:
+ было:
Резервное копирование
было начато в 01:00:08
и успешно завершилось 03:26:32
стало:
Резервное копирование
было начато в 01:00:09
и успешно завершилось 01:40:36
+ Сэкономлено 30+ % хранилища: файлы уходят из тяжеловесного Base64 и иже с ним в нормальный формат файловой системы, плюс множество дубликатов обнаружилось даже внутри отдельных ящиков.
+ Увеличивается скорость обработки ящиков сервером и почтовыми программами.
+ Пропадает «я открыла письмо из почты, 10 часов редактировала и оно не сохранилось»
+ Можно отказаться от квот.
+ Остаётся возможность найти вложение в почте, в отличие от простого переноса в файловое хранилище.
+ Приближаю конец MIME. Покайтесь, авторы!
Минусы решения:
— некоторые письма (но не вложения) всё же бьются. В основном не внутренне, а при просмотре в некоторых клиентах;
— в ftp постоянно ломятся какие-то черти;
— не все почтовые клиенты поддерживают открытие через file:///
Спорные моменты:
? Apple mail not supported. По мне – и Будда с ним;
? Бьются письма со сложным форматированием. Обычно это флаеры с Букинга или реклама;
? Если ftp-сервер на нестандартном порту, то могут быть проблемы с доступом. Решил почтовым ботом.
Таким вот тернистым путём задача была решена.
Спасибо за внимание!
Комментарии (45)
remzalp
16.08.2018 14:32Недавно пролетало про софт для бэкапов BORG, где встроена дедупликация.
https://habr.com/company/flant/blog/420055/
Так же можно поделить на 2 категории — новые письма и старые.
Раскидать по каталогам по годам, активно бэкапить только текущий год, остальные проверять на изменения и не трогать, если есть копия.
А еще весёлый факт расскажу — у меня смежная задача — анализировать почту на предмет нужных вложений с четкими названиями. Как выяснилось, иногда справляются с задачей вставив картинку в html тело письма (gmail таким грешит), бывает mime вложенное в mime вложенное в mime.
Lazytech
16.08.2018 15:02Так же можно поделить на 2 категории — новые письма и старые.
Раскидать по каталогам по годам, активно бэкапить только текущий год, остальные проверять на изменения и не трогать, если есть копия.
Давным-давно, когда жесткие диски были медленные, я вынужденно применял именно этот подход к своей скромной почтовой базе. Для обработки только нужных каталогов использовал связку nnCron + nnBackup. К сожалению, не могу больше рекомендовать этот софт, поскольку не уверен в том, что с ним не возникнет проблем на новых ОС (привет Windows 10).
LevOrdabesov Автор
16.08.2018 15:37BORG – интересный проект, спасибо.
На хабре еще было некое коммерческое решение с похожим функционалом. Цена расстроила.
Минус таких проектов (для меня, по крайней мере): «свой формат». По сути, тоже костыли, только больше (и, следовательно, больше поле для поломок). Проблема-то, в общем, а) в формате б) в организованности пользователей.
А что касается раскидывания – в моём сервере только две опции: «бэкапить» и «не бэкапить» :(
gecube
16.08.2018 15:36Как решается проблема с безопасностью доступа к файлам? Условно — если раньше файл был в письме, то он доступен только адресату и отправителю (ну, и всем промежуточным узлам). Теперь — можно ходить по ссылкам на аттачменты всем
LevOrdabesov Автор
16.08.2018 15:38На усмотрение разворачивающего инфраструктуру.
Я положил файлы в папки на сетевое хранилище с доступом только на чтение и только пользователю, чей ящик, и соответственно права на ftp.gecube
16.08.2018 15:50обработке подвергается ТОЛЬКО входящая почта? Т.е. в исходящей никаких оптимизаций?
LevOrdabesov Автор
16.08.2018 15:54Нет, для Sent папок ровно то же, что и для входящих.
На вход любые eml можно подать, утилите без разницы.gecube
16.08.2018 15:56не-не. Вы не поняли.
Sent — это папка. Т.е. фактически письмо, которое ушло НАРУЖУ, отличается от того, что сохранено в папке Sent. Меня интересовало внешний адресат увидит ли оптимизированное письмо или нет.LevOrdabesov Автор
16.08.2018 15:59А, ясно.
Это не обработка на лету, а оптимизация уже существующих файлов.
Я обрабатывал только письма старше года. Обычно они уже никому не пересылаются.
Sergey-S-Kovalev
16.08.2018 16:091. Квоты (1-2 гигабайта, випам побольше с сетевым архивом), иначе почта мгновенно превращается в аналог файлопомойки.
2. Выгрузка почты старше пары месяцев в локальный архив на ПК пользователя.
3. Инкрементное резервное копирование. Полные копии на выходных.
4. Обслуживание и оптимизация почтовой базы раз в квартал.
5. Выгрузка в архив ящиков пользователей покинувших организацию с последующим удалением из базы.
6. Бэкап с поддержкой application aware. Восстановление от виртуалки в целом, до вложения из письма.
Виртуализация, СРК и хранилище с поддержкой дедупликации, мониторинг, варнинги если что идет не так — само собой разумеющиеся вещи.
LevOrdabesov Автор
16.08.2018 16:18Всё это бесспорно.
Однако корень проблемы и причина этого длинного списка ресурсоёмких задач со сложными связями – по моему мнению, в старом и кривом стандарте. Письмо – это текст, а не интерактивная вебдваноль страница и не файловое хранилище. Можно бесконечно дедуплицировать, инкрементировать, обслуживать и так далее, пока хватает мощностей. Но насколько это на самом деле оптимальный путь? Может быть, пока спрямить?gecube
16.08.2018 16:48гугл и яндекс автоматически конвертируют большие файлы в ссылку на файл в гуглодиск или яндексдиск.
LevOrdabesov Автор
16.08.2018 16:53Верно, и правильно делают.
Одним из вариантов было использование плагина Google Drive для Outlook.
Натолкнулось на следующие проблемы:
— полное отсутствие понимания со стороны пользователей;
— старая почта останется лежать.
Ну и секьюрность, объёмы, прайсинг, буде случится, бэкапы опять же.
Sergey-S-Kovalev
16.08.2018 16:58Я понимаю Ваш энтузиазм и внутреннюю гордость от реализации решения.
У меня 10к-12к это просто среднее число писем за сутки прошедшее через транспортный сервер в рабочие дни. Ты либо делаешь по правильному, либо оно не бэкапится.LevOrdabesov Автор
16.08.2018 17:0810к-12к среднее число писем за сутки
А это со спамом или чистыми?
либо делаешь по правильному, либо оно не бэкапится
Опять же, сложно спорить. Объёмы сейчас гигантские. Но, как я упомянул в статье, «добавить мощности» для меня был не вариант. А в процессе реализации этого решения мне подумалось, что найденный путь проще и экономит множество ресурсов как вычислительных, так и человеческих и организационных. Процессор-часы, например, можно потратить на Folding@home, а не на сортировку никому не нужных, забытых котиков.
Мы привыкли, что у нас в письмах лежит всё что угодно, но насколько это оправдано?Sergey-S-Kovalev
16.08.2018 17:46Чистыми, таки за спам пограничные решения отвечают.
Да и ресурсы, не Ваши, а принадлежат организации. Как и Ваше рабочее время.
Если руководство прямо говорит что, нужно свободные ресурсы направлять на Folding@home, то все вроде норм. Иначе Ваша инициатива ничем не отличается от майнинга на себя, поскольку работающему оборудованию и счетам за электричество всеравно какими намерениями Вы руководствовались.
Содержимое писем, акромя проверки на спам, процессов в рамках DLP и того что в Вашем ящике нисколь Вас не должно интересовать. Котики, бизнес информация или ежедневная рассылка интимных прелестей — это информация тех кто участвует в двухстороннем обмене, она не Ваша.
Если есть проблемы с ресурсами: озвучьте их руководству, приходите сразу с готовыми решениями: добавить диски, ограничить ящики и пользователей
Принесите статистику: топ 10-20-50-100 ящиков по размеру, топ 10-20-50-100 получателей почты, как быстро растет база. Прогноз, когда все это встанет колом, если ничего не сделать.
По резервному копированию тоже самое: Текущее состояние, сколько времени понадобится что бы сервер после полного падения опять начал получать и отправлять почту, сколько времени до момента когда пользователи получат доступ к своим ящикам и почте в ней. Наглядную картинку в RTO/RPO.
Затем предложения: Столько денег — такие то RTO/RPO, такая то глубина архива, а за такое количество денег — такие то фишечки в довесок, которые снижают RTO в разы.
Пускай они примут решение и несут ответственность. Ваша задача объяснить риски, их на основе рискменеджмента принять решение.
И помните, пока вы тут колхозите, драугр качается.Gutt
16.08.2018 18:18Вы, вероятно, никогда не работали в не-ИТ конторах. Кратко суть такова: руководство не интересуют технические детали, оно не хочет вникать в возможные решения, и из вариантов, требующих вложения денег или вложения времени администратора, оно всегда выберет вложение времени: оно всё равно уже оплачено. «Делай как хочешь, но чтобы всё работало и пользователи не жаловались». Такие вот простые и понятные KPI.
По сути проблемы: решение с выдёргиванием вложений имеет право быть, но когда исчерпаны другие, более простые и безопасные решения: расширение хранилища, инкрементный/дифференциальный бекап, многопоточный бекап, переезд хранилища в БД.
Решение — яркий пример того, что менеджмента в области ИТ в компании не существует. Сам так долго работал, теперь мучительно избавляюсь от приобретённых вредных привычек.gecube
16.08.2018 18:37Если компания — не-ИТ, то вполне логично отдать ИТ на сторону. Так дешевле.
Вариант, когда это не работает, когда ты очень большой (ГазПром?), но там может быть внутренний аутсорс.Sergey-S-Kovalev
16.08.2018 20:10Любые, непрофильные процессы выгоднее отдать на аутсорс.
Клининг, ИТ, бухгалтерию, маркетинг… все что не приносит дохода можно, а иногда и нужно отдавать на аутсорс. Естественно к этому нужно подходить с умом.
Sergey-S-Kovalev
16.08.2018 20:06Отчего ж не работал. Я и в колледже успел поработать, и в ФГУПах разных, и на корп как сейчас.
Вы просто пытаетесь помочь и спасти чужой бизнес за счет себя самого. Ну окей, жертвуйте собой за «Большое спасибо». Если организации удобно оплачивать Ваши ночные работы и ждать, когда Вы все почините, а в коллективе Вас будут восхвалять как героя и Вам это будет нравиться, это прекрасно. Однако годы идут, а писец который случится в ночь за день до вашей давно запланированной поездки в далекую и солнечную страну поставит Вас перед выбором: про$рать отдых, потому что Вам нужно пару дней (там все медленно и сложно, и только Вы знаете где какой нужный скрипт лежит) на оживление всего и остаться героем в коллективе за «Большое спасибо!», или отдохнуть с чувством тревоги и выключенным телефоном, и вернуться в переполненный серной кислотой коллектив, который лишился из-за Вас премий в этом месяце/квартале, или проекта, который мог кормить контору ближайшие полгода.
Вы проиграете, это просто вопрос времени.
Зыю
«Большое спасибо» в рот своему голодному ребенку не положишь.
LevOrdabesov Автор
16.08.2018 21:03Вот, здесь я как раз увидел, в чём разница в наших подходах.
У меня, видимо, просто другие отношения в организации.
Они действительно везде разные, это не делает абсолютно правым ни меня, ни вас.
LevOrdabesov Автор
18.08.2018 20:16Всё так.
Расскажите, каковы критерии вредности привычек.Gutt
18.08.2018 22:271. Отсутствие обсуждения решений с другими сотрудниками ИТ-отдела, если таковые существуют. Обсуждать желательно даже то, что к компетенции других сотрудников не относится: даже в этом случае взгляд со стороны позволяет выявить слабые стороны решения.
2. Замена тупых, надёжных, проверенных стандартных решений велосипедами. Я прекрасно понимаю, что хочется сделать своё решение (сам ловлю кайф от велосипедописания), но нужно ударить себя по рукам и найти поддерживаемое широким сообществом или коммерческой компанией решение. Почти всё уже написано до нас, и лучше потратить месяц на поиски и тесты, чем потом полгода на допиливание и самостоятельную поддержку велосипеда. Время администратора почти всегда дороже стоимости софта и железа с поддержкой, если посчитать TCO. Поэтому нужно считать и показывать цифры руководству.
3. Отсутствие системного подхода к обеспечению функционирования и развития ИТ-систем. Это, на самом деле, задача руководителя. Но если такового с нужными навыками нет, то хинт — заочный курс ИТ-менеджмента от ВШЭ стоит совсем недорого (меньше $2k пару лет назад). ITSM в виде COBIT/ITIL, методологии менеджмента ИТ-проектов — всё это офигительно важно в стратегическом плане. Туда же — документирование и процессы, это всё уже продумано в ITSM.
Но! Если в компании три человека и перспективы неясны, то это особого смысла не имеет. В ситуации стартапа имеет смысл делать ad hoc и думать об архитектуре и процессах позже, когда взлетело. В случае же более-менее устойчивого и развивающегося бизнеса это важно с самого начала.
gecube
16.08.2018 16:471. Категорически не согласен. Бесплатные почтовики уже предлагают десятки ГиБ свободного пространства.
У нас в компании проблема решается проще. Есть два типа пользователей: с ящиками 1ГиБ и 5ГиБ с разной стоимостью (ага!). И дурацким ограничением на размер аттачмента в 10МиБ. Не скажу, что это идеально, но вроде работает.
Что мешает сделать бездонный (относительно) ящик?
2. Сомнительно.
В остальном согласен.Sergey-S-Kovalev
16.08.2018 17:581. Ой. Покажите мне бесплатный почтовик, который проглотит хотя бы больше 500 пользователей и даст возможность автоматизации в управлении жизненным циклом учетных записей. И не будет банить ВСЕ учетки в почтовом домене, потому что «наши алгоритмы зафиксировали подозрительную активность» каждые три дня.
Бездонные ящики на вполне конечных стороджах не бывают.
2. А куда Вы деваете почту когда у сотрудника ящик забивается? Меняете сотрудника?gecube
16.08.2018 18:341. Любой корпоративный тариф у GMail или Outlook 365 скорее всего будет стоить денег. Но все равно несравнимых со стоимостью поддержки своего почтового сервера (стандартная дилемма CAPEX/OPEX). Яндекс вроде как бесплатен совсем, но прямо скажу, что его интерфейс действительно не очень удобен. Касательно «подозрительной активности». Никто, повторяю — никто не сравнится со спам фильтрами в гмайле и яндексе. Был опыт использование kaspersky antispam (бонусом антивирус или наоборот), но он просто адово дорогой + у него процент срабатывания несущественно, но хуже.
> Бездонные ящики на вполне конечных стороджах не бывают.
согласен, что чудес не бывает.
2. Ну, если он уперся в 5 ГиБ, то это его персональные проблемы. На текущий момент это достаточно разумная квота (но 10 ГиБ лучше)))) Архив на локальном устройстве не решает проблему мобильности пользователя: у него может быть и ноутбук, и планшет, и телефон. И все с настроенной корп. почтой.Sergey-S-Kovalev
16.08.2018 21:41При 10-20 пользователях да. Несравнимо.
Возьмем 300.
Самый дешманский Office 365 бизнес базовый с Exchange в месяц будет стоить 112 500, или 1 125 000 рублей если сразу брать год. Ящик 50 гигов, облачный диск 1 террабайт. Все на одного пользователя.
Берем гугл. цены там без НДС и в баксах, $ прямо сейчас он стоит 66.88.
в месяц будет стоить 118 377,6, или 1 183 776 рублей если сразу брать год. Почта безлимит, облачный диск 30 гигов на пользователя.
Итого видим, что меньше 1.1 миллиона не выходит, но цены растут, так что 1.2 можно смело закладывать.
Админ у нас уже есть, его не может не быть на контору из 300 сотрудников. И без разницы, что он будет админить, облако или онпремайз. Если он нормальный админ конечно.
Можно ли обеспечить почтовую инфраструктуру в разрезе пяти лет включая железо с дублированием и решением для резервного копирования + лицензии на софт? Легко. И выйдет дешевле.
Гибкость под потребности организации в разы выше. Скорость реакции выше. Автоматизация и интеграция с внутренними ресурсами легче и проще.
Контроль своей инфраструктуры — да.gecube
17.08.2018 00:53Расчет сложный получается.
Если забиваться на MS Exchange, то это стоимость почтового сервера + лицензии на пользователей. Для крупных компаний это скорее всего как минимум две лицензии на Exchange Server 2016 Enterprise (для отказоустойчивости) + лицензии на БД (MSSQL?) + User CAL Standard + User CAL Enterprise. Релизный цикл ПО такого класса у M$ примерно 3 года. Потом вроде как нужно апгрейдиться (хотя секьюрити патчи выходят — поэтому теоретически — можно сидеть хоть на Экчендж 2010). Помимо прочего — нужна лицензия на ОС, дополнительные средства ПО (антивирус? что-то типа ISA? и пошло-поехало). Поэтому сумма млн 5. руб в разрезе TCO 3 года кажутся вполне нормальными для организации в 300 человек при условии, что делаем свой почтовик в периметре.
Вы сами показали, что облачный сервис выходит в 1.2 млн руб. в год.
Я абсолютно уверен, что разница в суммах между своей почтой и почтой в облаке не будет на порядки. Может в разы — для каждого конкретного случая с перевесом в одну из сторон.
Что мы имеем в минусах с облаком?
1. Контроль своей инфраструктуры — да
2. Сложности с интеграцией со всякими скриптами и пр. — да
3. Невозможность настроить некоторые вещи (типа спам-фильтров) — да, хотя неясно нужно ли это
Вопрос с маркетинговыми рассылками открыт. Если их рассылать самостоятельно со своего почтовика, есть шанс залететь в черный список, а потом и легитимная почта не будет ходить. Что делать? Есть куча сервисов типа sendgrid, Mailchimp и пр., но они прям недешевые.Sergey-S-Kovalev
17.08.2018 07:16Три. Транспорт, и два держателя мэйлбоксов для поддержки DAG. MSSQL включен в стоимость изначально. Возможностей Standard редакции вполне хватает. Одну мажорную версию вполне можно пропустить, поскольку тот же 2010 вполне сосуществует с 2016 и позволяет напрямую мигрировать ящики в старшую версию. Итого 5-7 лет использования купленной чанги вполне реально без ущерба безопасности и функционала.
Считается, да, сложно. Всегда индивидуально. Всегда нужно считать экономику и использовать рискменеджмент. Никто не запрещает использовать гибрид, и для мелких организаций, до 200-300 сотрудников, почта в облаке это реальный выход на текущий момент. Но и это будет не бесплатно, это нужно понимать. И всеравно нужен человек, который будет понимать что делать с этим облаком и разбираться с его особенностями.
У мэйла и яндекса, сейчас почту взять дешевле. За яндекс не скажу, но мэйл бизнес вполне стабилен, если ты на платном тарифе.
electronus
16.08.2018 19:55Все же хотелось бы цифры увидеть? 20 пользователей, а общий объем?
LevOrdabesov Автор
17.08.2018 16:51Да, это я не записал, врать не буду.
Могу только сказать, что минимум пять ящиков с квотой 4 Гб, раньше забитые под завязку, теперь спокойно умещаются в 1 Гб каждый.
jrthwk
16.08.2018 20:17> Apple mail not supported. По мне – и Будда с ним;
Они в итоге обрабатываются-то хотя бы? Потому что если нет — вас однажды обязательно ждет увлекательная беседа с начальством «ПАЧИМУМЫНЕПОЛУЧИЛИПИСЬМООТВАЖНОГОКЛИЕНТА???!!!!»
> Бьются письма со сложным форматированием. Обычно это флаеры с Букинга или реклама;
О как. Тогда я таки советую заранее сочинить увлекательную отмазку для начальства на вышеописанный случай. Подсказка — технические детали насчет бэкапа его не убедят, инфа 146%.
> Таким вот тернистым путём задача была решена.
Это, увы, не задача решена. Это был сделан временный костыль, который вам однажды аукнется. По закону подлости однажды или грохнется нужное письмо или там понадобится письмо _именно_то_которое_пришло_от_отправителя_ и вы как автор этой системы окажетесь крайним.
С котиками и семейными альбомами в почте надо бороться только административно, подкладывая подписанную шефом бумажку под каждое решение. А постфактум, под капотом какие-то действия с почтой делать — моветон и игра с огнем.
А проблемы с объемом и скоростью бэкапа лучше все-таки забивать железом.LevOrdabesov Автор
16.08.2018 20:59Спасибо за мнение!
Apple mail not supported.
Они в итоге обрабатываются-то хотя бы?
Они остаются в неизменном виде. Никакого криминала.
Бьются письма со сложным форматированием. Обычно это флаеры с Букинга или реклама;
О как. Тогда я таки советую заранее сочинить увлекательную отмазку для начальства
Вот в этом минус сугубо технического подхода.
Письма старше года на самом деле никто не читает и не использует. Просто «нам так спокойнее».
С котиками и семейными альбомами в почте надо бороться только административно, подкладывая подписанную шефом бумажку под каждое решение. А постфактум, под капотом какие-то действия с почтой делать — моветон и игра с огнем.
Видимо, я не совсем корректно сформулировал общую мысль.
lingvo
16.08.2018 20:21Когда у меня в очередной раз сбойнул почтовый сервер, я тупо потратил день и переметнулся на Гугл Почту. Больше всего времени понадобилось на изучение, как сделать доменные почтовые адреса.
Пока уже почти год юзеры(10 штук) не беспокоят. Гугл и все остальные в плане приложений поддерживают отличную политику — до 10Мб пересылай аттачментом, а больше — заливай на гуглдиск и давай ссылку. Имхо очень дисциплинирует.LevOrdabesov Автор
16.08.2018 21:01Кстати, был опыт похожий с отечественным хостером – Яндекс ПДД.
Так вот, у них бывает, что письма уходят по нескольку часов. А в поддержке отвечают «Да, так и есть, терпите».
до 10Мб пересылай аттачментом, а больше — заливай на гуглдиск и давай ссылку. Имхо очень дисциплинирует.
Полностью поддерживаю.
firk
18.08.2018 16:06+1Тоже заметил что все форматы, связанные с электронной почтой (как формат писем так и протоколы), совершенно отвратительны и отбивают желание писать какой бы то ни было софт для их поддержки. А ещё эта зараза проникла в http под видом content-type multipart/form-data. А ещё наверно с этим как-то связано то, что конфиги известного серверного почтового софта (sendmail, exim) тоже смотрятся неадекватно.
По-моему в самом начале (70-е годы или около того) там было всё хорошо, но то ли они были малопригодны для расширения, то ли авторы первых расширений к ним были криворуки, но все последующие расширения к почтовым форматам выглядят сделанными и интегрированными в базовый формат абы как. А без всей этой кучи мусора современная почта уже не будет работать, к сожалению, и все новые реализации вынуждены её поддерживать.
Lazytech
По-дилетантски предположу, что вместо изобретения велосипеда можно было ежедневно создавать разностные резервные копии (differential backup). Что касается файлов электронных писем, содержащих вложения, для их упаковки можно было использовать бесплатный архиватор 7-Zip со сторонним плагином eDecoder.
Если я в чем-то ошибаюсь, прошу поправить.
P.S. Кстати, есть еще бесплатный архиватор ZPAQ, который тоже может подойти для означенных целей.
alexanster
Спасибо за упоминание eDecoder, на первый взгляд выглядит мегаполезно.
Lazytech
Если что, я использовал плагин eDecoder давным-давно, когда в нем еще не было кодека eSplitter.
LevOrdabesov Автор
О, классно, спасибо!
Решает как минимум проблему объёма бэкапа.
Правда, скорость обработки вряд ли сильно вырастет. А само ПО сервера по-прежнему останется нагружено тоннами котят.