Max Kostikov

Интернет полон руководств о том, как можно просто и удобно организовать поддержку системы электронной почты для собственного корпоративного домена используя возможности, предоставляемые Google.

Казалось бы, ваша корпоративная почта на Google mail получает лишь одни преимущества, к примеру, в виде стандартизированного интерфейса, качественной защиты от спама, наличие общего календаря и доступа к документам. И всё это при простом развёртывании и высокой надёжности системы.

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

Но, обо всё по порядку.

Max Kostikov

Сегодня блогу kostikov.co исполняется один год!

Именно в этот день ровно год назад был опубликован первый пост "Получаем и обновляем SSL сертификат Let's Encrypt" который и спустя год является самым популярным материалом на сайте с 1723 просмотрами на данный момент. И это неудивительно, ведь он появился как раз в тот момент, когда начался взрывной рост перехода сайтов на использование протокола HTTPS.

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

Max Kostikov

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

Среди последних проявлений такого прогресса можно отметить и недавнее решение CA/Browser Forum о необходимости обязательного использования контроля DNS-записей типа CAA (Certification Authority Authorization) в процессе выдачи SSL-сертификатов начиная с сентября 2017 года.

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

Shell-script to syncronize directory list to Mega cloud drive

Max Kostikov

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

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

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

Greylisting используя Exim ratelimit

Greylisting using Exim ratelimit

Max Kostikov

Составление "серых списков" (greylising) отправителей электронной почты в том или ином виде и работа с ними в почтовых системах являются одной из популярных методик борьбы со спамом. Вкратце, её суть состоит в ограничении и / или откладывании приёма сообщения от подозрительных хостов.

Список этих хостов может формироваться на основании синтаксического разбора начальной сессии или, к примеру, на основании ранее накопленной статистики антиспам-подсистемы на данном сервере (см. статью "Использование статистики Spamassassin в конфигурации Exim"). Главным критерием при этом должно стать обеспечение беспрепятственной и быстрой доставки корреспонденции от хостов с хорошей репутацией и создание трудностей для тех отправителей, которые по принятым критериям потенциально (или реально) могут быть отнесены к рассыльщикам несанкционированной почты. При этом предпологается, то корректно настроенные серверы будут осуществлять повторную отправку через не слишком короткие, со временем увеличивающиеся интервалы, а спамеры будут пытаться осуществлять массированную отправку в кратчайшие сроки, стремясь накрыть как можно больший набор адресатов до момента блокировки и / или включения в общедоступные списки оценки саммеров, такие как DNSBL и на базе контрольных сумм.

Max Kostikov

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

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

Особенностям конфигурирования почтовых систем для беспроблемной работы с такого рода отправками и посвещена данная статья.

Max Kostikov

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

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

Рассмотрим механизм реализации такого двухуровневого квотирования используя возможности POP3 / IMAP4 сервера Dovecot 2.

Max Kostikov

Тема особенностей использования Domain-based Message Authentication, Reporting and Conformance или DMARC уже затрагивалась в рамках этого блога. Теперь хотелось бы остановиться на уже упомянутой в статье "DMARC для борьбы со спам на локальном и глобальном фронтах" особенностью обработки DMARC связанной с использованием возможности постепенного введения в действие политик типа quarantine и reject через использование их процентного модификатора.

К примеру, для отправителей из домена kostikov.co в соответствующей DMARC DNS-записи мы имеем следующее описание.

root@beta:~ # host -t txt _dmarc.kostikov.co
_dmarc.kostikov.co descriptive text "v=DMARC1; p=quarantine; pct=100; rua=mailto:dmarc-rua@kostikov.co"