Тази статия е продължение на Подобрение SSL/TLS, Maildir, LMTP До тук имаме: ● инсталиран сървър за електронна поща без защита от спам и вируси ● настроени PostFix и Dovecot за работа с пощенските кутии по стандарт Maildir ● PostFix и Dovecot работят взаимно един с друг ● PostFix и Dovecot работят със сертификати на Let's Encrypt ● удостоверяването в сървъра извършва Dovecot ● има дефиниран в сървъра филтър на съобщенията Sieve Какво не ни достига ● работим със домейни дефинирани в самата ОС, което е много неудобно ако имате пощи на много домейни ● работим с потребители на ОС и дефинирането на всеки потребител за кой домейн е много неудобно Как ще процедираме: ● ще създадем виртуални домейни, потребители, алиаси и т.н. без да ползваме база данни ● ще конфигурираме PostFix и Dovecot да работят с виртуалните променливи ● ще тестваме работата на сървъра за електронна поща ● ще инсталираме приложение за управление на виртуалните домейни, потребители и т.н. Ако внимателно сте проследили предната публикация ще забележите, че виртуализацията има отношение към удостоверяването в сървъра. За удостоверяването отговаряше Dovecot. Даже PostFix предоставяше тази услуга да се извършва от Dovecot. И направили това уточнение да погледнем как стоят нещата на Нашия сървър. Захващаме се с главния "виновник" Dovecot. Файла отговарящ за удостоверенията беше /etc/dovecot/conf/10-auth.conf. Започваме да го разглеждаме отгоре надолу.
nano /etc/dovecot/conf.d/10-auth.conf ### Търсим за наличие на disable_plaintext_auth = yes disable_plaintext_auth = yes ### Търсим за наличие на auth_username_format = %n # auth_username_format = %n ### Търсим за наличие на auth_mechanisms = plain login auth_mechanisms = plain login ### Търсим за наличие на !include auth-system.conf.ext # !include auth-system.conf.ext !include auth-passwdfile.conf.ext
disable_plaintext_auth = yes - предлага се на клиента да използва SSL/TLS, но не го задължава # auth_username_format = %n - забраняваме го защото при виртуализацията се ползва пълното име на клиента auth_mechanisms = plain login - задължаваме клиента да се удостоверява чрез протокол клиент/сървър (plain) и парала (login). # !include auth-system.conf.ext - забраняваме удостоверяване чрез системните потребители на операционната система !include auth-passwdfile.conf.ext - удостоверяване чрез специален файл за имена и пароли. И сега идва логичния въпрос. Как и къде да създаваме потребители с техните пароли? Това се дефинира чрез файла /etc/dovecot/conf.d/auth-passwdfile.conf.ext
nano /etc/dovecot/conf.d/auth-passwdfile.conf.ext passdb { driver = passwd-file # args = scheme=CRYPT username_format=%u /etc/dovecot/users args = scheme=SHA256-CRYPT username_format=%u /etc/dovecot/users } userdb { driver = passwd-file args = username_format=%u /etc/dovecot/users # Default fields that can be overridden by passwd-file #default_fields = quota_rule=*:storage=1G # Override fields from passwd-file #override_fields = home=/home/virtual/%u }
Чрез passdb се извлича паролата на потребителя от файл намиращ се в /etc/dovecot/users. Тук име и още една секция, userdb. Тази секция служи за извличане на местоположение на пощенските кутии, квоти, кое UID и GID могат да боравят с потребителя и т.н. Забележете, че паролите и местоположението на пощенските кутии се намират в един файл. Това налага пълно описание на потребителя, не само име и парола, а кой му е принципал и къде му е пощенската кутия. Следват обаче няколко задачи. Първо да създадем файл отговарящ за потребителите /etc/dovecot/users Файла трябва да има формата:
user:password:uid:gid:(gecos):home:(shell):extra_fields
user - пълното име на потребителя с домейна (задължително) password - парола на потребителя започваща с {SHA256-CRYPT} (задължително) uid - ID на потребителя (задължително) gid - ID на групата (задължително) (decos) - поле за коментари (не задължително) home - домашна папка на клиента за ел. поща (задължително) (shell) - обвивка с която работим, най-често е BASH (не задължително) extra_fields - допълнително поле за настройки (не задължително) Забележете, формата на файла е същия както на /etc/passwd. Незадължителните атрибути може да не се попълват но разделителя (:) трябва да съществува За да създадем файла с потребители е необходимо няколко неща. За начало да генерираме паролата. Може да се пробваме да създадем един клиент с помоща на doveadm
doveadm pw -s SHA256-CRYPT -u cccp@my.tlan.net -p Iceman {SHA256-CRYPT}$5$kCmRXpzGr/kneSkr$DLUTQo98DaVhxkoMZ8kI2nnpPp0sU.vJD6Kgonrb1G9
И да попълним файла с потребителите и паролите.
nano /etc/dovecot/users cccp@my.tlan.net:{SHA256-CRYPT}$5$kCmRXpzGr/kneSkr$DLUTQo98DaVhxkoMZ8kI2nnpPp0sU.vJD6Kgonrb1G9:vmail:vmail: : /var/vmail/%d/%u : :
Създадохме файл с потребител в него. cccp@my.tlan.net - пълното име на потребителя {SHA256-CRYPT}$5$2JMPey/r3Ju3QSkC$8ac0USwxSfwMX5yFPU2vKK3NrOrvIa/5Zu5D0V7/2p9 - парола vmail:vmail - UID и GID обслужващи потребителя /var/vmail/%d/%u - местоположение на пощенските кутии От файла с потребителите виждаме, че е необходим системен потребител vmail, с някакво UID и GID. Също така във файла auth-passwdfile.conf.ext, чрез параметъра userdb дефинирахме, че във файла /etc/dovecot/users също има системен потребител с UID и GID който да може да борави с папките на клиента. Всичко това ни задължава да създадем такъв системен потребител. Започваме с дефинирането му. Първо създаваме групата на която ще принадлежи.
groupadd -g 5000 vmail
До тук създадохме група vmail с GID 5000 Сега и самия потребител.
useradd -g vmail -u 5000 vmail -d /var/vmail -m
В групата vmail присъединихме потребител vmail с UID 5000, който е собственик на /var/vmail. Параметъра –m пък създаде папката /var/vmail Да проверим:
groups vmail
vmail : vmail
ls -ld /var/mail/vhosts/
drwxr-xr-x 2 vmail vmail 4096 May 11 04:41 /var/mail/vhosts/
id vmail
Ако не бяхме ползвали параметъра -m когато създавахме потребителя vmail, трябваше последователно да изпълним следните команди.
mkdir -p /var/vmail/ chown -R vmail:vmail /var/vmail/ chmod -R 0700 /var/vmail/
Забелязахте ли къде се намират вече папките на потребителите? Мястото е в /var/vmail/. Да укажем новото място в Dovecot.
nano /etc/dovecot/conf.d/10-mail.conf # mail_location = maildir:~/Maildir mail_location = maildir:/var/vmail/%d/%n
Пощенските кутии ще се разполагат в /var/vmail/име на домейна/име на потребителя/Maildir/... Има и по-лесен вариант за създаване на файл с имена и пароли. UID и GID са винаги едни и същи, това е потребителя vmail който е член на групата vmail. Също така положението на пощенските кутии е едно и също /var/vmail/%d/%u. Значи тези значения можем да ги укажем като статични. Динамични ще останат само имената и паролите. Тогава само тях ще опишем в файла за имена и пароли. Да проиграем и този вариант.
nano /etc/dovecot/conf.d/auth-passwdfile.conf.ext passdb { driver = passwd-file # args = scheme=CRYPT username_format=%u /etc/dovecot/users args = scheme=SHA256-CRYPT username_format=%u /etc/dovecot/users } userdb { # driver = passwd-file # args = username_format=%u /etc/dovecot/users driver = static args = uid=vmail gid=vmail home=/var/vmail/%d/%n # Default fields that can be overridden by passwd-file #default_fields = quota_rule=*:storage=1G # Override fields from passwd-file #override_fields = home=/home/virtual/%u }
И тогава файла с имената и паролите ще изглежда:
nano /etc/dovecot/users cccp@my.tlan.net:{SHA256-CRYPT}$5$kCmRXpzGr/kneSkr$DLUTQo98DaVhxkoMZ8kI2nnpPp0sU.vJD6Kgonrb1G9
ВНИМАНИЕ !!! Ако не дефинирате правилно userdb, то тогава ще можете да изпращате писма, но няма да можете да получавате, защото неправилно ще се работи с LMTP протокола.
Помните ли, че Dovecot удостоверяваше PostFix. Освен това се грижеше и за обслужването на пощенските кутии, като отново PostFix се ползваше от услугите му. Предния път дефинирахме Dovecot да удостоверява PostFix, също и за кутиите. Да проверим за всеки случай.
nano /etc/postfix/main.cf smtpd_sasl_type = dovecot smtpd_sasl_path = private/auth smtpd_sasl_auth_enable = yes mailbox_transport = lmtp:unix:private/dovecot-lmtp smtputf8_enable = no
УДОСТОВЕРЯВАНЕ: smtpd_sasl_type = dovecot - удостоверяването се прави от Dovecot SASL, по подразбиране беше Cyrus SASL. smtpd_sasl_path = private/auth - Dovecot и PostFix комуникират помежду си чрез сокет smtpd_sasl_auth_enable = yes - активираме SASL удостоверяване на SMTP сървъра LMTP mailbox_transport = lmtp:unix:private/dovecot-lmtp - настройка на LMTP за невиртуален потребител smtputf8_enable = no - по подразибране тази опция е активна, това значи, че можем да ползваме само UTF-8 формата, затова изключваме това условие. Примерно за България понякога се ползва Windows-1251. След толкова пояснения да приложим знанията в Нашия случай.
nano /etc/postfix/main.cf smtpd_sasl_type = dovecot smtpd_sasl_path = private/auth smtpd_sasl_auth_enable = yes # mailbox_transport = lmtp:unix:private/dovecot-lmtp smtputf8_enable = no virtual_transport = lmtp:unix:private/dovecot-lmtp virtual_mailbox_domains = /etc/postfix/virtual_mailbox_domains
Още едноо уточнение. Да погледнем mydestination в /etc/postfix/main.cf
nano /etc/postfix/main.cf mydestination = $myhostname, my.tlan.net, localhost.ns1.my.tlan.net, localhost.my.tlan.net, , localhost
Ако искаме да ползваме друг виртуален домейн, то трябва да го опишем и него тук. А сега си представете, че имате 50 такива виртуални домейни. Става един дълъг ред който мъчно се контролира. За целта ще слушаме за SMTP на локалния хост, а виртуалните домейни ще ги отделим в отделен файл. Да редактираме main.cf
nano /etc/postfix/main.cf # mydestination = $myhostname, my.tlan.net, localhost.ns1.my.tlan.net, localhost.my.tlan.net, , localhost mydestination = localhost virtual_mailbox_domains = /etc/postfix/virtual_mailbox_domains
virtual_mailbox_domains = /etc/postfix/virtual_mailbox_domains - дефинирахме в кой файл да запишем виртуалните домейни. Това изисква създаване на файл /etc/postfix/virtual_mailbox_domains
nano /etc/postfix/virtual_mailbox_domains my.tlan.net my.tachko.com
Файла го създадохме, но PostFix не може да го разчете, защото е с неразпознаваема за него структура. Да го конвертираме за PostFix
postmap /etc/postfix/virtual_mailbox_domains
Командата създаде нов файл /etc/postfix/virtual_mailbox_domains.db, разбираем вече за PostFix
Готови сме, остана да рестартираме PostFix и Dovecot.
service postfix restart service dovecot restart
Да тестваме:
doveadm user *@my.tlan.net cccp@my.tlan.net doveadm auth test -x service=imap -x rip=192.168.11.5 cccp@my.tlan.net passdb: cccp@my.tlan.net auth succeeded Password: Iceman extra fields: user=cccp@my.tlan.net doveadm auth test -x service=smtp -x rip=192.168.11.5 cccp@my.tlan.net passdb: cccp@my.tlan.net auth succeeded Password: Iceman extra fields: user=cccp@my.tlan.net doveadm user cccp@my.tlan.net userdb lookup: user cccp@my.tlan.net doesn't exist field value
Последния тест показва, че не съществува потребител cccp@my.tlan.net. На практика е така. Ако помните в началото на статията казахме, че ще ползваме пълни имена, защото вече работим с виртуални потребители на електронна поща. И би трябвало да няма проблем но като писах статията съм забравил да забраня ползването на къси имена. Да поправим проблема.
nano /etc/dovecot/conf.d/10-auth.conf #auth_username_format = %Lu # auth_username_format = %n # Това не го бях забранил service dovecot restart
И наново да тестваме:
doveadm user cccp@my.tlan.net field value uid 5000 gid 5000 home mail maildir:/var/vmail/my.tlan.net/cccp
Този път всичко е наред. Сега да се пробваме да влезем през WEB на https://my.tlan.net/roundcube/ Следващия тест е да пратим писмо на външна поща. В моя случай на tachko@mail.bg. Писмото ще пристигне успешно. Сега обратния случай. Пращаме от tachko@mail.bg до cccp@my.tlan.net. Писмото пак трябва да пристигне успешно. Ако пращаме писма а не получаваме. Най-често проблема е дефинирането на userdb в /etc/dovecot/conf.d/auth-passwdfile.conf.ext. Не е описан правилно пътя на пощенската кутия. Тогава удостоверяването ще върви (SASL), а LMTP няма да работи правилно. По-точно протокола ще си работи правилно но няма да знае къде да достави писмото. С това завършваме риртуализацията без SLQ база данни.