Комментарии 84
Ушел поднимать почтовый сервер.
В статье не хватает упоминания о настройке SPF, DKIM, DMARC, FBL без которых жизнь почтового сервера в современном мире почти невозможна — добавьте хотя бы ссылки. В раздел Итоги прекрасно бы вписался mail tester.
Поддерживаю! Сам сталкивался когда с настройкой, не раз убеждался, что сам сервер поднять до рабочего состояния не так и сложно, а вот учесть всё необходимое, чтобы получить 10 из 10 — сложновато.
Мало того, чтобы он взлетел, мало того чтоб тест выдал хороший результат. Непредвиденные (и невидимые) вещи часто бывают такими важными, именно потому, что они непредвиденные.
Случай из недавнего. Запустили грейлистинг на почтовике, давно уже. Все отлично работает. Тут один клиент говорит, что к нему письма очень долго идут, дает примеры. Смотрим логи — о, и правда! Оказывается, домен с которого шли письма имеет много серверов для исходящей почты, и шлют каждый раз разные, поэтому грейлистинг считает, что это новые сервера и заворачивает их. Мы этот фактор не учитывали, когда ставили грейлистинг.
У postgrey есть два решения на этот случай. Первое — белый список. Мы внесли тот домен в белый список и проблема решена. Но решена — через несколько лет, после того как мы запустили его! (Никто не жаловался, и нам все выглядело хорошо).
Второе решение — он считает сервер «одним и тем же» если совпадают 3 первых октета IPv4 адреса. Так что, такой проблемы не должно быть если все рассыльщики в одной Class C сети. Но… во-первых у крупных компаний они в разных сетях. И во вторых, мы по логами видели — что у нас вроде он сконфигурирован как должен, но тем не менее были две попытки из одной /24 подсети, и он вторую не принял почему-то (вопреки документации и ручным тестам).
Пока мы этого не видели — спали спокойно. Сейчас увидели — и приходится и ручками его тестить и в сорцы лезть и скрипты для анализа лога писать, чтобы эту чертовщину отловить.
Так что по гайду — можно сделать, но будет как китайский шуруповерт — вроде работает. А для долгой работы — нужно не только чтобы «вроде работал», а быть твердо уверенным что все возможные проблемы исключены, а для этого гайд не поможет, тут и тестить надо, и мониторить и даже в сорцы лазить иногда.
Случай из недавнего. Запустили грейлистинг на почтовике, давно уже. Все отлично работает. Тут один клиент говорит, что к нему письма очень долго идут, дает примеры. Смотрим логи — о, и правда! Оказывается, домен с которого шли письма имеет много серверов для исходящей почты, и шлют каждый раз разные, поэтому грейлистинг считает, что это новые сервера и заворачивает их. Мы этот фактор не учитывали, когда ставили грейлистинг.
У postgrey есть два решения на этот случай. Первое — белый список. Мы внесли тот домен в белый список и проблема решена. Но решена — через несколько лет, после того как мы запустили его! (Никто не жаловался, и нам все выглядело хорошо).
Второе решение — он считает сервер «одним и тем же» если совпадают 3 первых октета IPv4 адреса. Так что, такой проблемы не должно быть если все рассыльщики в одной Class C сети. Но… во-первых у крупных компаний они в разных сетях. И во вторых, мы по логами видели — что у нас вроде он сконфигурирован как должен, но тем не менее были две попытки из одной /24 подсети, и он вторую не принял почему-то (вопреки документации и ручным тестам).
Пока мы этого не видели — спали спокойно. Сейчас увидели — и приходится и ручками его тестить и в сорцы лезть и скрипты для анализа лога писать, чтобы эту чертовщину отловить.
Так что по гайду — можно сделать, но будет как китайский шуруповерт — вроде работает. А для долгой работы — нужно не только чтобы «вроде работал», а быть твердо уверенным что все возможные проблемы исключены, а для этого гайд не поможет, тут и тестить надо, и мониторить и даже в сорцы лазить иногда.
Да, это было бы отличным дополнением. Думаю, рассказ об этих вещает заслуживает отдельной статьи.
Я понимаю что это перевод и спасибо за него.
Однако у автора статьи я бы спросил как он относится к iRedMail и почему он не упомянул хотя бы кратко DKIM?
Однако у автора статьи я бы спросил как он относится к iRedMail и почему он не упомянул хотя бы кратко DKIM?
Помимо SPF и прочих бантиков, упомянутых выше, по-моему, идея использования самоподписанного сертификата на публичном почтовике — не самый правильный совет. Да и RBL за последние годы изрядно себя дискретитировали…
Я бы не рекомендовал бы никому данную статью в качестве инструкции по настройке почтового сервера (в том числе и по причине неполноты описания связки SELinuix+SpamAssassin+Postfix).
идея использования самоподписанного сертификата на публичном почтовике — не самый правильный совет.
На коннекторе, который отправляет почту в инет или принимает её оттуда, можно любой сертификат использовать, потому что он применяется исключительно в целях шифрования канала, а не для проверки подлинности клиента или сервера. Вот если тот же коннектор используется и для аутентифицированного трафика (подключение клиентов, например), там уже могут быть вопросы.
При наличии бесплатного и удобного Lets Encrypt — разве есть смысл в самоподписных?
Даже если мы не возлагаем серьезных задач по проверке подлинности на него, все равно этот милый бонус очень приятен, если забесплатно.
Даже если мы не возлагаем серьезных задач по проверке подлинности на него, все равно этот милый бонус очень приятен, если забесплатно.
Смысл есть как минимум в понимании того, какой сертификат для чего используется, и какими свойствами (исходя из своего предназначения) он должен обладать. Когда такое понимание есть, пусть человек уже сам решает, какой вариант выбрать. А когда выбор делается просто из соображений "ну так в гайде написано" или "в комментах на хабре написали, что некошерно" — это не есть хорошо.
Что же до конкретно Lets Encrypt — у меня к этому смешанное отношение. Идея менять сертификаты раз в пару месяцев при отсутствии стандартных средств автоматизации этого процесса мне не очень нравится.
Одно из лучших — проект с открытым исходным кодом SpamAssassin.
Очень старый проект, последняя версия которого вышла аж в 2015. Сейчас набирает популярность Rspamd, который активно развивается. Работает в разы быстрее и лучше SpamAssassin.
Хотя уже сам погуглил, действительно Rspamd выглядит интересно.
DSPAM работает только с телом сообщения, чего не всегда хватает. Хочется проверять еще заголовки, dkim/spf/dmark, спам базы, сколько писем уже пришло с этого ip(настройка рейтлимитов) и прочие параметры.
К Rspamd можно прикрутить антивирус для проверки вложений, что так же является плюсом. Но больше всего радует его скорость работы
Плюс он легко маштабируется и имеет вебку для просмотра статистики(раньше скриптовать приходилось).
Благодаря Rspamd удалось большую часть работы по обработки сообщений переложить на него. Exim+dovecot лишь принимают/кладут письма.
К Rspamd можно прикрутить антивирус для проверки вложений, что так же является плюсом. Но больше всего радует его скорость работы
Плюс он легко маштабируется и имеет вебку для просмотра статистики(раньше скриптовать приходилось).
Благодаря Rspamd удалось большую часть работы по обработки сообщений переложить на него. Exim+dovecot лишь принимают/кладут письма.
Для того, чтобы антиспам работал более-менее адекватно, требуется его постоянное обучение и администрирование, что для небольшого сервера может быть проблемой. Поэтому очень важно наличие общей глобальной базы спама, с которой антиспам бы сверялся либо в онлайне, либо выгружал обновления каждые 5-10 минут. Есть ли подобные свободные решения? Пока попадались только коммерческие.
Проект Rspamd бесплатно предоставляет базу хешей спама: https://rspamd.com/doc/modules/fuzzy_check.html, которая включена по умолчанию. Bayes статистика — это слишком, скажем так, личная вещь, которую очень сложно сделать универсальной для всех языков и всех пользователей.
Я бы еще отметил такие вещи, которые многим оказываются полезными, как dkim подпись и встроенная работа с исходящими сообщениями, а также ответами. Ну и различные современные средства машинного обучения и анализа потоков почты.
Хорошо бы ещё и прикручивание антивируса добавить, чтобы уже совсем более-менее полный комплект получился. Спасибо!
Коллеги, а кто как защищает postfix от флуда клиентов? Я пробовал использовать smtpd_client_connection_rate_limit = 600 но исходя из того, что я вижу, эта установка не сильно помогает.
две наиболее распространённых реализации SMTP: sendmail и postfix
Ога. Только почему-то доля Exim в сети превышает суммарную долю их обоих примерно раза в 2.
Итак, мы наладили процесс отправки и получения электронных писем по SMTP,О как. Так что же мы настроили по SMTP?
А я не понял, что такое параметр mynetworks, можете рассказать поподробнее? Что такое «пересылка»? То же, что и отправка, или что-то другое? Если я на сервере поднял SMTP и пытаюсь с его помощью отправить почту со своего локального компа через почтовый клиент, значит ли это, что мне надо добавлять свой IP в список доверенных в mynetworks?
Можно начать читать с
http://www.postfix.org/postconf.5.html
http://www.postfix.org/postconf.5.html
Первым же делом туда полез, только там тоже ничего не понял. Мануал лишь усилил ощущение, что здесь должны быть перечислены разрешённые адреса для любых коннектов извне, но если так, то это противоречит информации в посте о том, что публичный доступ к SMTP-серверу крайне опасен, его тут же захавают спамлисты и вообще. Как им тогда предполагается пользоваться — вносить в список все адреса, с которых я когда-либо могу захотеть отправить почту? И перед каждой поездкой в другой город или страну надо изучать, какие там провайдеры и какие у них диапазоны адресов, чтобы их тоже заранее разрешить?
Ну в общем по фразе
The list of «trusted» remote SMTP clients that have more privileges than «strangers».
In particular, «trusted» SMTP clients are allowed to relay mail through Postfix. See the smtpd_relay_restrictions parameter description in the postconf(5) manual.
итд
и примеру
mynetworks = 127.0.0.0/8 168.100.189.0/28
примерно становится очевидно.
Если коротко — то mynetworks = 127.0.0.0/8 это все, что там нужно.
Есть книга по postfix которую советую купить и почитать.
— За исключением тех случаев, когда вы по какойто странной причине
хотите разрешить некоторым пользователям Интернета использовать
ваш Postfixсервер в качестве ретранслятора (см. главу 16), вам следу
ет ограничить ретрансляцию интерфейсом локальной сети и интер
фейсом обратной связи (loopback) в файле main.cf. Покажем, как это
можно сделать для частной сети 192.168.0.0/24:
mynetworks = 192.168.0.0/24, 127.0.0.0/8
—
The list of «trusted» remote SMTP clients that have more privileges than «strangers».
In particular, «trusted» SMTP clients are allowed to relay mail through Postfix. See the smtpd_relay_restrictions parameter description in the postconf(5) manual.
итд
и примеру
mynetworks = 127.0.0.0/8 168.100.189.0/28
примерно становится очевидно.
Если коротко — то mynetworks = 127.0.0.0/8 это все, что там нужно.
Есть книга по postfix которую советую купить и почитать.
— За исключением тех случаев, когда вы по какойто странной причине
хотите разрешить некоторым пользователям Интернета использовать
ваш Postfixсервер в качестве ретранслятора (см. главу 16), вам следу
ет ограничить ретрансляцию интерфейсом локальной сети и интер
фейсом обратной связи (loopback) в файле main.cf. Покажем, как это
можно сделать для частной сети 192.168.0.0/24:
mynetworks = 192.168.0.0/24, 127.0.0.0/8
—
Ну, то есть, как я и спрашивал с самого начала: ретрансляция — это что-то особенное, и это не то, что происходит, когда мой почтовик подключается к SMTP-серверу для отправки почты, правильно?
P.S. Я пока не планировал настраивать свой почтовик, поэтому глубоко вдаваться в детали не было намерения. Но какое-то самое общее представление хочется получить.
P.S. Я пока не планировал настраивать свой почтовик, поэтому глубоко вдаваться в детали не было намерения. Но какое-то самое общее представление хочется получить.
Все зависит от задач.
Например у вас может быть внешний шлюз для почты, но почту он пересылает от другого почтового сервера, который например находится в DMZ зоне. Это может быть группа серверов итд итп.
Просто при непонимании процесса, можно легко сделать open relay :)
Например у вас может быть внешний шлюз для почты, но почту он пересылает от другого почтового сервера, который например находится в DMZ зоне. Это может быть группа серверов итд итп.
Просто при непонимании процесса, можно легко сделать open relay :)
Немного погуглил на эту тему — теперь у меня полная каша в голове. :-( Распишу, что я понял, и прошу поправить, если где ошибся.
Предположим, у меня задача отказаться от яндекса/гмыла и настроить свою собственную почтовую систему на своём VPS со своим доменом. Чтобы я мог в почтовике указать smtp.mydomain.com и отправлять любую почту, как делаю сейчас со своим гмыловским ящиком. Из гуглежа я понял, что ретрансляция — это приём и пересылка любых писем, направленных на домен, отличный от «родного» для текущего SMTP-сервера. То есть, в моём случае все письма, кроме тех, у которых адресат на mydomain.com, будут считаться ретрансляционными, и чтобы они были корректно доставлены, мне необходимо разрешить ретрансляцию в своём SMTP-сервере, причём в mynetworks прописать 0.0.0.0, потому что я не знаю заранее, на каком IP-адресе будет сидеть мой компьютер в тот момент, когда мне понадобится отправить почту. То есть, фактически, сделать open relay, чего категорически рекомендуется ни в коем случае не делать.
Вопросы:
1. Правильно ли я уяснил ситуацию? Если да, то как разрешить противоречие из последнего предложения?
2. Являются ли SMTP-серверы smtp.yandex.ru и smtp.gmail.com открытыми ретрансляторами? Или не открытыми? Я же могу через них отправлять почту на любой другой домен.
3. Бывают ли не-открытые ретрансляторы? Если я сделают открытый ретранслятор и добавлю какую-нибудь авторизацию (как на тех же гмылояндексах), будет ли это нормальной конфигурацией, не порицаемой общественно и не рискующей вляпаться в спамлисты?
Предположим, у меня задача отказаться от яндекса/гмыла и настроить свою собственную почтовую систему на своём VPS со своим доменом. Чтобы я мог в почтовике указать smtp.mydomain.com и отправлять любую почту, как делаю сейчас со своим гмыловским ящиком. Из гуглежа я понял, что ретрансляция — это приём и пересылка любых писем, направленных на домен, отличный от «родного» для текущего SMTP-сервера. То есть, в моём случае все письма, кроме тех, у которых адресат на mydomain.com, будут считаться ретрансляционными, и чтобы они были корректно доставлены, мне необходимо разрешить ретрансляцию в своём SMTP-сервере, причём в mynetworks прописать 0.0.0.0, потому что я не знаю заранее, на каком IP-адресе будет сидеть мой компьютер в тот момент, когда мне понадобится отправить почту. То есть, фактически, сделать open relay, чего категорически рекомендуется ни в коем случае не делать.
Вопросы:
1. Правильно ли я уяснил ситуацию? Если да, то как разрешить противоречие из последнего предложения?
2. Являются ли SMTP-серверы smtp.yandex.ru и smtp.gmail.com открытыми ретрансляторами? Или не открытыми? Я же могу через них отправлять почту на любой другой домен.
3. Бывают ли не-открытые ретрансляторы? Если я сделают открытый ретранслятор и добавлю какую-нибудь авторизацию (как на тех же гмылояндексах), будет ли это нормальной конфигурацией, не порицаемой общественно и не рискующей вляпаться в спамлисты?
У вас полная каша в голове. Советую просто сесть и расписать, что происходит с письмом от одного клиента к другому и какие цепи он проходит.
Вы в MX записи можете указать любой сервер, который готов вашу почту ПРИНЯТЬ!
Его имя может быть вообще вася_пупкин.рф.
Описание openrelay вполне нормально написано на вики
https://en.wikipedia.org/wiki/Open_mail_relay
P.S. Yandex может пересылать почту для вашего домена, после того, как вы пропишите MX сервера yandex/google и кто там еще дает почту для доменов.
Вы в MX записи можете указать любой сервер, который готов вашу почту ПРИНЯТЬ!
Его имя может быть вообще вася_пупкин.рф.
Описание openrelay вполне нормально написано на вики
https://en.wikipedia.org/wiki/Open_mail_relay
P.S. Yandex может пересылать почту для вашего домена, после того, как вы пропишите MX сервера yandex/google и кто там еще дает почту для доменов.
У вас полная каша в голове. Советую просто сесть и расписать, что происходит с письмом от одного клиента к другому и какие цепи он проходит.Так я же и написал, что при самостоятельных попытках разобраться я получил кашу. Как я сяду и распишу, если ни шиша не понимаю, что вообще происходит, и не уверен даже, что самая базовая базовая терминология обозначает то, что я думаю она обозначает.
Описание openrelay вполне нормально написано на викиИ это, и все прочие описания, которые мне попадались, слишком абстрактные. Я пока не нашёл ни одного внятного объяснения, что к чему подключается, что как называется и что как для этого должно быть настроено. Либо самые общие сведения «для домохозяек», либо, наоборот, зубодробительные подробности с кучей невнятных и необъясняемых терминов, без единого примера.
https://en.wikipedia.org/wiki/Open_mail_relay
P.S. Yandex может пересылать почту для вашего домена, после того, как вы пропишите MX сервера yandex/google и кто там еще дает почту для доменов.Именно так у меня сейчас и сделано. Меня как раз интересует, что надо делать, если я захочу полностью отказаться от Яндекса и поднять свою инфраструктуру.
>либо, наоборот, зубодробительные подробности с кучей невнятных и необъясняемых терминов, без единого примера.
Делайте свою лабу и начинайте смотреть в ней как все работает.
Термины всегда можно спросить или посмотреть их значение.
>Меня как раз интересует, что надо делать, если я захочу полностью отказаться от Яндекса и поднять свою инфраструктуру.
Не воспринимайте как издевательство но:
Чтение документации и попытка разобраться во всей этой чехарде.
Можете начинать изучать курсы LPI-1 и LPI-2. Во втором как раз про почту вроде.
Да и книгу про postfix заодно и про dns/bind.
P.S. Удивительно, но сейчас при доступном интернете, литературу, видео — курсов и вообще учебном материале — люди умудряются не изучать? Остается только задать вопрос самому себе, как же мы все это настраивали лет так 20 назад?
Делайте свою лабу и начинайте смотреть в ней как все работает.
Термины всегда можно спросить или посмотреть их значение.
>Меня как раз интересует, что надо делать, если я захочу полностью отказаться от Яндекса и поднять свою инфраструктуру.
Не воспринимайте как издевательство но:
Чтение документации и попытка разобраться во всей этой чехарде.
Можете начинать изучать курсы LPI-1 и LPI-2. Во втором как раз про почту вроде.
Да и книгу про postfix заодно и про dns/bind.
P.S. Удивительно, но сейчас при доступном интернете, литературу, видео — курсов и вообще учебном материале — люди умудряются не изучать? Остается только задать вопрос самому себе, как же мы все это настраивали лет так 20 назад?
Интересно, когда у вас спрашивают, сколько сейчас времени, вы отправляете в мануалы по компасу, секстанту и географии, чтобы спрашивающий сам определил время по положению солнца? Я же говорил, что у меня нет задачи поднимать свой сервер и досконально во всём разбираться. Просто возникла конкретная мелкая непонятка по конкретной статье. Фиг с ней, раз такое дело, перебьюсь как-нибудь.
Посмотрите в документацию, там всё нормально описано: http://www.postfix.org/BASIC_CONFIGURATION_README.html#relay_from:
By default, Postfix will forward mail from clients in authorized network blocks to any destination. Authorized networks are defined with the mynetworks configuration parameter. The current default is to authorize the local machine only. Prior to Postfix 3.0, the default was to authorize all clients in the IP subnetworks that the local machine is attached to.
… snip…
By default, Postfix will forward mail from strangers (clients outside authorized networks) to authorized remote destinations only. Authorized remote destinations are defined with the relay_domains configuration parameter. The default is to authorize all domains (and subdomains) of the domains listed with the mydestination parameter.
Почта от клиентов из авторизованной сети отправляется на любой адрес, от "чужаков" — только на relay_domains. Если хочется иного, то смотрим далее в http://www.postfix.org/SASL_README.html:
SMTP servers need to decide whether an SMTP client is authorized to send mail to remote destinations, or only to destinations that the server itself is responsible for. Usually, SMTP servers accept mail to remote destinations when the client's IP address is in the "same network" as the server's IP address.
SMTP clients outside the SMTP server's network need a different way to get "same network" privileges. To address this need, Postfix supports SASL authentication (RFC 4954, formerly RFC 2554). With this a remote SMTP client can authenticate to the Postfix SMTP server, and the Postfix SMTP client can authenticate to a remote SMTP server. Once a client is authenticated, a server can give it "same network" privileges.
Что обычно в том или ином варианте происходит на smtp серверах различных провайдеров. Пользователь должен авторизоваться, чтобы отправить почту наружу с данного сервера. Плюс делается ограничение на то, чтобы пользователь мог отправить почту только от своего имени, но не от имени соседнего Васи Пупкина.
Вам это взрывает мозг? Мне, честно, не очень понятно, что тут сложного? Если язык — то эти readme/howto уже десяток-другой раз переводили. От версии к версии там отличия минорные.
Postfix supports SASL authentication (RFC 4954, formerly RFC 2554). With this a remote SMTP client can authenticate to the Postfix SMTP server, and the Postfix SMTP client can authenticate to a remote SMTP server. Once a client is authenticated, a server can give it «same network» privileges.ВОТ ОНО! Мне это не могло взрывать мозг просто по той причине, что вплоть до этого момента у меня не было этого кусочка информации, и я безуспешно пытался его получить (не зная, что мне нужен именно он). Непонятно, почему в моих поисках оно мне ни разу не попалось (наоборот, были статьи, где утверждалось, что SMTP принципиально не поддерживает аутентификацию — видимо, устаревшая инфа), но наличие аутентификации, которая перекидывает клиента в список доверенных, всё переворачивает с головы на ноги.
Спасибо за объяснение.
Непонятно, почему в моих поисках оно мне ни разу не попалось (наоборот, были статьи, где утверждалось, что SMTP принципиально не поддерживает аутентификацию — видимо, устаревшая инфа), но наличие аутентификации, которая перекидывает клиента в список доверенных, всё переворачивает с головы на ноги.
Не знаю, где вы искали информацию, касающуюся SMTP. У меня складывается впечатление, что в статьях, подобных этой.
Т. к. если бы вы заглянули в RFC4954 или просто загуглили smtp auth, то наткнулись бы на ту же википедию в первых трёх ссылках.
Искал в гугле и да, ориентировался именно на статьи типа этой, чтобы были достаточно дружественными к человеку, который ни разу в жизни не поднимал почтовик (да и не собирается пока этого делать). RFC в эту категорию, увы, не попадают. Мне их тяжело читать, даже когда они по тематике, с которой я знаком довольно твёрдо, что уж говорить о предмете, в котором я даже базовую терминологию не был уверен, что правильно понимаю.
А чтобы загуглить smtp auth, надо было сначала магическим образом узнать, что мне надо гуглить именно smtp auth.
А чтобы загуглить smtp auth, надо было сначала магическим образом узнать, что мне надо гуглить именно smtp auth.
>что мне надо гуглить именно smtp auth.
те мысль об аутентификация почты в голову не приходила?
те мысль об аутентификация почты в голову не приходила?
О её существовании мысль, разумеется, приходила. Не приходила мысль, что эта аутентификация может перекрывать собой жёстко заданный в настройках постфикса список IP-адресов, считающихся разрешёнными. Обычно бывает в точности наоборот: сначала решаем, принимать ли вообще соединение с этого IP, а уж потом, если всё-таки приняли, запускать процедуру аутентификации.
> Просто возникла конкретная мелкая непонятка по конкретной статье. Фиг с ней, раз такое дело, перебьюсь как-нибудь.
Это вам она кажется мелкой и незначительной, я же вижу, что у вас вообще все хромает. Я вам дал четкие ответы, на вполне конкретные вопросы.
Увы но это не время спросить. Время спросить, это например спросить какой пакет для спама поставить, а не рассказывать вам о типов часов, какие бывают механизмы и как они устроенны.
Это вам она кажется мелкой и незначительной, я же вижу, что у вас вообще все хромает. Я вам дал четкие ответы, на вполне конкретные вопросы.
Увы но это не время спросить. Время спросить, это например спросить какой пакет для спама поставить, а не рассказывать вам о типов часов, какие бывают механизмы и как они устроенны.
Нельзя просто так взять и в двух словах объяснить Вам эту «конкретную мелкую непонятку», когда у Вас нет представления о том, что происходит с письмом после нажатия на клиенте кнопки «отправить». С другой стороны, если бы такое представление было, никаких непоняток бы не возникло. Советую прочитать «Postfix. Подробное руководство», даже если нет задачи поднимать почтовый сервер, книга сама по себе интересна, поскольку написана не в стиле технического мануала.
и да — еще раз
The list of «trusted» remote SMTP clients that have more privileges than «strangers»
и 0.0.0.0 там точно не должно быть :)
The list of «trusted» remote SMTP clients that have more privileges than «strangers»
и 0.0.0.0 там точно не должно быть :)
НЛО прилетело и опубликовало эту надпись здесь
Уже очень давно поднимаю почтовые сервера в docker, на самом деле все очень просто. За нас уже все сделали.
https://github.com/tomav/docker-mailserver
https://github.com/tomav/docker-mailserver
Почтовый сервер, как и любая другая мало-мальски сложная система, настраивается под задачу. Глобально вариантов конфигурации, может, и немного, но для осознанного выбора и подкручивания настроек надо быть способным понять и настроить руками.
В контейнер можно загонять уже после, для удобства распространения этого окружения. Бездумный деплой контейнера — полная глупость.
>Бездумный деплой контейнера — полная глупость.
Это вообще общая тенденция.
Это вообще общая тенденция.
К сожалению, да. Хотя использование тех же публично доступных образов крайне удобно для экспериментов и dev-окружения. Порой сильно экономит время и нервы.
Это очевидно, никто не говорил про бездумный деплой. Вам же не запрещают довести конфигурацию до ума, правда? А если так судить то любой bootstrap — зло.
Вопрос про доверяя к данному контейнеру.
Я в жизни не буду использовать чужие контейнеры. Сам и только сам.
Минимум можно посмотреть на примерную его конфигурацию.
Я в жизни не буду использовать чужие контейнеры. Сам и только сам.
Минимум можно посмотреть на примерную его конфигурацию.
А базовые (debian/ubuntu/centos/fedore/alpine)?
К контейнерам из пользовательского неймспейса доверие исходно низкое. Исключением здесь вполне может быть контейнер от знакомого доверенного вендора. Как пример, от PMC какого-нибудь Apache'вского проекта. Или от RedHat.
Как показывает моя практика, контейнеры от официальных вендоров тоже далеко не всегда оптимально настроены.
alpine — неплохо минимизирован. Считаю годнотой, но когда есть понимание зачем оно надо.
Это вообще одно из главных условий. Другой момент, что у меня так и не сложилась любовь с докером. Обхожусь kvm и lxc. lxc пришел на замену openvz.
Вендер, вендору рознь и надо смотреть. Недавно, что-то смотрел и волосы шевелились во всех местах.
Это вообще одно из главных условий. Другой момент, что у меня так и не сложилась любовь с докером. Обхожусь kvm и lxc. lxc пришел на замену openvz.
Вендер, вендору рознь и надо смотреть. Недавно, что-то смотрел и волосы шевелились во всех местах.
Обхожусь kvm и lxc. lxc пришел на замену openvz.
Кстати при актуальной версии systemd ещё systemd-nspawn может быть неплохой заменой lxc. Пробовал для сборки сишных/плюсовых библиотек под centos (хост — archlinux).
Ну и для простых случаев типа ограничения по cgroups и namespaces можно делать в самих юнитах. Но, правда, это только на актуальной инфраструктуре.
mailcow под докер разворачивается за минуты через docker-compose. На выходе получаем: postfix, dovecot, rspamd, sogo, веб-панель Администрирования, и другие плюшки.
Еще бы добавить в статью пару слов об интеграции MTA и MDA с базой данных и о postfixadmin.
Да, я в курсе что все это в изобилии есть в интерете, но раз уж тут такая обзорная статья…
Да, я в курсе что все это в изобилии есть в интерете, но раз уж тут такая обзорная статья…
Откройте конфигурационный файл Postfix /etc/postfix/main.cf, измените параметр smtpd_recipient_restrictions и настройте другие параметры следующим образом:
и никаких комментариев или объяснений почему именно эти параметры и почему в таком порядке, а ведь порядок имеет значение.
Вспоминается картинка с совой
Возможности самого postfix в плане гибкости очень скудные, поэтому я бы рекомендовал посмотреть в сторону того же postfwd
echo "This is message body" | mailx -s "This is Subject" -r "likegeeks<likegeeks@example.com>" -a /path/to/attachment someone@example.com
уже давно придумали swaks для удобного тестирования smtp
Могу написать пост об моем опыте связки postfix + dovecot + rspamd + clamav с использованием dkim, dmarc и некоторых своих разработках для этого чуда. Ну еще о том, как это дело кластеризовать в несколько датацентров и пережить падения половину машин.
Если, конечно, будет кому-либо это интересно.
Если, конечно, будет кому-либо это интересно.
Заранее буду благодарен автору, если он подредактирует материал под пожелания комментариев выше. Тоже хотелось увидеть актуальные на данный момент, настройки и фичи. Хотя и могу понять автора, если у него мало времени будет.
НЛО прилетело и опубликовало эту надпись здесь
$ firewall-cmd --permanent --add-port=110/tcp --add-port=995
$ firewall-cmd --permanent --add-port=143/tcp --add-port=993
$ firewall-cmd --reload
Зачем так странно, если можно использовать --add-service=pop3 и аналогично pop3s, imap, imaps, smtp/smtps?
В этой статье написаны дурные советы.
Особенно поможет сохранить сервер в чистоте от писем клиентов и прочих контрагентов. Погуглите на предмет блокировки серверов gmail майкрософтовским RBL. В меньших масштабах подобное происходит ежедневно.
Спамер арендует shared хостинг за доллар, рассылает миллионы писем в час, хостер блокирует спамовый аккаунт, но релеи хостера, а то и вся подсеть попадают в RBL и почта клиентов хостера оказывается в ловушке на несколько дней. Спамер же после блокировки аккаунта повторяет трюк на другом хостинге.
В 2017 году RBL не защищает от спама, но регулярно нарушает связность электронной почты.
Именно чтобы избежать такого костыля, умные люди придумали и поддерживают сервис Let's Encrypt. Самый простой в установке и настройке вариант — скрипт dehydrated.
Про отсутствие в статье DKIM, SPF и антивируса (к примеру, clamav присутствует во всех GNU/Linux. которые я видел) тут уже много раз прокомментировали.
В статье не описаны преимущества IMAP: хранение писем на сервере, где есть (должно быть!) резервное копирование и возможен доступ из браузера (roundcube, squirrelmail, ...).
Не упомянуты Exim и Qmail. Последний ещё ладно, он не в тройке лидеров, но Exim устанавливается по умолчанию в популярных дистрибутивах GNU/Linux.
Насчёт dovecot. В конфигурации по умолчанию (mbox!) нормально работает только с маленькими объёмами почтовых ящиков. Это означает, что пользователи либо забирают почту по POP3, либо следят за количеством почты в IMAP. Когда возникнут проблемы, изменить конфигурацию будет проблематично.
Вы никогда не встречались с почтовыми ящиками размеров в 15-20 Гб? Сравните время удаления письма из начала-середины файла и удаление файла из каталога в случае maildir.
Кроме того, в dovecot через жопу делаются виртуальные домены и виртуальные пользователи, касательно imap нет публичных (shared) папок и сильно ограничена вложенность папок.
Из-за этих его недостатков я выбрал Cyrus-IMAP. Он чуть сложнее управляется, зато даёт широчайшие возможности, в том числе элементарно даётся доступ одного сотрудника к почте другого в том же домене. Например, сотрудник, подменяющий заболевшего коллегу, видит его почту и отвечает на письма от своего имени.
Касательно postfix.
К сожалению, сделать фильтрацию почты в postfix в процессе обработки входящего соединения крайне затруднительно. В sendmail для этого используется milter, но в postfix milter не так развит, создаёт большую нагрузку на сервер, поэтому традиционно используется фильтрация через pipe. Эффективность фильтров в результате низкая, нагрузка на сервер высокая. Простого решения проблемы до сих пор не существует, приходится использовать сервис-прокладку: фильтрующий релэй.
К счастью, сообщения, прежде чем они достигнут почтового сервера на Postfix, можно фильтровать, используя Realtime Blackhole Lists (RBLs). Это снизит нагрузку на почтовый сервер и поможет сохранить его в чистоте.
Особенно поможет сохранить сервер в чистоте от писем клиентов и прочих контрагентов. Погуглите на предмет блокировки серверов gmail майкрософтовским RBL. В меньших масштабах подобное происходит ежедневно.
Спамер арендует shared хостинг за доллар, рассылает миллионы писем в час, хостер блокирует спамовый аккаунт, но релеи хостера, а то и вся подсеть попадают в RBL и почта клиентов хостера оказывается в ловушке на несколько дней. Спамер же после блокировки аккаунта повторяет трюк на другом хостинге.
В 2017 году RBL не защищает от спама, но регулярно нарушает связность электронной почты.
Для начала нужно сгенерировать сертификат и ключ с использованием команды openssl
Именно чтобы избежать такого костыля, умные люди придумали и поддерживают сервис Let's Encrypt. Самый простой в установке и настройке вариант — скрипт dehydrated.
Про отсутствие в статье DKIM, SPF и антивируса (к примеру, clamav присутствует во всех GNU/Linux. которые я видел) тут уже много раз прокомментировали.
В статье не описаны преимущества IMAP: хранение писем на сервере, где есть (должно быть!) резервное копирование и возможен доступ из браузера (roundcube, squirrelmail, ...).
Не упомянуты Exim и Qmail. Последний ещё ладно, он не в тройке лидеров, но Exim устанавливается по умолчанию в популярных дистрибутивах GNU/Linux.
Насчёт dovecot. В конфигурации по умолчанию (mbox!) нормально работает только с маленькими объёмами почтовых ящиков. Это означает, что пользователи либо забирают почту по POP3, либо следят за количеством почты в IMAP. Когда возникнут проблемы, изменить конфигурацию будет проблематично.
Вы никогда не встречались с почтовыми ящиками размеров в 15-20 Гб? Сравните время удаления письма из начала-середины файла и удаление файла из каталога в случае maildir.
Кроме того, в dovecot через жопу делаются виртуальные домены и виртуальные пользователи, касательно imap нет публичных (shared) папок и сильно ограничена вложенность папок.
Из-за этих его недостатков я выбрал Cyrus-IMAP. Он чуть сложнее управляется, зато даёт широчайшие возможности, в том числе элементарно даётся доступ одного сотрудника к почте другого в том же домене. Например, сотрудник, подменяющий заболевшего коллегу, видит его почту и отвечает на письма от своего имени.
Касательно postfix.
К сожалению, сделать фильтрацию почты в postfix в процессе обработки входящего соединения крайне затруднительно. В sendmail для этого используется milter, но в postfix milter не так развит, создаёт большую нагрузку на сервер, поэтому традиционно используется фильтрация через pipe. Эффективность фильтров в результате низкая, нагрузка на сервер высокая. Простого решения проблемы до сих пор не существует, приходится использовать сервис-прокладку: фильтрующий релэй.
В 2017 году RBL не защищает от спама
Практика говорит об обратном. Вот смотрю на статистику на одном из серверов — почти 90% писем через RBL отсеиваются. Ложноположительных случаев за несколько лет не припомню, хотя понимаю, что для какой-то другой организации статистика может быть иной. Случаи, когда контрагент попадает в RBL за дело, а почту от него принимать всё равно надо, были, но все они в рабочем порядке решаются, благо белые списки никто не отменял.
Плюсы и минусы RBL могут весить по-разному в каждом конкретном случае, выбор пусть каждый делает сам, но вот насчет "не защищает" — не надо.
В моей практике более 90% спама отсеивается на уровне установления соединения в проверках «качества» клиента SMTP. В итоге до проверки RBL дело просто не доходит: в моих конфигурациях проверку по RBL проводит spamassassin.
Я писал о таких случаях. Прочитайте комментарии, описанная ситуация имела повторения. В комментариях есть пример грамотного использования RBL, если другие проверки настроить лень:
Ложноположительных случаев за несколько лет не припомню
Я писал о таких случаях. Прочитайте комментарии, описанная ситуация имела повторения. В комментариях есть пример грамотного использования RBL, если другие проверки настроить лень:
Мой greysmtpd использует эти RBL-списки, но не для блокирования почты, а только для активирования грейлистинга. Таким образом и спама отсекается львиная доля (80-90%), и в то же время доставка нормальных писем гарантировано работает ...
>Из-за этих его недостатков я выбрал Cyrus-IMAP. Он чуть сложнее управляется, зато даёт широчайшие возможности, в том числе элементарно даётся доступ одного сотрудника к почте другого в том же домене. Например, сотрудник, подменяющий заболевшего коллегу, видит его почту и отвечает на письма от своего имени.
Мне кажется, такого человек просто не должен хотеть делать.
Минимум, некие публичные папки или пересылка новой почты.
Ну а Cyrus надо будет попробовать 3 версию что там и как. Да и кстати mbox — это один из форматов, который dovecot умеет использовать.
Мне кажется, такого человек просто не должен хотеть делать.
Минимум, некие публичные папки или пересылка новой почты.
Ну а Cyrus надо будет попробовать 3 версию что там и как. Да и кстати mbox — это один из форматов, который dovecot умеет использовать.
Мне кажется, такого человек просто не должен хотеть делать.
Минимум, некие публичные папки или пересылка новой почты.
То, что вам кажется и производственная необходимость противоречат друг другу.
Сложившаяся практика такова: руководитель организации или подразделения принимает решение, что имярек замещает отсутствующего и, чтобы сотруднику не нужно было выяснять у клиента всю историю вопроса, ему нужно просматривать всю историю переписки. Заметьте, речь о служебной переписке, тайна которой регулируется в понятиях коммерческой тайны.
Там, где на сервере почты работает Dovecot, пользователю приходится настраивать ещё одну учётную запись почты, а при использовании POP3 сотрудник бегает между компьютерами. Если же на сервере Cyrus, достаточно выполнить две команды.
Да все это мне знакомо прекрасно.
Сейчас уже деталей не скажу, но подключали в режим RO ящик человеку.
Dovecot все же имеет прекрасный ACL
Сейчас уже деталей не скажу, но подключали в режим RO ящик человеку.
Dovecot все же имеет прекрасный ACL
Там, где на сервере почты работает Dovecot, пользователю приходится настраивать ещё одну учётную запись почты, а при использовании POP3 сотрудник бегает между компьютерами. Если же на сервере Cyrus, достаточно выполнить две команды
Простите, но я устал читать вашу некомпетентную отповедь Dovecot, которая со всей очевидностью показывает ваше поверхностное знакомство с темой.
Во-первых, в Dovecot есть и public namespaces и shared mailboxes. И уже очень давно.
Работа с общими почтовыми ящиками для группы реализуется через оба варианта. Shared mailboxes тоже, мягко говоря, не проблема. После настройки передача доступа реализуется в однострочную команду из консоли либо самим пользователем.
НЛО прилетело и опубликовало эту надпись здесь
а чем плох iRedMail? все тоже самое но в два клика
кто подскажет — если уже используется mailbox_command=/usr/libexec/dovecot/deliver, то как добавить:
P.S. postfix check выдает
mailbox_command = /usr/bin/procmail
P.S. postfix check выдает
postfix/postlog: warning: /etc/postfix/main.cf, line 741: overriding earlier entry: mailbox_command=/usr/libexec/dovecot/deliver
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почтовый сервер на Linux