Проблемы учёта доменной квоты в Dovecot 2

Domain quota accounting problems in Dovecot 2

Несколько лет назад в статье "Двухуровневое квотирование в Dovecot 2" автором была описана система устройства квот пользователь / домен в популярном IMAP4 / POP3 сервере Dovecot. Вкратце, напомню, что она позволяет ограничивать размер занимаемый как конкретным почтовым ящиком, так и всеми принадлежащими данному домену учётным записям. Это решение нашло применение на многих инсталляциях почтовых систем по всему миру.

Однако, в ходе реальной эксплуатации рядом пользователей были замечены некоторые технические проблемы такого решения. Рассмотрим в чём они состоят и как решаются.

Вероятно, постоянные читатели блога kostikov.co заметили, что он, как, впрочем, и ряд других поддерживаемых автором HTTP-серверов, работают на базе Lighttpd. Действительно, этот быстрый и лёгкий веб-сервер снискал широкую популярность и был широко распространён в качестве лучшей альтернативы стандартному Apache. Однако, с течением времени и неизбежным прогрессом в сетевых технологиях разработчики Lighttpd заметно отстали в их поддержке, а конкуренты, в лице, главным образом, Nginx, за тот же интервал существенно нарастил функционал и стал куда более распространённым решением.

Наиболее существенным недостатком Lighttpd представляется отсутствие в настоящее время поддержки им современной версии протокола HTTP/2, которая имеет большое количество преимуществ перед предыдущими версиями. Также минусом этого веб-сервера является отсутствие поддержки протокола Online Certificate Status Protocol (OCSP), который начинает приобретать важное значение в свете борьбы со злоупотреблениями при выпуске SSL-сертификатов.

В связи с вышеизложенным, после изучения возможных альтернатив, автор принял решение о переносе блога на HTTP/2 сервер H2O, которому ранее была посвещена обзорная статья, как на наиболее прогрессивный и перспективный в обозримом будущем вариант.

Вернуться к теме обучения антиспам-фильтров в Dovecot, которая ранее уже затрагивалась в одной из статей на этом сайте, меня заставило недавнее сообщение от всё помнящего "Charlie Root" прекращении поддержки широко используемого для этих нужд расширения Antispam plugin.

To: root@my.server
Subject: my.server weekly security run output
Message-Id: <E1dObLP-000MHX-25@my.server>
From: Charlie Root <root@my.server>
Date: Sat, 24 Jun 2017 05:02:43 +0200

Checking for packages with security vulnerabilities:
dovecot2-antispam-plugin-20130429_29: Tag: expiration_date Value: 2017-07-31
dovecot2-antispam-plugin-20130429_29: Tag: deprecated Value: Use pigeonhole instead. See https://wiki2.dovecot.org/HowTo/AntispamWithSieve

-- End of security output --

Одной из важных задач администрирования корпоративных и публичных почтовых систем всегда являлось, во-первых, поддержание базы данных пользователей в надлежащем состоянии, а, во-вторых, связанная с этим задача оптимизации нагрузки на файловые хранилища, предназначеные для размещения пользовательской информации. Проблемой это может становиться уже при количествах почтовых ящиков, исчисляемых сотнями, не говоря уже про серверы, поддерживающие многие тысячи учётных записей пользователей электронной почты, когда ручное управление ими может быть крайне затруднительным.

В этой связи, встаёт вопрос автоматизации контроля за актуальностью пользовательских аккаунтов и освобождения используемых ими учётных данных и ресурсов для хранения корреспонденции.

Вопросы безопасности в целом, и проблемы аутентификации в частности, уже давно являются главной проблемой функционирования сети Интернет. К настоящему времени разработана масса способов, протоколов и стандартов, призванных сделать работу в глобальном киберпространстве надёжной и защищённой от различного рода угроз. К примеру, одним из самых известных и широкоупотребимых механизмов обеспечения безопасности является протокол HTTPS, который предназначен для передачи данных, в основном, во Всемирной паутине на базе криптографических методов SSL / TLS. Последние же неотъемлемо связаны с инфраструктурой удостоверяющих центров (CA), которые через цепочку доверия посредством цифровых подписей призваны гарантировать подлинность того или иного ресурса в сети.

Если удостоверяющий центр включён в список доверенных для данного программного обеспечения, в частности браузера в случае с протоколом HTTPS, то узел сети использующий выданный этим CA сертификат заведомо признаётся подлинным и, следовательно, заслуживающим доверия. Однако, именно здесь и находится главная проблема данной системы. Пользователь вынужден слепо доверять всем сертификатам, которые такие доверенные удостоверяющие центры выдали стороннему по отношению к ним самим ресурсу. При этом, нет никаких гарантий что это было сделано с ведома самого владельца такого ресурса. Ставшие достоянием общественности в последние годы многочисленные прецеденты выпуска известными удостоверяющими центрами сертификатов с серьёзными нарушениями правил их выдачи, самым громким из которых явился случай с DigiNotar, вновь поставили вопрос доверия к самой системе CA со стороны пользователей и заказчиков, а также разработку и внедрение более надёжных методов аутентификации в Интернет.

Скрипт синхронизации набора каталогов в облако Mega

Shell-script to syncronize directory list to Mega cloud drive

И вновь по просьбам помочь с усовершенствованием скрипта синхронизации с облачным харанилищем Mega, описанным в соответствующей статье, публикую его доработанную с учётом пожеланий версию.

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

Очевидно, что в случае, если требуется независимая синхронизация набора каталогов объём которых и, соответственно, и время потребное на их загрузку во внешнее хранилище, может быть существенным, такой подход применять нельзя, поскольку всегда есть риск, что содержимое одного из синхронизируемых каталогов может измениться в этот промежуток и, следовательно, оно не будет впоследствии идентифицированно как обновлённое.