wau |
|
Темы:
168
Сообщения:
1245
Участник с: 11 октября 2013
|
см. также апдейты - 2024-09 https://archlinux.org.ru/forum/post/262410/ 2024-09 https://archlinux.org.ru/forum/topic/22163/ Гугл переносит сервера в РФ. Да и квота его как-то исчерпалась. В общем, решено вновь, как сколько-то лет назад, почти уже 10, поднять свой почтовый сервер. Поскольку он будет обслуживать только закрытую группу пользователей, то всех пользователей будем прописывать ручками, базы данных для их учета нам не нужно. Это принципиальная позиция - обойтись минимумом. Вывод - вполне хватит связки Postfix + Dovecot. Среди кучи, просто кучи руководств, бОльшая часть из которых создана в 2005-9гг, при попытке соединить в натуре все прочитанное, можно много слов высказать. Но виновато во всем время, изменившее и программы, и замусорившее поисковую выдачу. Потому, подняв свой сервер, отпишу акутальную для 2015г. последовательность действий. Какая ставилась задача - 1. поднять свой собственный почтовый сервер на простеньком железе и с минимумом софта. Сервер питается и-нетом через обычного провадера домашнего и-нета, сервер стоит "за" ротутером 2. замкнуть (перевести) все регистрационные записи домена на поднятый сервер 3. выкачать с gmail весь накопленный массив писем и залить его в пользовательский аккаунт своего сервера 4. обеспечить совместный доступ к почте нужных пользователей 5. веб-морду доступа к почте в конечном итоге было решено не подниамть. Типовое решение - роундкубе, он завязан на использование SQL, который на сервере хоть и поднят, но подключать не хотелось, поскольку этот роундкуб является слабым звеном - именно в нем находятся, редко, но бывают, уязвимости. Все зедачи реализовать удалось. Гибкость и производительность на несколько голов выше Гугля. Например, каждый пользователь может дать доступ, РЕГУЛИРУЕМЫЙ (т.е. можно выставить раздельные разрешения на каждую папку в почте на каждое действие - читать, писать, удалять, создавать, менять влаги (прочтено\не) и т.п.) и это честный imap--доступ, понимаемый каждым почтовым клиентом. Это, кстати, и добило идею веб-морды, которая на джимыле использовалась преимущественно для "посмотреть расшаренную почту другого пользователя". Компоненты решения - pigeonhole dovecot postfix spamassassin. Ставим их из репозиториев. Postfix обеспечиват smtp - как принятие почты от наших клиентов, клиентов нашего домена с последующей передачей нашим же клиентам или во внешний мир, причем сразу на сервера получателей (минуя ретранслятор, smtp, нашего провайдера), а также обеспечивает принятие почты на наш домен от всех к нему обращающихся (на основании MX записи нашего домена). Dovecot обеспечивает нам раздачу по нашим ящикам, сервис IMAP, POP3 и пр. Потому их и используют в связке. pigeonhole - это набор плагинов к dovecot spamassassin - спам-фильтр Существенно - для нормальной работы требуется нормальный провайдер. Нам потребуется выделенный ip и явно для него заданная обратная запись PTR. PTR может указывать только владелец ip адреса. Если у хорошего провайдера есть для этого явно созданный интерфейс, то в случае с домашними провайдерами это предмет переговоров. Важно - если мы делаем почту на домене domen.ru, то ptr надо настраивать не domen.ru, а mx.domen.ru. Эта PTR запись требуется при проверках, которые осуществляют получатели вашей почты при детекции валидности почты, спамоподавлении. Spamassassin по результатам многлетнего использования буду менять на rspamd, поскольку не примере неприбития яндексписем наблюдаю неадекватную обучаемость ассассина. Что общего отмечу - разбросанные по сети мануалы ощутимо путают, ибо написаны в разные годы. Особенно это касается Dovecot, у которого, например, теперь больше нет плагина autocreate, на который ссылается большинство мануалов. Что Postfix, что Dovecot теперь состоят каждый из одного пакета. Ставятся тривиально,
Наверняка интересанту будет нужно на одной машинке иметь почтовый сервер, обрабатывающий ящики нескольких доменнов и нескольких клиентов, причем на машинке-сервере этих клиентов (логинов) нет. Т.е., это важно понимать, речь идет и о виртуальных доменах, и о виртуальных пользователях. Кроме того важно понимать, что конфиг у обоих серверов содержит очень большое число настроечных параметров. Разнообразные мануалы создают иллюзию несложных, простых настроек - буквально в пару строчек. Фишка в том, что логика всех указанных программ работы следующая - созданный вручную файл конфига переписывает (переопределяет) лишь те параметры, которые в нем явно указаны. Т.е. если в мануале настройке Dovecot не указать явным образом допустимые в работе протоколы, то он будет предоставлять доступ сразу по всем. Если не определить т.н. "пространство имен" или определить его несколько раз, или без учета правил путей к файлам, то будет каша и аборт. Лично я в итоге заблокировал pop3. Почему? - когда ноут постоянно подключен к сети, он скачивает по поп3 письма и сервер их автоматом считает "прочитаными", что отражается на уведомлениях в мобильной почте. Кромет того, если я скачанное по поп3 письмо перемещу в спам, то сервер об этом не узнает. Поехали. Нужен пользователь, от имени которого будет работать почта - Существенно - директорий, где будет храниться почта. Имеет смысл указывать директорий на шифрованном разделе, а данном случае /home/vmail. Настройки Postfix вместо обычно используемых файлов конфига буду вставлять командой модификации конфига (все эти команды меняют /etc/postfix/main.conf). Собственно после чистой установки в /etc/postfix есть шаблон main.conf, его можно прибить, приводимые команды создадут новый и в прямо не указанной части будут действовать т.н. "параметры по умолчанию". Я лично почему-то пошел иным путем, то-ли шаблон переименовал в main.conf, то ли там уже был свой. В нем туева туча строчек, все строки упорядочены по алфавиту (это знание полезно при попытке отыскать нужный параметр в редакторе). Правим - всем этим мы сказали, где брать наши ключи\сертификаты, логины\пароли, наши домены, дали инструкции хоть как-то отбрыкиваться от спамеров (т.е. не отправлять\не принимать через сервер почту от имени и для несуществующих пользователей), указали на связку с Dovecot.Ключи, цифровые сертификаты сервера, выше мы указали место их хранения (можете прописать любое свое, главно их создать). Желательно, конечно, иметь "взрослые" сертификаты, подписанные хоть каким-нибудь сертификационным центром. В простейшем случае можно использовать свои, самосозданные (не помню я как их сделал, но вариаций и инструкций много) - Теперь можно разобраться с именами, пользователями. Все реальные пользователи (самого сервера, не путать с пользователями почтового сервера) есть в Системе (кто может залогиниться на сервере как пользователь). Файл /etc/aliases содержит псевдонимы локальных пользователей. Т.е. в системе есть root и куча других, в этом файле их сопоставляют с теми, кто может залогиниться. Входящий в комплект Postfix аналогичный файл /etc/postfix/aliases лишь дополняет /etc/aliases, т.е. при запуске сервера инклудит (вроде) в себя /etc/aliases. Вцелом кроме как указать кому пересылать почту за рута, постмастера и т.п. эти файлы не нужны. Но после любого их изменения надо выполнить команды, изменения в этих файлах требуют индексации и (возможно) перезапуска postfix - Наиболее активно используемый файл, это файл виртуальных имен,/etc/postfix/virtual Именно в нем мы можем делать чудеса маршрутизации, указывая сперва имя, хоть просто имя, могущее существовать в любом из обслуживаемых доменов (или не существовать, но почту принимать), хоть конкретный мейл (включая мейл, не обслуживаемый вашим сервером, но отправку на который вы хотите поймать в ящик на вашем сервере), затем после пробела набор мейлов (включая любые внешние) или имен, на которые нужно перекидывать почту - user имя1, ekjwr@vibew.ty, ewvrevr добавлять можно так -
повторюсь, после редактирования обязательно выполнить команду -
Далее уже надо ручками поправить /etc/postfix/master.cf, указав в нем на обслуживающего агента (dovecot) и спамодав. Во избежание ошибок рекомендую сперва -
теперь
вставив туда (будье внимательны при копи-пасте - длинные строки могут терять кончики с трагическими последствиями!)-
намаявшись с разбросанными в разных местах конфигами я пришел к тому, что зачистил директорий давкота и все сложил туда.
теперь сам скрипт спамодава. В Вики спамодава указаны разные способы увязки всех демонов, я пробовал разные, завелся именно этот, хоть я его и пробовал последним (в нем задействован sendmail, имеющийся в любой системе) -
даем права на запуск -
рисуем скрипт, которым будет создана связка Логин-пароль пользователя почтового сервера. Логин и пароль (хэш пароля) будут записаны в файл /etc/dovecot/users. Логины предпочтительно создавать как user@domen.x. Это имеет значени, поскольку именно с учетом схемы принятых имен будут создаваться директории (папки), на которые завязаны разные настроечные параметры, в т.ч. "пространство имен". Пойдя по пути пользователь = 'user' вы столкнетесь с конфликтом имен. Создаем -
скрипт -
права на запуск -
Пример запуска (создания) -
Скрипт обучения антиспама, я его затачивал на обучение по спам-папкам лишь продвинутых пользоваталей, которые следят за вопросом.
скрипт -
права на запуск -
затем скормим команду крону, чтобы с какой-то периодичностью спам-фильтр самообучался -
там нарисуйте строчку - 30 5 */1 * * /etc/dovecot/spam Еще один срипт, последний, который будет делать простую вещь - все письма, помеченные Спамфильтром как спам НЕ убивать, а просто перекладывать в папку спам клиента. Почему так? - если спам прибивать, то потеряются письма, ошибочно принятые за спам. Если не прибивать и не перекладывать, то во Входящих на 1 полезное будет 50-100 спамовых писем и телефоны с их мобильными клиентами почты замучают нотификациями. В этом же файле можно настроить и другие сортировки, выполняемые в рамках стандартного для вашего сервера "пространства имен". Кроме того, для обучения спам-фильтра ему нужно иметь место, куда сложен отобранный спам.
скрипт -
Права на исполнение давать не надо, надо скомпилировать -
Как видите, сортировщик ищет в теме письма нужные ему буквы, символы. Их рождает антиспам-фильтр, который тоже надо подстроить. Прибьем лишний конфиг (чтобы глаза не разбегались) и сделаем свой. Если есть желание менять заголовок, то это надо делать здесь и в скрипте сортировщика, синхронно (не забыв про компиляцию сортировщика) -
ВНИМАНИЕ - при последующих, с годами, обновлениях будет меняться версия ассассина и вместо 3.004001 будут другие цифры, а конфиги рабочие будут таки по пути /etc/mail/spamassassin/local.cf в редакторе - Теперь конфигурируем сам давкот -
в редакторе - Избегайте отсебятины в именах и схемах директориев, на них завязан и совместный доступ, и срипт сортировки, и скрипт обучения антиспама.В части создания и настройки сервера это все. Пора запускать. смотреть логи так -
При первом же логине клиента будут созданы каталоги (директории), все необходимые файлы. Рекомендую дальнейшие операции выполнять почтовым клиентом Thunderbird, он вполне адекватен. Но заводить "учетную запись" ЕЩЕ РАНО. Поскольку потребуется масса перезагрузок клиента, отключите плагин календаря (сильно задерживает запуск), найдите и подключите плагин imap-acl-ext... - сам расшаренный доступ к папкам пользователей дает плагин давкота acl, а плагин давктоа imap-acl позволяет пользователям через их почтовую программу с плагином почтового клиента imap-acl-ext.. рулить правами доступа к своей почте другим пользователям. Собственно рулежка эта обеспечивается имеющимся в каждом каталоге почты файлике -
в нем -
владельцу полные права, а юзеру - иные (чтение, просмотр папок) Через почтовую программу в списке папок учетной записи - Свойства - вкладка Совместное использование - Сет пермишн - упражняйтесь вволю Подписаться - внизу (согласно Пространству имен) будет shared и список доступных почт других пользователей. Поскольку мы планово собирались выкачать с джимыла всю накопленную почту, то встанет вопрос ограничений Thund... на размер папки почты (4.х гб). Тырнет изобилует ссылками на нерешаемость проблемы. Это не так. Thund - настройки - Дополнительные -внизу вкладки "тип харнилища сообщений..." следует выбрать "по файлу на сообщение". Перезагрузка программы. Идем в веб-версию джимыла (мэйл-ру, яндекс и т.п.), в настройках ищем про pop3 или imap. Включаем доступ по поп3 КО ВСЕМ письмам. Здесь же, зависит от вашей решительности, ставим галки - удалять ли скачанные письма. пугаться не надо - удаляются они в Корзину и если что не так, легко оттуда достаются. Далее глубоко заполночь, чтобы не мешать домашним, в Thund заводите почтовый ящик джимыла. Да, он был и ранее (наверняка). Но ведь в нем же проводились чистки? А стоит задача выкачать все? так что новый ящик. Если Thund будет ругаться на дублирование (ранее был поп3 ящик), заведите imap и наоборот. Теперь медленно и печально Thund выкачает все гигабайты вашей почты. Не мешайте ему. Проверьте итоговый размер ящика в Thund и число писем, сопоставьте с данными вебверсии джимыла. Если что не так - все прибить и повторить. Пока он качает, идем в паннель управления Роутера и прописываем в нем проброс портов (25, 110, 587, 143, 465) из и-нета на сервер (машину) с почтой. Также идем в паннель управления хостинг-провайдера и там для нашего домена указываем адрес нашего сервера (роутера, его внешний ip). В моем случае, поскольку настройки не позволяли указать сразу ip адрес, хостинг-провайдер пририсовал свой адрес-псевдоним, который в свою очередь ссылался на мой ip. Техподдержка поможет. Когда выкачалась почта в Thund заводим учетную запись со своего сервера, сразу указывая ВНЕШНИЙ ip (роутер это должен позволять). Ну соотв. выбрать imap, указать имя пользователя и пр. Хорошо бы перезапустить Thund. Место для принципиального решения - куда конкретно класть выкачанную из джимыла почту? - я в "удаленные" (которые Thund было запрещено чистить). У Вас иное мнение? - создайте папку и вперед. Тыкаем мышью в список писем джимыла и пробуем Ctrl+A (выделить все). Добиваемся выделения всего (сколько-то десятков тысяч?). Правой кнопкой - переместить (или скопировать - на Ваш вкус) в папку - и указываем куда именно какой именно учетной записи. Могу уверенно утверждать, что если при этом ничего с Thund не вытворять, то тысяч 20 писем он так перенесет. Но если попытаться еще что-то делать, то он может раздуться в ОЗУ заняв его целиком (мои 4гб) и ..... что-то может пойти не так. Терпение. Сперва он тащит маленькие письма, самые большие - в самом конце. Сколько-то часов. Комп при этом нормально работает. После переноса учетную запись джимыла можно прибить, в его вебморде настроить автоответчик и пересылку почты. И забыть о нем. Получив взамен очень хорошую скорость, патриотичность (никаких проблем и в Крыму), возможность кидать любого размера почту с любыми вложениями и без "большого брата" в мыльнице, возможность гибко настраивать совместный доступ и пользовать его в мобильных и настольных клиентах. |
indeviral |
|
Темы:
39
Сообщения:
3204
Участник с: 10 августа 2013
|
спасибо
Ошибки в тексте-неповторимый стиль автора©
|
ghost |
|
Темы:
26
Сообщения:
637
Участник с: 07 мая 2013
|
статья что надо |
vadik |
|
Темы:
57
Сообщения:
5494
Участник с: 17 августа 2009
|
Думаю статье место в блогах. ) |
gorynych |
|
Темы:
0
Сообщения:
5
Участник с: 23 июля 2015
|
Хорошая статья, только у меня возник вопрос зачем в virtual_mailbox_domains прописывать мой.главный_домен_с_МХ_записью_у_провайдера.ru если он уже прописан в mydestination и как следствие является локальным доменом с локальными пользователями? или я чего то недопонимаю? |
wau |
|
Темы:
168
Сообщения:
1245
Участник с: 11 октября 2013
|
не возьмусь убедительно ответить. Но исходил из следующего, и, казалось, это вроде отразил - машина, на которой поднят сервер, имеет локальных пользователей, но ни их число, ни их имена не совпадают (могут не совпадать) с именами пользователей почты. И само имя машины, на которой развернут сервер, может быть любым (иным), не совпадающим с доменом поддерживаемой почты. Исторически сложилось так, что сперва родилась машина-сервер, по-сути с одним пользователем-админом, потом к ней постепенно прикручиваются различные сервисы и, думаю, это весьма распространенная ситуация. Соответственно следствием является частичное дублирование - это как указание даже в разных местах aliases, когда постфиксовый сам по себе считывает (инклудит, включает в себя) системный, ведь обычно как о само собой разумееющихся вещах не говорят (не пишут), а новички о них и не узнают. |
gorynych |
|
Темы:
0
Сообщения:
5
Участник с: 23 июля 2015
|
В принципе понял, просто всегда считал что один и тот же домен нельзя прописывать и как локальный и как виртуальный UPS: И как оказалось был прав, если домен - мой.главный_домен_с_МХ_записью_у_провайдера.ru указать в $mydestination, а также его указать в $virtual_mailbox_domains. То мы получаем в логах предупреждение: warning: do not list domain мой.главный_домен_с_МХ_записью_у_провайдера.ru in BOTH mydestination and virtual_mailbox_domains Т.е. мы указали один и тот же домен сразу в двух классах адресов - локальных и виртуальных. Чего не стоит никогда делать. |
gorynych |
|
Темы:
0
Сообщения:
5
Участник с: 23 июля 2015
|
Эм заметил что в статье для postfix не используется virtual_mailbox_domains, откуда postfix знает какие у него есть ящики? |
wau |
|
Темы:
168
Сообщения:
1245
Участник с: 11 октября 2013
|
Сам в свое время удивлялся, когда читал множественные хаутушки. Во всех случаях постфикс обязательно работал в связке с чем-нибудь типа давкота. Собственно реальных пользователей почты я создавал в давкоте (описано). Виртуальных, включая всевозможные переадресации, указывал в /etc/postfix/virtual и ссылки на вирутальных по мере надобности в /etc/postfix/aliases. Вики по давкоту глаголят примерно так - "при первом входе пользователя будут созданы ящики\директории". Связка между постфиксом (транспорт) и агентом, выразимся в контексте вопроса так - "раскладки по ящикам" (это я умничаю, возможно и напрасно, без глубокого знания предмета), непосредственно в конфиге постфикса указан давкот. Т.е. указание постфиксу использовать давкот содержится в конфиге (описано), и отдельно повторю - postconf -e 'mailbox_command = /usr/lib/dovecot/deliver' |
gorynych |
|
Темы:
0
Сообщения:
5
Участник с: 23 июля 2015
|
Хорошо, может я что то просто не допонимаю, в силу того что я тоже не шибко соображаю в данном вопросе, ваше пояснение я принял к сведению постараюсь разложить его у себя в голове по полочкам. В предыдушем посте я допустил ошибку я имел виду не virtual_mailbox_domains а virtual_mailbox_maps, и его упоминание я всетки нашол у вас, оно у помянуто в local_recipient_maps, тем самым вы виртуальных пользователей относите к локальным, если я правильно помню назначение данного параметра. |