Для того, что бы доставлять сообщения в почтовый ящик пользователя, в ZMailer существует . Но у него есть ряд ограничений:
- он умеет работать только с mailbox ящиками (не умеет maildir или dbox)
- он не имеет почтовых фильтров (и не умеет доставлять куда-либо, кроме INBOX)
- квота может быть только на файловой системе (только fs_quota)
- никак не учитывает того, кто дальше работает с этим ящиком (pop/imap)
Если же вы уже используете в качестве pop/imap сервера dovecot, то использование выглядит хорошей идеей.
Тогда вы получаете:
- индексирование ящика в момент доставки, что ускоряет доступ к нему через pop/imap
- использование разных тип квот, которые умеет dovecot (fs, dirsize, dict, maildir)
- язык фильтров sieve (переадресация, авто-ответ, доставка в любые папки)
- ящик может быть не только mailbox типа (mbox, maildir, dbox)
Для установки в ZMailer'е dovecot LDA в качестве доставщика сообщений в ящик пользователя надо:
У NFS клиента в 2.6.x ядре появилась неприятная особенность. Он никак не сигнализирует о невозможности записать данные по причине превышения файловой квоты. А наоборот всем своим поведением говорит о том, что всё хорошо. Все операции, включая fsync() и close() заканчиваются успешно. Более того, даже ls после этого показывает якобы всё записано(размер файла равен записанному, что превышает квоту). Но через несколько секунд размер файла «укорачивается» до того размера, что поместилось в квоту (что в общем-то и есть правда).
Вот небольшая тестовая программа test_nfswrite.c, которая пишет 1024 байтные блоки. Тестовый файл /mount/m7/tmp/test должен быть на NFS сервере (не важно с каким ядром). А клиент, который пишет с ядром 2.6.x.
Компилить надо так: gcc test_nfswrite.c -o test_nfswrite
Запускать так: ./test_nfswrite 500
где 500 — это количество блоков по 1024 байта. Если указать большое количество блоков, которое не влезает в квоту, то вы должны наблюдать ошибки. Читать полностью »
Как известно для прикручивания антивируса ClamAV к CGP есть два открытых helper’а: clamav-cgp и .
Есть еще один платный от , но его мы рассматривать не будем.
Как выяснилось, работают они не одинаково. При рассылке большого потока одинаковых сообщений, заметили, что письма уходят медленно — в среднем 1 в секунду. Анализ SMTP диалога отправки сообщений показал, что тормозит проверка антивирусом. При отключенном антивирусе трафик вырос до 30 писем в секунду.
Исследования показали, что сам антивирус не потребляет особо много ресурсов. Тогда возникла мысль про тормоза «прокладки» между CGP и ClamAV. В это время у нас работал cgpav, решили попробовать clamav-cgp. И о чудо, с новым helper`ом трафик вырос до 15 писем в секунду. Спасибо Andy Igoshin’у за замечательный продукт!
У себя я выложил слегка модифицированную «под себя» версию:
- Добавлено отрезание CGP-ных заголовков перед отправкой письма на проверку к ClamAV (рекомендации Николая Варинова из рассылки mx.ru: ).
- Немного изменена логика работа helper’а. В случае каких-то внутренних проблем он всегда пропускает сообщение. В логи пишется диагностика ошибки.
- Если ClamAV сообщает, что письмо инфицировано, то вместо молчаливого удаления сообщения, генерируется ответ с причиной: в сообщении <YYYYY> найден <XXXXX> вирус.
Комментарии к изменениям: Читать полностью »
Групповая NFS квота для Dovecot
— это IMAP и POP3 сервер для Linux/UNIX подобных систем. Он удобен и интересен тем, что имеет подключаемые плагины с различными расширениями функционала.
Одним из таких плагинов является . Он позволяет IMAP пользователям сообщать о текущем занятом ими месте в ящике, и отправлять предупреждения, при подходе свободного места к концу. К сожалению, но у него нет функционала, получать групповые квоты для ящиков, лежащих на NFS хранилище.
В списке рассылки dovecot , для реализации поддержки в quota-fs групповых квот на NFS для linux.
Автор: fandorin at rol.ru
fandorin at rol.ru Tue Feb 17 10:14:11 EET 2009 Unfortunately, the existing quota-fs does not know how to get GROUP quota with NFS storage. But there is a tool for Linux . This patch is made on the basis quota-tools. The patch was successful alpha-testing. Suggestions and comments are welcome.
UPD: Начиная с версии 1.2.* Dovecot поддерживает групповые fs квоты.
Greylisting для CGP
Как я уже писал чуть раньше в заметке: «Эффективность решений по борьбе с нежелательными сообщениями», различные технологии борьбы с нежелательными сообщениями имеют разный коэффициент эффективности. Кроме всем известных и часто используемых: DNSBL, SPF и прочего, я попробовал использовать DCC (Distributed Checksum Clearinghouse). Сама по себе технология не нова и не забыта. Яндекс.Cпамооборона работает по сходному принципу: сообщение превращается в шинглы (в контрольные суммы, по терминологии DCC), шинглы (суммы) отправляется на сервер хранения и сервер возвращает ответ. На основании этого ответа можно, либо принять сообщение, либо отвергнуть как массовую рассылку. Как показали тесты, технология «Серые списки» (англ. Greylisting) так же показала себя достаточно эффективно. По моим данным, поток спама упал в 2 раза (на 50%).
Для реализации технологии Greylisting и DCC для (CGP) можно применить «DCC interface for CommuniGate®Pro server» от
Под linux cобирается это достаточно просто:
- берём
- берём (он представляет собой несколько патчей для DCC)
- патчим DCC по инструкции от DCC-CGP
- собираем DCC и получаем сам DCC клиент и сервер, и DCC-CGP helper, который подключается в CGP так же как обычный helper
С этого момента в CGP доступны серые списки и контекстный антиспам фильтр на базе DCC. Как настроить сам DCC для работы с серыми списками и реализовывать антиспам защиту, я уже описывал ранее в заметке: DCC (Distributed Checksum Clearinghouse)
Фильтрация и принятие решения о приёме или об отказе принять почтовое сообщение может происходить синхронно и асинхронно. В синхронном режиме процесс проверки происходит во время SMTP-диалога с отправляющей стороной. Асинхронная работа заключается в том, что письмо принимается в любом случае, SMTP-диалог завершается успешно, а далее происходит принятие решения о доставке или отказе в доставке сообщения в ящик пользователя.
В каждом этом методе есть плюсы и минусы. Синхронный режим заставляет отправляющую сторону оставаться подключенной к нашему серверу в течении всего периода принятия решения, что тратит наши ресурсы (память, открытые сокеты). Асинхронный режим позволяет быстро завершить SMTP-диалог, освободить ресурсы, а уже потом заняться анализом сообщения.
Минусом асинхронного режима является ситуация, когда мы принимаем решение — отказать в доставке. В таком случае сообщение об ошибке доставки() уходит на адрес отправителя. Распространенный ход при отправке спама — это подделка адреса отправителя. В результате этого, мы отправляем ошибку о доставке на поддельный адрес, который ничего не знает про исходное сообщение. А при большом потоке таких писем на наш сервер, мы можем попросту «завалить» чей-то ящик своими ошибками о доставке.
В настоящее время серверные ресурсы достаточно не дороги, потому синхронный режим выглядит более успешным. Мы не принимаем тех сообщений, что нам не нравится. Спам остаётся у спамера. Мы не копим очереди с bounce message у себя на сервере и не заваливаем ими не виновные сервера и ящики. Все довольны!
В синхронном режиме можно выделить два этапа принятия решения: ранний этап (early rejection) и поздний (rejection). Разница между ними в том, что ранний этап происходит до начала передачи основного тела сообщения(DATA), а поздний этап происходит, когда всё письмо уже принято и отправляющая сторона ждёт от нас завершающего ответа. Отклонение сообщения на раннем этапе позволяет сэкономить трафик и ресурсы нашего сервера. Мы не приняли еще само сообщение, но у нас уже есть ip-адрес передающей стороны, email-адрес отправителя и email-адреса получателей. Если по этим данным уже можно принять решение об отказе в приёме сообщения — надо это делать на ранней стадии.
Давайте на примере суточной статистика одного почтового сервера рассмотрим эффективность разных типов борьбы с нежелательными сообщениями на разных стадиях.
DCC Honeypot — ловушка для спамеров
Honeypot (от англ. — «горшочек с медом»), в компьютерной терминологии — это приманка для злоумышленника. Задача Honeypot — подвергнуться атаке или несанкционированному исследованию, что позволит изучить стратегию злоумышленника и определить круг средств, с помощью которых могут быть нанесены удары по реальным объектам безопасности. Реализация Honeypot не принципиальна, это может быть как специальный выделенный сервер, так и один сетевой сервис, задача которого — привлечь внимание хакеров.
В применении к почте такие ловушки называют «email trap» или «spam trap». Задача таких ловушек — привлечь к себе спамера и начать получать спамерские рассылки в большом количестве. Анализируя приходящие в эти ловушки сообщения и их источники, можно адаптироваться к поведению спамеров и эффективно защищать реальные почтовые системы.
Давайте рассмотрим реальный пример построение honeypot (spamtrap) с использованием DCC (Distributed Checksum Clearinghouse).
