Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 65
Позновательно и красиво оформлено.
и прикручу к нему iRedMail и SOGo
Присоединяюсь: отлично оформлено, доступно изложено — для новичков то что надо.
Однако в боевых условиях становится ясно, что одними greylisting защита не ограничивается, придется разбираться в политиках и учиться составлять вручную цепочки правил.
Гвоздь поста (лично для меня) fail2ban. Мега-вещь, никогда о ней не слышал. Благодарствую за наводку.
Однако в боевых условиях становится ясно, что одними greylisting защита не ограничивается, придется разбираться в политиках и учиться составлять вручную цепочки правил.
Гвоздь поста (лично для меня) fail2ban. Мега-вещь, никогда о ней не слышал. Благодарствую за наводку.
Когда я начал превращать внутреннюю вики-документацию в статью, то ужаснулся от объёма только лишь опорного плана и листингов конфигурационных файлов. Поэтому пришлось пожертвовать деталями. Процесс настройки до боевых условий будет разниться в зависимости от нужд (корпоративный сервер, провайдерский, для личного использования или для публичного хостинга и т.п.). Охватить всё просто не представлялось возможным. Равно как не увидел необходимости пытаться систематизировать какие-то best practicies — они для всех разные будут.
Поэтому я поставил цель показать последовательность настройки основных систем почтового сервера с нуля в рамках единой статьи, ориентируясь на начинающих.
Fail2ban у меня крутится на многих серверах, защищая даже от любопытных глаз, которые ищут всякие phpmyadmin, пытаются залогиниться в OTRS систему и т.п. Ну не люблю я грязные error_log'и =). Кастомные правила для него пишутся очень легко и инструмент для тестирования весьма удобен (fail2ban-regex).
Поэтому я поставил цель показать последовательность настройки основных систем почтового сервера с нуля в рамках единой статьи, ориентируясь на начинающих.
Fail2ban у меня крутится на многих серверах, защищая даже от любопытных глаз, которые ищут всякие phpmyadmin, пытаются залогиниться в OTRS систему и т.п. Ну не люблю я грязные error_log'и =). Кастомные правила для него пишутся очень легко и инструмент для тестирования весьма удобен (fail2ban-regex).
У вас используется 1 сервер?
Класть /etc в гит это крутой :) есть же chef для этого
Класть /etc в гит это крутой :) есть же chef для этого
ну можно воспользоваться etckeeper.
Очень удобно отслеживать изменения.
Очень удобно отслеживать изменения.
можно ли использовать etckeeper для развертывания конфигурации?
Шеф в данном случае более адекватное решение.
Шеф в данном случае более адекватное решение.
Не находите, что тут разные задачи?
не нахожу.
Хранение конфигов отдельно от приложений с привязкой к версии — бесползеная вещь.
Делать автоматизацию — так нормально
Хранение конфигов отдельно от приложений с привязкой к версии — бесползеная вещь.
Делать автоматизацию — так нормально
Проблема в том, что если у вас 1-2 сервера, то автоматизация бессмысленна.
А вот посмотреть историю изменений, когда ты что то там поменял, имеет смысл.
А вот посмотреть историю изменений, когда ты что то там поменял, имеет смысл.
даже если у вас 1 сервер — автоматизация имеет смысл.
Другой вопрос — даст ли бизнес время на обучение админа и внедрение?
Опять повторю, если делать автоматизацию — то нормально, а не бесполезными способами
Другой вопрос — даст ли бизнес время на обучение админа и внедрение?
Опять повторю, если делать автоматизацию — то нормально, а не бесполезными способами
Да как вы не поймете. В данном случаи, это не автоматизация. И там где она не нужна, не надо ее делать.
etckeeper — просто позволяет вам «вспомнить» какие изменения и когда вы или не вы вносили в конфигурацию и в случае проблем откатится назад.
У меня дома стоит 1 сервер, зачем мне для него развертывание конфигураций?
На работе да, когда надо подготовить махом 100 машин — вообще без вопросов.
etckeeper — просто позволяет вам «вспомнить» какие изменения и когда вы или не вы вносили в конфигурацию и в случае проблем откатится назад.
У меня дома стоит 1 сервер, зачем мне для него развертывание конфигураций?
На работе да, когда надо подготовить махом 100 машин — вообще без вопросов.
Мне по старой привычке удобнее puppet, но кто использует SCM, тем этот туториал не нужен :)
А для обучалки хорошо подходит git+gitlab или redmine, позволяя отслеживать и наглядно отображать изменения конфигураций в привычном интерфейсе.
А для обучалки хорошо подходит git+gitlab или redmine, позволяя отслеживать и наглядно отображать изменения конфигураций в привычном интерфейсе.
А чем сделан последний график?
Удалено, автор внес ясность.
Я ждал этого вопроса :)
График сделан системой OpenNMS. Данные собираются по SNMP. На почтовом сервере в
А сами файлы всиняк силами.
График сделан системой OpenNMS. Данные собираются по SNMP. На почтовом сервере в
snmpd.conf указываются extend'ыextend mailbounced /bin/cat /var/tmp/mailbounced
extend maildeferred /bin/cat /var/tmp/maildeferred
extend mailexpired /bin/cat /var/tmp/mailexpired
...
А сами файлы в
/var/tmp/ пишутся через syslog-ng, который пишет их на основании логов. Статья по этой системе у меня пока лежит в виде опорных планов и кусков кода. Соберу камни и критику по этому туториалу, извлеку урок и возьмусь с новыми Мне интересен самый последний пункт — про syslog-ng. Не поделитесь конфигами?
Пожалуйста:
- Изначальный syslog-ng.conf без сбора статистики
- Syslog-ng.conf со сбором статистики + обрабатывающий эту радость perl-скрипт
Кстати, на картинки же написано OpenNMS :)
Статья хорошая. Вместо SpamAssassin можно использовать dspam.
Ну и ждем теперь кластереизации :)
Еще вопрос, почему maildir?
Ну и ждем теперь кластереизации :)
Еще вопрос, почему maildir?
Изначальная причина — миграция с существующего сервера courier. А в остальном пока не возникло необходимости в конвертации в *dbox. Наверное, Вы правы — с нуля имело бы смысл и в родном формате dovecot'а держать.
> Работа с SELinux достойна отдельного материала, поэтому в рамках данной статьи примем, что selinux по-ламерски сделан permissive или disabled.
stopdisablingselinux.com/
stopdisablingselinux.com/
Когда меня задолбали спамеры, я открыл для себя postscreen. И получил рейтинговый dnsbl, dnswl и отсев большинства спам-ботов до передачи непосредственно smtp, благодаря pregreet. В итоге кроме postfix у меня SPF, dkim, dspam и я счастлив. :)
Postfix postscreen howto
Postfix postscreen howto
мой кусок конфига про postscreen
# реакция postscreen на адрес, помещенный в черный список
postscreen_blacklist_action = enforce
# порог веса, выше которого соединения будут блокироваться
postscreen_dnsbl_threshold = 2
# список dnsbl-серверов с весами
postscreen_dnsbl_sites =
zen.spamhaus.org
bl.spamcop.net
cbl.abuseat.org
http.dnsbl.sorbs.net*3
socks.dnsbl.sorbs.net*3
misc.dnsbl.sorbs.net*3
smtp.dnsbl.sorbs.net*3
web.dnsbl.sorbs.net*3
dul.dnsbl.sorbs.net*3
rhsbl.sorbs.net*3
dul.ru*3
old.spam.dnsbl.sorbs.net
list.dnswl.org*-4
# реакция postscreen на адрес, получивший вес больше порога
postscreen_dnsbl_action = enforce
# сообщение о паузе перед началом SMTP-диалога
postscreen_greet_banner = Pregreet. Please wait…
# реакция postscreen на адреса, начавшие диалог до завершения паузы
postscreen_greet_action = drop
#чтобы работало в чруте
postscreen_cache_map = proxy:btree:/var/lib/postfix/postscreen_cache.db
postscreen_blacklist_action = drop
postscreen_access_list = permit_mynetworks,
cidr:/etc/postfix/postscreen_access.cidr
postscreen_blacklist_action = enforce
# порог веса, выше которого соединения будут блокироваться
postscreen_dnsbl_threshold = 2
# список dnsbl-серверов с весами
postscreen_dnsbl_sites =
zen.spamhaus.org
bl.spamcop.net
cbl.abuseat.org
http.dnsbl.sorbs.net*3
socks.dnsbl.sorbs.net*3
misc.dnsbl.sorbs.net*3
smtp.dnsbl.sorbs.net*3
web.dnsbl.sorbs.net*3
dul.dnsbl.sorbs.net*3
rhsbl.sorbs.net*3
dul.ru*3
old.spam.dnsbl.sorbs.net
list.dnswl.org*-4
# реакция postscreen на адрес, получивший вес больше порога
postscreen_dnsbl_action = enforce
# сообщение о паузе перед началом SMTP-диалога
postscreen_greet_banner = Pregreet. Please wait…
# реакция postscreen на адреса, начавшие диалог до завершения паузы
postscreen_greet_action = drop
#чтобы работало в чруте
postscreen_cache_map = proxy:btree:/var/lib/postfix/postscreen_cache.db
postscreen_blacklist_action = drop
postscreen_access_list = permit_mynetworks,
cidr:/etc/postfix/postscreen_access.cidr
Вдумчивое изучение мануалов и руководств показало довольно любопытный факт – нигде не было найдено однозначно достоверного руководства или подобия Best Practice по развёртыванию почтовика.
Правда что ль?
Много фактических и технических ошибок. Например, накой вам virtual доставка, если используется dovecot? Вообще утверждать, что virtual_mailbox_base и иже с ними нужен для «дружбы» Postfix и Dovecot мягко говоря некорректно. Это вообще никак не связанные вещи.
В результате — очередная (красивая и подробная) статья на тему как я не осилил изучение Postfix и Dovecot. Таких, с такими же ляпами и таким же отсутствием представления о том, как всё это устроено и за что отвечает каждая используемая опция — и вправду навалом. Может, не таких красивых, но всё же.
Если уж пишите статьи, не разобравшись до конца — то хоть вставляйте в них только то, в чём на 100% уверены.
В результате — очередная (красивая и подробная) статья на тему как я не осилил изучение Postfix и Dovecot. Таких, с такими же ляпами и таким же отсутствием представления о том, как всё это устроено и за что отвечает каждая используемая опция — и вправду навалом. Может, не таких красивых, но всё же.
Если уж пишите статьи, не разобравшись до конца — то хоть вставляйте в них только то, в чём на 100% уверены.
Внесите комиты или сделайте свой бранч со своими правками исходники то открыты.
Зачем? Смысл не в конфигах, а в правильном их описании. Вкорячивать на сервер конфиги, не понимая что и как они конфигурируют — это величайшее зло системного администрирования.
Кстати я смотрел историю правок там уже часть ошибок исправили. Commits
Ёж! Если следовать этой вашей инструкции — получится прекрасный спам-сервер. Блин, банальнейшие детские ошибки:
1. Какой, к лешему, permit_mynetworks для всей локалки?? параметр mynetworks при правильной настройке всегда должен быть пустым. SMTP без авторизации — это абсурд.
2. Туда же — mydestination и alias_maps тоже должны быть пустыми, хотя это и не создаёт проблем, но всё же.
дальше даже читать не хочется. Это не просто очередная обычная статья, это очередная вредная статья на тему как не надо делать. Не стоит настраивать какие-то сервисы взаимодействия с внешним миром не отдавая себе отчёта как они работают и не зная банальнейших вещей, связанных с архитектурой и типичными ошибками.
1. Какой, к лешему, permit_mynetworks для всей локалки?? параметр mynetworks при правильной настройке всегда должен быть пустым. SMTP без авторизации — это абсурд.
2. Туда же — mydestination и alias_maps тоже должны быть пустыми, хотя это и не создаёт проблем, но всё же.
дальше даже читать не хочется. Это не просто очередная обычная статья, это очередная вредная статья на тему как не надо делать. Не стоит настраивать какие-то сервисы взаимодействия с внешним миром не отдавая себе отчёта как они работают и не зная банальнейших вещей, связанных с архитектурой и типичными ошибками.
дак покажите как надо, в чем проблема? Всем будет очень полезно перенять Ваш опыт в настройке почтового серева или поправить уже существующий
Чтобы показать как надо — надо потратить день рабочего времени минимум на написание статьи. Увы, у меня давно уже нету свободных дней(
Я просто вижу стандартные простейшие ошибки и пытаюсь предупредить тех, кто вдруг решит настраивать сервер по этой статье. Как настраивать — дело каждого. Но в любом случае надо понимать каждую строчку конфига — зачем, почему и последствия.
Последствия необдуманного использования mynetworks — спам-рассылка изнутри сети, которая приведёт к попаданию вашего сервера в блок-листы. Я много таких серваков переделывал в своё время. Все такие специалисты — зачем париться, настраивать авторизацию, клиентов и т.д. и т.п., когда можно просто сделать permit_mynetworks?
Я просто вижу стандартные простейшие ошибки и пытаюсь предупредить тех, кто вдруг решит настраивать сервер по этой статье. Как настраивать — дело каждого. Но в любом случае надо понимать каждую строчку конфига — зачем, почему и последствия.
Последствия необдуманного использования mynetworks — спам-рассылка изнутри сети, которая приведёт к попаданию вашего сервера в блок-листы. Я много таких серваков переделывал в своё время. Все такие специалисты — зачем париться, настраивать авторизацию, клиентов и т.д. и т.п., когда можно просто сделать permit_mynetworks?
1. Увы, но SMTP без авторизации в моём случае — необходимость и mynetworks являются действительно trusted подсетками. Борьба с абьюзом и вообще спамом осуществляется на уровне ACL и QoS на коммутаторах, так что спам-сервера из такой конфигурации не получится, это всё же не open relay. В блэк-листах не сидели отродясь :) Но Вы правы, я внесу соответствующие правки, обозначив, что такой подход мм… опасен.
2. Если классы не пересекаются, то проблемы быть не должно, но да, можно исключить вообще. Пытаться перенести что-то из старой конфигурации было довольно дурной идеей…
По Вашему предыдущему комментарию:
2. Если классы не пересекаются, то проблемы быть не должно, но да, можно исключить вообще. Пытаться перенести что-то из старой конфигурации было довольно дурной идеей…
По Вашему предыдущему комментарию:
virtual_mailbox_base указан в секции «virtual» только чтобы логически разделить секции настроек по группам. Выглядит «немного» некорректно, там из «дружбы» только virtual_transport и есть. Подумаю над изменением формулировок. Спасибо за конструктивную критику.По поводу SMTP без авторизации: опять же, как показывает практика — необходимости в этом не бывает никогда) Шифрование поддерживают не все устройства, да. В этом случае в локалку выставляется SMTP на отдельном порту с авторизацией, но без шифрования. Но авторизацию поддерживают практически все. Те, которые не поддерживают, нужно либо выкинуть (оптимально), либо вынести на отдельный SMTP, в котором в mynetworks прописать конкретные IP адреса (нив коем случае не сети). Накрайняк — конкретные IP можно прописать на основном SMTP. У нас даже столетние RICOH прекрасно живут с авторизацией. Я даже представить себе не могу девайс с возможностью отправки по SMTP, но без авторизации)
А как вы на уровне ACL отсекаете совершенно валидный трафик от клиентов к вашему серверу и от сервера в интернет? Поясню: вот засел на каком-то компе в вашей сети бот. Принципиально он ничем не отличатся от SMTP клиента и отличить на коммутаторе вы его не сможете. Шлёт этот бот через ваш SMTP сервер спам наружу. Как вы его отловите? Я вот не умею такого кунг-фу. Разве что зарезать аномально большой трафик. Но это чревато, да и не тривиально. И вообще — из пушки по воробьям.
А как вы на уровне ACL отсекаете совершенно валидный трафик от клиентов к вашему серверу и от сервера в интернет? Поясню: вот засел на каком-то компе в вашей сети бот. Принципиально он ничем не отличатся от SMTP клиента и отличить на коммутаторе вы его не сможете. Шлёт этот бот через ваш SMTP сервер спам наружу. Как вы его отловите? Я вот не умею такого кунг-фу. Разве что зарезать аномально большой трафик. Но это чревато, да и не тривиально. И вообще — из пушки по воробьям.
Авторизацию не поддерживают некоторые пользователи :) Точнее они не поддерживают изменения привычного уклада вещей и оборвут телефоны техподдержке, когда их привычный ламповый мейл вдруг перестанет принимать почту, требуя аутентификацию. К сожалению, даже древняя аппаратура в этом плане посговорчивее будет. Впрочем, я взял на заметку этот совет, попробую провести методичную артподготовку — менять к лучшему, так на всех фронтах.
Не совсем — воробьёв очень уж много :). Поэтому в системе задействован snort, на который миррорится smtp трафик и который чутко его слушает. В случае превышения допустимого значения (найденного в своё время эмпирическим путём), по SNMP засылает команду на коммутатор или на модем (не к ночи будь помянут), выставляя на порту соответствующий CoS. Блокировка smtp трафика происходит на маршрутизаторах по соответствующему ip access-list.
На практике получается, что боты не умеют не жадничать и моментально попадают в блокировку. False positive срабатывания крайне редки и укладываются в статистическую погрешность :). Разумеется, есть политики исключений для определённых категорий клиентов, которым действительно нужен большой поток исходящей почты (например, охранка + sms) — они проверяются по-другому. В целом, abuse ящик очень чутко реагирует на любой срач в сети. Последняя жалоба на спам была забавной — спам шёл с нормально авторизующегося аккаунта — у пользователя test был гениальный пароль, его только идиот бы не подобрал. В остальном спам-боты не проходят, а вот жалобы на брутфорс из сети последнее время зачастили, ну не читать же HTTP запросы теперь…
Но это чревато, да и не тривиально. И вообще — из пушки по воробьям.
Не совсем — воробьёв очень уж много :). Поэтому в системе задействован snort, на который миррорится smtp трафик и который чутко его слушает. В случае превышения допустимого значения (найденного в своё время эмпирическим путём), по SNMP засылает команду на коммутатор или на модем (не к ночи будь помянут), выставляя на порту соответствующий CoS. Блокировка smtp трафика происходит на маршрутизаторах по соответствующему ip access-list.
На практике получается, что боты не умеют не жадничать и моментально попадают в блокировку. False positive срабатывания крайне редки и укладываются в статистическую погрешность :). Разумеется, есть политики исключений для определённых категорий клиентов, которым действительно нужен большой поток исходящей почты (например, охранка + sms) — они проверяются по-другому. В целом, abuse ящик очень чутко реагирует на любой срач в сети. Последняя жалоба на спам была забавной — спам шёл с нормально авторизующегося аккаунта — у пользователя test был гениальный пароль, его только идиот бы не подобрал. В остальном спам-боты не проходят, а вот жалобы на брутфорс из сети последнее время зачастили, ну не читать же HTTP запросы теперь…
А Вы как -нибудь защищаете учетки пользователей от подбора пароля по SMTP или только по POP3/IMAP?
*хлопнул себя по лбу* вот я краб. Теперь да, защищаю. Добавил третье правило в jail.conf для fail2ban. Думал руками написать, но родной filter.d/sasl.conf полностью подошёл.
Позор на самом деле, потому что в последний инцидент со спамом через почтовик была вовлечена авторизованная учётка (у пользователя test был гениальный пароль). Радость эта шла извне сети и поэтому не попадала под внутренний антиспам на SNORT'е. После такого забыть поставить проверку — просто непростительно. Спасибо за напоминание :)
Позор на самом деле, потому что в последний инцидент со спамом через почтовик была вовлечена авторизованная учётка (у пользователя test был гениальный пароль). Радость эта шла извне сети и поэтому не попадала под внутренний антиспам на SNORT'е. После такого забыть поставить проверку — просто непростительно. Спасибо за напоминание :)
CHARSET=latin1
Убиватьубиватьубивать.
Делал по этому гайду sealedabstract.com/code/nsa-proof-your-e-mail-in-2-hours/
Из плюшек — хранение почты на шифрованном разделе и dspam с автоматической тренировкой, а так-же Sieve.
Из плюшек — хранение почты на шифрованном разделе и dspam с автоматической тренировкой, а так-же Sieve.
Читаю сотни подобных howto, и вижу, что из SMTP-серверов чаще всего ставят Postfix, за них идет Exim. Из POP/IMAP — Dovecot. Подходы у всех одинаковы, что любопытно: хотя в любом сетапе есть sql-сервер, алиасы будут лежать в файле, очень часто используют amavis. Никто в таких howto не цепляет проверку на спам и на вирусы через штатные механизмы того же Exim. Почти все ставят dovecot как lmtp-доставщика, хотя smtp сервер, разумеется, может точно в то же место положить письмо… Про всякие антиспам-идеи в виде того же DKIM тоже тихо обычно, никто не ставит даже на новые сервера… Не могу понять — старое, конечно, забывать не след, но какие-то новые возможности почему не попробовать?
P.S. Странно, что smtpd особо не используется. Странно, что почтовые сервера на дубовой openbsd никто не пытается поднимать…
P.S. Странно, что smtpd особо не используется. Странно, что почтовые сервера на дубовой openbsd никто не пытается поднимать…
Напишите. Мне будет интересно. И про всякие TLS/SSL тоже, и вообще «чего нового есть в почте»
Причем тут «нового в почте»? ) Даже DKIM-у уже лет 8, не говоря про идею использование TLS для передачи почты. Все это прекрасно описано, но по кусочку (далеко ли ходить — habrahabr.ru/search/?q=dkim ), а уж настроить TLS по мануалу Exim ну очень просто, главное — не забыть :)
Вот тут ниже комментарий — «Postfix + Dovecot + MySQL + Amavis = моя любимая связка на протяжении уже многих лет» — она многое объясняет: люди каждый новый сервер обычно настраивают по традиции старого, и что-то кардинально новое вносить не рискуют/времени не имеют. Потому и пишут howto в стиле учебы в российских вузах: знаете, когда преподаватель приходит, и говорит — «ребята, сейчас наша область шагнула далеко вперед, но стенды у нас про технологии 60-х годов, поэтому мы те подходы и будем изучать». Смех смехом, а я такого препода видел, у него студенты новое в профессии открывали на подготовке к диплому, и за эту подготовку и изучали все, чем потом пользовались.
Мне так кажется, Вы лично и так неплохо настроите «чего нового есть в почте», а хорошая статья про настройку почтовика, считаю, должна содержать не только моменты дефолтной установки ОС и ПО из пакетов, но и выбора варианта хранения почты (для того же Dovecot это классический выбор между maildir vs dbox), тонкого тюнинга настроек (таймауты, распределение нагрузки), резервирования — все то, что отличает хорошую статью с объяснением сделанных выборов от простого перечисления шагов.
Как-то так.
Вот тут ниже комментарий — «Postfix + Dovecot + MySQL + Amavis = моя любимая связка на протяжении уже многих лет» — она многое объясняет: люди каждый новый сервер обычно настраивают по традиции старого, и что-то кардинально новое вносить не рискуют/времени не имеют. Потому и пишут howto в стиле учебы в российских вузах: знаете, когда преподаватель приходит, и говорит — «ребята, сейчас наша область шагнула далеко вперед, но стенды у нас про технологии 60-х годов, поэтому мы те подходы и будем изучать». Смех смехом, а я такого препода видел, у него студенты новое в профессии открывали на подготовке к диплому, и за эту подготовку и изучали все, чем потом пользовались.
Мне так кажется, Вы лично и так неплохо настроите «чего нового есть в почте», а хорошая статья про настройку почтовика, считаю, должна содержать не только моменты дефолтной установки ОС и ПО из пакетов, но и выбора варианта хранения почты (для того же Dovecot это классический выбор между maildir vs dbox), тонкого тюнинга настроек (таймауты, распределение нагрузки), резервирования — все то, что отличает хорошую статью с объяснением сделанных выборов от простого перечисления шагов.
Как-то так.
У постфикса mda в лице local(8) примитивный: нет квот, нет sieve. Вот и используют dovecot.
Ну, это-то понятно. Более того, понятно, почему в этой роли используют именно Dovecot при больших размерах системы, особенно если IMAP будет основным протоколом работы с ней: поскольку потом Dovecot-ом отдавать почту, то ему и карты в руки уже на этапе раскладки ее.
Но, если система мала по размеру, почему не Exim? Казалось бы, его средствами извернуться можно очень гибко, и получаем две независимые (почти) системы: одна (Exim в роли SMTP) почту принимает и кладет в хранилище, вторая (Dovecot в роли IMAP4/POP3) ее раздает. Что приятно: любая из них перестань работать, на вторую это мало повлияет. Они связаны будут только хранилищем, да общим источником авторизации, но это-то естественно, хотя авторизацию можно также разнести.
Холивар разводить нет желания. Понятно, что многие делают что-то оттого, что сами когда-то прочли конкретных howto, и на его основе выучили тот же postfix или exim — грубо говоря, «что умею, то и пою». Конечно, на Хабре это смотрится странно, здесь аудитория обычно старается разобраться, а не просто сделать так, как делали раньше.
Тем более, «старое» — не всегда значит «хорошее». Так, глупость одного из первых мануалов по настройки связки Exim + MySQL до сих пор всплывает почти в каждом их новых howto, т.е. старое недопланирование живет и здравствует. Этот пример не единичен, очень часто новое пишется на основе старого без включение мозга на предмет «а зачем так?», так что… Одно хорошо, раз оно работает, можно заняться чем-то другим, не менее важным :)
Но, если система мала по размеру, почему не Exim? Казалось бы, его средствами извернуться можно очень гибко, и получаем две независимые (почти) системы: одна (Exim в роли SMTP) почту принимает и кладет в хранилище, вторая (Dovecot в роли IMAP4/POP3) ее раздает. Что приятно: любая из них перестань работать, на вторую это мало повлияет. Они связаны будут только хранилищем, да общим источником авторизации, но это-то естественно, хотя авторизацию можно также разнести.
Холивар разводить нет желания. Понятно, что многие делают что-то оттого, что сами когда-то прочли конкретных howto, и на его основе выучили тот же postfix или exim — грубо говоря, «что умею, то и пою». Конечно, на Хабре это смотрится странно, здесь аудитория обычно старается разобраться, а не просто сделать так, как делали раньше.
Тем более, «старое» — не всегда значит «хорошее». Так, глупость одного из первых мануалов по настройки связки Exim + MySQL до сих пор всплывает почти в каждом их новых howto, т.е. старое недопланирование живет и здравствует. Этот пример не единичен, очень часто новое пишется на основе старого без включение мозга на предмет «а зачем так?», так что… Одно хорошо, раз оно работает, можно заняться чем-то другим, не менее важным :)
Спасибо за статью, всё доступно и разложено по полочкам.
Пара мелких косяков:
Надо в
И в
Надо в
/etc/dovecot/conf.d/10-auth.conf раскомментировать строку:!include auth-sql.conf.extИ в
/etc/dovecot/dovecot-sql.conf.ext стоит разрыв строки перед буквой «E», в слове «WHERE» должно быть вот так:driver = mysql
connect = host=localhost dbname=postfix user=postfix password=mypassword
default_pass_scheme = MD5-CRYPT
user_query = SELECT '/var/vmail/%d/%n' as home, 'maildir:/var/vmail/%d/%n'as mail, 1000 AS uid, 1000 AS gid, concat('*:bytes=', quota) AS quota_rule FROM mailbox WHERE username = '%u' AND active = '1'
password_query = SELECT username as user, password, '/var/vmail/%d/%n' as userdb_home, 'maildir:/var/vmail/%d/%n' as userdb_mail, 1000 as userdb_uid, 1000 as userdb_gid, concat('*:bytes=', quota) AS userdb_quota_rule FROM mailbox WHERE username = '%u' AND active = '1'
Некропостинг :)
В статье используется для выборки SELECT .../var/vmail/… на гитхабе в файле прописано .../data/vmail/…
Как правильно будет?
Создаём /etc/dovecot/dovecot-sql.conf.ext:
В статье используется для выборки SELECT .../var/vmail/… на гитхабе в файле прописано .../data/vmail/…
Как правильно будет?
Нужно указывать на ту директорию, где лежат данные. На гитхабе везде /data/vmail — это скелет живой конфигурации с реальными путями (так было проще пушить, простите). В статье используется /var/vmail. Проще говоря — указывайте туда, где будут лежать домены-письма, этот же путь указывается в dovecot-sql.conf.ext, 10-mail.conf и postfix/main.cf.
* /me закапывает некропост обратно *
* /me закапывает некропост обратно *
Ещё вопрос, не появилось уже статьи для «не начинающих»? Хотя бы TODO, кроме более углублённого ознакомления с документацией конечно.
Вот для новичков явно не хватает во всех статьях мне кажется одной из основных вещей — «как найти то, что сломалось, когда не работает». Ведь действительно, накидать конфигов и пакетов по примеру для начала совсем нетрудно, а вот потом начинается самое интересное :)
Хотя бы обзорно, методики проверки, и где чьи логи смотреть, если что не так.
Вот для новичков явно не хватает во всех статьях мне кажется одной из основных вещей — «как найти то, что сломалось, когда не работает». Ведь действительно, накидать конфигов и пакетов по примеру для начала совсем нетрудно, а вот потом начинается самое интересное :)
Хотя бы обзорно, методики проверки, и где чьи логи смотреть, если что не так.
Эта howto-статья появилась потому, что я не нашёл последовательного и детального изложения установки всего комплекса. На тот момент, конечно же. Статей была куча, но все создавались по методу «нарисуем сову», поэтому я решил сделать step-by-step.
Касательно же устранения неполадок — тут я в сомнениях, можно ли написать что-то не вырванное из контекста и более полезное, чем «читайте логи». После корректных установки и запуска сломаться может только если вносить изменения. Может «потеряться» письмо — это будет отражено в логах postfix/amavisd. Может забиться диск (помогут метрики в OpenNMS или Zabbix). Может не обновиться spamassassin или clamav, у них иногда падают зеркала, это будет тоже видно в логах. Может забиться mailq-очередь, может сервер попасть в dnsbl, если чей-то ящик взломали и спамят.
В общем, я немного в сомнениях. Всё как-то тривиально и не стоит статьи, на мой взгляд. Если накидаете каких-нибудь кейсов, интересных вопросов, попробую подумать над чем-то более-менее универсальным на досуге, что может вписаться в формат хабра.
Вот для новичков явно не хватает во всех статьях мне кажется одной из основных вещей — «как найти то, что сломалось, когда не работает».Более продвинутая статья очень сильно зависит от бизнес-правил, кейсов и условий. Вот у меня почтовый сервер для локальной сетки без авторизации, просто потому что за кучу лет несколько сотен человек так привыкли. Но это bad practice по-хорошему. Можно описать мониторинг очереди и пульса сервера, пример есть в статье в виде графика в разделе про fail2ban. Но я буду описывать мониторинг OpenNMS, а система не шибко популярна, поэтому полезность такой информации сомнительна.
Касательно же устранения неполадок — тут я в сомнениях, можно ли написать что-то не вырванное из контекста и более полезное, чем «читайте логи». После корректных установки и запуска сломаться может только если вносить изменения. Может «потеряться» письмо — это будет отражено в логах postfix/amavisd. Может забиться диск (помогут метрики в OpenNMS или Zabbix). Может не обновиться spamassassin или clamav, у них иногда падают зеркала, это будет тоже видно в логах. Может забиться mailq-очередь, может сервер попасть в dnsbl, если чей-то ящик взломали и спамят.
В общем, я немного в сомнениях. Всё как-то тривиально и не стоит статьи, на мой взгляд. Если накидаете каких-нибудь кейсов, интересных вопросов, попробую подумать над чем-то более-менее универсальным на досуге, что может вписаться в формат хабра.
del
Про fail2ban, на гите и в статье не прописано. Как выглядит /etc/fail2ban/filter.d/sasl.conf ??
Файл sasl.conf подхватится «из коробки», после yum install или apt-get. Но чтобы не вводить в смущение, я добавил его на Github.
Сам по себе демон fail2ban работает просто — он просматривает логи, которые указаны в jail.conf на предмет совпадений с заданными регулярными выражениями и при появлении совпадения производит определённое в правиле действие. Например:дать леща, забанить iptable'ами, выполнить внешний скрипт, отправить мыло и т.д. Ресурсы потребляет тем охотнее, чем бодрее пишутся логи, за этим нужно следить по внешним метрикам.
Сам по себе демон fail2ban работает просто — он просматривает логи, которые указаны в jail.conf на предмет совпадений с заданными регулярными выражениями и при появлении совпадения производит определённое в правиле действие. Например:
Спасибо.
Понимаю, что возможно нет времени, но может немного подкорректировать статью, придать ей актуальности? (Считаю, что это было бы доброй традицией на хабре.) В части Fail2ban хотя-бы. Например: новая версия с теми конфигами в статье/на гите не запускается, sasl.conf из коробки отсутствует, есть postfix-sasl.conf.
Ещё если настраивать по статье то первые тесты не проходят, т.к. Dovecot не запущен (к вопросу поиска, что сломалось). Надо добавить в статью команду включения и запуска:
chkconfig dovecot on && service dovecot start
Понимаю, что возможно нет времени, но может немного подкорректировать статью, придать ей актуальности? (Считаю, что это было бы доброй традицией на хабре.) В части Fail2ban хотя-бы. Например: новая версия с теми конфигами в статье/на гите не запускается, sasl.conf из коробки отсутствует, есть postfix-sasl.conf.
Ещё если настраивать по статье то первые тесты не проходят, т.к. Dovecot не запущен (к вопросу поиска, что сломалось). Надо добавить в статью команду включения и запуска:
chkconfig dovecot on && service dovecot start
Fail2ban немного поменял структуру конфигов, да. Но и статья в 2013-м была написана :)
Сейчас, по-хорошему, нужно уже делать гайд под CentOS 7 и прочие актуальные версии. В ближайшее время не могу обещать, на горизонте приветливо помахивают чем-то нехорошим пара дедлайнов, но раз тема востребована, я сохраню себе в планы актуализацию материала.
Сейчас, по-хорошему, нужно уже делать гайд под CentOS 7 и прочие актуальные версии. В ближайшее время не могу обещать, на горизонте приветливо помахивают чем-то нехорошим пара дедлайнов, но раз тема востребована, я сохраню себе в планы актуализацию материала.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Я построю свой почтовый сервер с Postfix и Dovecot