Инсталиране и настройка на пощенски сървър с виртуални домейни и кутии
Ако не сте следили статиите за Debian 12, горещо препоръчвам да ги прочетете, защото тази тема е продължение на предните. За пояснение: ● инсталирахме Debaian 12 ● настроихме Debian 12 ТУК ● настроихме DNS сървъра ТУК ● инсталирахме и настроихме Apache ТУК ● инсталирахме и настроихме MySQL и PHPMyAdmin ТУК Следва да създадем сървър за електронна поща с виртуални домейни и виртуални пощенски кутии. За целта пренасочваме следните портове, ако сме зад рутер или ги освобождаваме в защитната стена ако сме с реално IP върху сървъра. TCP - 25 - SMTP TCP - 587 - SMTP Start TLS TCP - 465 - SMTP SSL TCP - 110 - POP3 TCP - 995 - POP3 SSL TCP - 143 - IMAP Start TLS TCP - 993 - IMAP SSL TCP - 589 - IMAP4 SSL Дълго се колебаех как да започна темата. Дали да продължа от елементарния сървъра за електронна поща или да почна отначало да го изграждам. Спрях се на втория вариант. В първия вариант има създадени много зависимости докато ги върнем в изходно състояние и след това да почнем виртуализацията, ще стане много объркващо. Затова предпочетох да започнем на чисто.
Подготовка на база данни
Създаване на база pfdb за пощенския сървър и потребители боравещи с нея
mysql create database pfdb; grant all on pfdb.* to 'pfadmin'@'localhost' identified by 'adminpass'; grant select on pfdb.* to 'pfuser'@'127.0.0.1' identified by 'pfpass'; quit
Създадохме база pfdb, потребители pfadmin и pfuser боравещи с нея. Съответно потребителите имат пароли adminpass и pfpass.
Създаване на таблици в базата pfdb
Таблица за виртуалните домейни.
mysql use pfdb; CREATE TABLE IF NOT EXISTS `virtual_domains` ( `id` int(11) NOT NULL auto_increment, `name` varchar(50) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Таблица за виртуалните потребители
CREATE TABLE IF NOT EXISTS `virtual_users` ( `id` int(11) NOT NULL auto_increment, `domain_id` int(11) NOT NULL, `email` varchar(100) NOT NULL, `password` varchar(150) NOT NULL, `quota` bigint(11) NOT NULL DEFAULT 0, PRIMARY KEY (`id`), UNIQUE KEY `email` (`email`), FOREIGN KEY (domain_id) REFERENCES virtual_domains(id) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
Таблица за виртуалните алиаси
CREATE TABLE IF NOT EXISTS `virtual_aliases` ( `id` int(11) NOT NULL auto_increment, `domain_id` int(11) NOT NULL, `source` varchar(100) NOT NULL, `destination` varchar(100) NOT NULL, PRIMARY KEY (`id`), FOREIGN KEY (domain_id) REFERENCES virtual_domains(id) ON DELETE CASCADE ) ENGINE=InnoDB DEFAULT CHARSET=utf8; quit
Попълване на таблиците с данни за тест
Ползвайте doveadm pw -s BLF-CRYPT за да генерирате парола която искате за вашия потребител. В случая е tachko@tachko.com.
doveadm pw -s BLF-CRYPT -u tachko@tachko.com
В случая не можете да генерирате парола, защото нямате инсталиран Dovecot и затова нямате doveadm. На по-късен етап пак ще се върнем към този проблем
mysql REPLACE INTO pfdb.virtual_domains (id,name) VALUES ('1','tachko.com'); REPLACE INTO pfdb.virtual_users (id,domain_id,password,email) VALUES ('1', '1', '{BLF-CRYPT}$2y$05$9ckfUS/OyY9/xSqZ5WdNKOO92oBJ0zTd6xhaZ5nXH4oPSV1oIGpUO', 'tachko@tachko.com'), ('2', '1', '{BLF-CRYPT}$2y$05$9ckfUS/OyY9/xSqZ5WdNKOO92oBJ0zTd6xhaZ5nXH4oPSV1oIGpUO', 'cccp@tachko.com'); REPLACE INTO pfdb.virtual_aliases (id,domain_id,source,destination) VALUES ('1', '1', 'cccp@tachko.com', 'tachko@tachko.com'); quit
PostFix
Инсталиране и конфигуриране на PostFix
За начало да инсталираме PostFix и допълнението му за работа с MySQL.
apt install postfix postfix-mysql -y
Внимание !!! Ползваме пълното име на хоста (FQDN), защото работим с виртуални домейни. Домейна ни е tachko.com, а FQDN mail.tachko.com. Между другото, на по-късен етап ще ползваме само localhost. Освен postfix инсталирахме и postfix-mysql, който ни е нужен за PostFix да взема данни от MySQL. Правим копие на конфигурационните файлове за PostFix.
cp /etc/postfix/main.cf /etc/postfix/main.cf.original cp /etc/postfix/master.cf /etc/postfix/master.cf.original
Проверяваме как работи.
telnet gmail-smtp-in.l.google.com 25 Trying 142.251.18.27... Connected to gmail-smtp-in.l.google.com. Escape character is '^]'. 220 mx.google.com ESMTP f10-20020a50a6ca000000b00571d8dfdb52si15011805edc.83 - gsmtp quit 221 2.0.0 closing connection f10-20020a50a6ca000000b00571d8dfdb52si15011805edc.83 - gsmtp Connection closed by foreign host.
Всичко е наред продължаваме.
PostFix взема данни от MySQL
virtual_mailbox_domains - виртуални домейни
postconf virtual_mailbox_domains=mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf nano /etc/postfix/mysql-virtual-mailbox-domains.cf user = pfuser password = pfpass hosts = 127.0.0.1 dbname = pfdb query = SELECT 1 FROM virtual_domains WHERE name='%s' postmap -q tachko.com mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf 1
virtual_mailbox_maps - виртуални пощенски кутии
postconf virtual_mailbox_maps=mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf nano /etc/postfix/mysql-virtual-mailbox-maps.cf user = pfuser password = pfpass hosts = 127.0.0.1 dbname = pfdb query = SELECT 1 FROM virtual_users WHERE email='%s' postmap -q tachko@tachko.com mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf 1
virtual_alias_maps - виртуални псевдоними
postconf virtual_alias_maps=mysql:/etc/postfix/mysql-virtual-alias-maps.cf nano /etc/postfix/mysql-virtual-alias-maps.cf user = pfuser password = pfpass hosts = 127.0.0.1 dbname = pfdb query = SELECT destination FROM virtual_aliases WHERE source='%s' postmap -q cccp@tachko.com mysql:/etc/postfix/mysql-virtual-alias-maps.cf tachko@tachko.com
Има обаче един много важен момент. Примерно решавате всичко което идва до @tachko.com да се препраща до tachko@tachko.com. До тука добре. Това ще се изпълни, но тъй като @tachko.com е специфичен псевдоним той е с най-висок приоритет и това ще спре на практика пощата до другите потребители и само tachko@tachko.com ще получава поща. За да се избегне това се прави трик. Описват се в алиасите потребителите да получават поща до себе си -------------------------------------------------------------------------------------------------- Адрес Дестинация -------------------------------------------------------------------------------------------------- @tachko.com tachko@tachko.com cccp@tachko.com cccp@tachko.com Поради всичко това е нужно да създадем още един конфигурационен ред в /etc/postfix/main.cf., той на практика ще препокрие горният, който създадохме за виртуалните псевдоними.
postconf virtual_alias_maps=mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf nano /etc/postfix/mysql-email2email.cf user = pfuser password = pfpass hosts = 127.0.0.1 dbname = pfdb query = SELECT email FROM virtual_users WHERE email='%s' postmap -q tachko@tachko.com mysql:/etc/postfix/mysql-email2email.cf tachko@tachko.com
Уверете се, че само „root“ и „postfix“ потребителят могат да четат „.cf“ файловете – все пак паролата за вашата база данни се съхранява там:
chgrp postfix /etc/postfix/mysql-*.cf chmod u=rw,g=r,o= /etc/postfix/mysql-*.cf
Сега да направим няколко теста на PostFix Теста започва в: 7 мин. и 15 сек.
telnet tachko.com 25 Trying 185.163.245.186... Connected to tachko.com. Escape character is '^]'. 220 mail.tachko.com ESMTP Postfix (Debian/GNU) ehlo tachko.com 250-mail.tachko.com 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250-SMTPUTF8 250 CHUNKING mail from:<tachko@tachko.com> 250 2.1.0 Ok rcpt to:<tachko@tachko.com> 250 2.1.5 Ok
Всичко е наред. Понякога се появява грешка от рода на 454 4.7.1 <tachko@tachko.com>: Relay access denied. Този код за грешка се наблюдава в регистрационните файлове на сървъра, когато сървърът на получателя временно не може да получава имейли. Може да се поправи с:
nano /etc/postfix/main.cf mydestination = $myhostname, mail.tachko.com, tachko.com, localhost.tachko.com, , localhost mynetworks = 127.0.0.0/8 192.168.11.0/24 185.163.245.186/32 [::ffff:127.0.0.0]/104 [::1]/128 service postfix restart
ВНИМАНИЕ !!!. редакцията на mydestination e само за този тест.
Ако не ползвате виртуални домейни, стандартно се работи във вида локален домейн:
mydestination = example.org, example.com, example.net
Никога не изброявайте домейните в mydestination при виртуалните домейни. Ползвайте пълното име на хоста на сървъра или просто задайте mydestination=localhost. Пример:
mydestination = $myhostname, localhost
И най-вече:
mydestination = localhost
Виртуалните домейни се описват чрез virtual_mailbox_domains = example.org, example.com, a още по-добре в база данни както направихме по-рано с virtual_mailbox_domains=mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf. Това беше много важно уточнение.
telnet tachko.com 25 Trying 185.163.245.186... Connected to tachko.com. Escape character is '^]'. 220 ns1.tachko.com ESMTP Postfix (Debian/GNU) ehlo tachko.com 250-ns1.tachko.com 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250-SMTPUTF8 250 CHUNKING mail from:<tachko@tachko.com> 250 2.1.0 Ok rcpt to:<tachko@tachko.com> 250 2.1.5 Ok data 354 End data with <CR><LF>.<CR><LF> Изпращам поща от tachko@tachko.com . 250 2.0.0 Ok: queued as D8260140D1A quit
Теста мина успешно. Сега ако отворим пощата на tachko@tachko.com ще видим писмо от непознат подател. Да върнем нещата за работа с виртуални домейни.
nano /etc/postfix/main.cf # mydestination = $myhostname, ns1.tachko.com, tachko.com, localhost.tachko.com, , localhost mydestination = localhost
Dovecot
Инсталиране и настройка на Dovecot
Започваме с инсталацията.
apt install dovecot-mysql dovecot-pop3d dovecot-imapd dovecot-managesieved dovecot-lmtpd -y
Пълната конфигурация на Dovecot може да се види с:
doveconf -a
Много дълго за разглеждане. Можете примерно цялата конфигурация да я запишете във файл и да я разгледате с nano.
doveconf -a >> /home/cccp/dovecot.conf nano /home/cccp/dovecot.conf
Много е дълъг файла. Можете да отделите това което Ви вълнува с grep.
doveconf -a | grep mail_location mail_location = mbox:~/mail:INBOX=/var/mail/%u
Много полезен инструмент ползвайте го. И едно леко отклонение. Ако се сещате малко по-нагоре попълнихме базата pfdb с данни за домейни, потребители и алиаси. Когато създадохме потребителя tachko@tachko.com за парола ползвахме най-различни символи. Сега ще покажа как я генерирахме.
doveadm pw -s BLF-CRYPT -u tachko@tachko.com Enter new password: Iceman Retype new password: Iceman {BLF-CRYPT}$2y$05$9ckfUS/OyY9/xSqZ5WdNKOO92oBJ0zTd6xhaZ5nXH4oPSV1oIGpUO
Не е проблем ако тогава сте сложили моята парола. Генерирайте сега Вашата парола и да попълним базата с Вашите данни.
mysql REPLACE INTO pfdb.virtual_users (id,domain_id,password,email) VALUES ('1', '1', 'ВАШАТА ПАРОЛА', 'ВАШИЯ МЕЙЛ АДРЕС 1'), ('2', '1', 'ВАШАТА ПАРОЛА', 'ВАШИЯ МЕЙЛ АДРЕС 2'); quit
Продължаваме с Dovecot. Запазваме оригиналните конфигурационни файлове
cp /etc/dovecot/dovecot.conf /etc/dovecot/dovecot.conf.original cp /etc/dovecot/conf.d/10-auth.conf /etc/dovecot/conf.d/10-auth.conf.original cp /etc/dovecot/conf.d/auth-sql.conf.ext /etc/dovecot/conf.d/auth-sql.conf.ext.original cp /etc/dovecot/conf.d/10-mail.conf /etc/dovecot/conf.d/10-mail.conf.original cp /etc/dovecot/conf.d/10-master.conf /etc/dovecot/conf.d/10-master.conf.original cp /etc/dovecot/conf.d/10-ssl.conf /etc/dovecot/conf.d/10-ssl.conf.original cp /etc/dovecot/conf.d/15-mailboxes.conf /etc/dovecot/conf.d/15-mailboxes.conf.original cp /etc/dovecot/dovecot-sql.conf.ext /etc/dovecot/dovecot-sql.conf.ext.original cp /etc/dovecot/conf.d/20-lmtp.conf /etc/dovecot/conf.d/20-lmtp.conf.origianal cp /etc/dovecot/conf.d/15-lda.conf /etc/dovecot/conf.d/15-lda.conf.original cp /etc/dovecot/conf.d/90-quota.conf /etc/dovecot/conf.d/90-quota.conf.original cp /etc/dovecot/conf.d/20-imap.conf /etc/dovecot/conf.d/20-imap.conf.original cp /etc/dovecot/conf.d/90-sieve.conf /etc/dovecot/conf.d/90-sieve.conf.original
Преди да почнем същинското конфигуриране да създадем потребител който да притежава всички виртуални пощенски кутии. Това се прави с цел защита. Уверете се, че нямате потребител и група с ID 5000. Ако това ID се използва ползвайте друго но по-голямо от 1000.
groupadd -g 5000 vmail useradd -g vmail -u 5000 vmail -d /var/vmail -m chown -R vmail:vmail /var/vmail
Конфигуриране на Dovecot.
nano /etc/dovecot/dovecot.conf
# Търсим наличието на:
!include conf.d/*.conf
nano /etc/dovecot/conf.d/10-auth.conf
### Търсим реда:
auth_mechanisms = plain
### login се ползва заради Outlook XP или Vista. Трябва да изглежда:
auth_mechanisms = plain login
### Търсим пасажа:
!include auth-system.conf.ext
#!include auth-sql.conf.ext
#!include auth-ldap.conf.ext
(\) означава, че командата продължава на следващия ред. Фиксираме ограничения
chown root:root /etc/dovecot/dovecot-sql.conf.ext chmod go= /etc/dovecot/dovecot-sql.conf.ext
Рестартираме Dovecot.
systemctl restart dovecot
Да погледнем логовете.
cat /var/log/mail.log 2024-04-21T07:43:02.467432-04:00 ns1 dovecot: master: Warning: Killed with signal 15 (by pid=5698 uid=0 code=kill) 2024-04-21T07:43:03.574299-04:00 ns1 dovecot: log(5682): Warning: Killed with signal 15 (by pid=1 uid=0 code=kill) 2024-04-21T07:43:03.613287-04:00 ns1 dovecot: master: Dovecot v2.3.19.1 (9b53102964) starting up for imap, lmtp, sieve, pop3 (core dumps disabled) journalctl | grep imap Apr 20 00:25:42 my dovecot[18869]: master: Dovecot v2.3.19.1 (9b53102964) starting up for imap, lmtp, sieve, pop3 (core dumps disabled) journalctl -u dovecot
По същия начин и за Postfix
journalctl -u postfix Apr 19 23:56:37 my systemd[1]: Starting postfix.service - Postfix Mail Transport Agent... Apr 19 23:56:37 my systemd[1]: Finished postfix.service - Postfix Mail Transport Agent.
Работата с journalctl е доста неудобна но какво да се прави, това е тенденцията.
Postfix изпраща имейли до Dovecot
Dovecot къде да слуша за LMTP връзки от Postfix
nano /etc/dovecot/conf.d/10-master.conf service lmtp { # unix_listener lmtp { #mode = 0666 # } unix_listener /var/spool/postfix/private/dovecot-lmtp { group = postfix mode = 0600 user = postfix }
Рестартираме и проверяваме Dovecot.
systemctl restart dovecot systemctl status dovecot
PostFix да доставя поща до Dovecot чрез LMTP
postconf virtual_transport=lmtp:unix:private/dovecot-lmtp
server-side правила за писмата
nano /etc/dovecot/conf.d/20-lmtp.conf protocol lmtp { # Space separated list of plugins to load (default is global mail_plugins). #mail_plugins = $mail_plugins mail_plugins = $mail_plugins sieve } systemctl restart dovecot systemctl status dovecot
По принцип сега трябва да покажа дефиниране на квоти, но за сега ще отложим тази задача. Първо ще пуснем сървъра да праща и получава писма, а след това ще го надграждаме.
Инсталиране на тестови програми
За да тестваме по-нататък са ни необходими програмите swaks и mutt. Да ги инсталираме.
apt install swaks mutt -y
Да пробваме да пратим писмо през SWAKS
swaks --server localhost --to tachko@tachko.com
Да проверим дали е пристигнало писмото използвайки IMAP протокола. За целта ще ползваме простия но много мощен IMAP клиент наречен mutt
mutt -f imaps://tachko@tachko.com@ mail.tachko.com
Навярно ще Ви е трудно да свикнете с програмата затова по-добре да инсталираме един IMAP WEB базиран клиент.
Roundcube
Инсталиране на Roundcube от изходни файлове можете да прочетете на: https://tlan.net/menu/linux/debian/debian12/simplemail/simplemail12.php. По специално в частта Инсталиране на Roundcube. Първо да проверим дали всички пакети на PHP и Apache са инсталирани.
apt install apache2 apache2-utils -y apt install php libapache2-mod-php php-mysql php-net-ldap2 php-net-ldap3 php-imagick php-common php-gd php-imap php-json php-curl php-zip php-xml php-mbstring php-bz2 php-intl php-gmp php-net-smtp php-mail-mime -y
Инсталиране на Roundcube
Сега ще инсталираме и самия Roundcube, но този път от репозиторите. Просто за разнообразие.
apt install -y roundcube roundcube-plugins roundcube-plugins-extra roundcube-mysql
Създаваме парола за администриране на базата на Roundcube.
Повтаряме паролата за съвпадение. Ако по-някаква причина сте сменили паролата на базата данни за Roundcube, то трябва да промените файла за връзка на Roundcube с базата данни.
nano /etc/roundcube/debian-db.php $dbuser='roundcube'; $dbpass='rcpaSS'; $basepath=''; $dbname='roundcube'; $dbserver='localhost'; $dbport='3306'; $dbtype='mysql';
Първото нещо което трябва да оправим е да позволим на Apache да го достига.
nano /etc/apache2/conf-available/roundcube.conf # Those aliases do not work properly with several hosts on your apache server # Uncomment them to use it or adapt them to your configuration # Alias /roundcube /var/lib/roundcube/public_html Alias /mail /var/lib/roundcube/public_html a2enconf roundcube service apache2 restart
И ако напишем в браузъра: https://tachko.com/mail/ Ще се отвори страницата за влизане в Roundcube. Можем да влезем примерно като tachko@tachko.com и ще си видим входящата поща и т.н. За сега обаче това не стига. Инсталирахме добавки и трябва да ги включим. Да проверим на кои портове и как влязохме в Roundcube.
nano /etc/roundcube/config.inc.php $config['imap_host'] = ["localhost:143"]; $config['smtp_host'] = 'localhost:587'; $config['imap_host'] = ["tls://tachko.com:143"]; $config['smtp_host'] = 'tls://tachko.com:587';
Допълнения
Да добавим допълненията password и managesieve.
nano /etc/roundcube/config.inc.php $config['plugins'] = [ // 'archive', // 'zipdownload', 'managesieve', 'password', ];
Допълнение за пароли
nano /etc/roundcube/plugins/password/config.inc.php <?php // Empty configuration for password // See /usr/share/roundcube/plugins/password/config.inc.php.dist for instructio> // Check the access right of the file if you put sensitive information in it. // $config=array(); // Използваме SQL. $config['password_driver'] = 'sql'; // Паролите да са по-дълги от 5 знака $config['password_minimum_length'] = 5; // Това ще презапише паролата в базата данни, дори ако не е променена. $config['password_force_save'] = true; // Криптографският алгоритъм за кодиране на паролата. $config['password_algorithm'] = 'blowfish-crypt'; // Добавете пред всяка парола този низ, така че Dovecot да знае как сме шифровали паролата. $config['password_algorithm_prefix'] = '{CRYPT}'; // Информация за връзка с локалната база данни. $config['password_db_dsn'] = 'mysql://pfadmin:adminpass@localhost/pfdb'; // SQL заявката, която се изпълнява за запис на новия хеш на паролата в базата данни. %P е контейнер за хеша на новата парола. И %u е влезлият потребител и удобно съвпада с имейл адреса. $config['password_query'] = "UPDATE virtual_users SET password=%P WHERE email=%u"; ?>
Файла отговарящ за плъгина за пароли да е собственост на root:www-data. Правата върху файла също да се променят.
chown root:www-data /etc/roundcube/plugins/password/config.inc.php chmod u=rw,g=r,o= /etc/roundcube/plugins/password/config.inc.php
Допълнение SIEVE
Това допълнение наречено Sieve е правило от страна на сървъра. Dovecot изпълнява тези правила всеки път когато влезе нов мейл. Тук ще кажем на Roundcube как да има достъп до тези правила.
nano /etc/roundcube/plugins/managesieve/config.inc.php <?php // Empty configuration for password // See /usr/share/roundcube/plugins/password/config.inc.php.dist for instructio> // Check the access right of the file if you put sensitive information in it. // $config=array(); // Roundcube с кой сървър да говори: $config['managesieve_host'] = 'localhost'; ?>
Влезте в Roundcube https://tachko.com/mail като tachko@tachko.com
Филтрите се създават успешно. Да проверим:
nano /var/vmail/tachko.com/tachko/sieve/Roundcube.sieve # rule:[Трие TEST съобщения] if allof (header :contains "subject" "test") { discard; }
На практика се създаде файл: /var/vmail/tachko.com/tachko/sieve/Roundcube.sieve. За сега спираме с допълненията към Roundcube.
Тест доставка на поща
До тук трябва да има изградена структура на място където ще се разполагат писмата. Да проверим:
find /var/vmail
Има създадена структура Maildir за съхранение на писмата.
Проверка на PostFix
postfix check
Понякога се появяват следните грешки: “error: open database /etc/aliases.db: No such file or directory“? - изпълнете командата newaliases за да създадете нов машинен файл от псевдоними в /etc/aliases. “postfix/postfix-script: warning: symlink leaves directory: /etc/postfix/./makedefs.out“ - не обръщайте внимание на грешката, просто е бъг на Debian 12.
Пращаме тестов мейл
Отваряме втори терминал и в него пишем:
tail -f /var/log/mail.log
Така в реално време ще следим какво се записва в мейл лога. На първия терминал пишем:
swaks --to tachko@tachko.com --server localhost
В лога ще се появят надписи най-различни на вид. В крайна сметка трябва да се появи файл в: /var/vmail/tachko.com/tachko/Maildir/new/. Файла трябва да прилича нещо подобно на: '1714839033.M44886P8841.ns1,S=700,W=720:2,'. Този файл на практика е писмото което получихме. Можем да разгледаме пощата с помощта на mutt.
mutt -f /var/vmail/tachko.com/tachko/Maildir/
Мощен инструмент, можете да се задълбаете повече в способностите му. По същия начин можете да проверите пощата си чрез Roundcube или използвайки настолен мейл клиент.
Изпращане на поща
Препредаване на изходящата поща през PostFix
До тук можем да получаваме поща но не можем да пращаме. Ако сте чели предните статии за елементарен пощенски съръвр ще попитате , та нали PostFix върши тази работа? Това е така, но първо сте написали писмо примерно през някой клиент, след това писмото е записано на сървъра. Dovecot достига до писмото и го вижда, но PostFix не го вижда и не знае какво да изпрати. За целта трябва да накараме Dovecot да препрати писмото до PostFix. Същевременно PostFix ще научи от Dovecot кой е собственика на писмото и за къде да ходи. Грубо казано Dovecot ще удостовери PostFix.
PostFix се удостоверява от Dovecot
postconf smtpd_sasl_type=dovecot postconf smtpd_sasl_path=private/auth postconf smtpd_sasl_auth_enable=yes
Активиране на криптиранията в PostFix
postconf smtpd_tls_security_level=may postconf smtpd_tls_auth_only=yes postconf smtpd_tls_cert_file=/etc/letsencrypt/live/tlan.net/fullchain.pem postconf smtpd_tls_key_file=/etc/letsencrypt/live/tlan.net/privkey.pem postconf smtp_tls_security_level=may
Горните настройки позволяват криптирани входящи (smtpd_) и изходящи (smtp_) връзки. Но не ги налагат. Така че, ако отдалечен пощенски сървър не е с активирано криптиране, ние пак ще приемаме техните имейли. Може да се изкушите да наложите криптиране, но това би отхвърлило комуникацията по имейл със сървъри, които са конфигурирани без криптиране.
Тест на SMTP удостоверяване
Ако ползваме telnet localhost smtp ще се свържем с ТСР на порт 25 да говорим по SMTP. Ние работим вече с криптиране. Независимо от всичко да опитаме:
telnet localhost smtp Trying ::1... Connected to localhost. Escape character is '^]'. 220 ns1.tachko.com ESMTP Postfix (Debian/GNU) ehlo tachko.com 250-ns1.tachko.com 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250-SMTPUTF8 250 CHUNKING quit 221 2.0.0 Bye Connection closed by foreign host.
Липва обаче ред със съдържание: 250-AUTH PLAIN LOGIN. Това е така защото нямаме криптирана връзка. Да направим теста наново:
telnet localhost smtp Trying ::1... Connected to localhost. Escape character is '^]'. 220 ns1.tachko.com ESMTP Postfix (Debian/GNU) ehlo tachko.com 250-mailtest 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250-SMTPUTF8 250 CHUNKING STARTTLS 220 2.0.0 Ready to start TLS quit
Теста по този начин е до тук, защото няма как да говорим със сървъра шифровано по този начин. За целта ползваме openssl.
openssl s_client -connect localhost:25 -starttls smtp ### Ще видите много много текст........ ehlo tachko.com 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-AUTH PLAIN LOGIN 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN AUTH PLAIN AHRhY2hrb0B0YWNoa28uY29tAEljZW1hbg== 235 2.7.0 Authentication successful quit
Кода за аутентикация го създаохме чрез:
printf '\0tachko@tachko.com\0Iceman' | base64 AHRhY2hrb0B0YWNoa28uY29tAEljZW1hbg==
Порт за подаване на PostFix
SMTP работи на порт 25. Тук ползваме не криптирана връзка. За нашата цел е необходимо да работим по TCP на порт 587. За целта:
nano /etc/postfix/master.cf #127.0.0.1:submission inet n - y - - smtpd #submission inet n - y - - smtpd submission inet n - y - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_tls_auth_only=yes -o smtpd_reject_unlisted_recipient=no -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_relay_restrictions= -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING # -o syslog_name=postfix/submission # -o smtpd_tls_security_level=encrypt systemctl restart postfix
Вече можете да изпращате през порт 587 криптирано. Да проверим дали порта е активен. За целта ни е необходим netstat, който първо трябва да го инсталираме.
apt install net-tools -y netstat -ntulp | grep master tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 17197/master tcp 0 0 0.0.0.0:587 0.0.0.0:* LISTEN 17197/master tcp6 0 0 :::25 :::* LISTEN 17197/master tcp6 0 0 :::587 :::* LISTEN 17197/master
Всичко е правилно. PostFix "слуша" на порт 587. Да изпратим криптирана тестова поща. За целта обаче трябва да инсталираме libnet-ssleay-perl.
apt install -y libnet-ssleay-perl swaks --server localhost --to tachko@tachko.com --port 587 -tls --auth-user tachko@tachko.com --auth-password Iceman
Защита срещу фалшиви адреси
postconf smtpd_sender_login_maps=mysql:/etc/postfix/mysql-email2email.cf nano /etc/postfix/master.cf #127.0.0.1:submission inet n - y - - smtpd #submission inet n - y - - smtpd submission inet n - y - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_tls_auth_only=yes -o smtpd_reject_unlisted_recipient=no -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_relay_restrictions= -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING -o smtpd_sender_restrictions=reject_sender_login_mismatch,permit_sasl_authenticated,reject # -o syslog_name=postfix/submission # -o smtpd_tls_security_level=encrypt systemctl restart postfix
Пробваме да пратим фалшив мейл
swaks --server localhost --from tachko@tachko.com --to tachko@tlan.org --port 587 -tls --auth-user tachko@tlan.org --auth-password Iceman
В mail.log трябва да прочетете нещо такова:
<~* 553 5.7.1 <tachko@my.tachko.com>: Sender address rejected: not owned by user tachko@tachko.com
Вече имаме пълноценен сървър за пощенски услуги. Следват няколко надстройки за ефективност и безопасност на работата му.
Квоти на пощенските кутии
Квотите са ограничения на размера за потребителите. Можете да се уверите, че потребителите не губят произволно количество дисково пространство, а са принудени да почистват стари имейли от време на време. Какво се случва: ● Postfix трябва да отхвърля нови имейли, ако пощенската кутия на потребителя е над квотата. ● Dovecot трябва да следи квотата и колко потребителят вече е изразходвал от нея.
Услуга за квотна политика на Dovecot
nano /etc/dovecot/conf.d/90-quota.conf ### Най-отгоре слагаме следното: plugin { quota = count:User quota quota_vsizes = yes quota_status_success = DUNNO quota_status_nouser = DUNNO quota_status_overquota = "452 4.2.2 Mailbox is full and cannot receive any more emails" } service quota-status { executable = /usr/lib/dovecot/quota-status -p postfix unix_listener /var/spool/postfix/private/quota-status { user = postfix } } systemctl restart dovecot
Postfix ограничения за получатели
postconf smtpd_recipient_restrictions=reject_unauth_destination,"check_policy_service unix:private/quota-status"
Тест
Първо да ограничим размера на пощенската кутия на tachko@tachko.com на 5КВ.
mysql pfdb update virtual_users set quota=4000 where email='tachko@tachko.com'; quit
И самия тест:
swaks --server localhost --to tachko@tachko.com
Повторете изпращането на писма докато напълните кутията. Да си призная доста трябва да повторите операцията. По-лесния вариант е пращате от друг мейл писмо с прикачен файл по-голям от 5КВ. В резултат ще се получи следното съобщение във /var/log/mail.log:
2024-05-04T20:40:50.994052-04:00 ns1 postfix/smtpd[18212]: NOQUEUE: reject: RCPT from unknown[109.160.80.230]: 452 4.2.2 <tachko@tachko.com>: Recipient address rejected: Mailbox is full and cannot receive any more emails; from=<tachko@tachko.com> to=<tachko@tachko.com> proto=ESMTP helo=<mail.tachko.com>
Квотите работят, но потребителите трябва да са предупредени, че са надхвърлили лимита.
nano /etc/dovecot/conf.d/90-quota.conf plugin { quota = count:User quota quota_vsizes = yes quota_status_success = DUNNO quota_status_nouser = DUNNO quota_status_overquota = "452 4.2.2 Mailbox is full and cannot receive any more emails" } service quota-status { executable = /usr/lib/dovecot/quota-status -p postfix unix_listener /var/spool/postfix/private/quota-status { user = postfix } } plugin { quota_warning = storage=95%% quota-warning 95 %u quota_warning2 = storage=80%% quota-warning 80 %u } service quota-warning { executable = script /usr/local/bin/quota-warning.sh unix_listener quota-warning { user = vmail group = vmail mode = 0660 } }
За да работи плъгина се нуждаем от скрипт.
nano /usr/local/bin/quota-warning.sh #!/bin/sh PERCENT=$1 USER=$2 cat << EOF | /usr/lib/dovecot/dovecot-lda -d $USER -o "plugin/quota=maildir:User quota:noenforcing" From: postmaster@ns1.tachko.com Subject: Quota warning - $PERCENT% reached Your mailbox can only store a limited amount of emails. Currently it is $PERCENT% full. If you reach 100% then new emails cannot be stored. Thanks for your understanding. EOF chmod +x /usr/local/bin/quota-warning.sh systemctl restart dovecot
С това приключваме темата квоти.
Антиспам с RSpamd
RSpamd работи по следния начин:
Много пъти съм обяснявал горната картинка. Нас ни вълнува т.4. PostFix като получи писмо го дава на RSpamd за анализ дали е спам. RSpamd анализира писмото и връща отговор на PostFix дали да приеме писмото или да го маркира като спам. Така работи проверката за СПАМ. В случая ползваме RSpamd да проверява, но по същата логика работят и другите антиспам решения. Примерно едно различно такова е SpmaAssasin. RPspamd е по-гъвкав, производителен и по-лесен за интегриране. RSpamd работи като сървис на сървъра и слуша PostFix използвайки milter (mail filter) протокола. Всеки път когато пристигне писмо, PostFix ще го прати до rspamd за проверка на съдържанието. RSpamd ще го анализира, оцени и ако резултата е висок имейла ще се счита за непоискан.
Инсталиране и настройка на RSpamd
apt install -y rspamd redis-server
Инсталирахме: rspamd - антиспам демон redis-server - сървър за съхранение на данните на RSpamd за обучение на спам и хам
PostFix използва RSpamd
Нека накараме PostFix да изпраща всички входящи писма чрез rspamd:
postconf smtpd_milters=inet:127.0.0.1:11332 postconf non_smtpd_milters=inet:127.0.0.1:11332 postconf milter_mail_macros="i {mail_addr} {client_addr} {client_name} {auth_authen}" service postfix restart
PostFix ще се свърже с rspamd, който слуша на TCP порт 11332 на localhost(127.0.0.1). Ще предаде имейла. smtpd_milters определя тази връзка чрез протокола SMTP. non_smtpd_milters setting е опция, която кара PostFix да проверява всички мейли произлизащи от системата. milter_mail_macros дефинира няколко променливи, които rspamd очаква за по-добро откриване на спам. RSPamd след това изпълнява проверките си и казва на PostFix дали мейла трябва да мине или да бъде отхвърлен.
Тестване откриването на спам
За теста ще ползваме спам мейл, който идва със SpamAssassin. Той се нарича GTUBE и съдържа артикулен модел, който се разпознава като спам от SpamAssassin. За тази цел първо ще смъкнем файла от сайта
cd wget http://spamassassin.apache.org/gtube/gtube.txt
Зачистваме логовете
> /var/log/mail.log > /var/log/mail.err
А сега да изпратим този мейл до себе си
sendmail tachko@tachko.com < gtube.txt
И проверяваме мейл лога
cat /var/log/mail.log | grep Gtube 2024-05-15T09:19:50.790258-04:00 ns1 postfix/cleanup[6105]: BE51A140DB1: milter-reject: END-OF-MESSAGE from localhost[127.0.0.1]: 5.7.1 Gtube pattern; from=<root@mail.tachko.com> to=<tachko@tachko.com> 2024-05-15T09:19:50.795763-04:00 ns1 postfix/cleanup[6105]: BE51A140DB1: to=<tachko@tachko.com>, relay=none, delay=0.02, delays=0.02/0/0/0, dsn=5.7.1, status=bounced (Gtube pattern)
5.7.1 Gtube pattern - причина 5.7.1 Gtube модел кара PostFix да отхвърли мейла. Много е важна първата цифра на генерирания код. За пример: - 2 = Успех - 4 = Времене проблем, за повторно връщане - 5 = Постоянен проблем, не опитвай повече В нашия случай кода казва "Провал не пробвай повече" Кодовете може да намерите в RFC 3463 И още една проверка, много е важно, по-късно ще разберете защо.
cat /var/log/rspamd/rspamd.log 2024-05-18 06:58:09 #1800(normal) <ead7f6>; task; rspamd_message_parse: loaded message; id: <GTUBE1.1010101@example.net>; queue-id: <00B05140DB1>; size: 825; checksum: <a69eaeaf775e0f5f91a24c15f1d2a983> 2024-05-18 06:58:09 #1800(normal) <ead7f6>; task; rspamd_check_gtube: gtube reject pattern has been found in part of length 521 2024-05-18 06:58:09 #1800(normal) <ead7f6>; task; rspamd_add_passthrough_result: <GTUBE1.1010101@example.net>: set pre-result to 'reject' (15.00): 'Gtube pattern' from GTUBE(3) 2024-05-18 06:58:09 #1800(normal) <ead7f6>; task; rspamd_task_write_log: id: <GTUBE1.1010101@example.net>, qid: <00B05140DB1>, ip: 127.0.0.1, from: <root@tachko.com>, (default: S (reject): [15.00/15.00] [GTUBE(0.00){}]), len: 825, time: 67.678ms, dns req: 0, digest: <a69eaeaf775e0f5f91a24c15f1d2a983>, rcpts: <tachko@tachko.com>, mime_rcpts: =<recipient@example.net>, forced: reject "Gtube pattern"; score=15.00 (set by GTUBE) 2024-05-18 06:58:09 #1800(normal) <ead7f6>; task; rspamd_protocol_http_reply: regexp statistics: 0 pcre regexps scanned, 0 regexps matched, 172 regexps total, 0 regexps cached, 0B scanned using pcre, 0B scanned total 2024-05-18 06:58:09 #1797(rspamd_proxy) <28cf6f>; proxy; proxy_milter_finish_handler: finished milter connection 2024-05-18 06:58:09 #1797(rspamd_proxy) <7f7eb9>; proxy; proxy_accept_socket: accepted milter connection from 127.0.0.1 port 46412 2024-05-18 06:58:09 #1797(rspamd_proxy) <7f7eb9>; milter; rspamd_milter_process_command: got connection from 185.163.245.186:59330 2024-05-18 06:58:09 #1797(rspamd_proxy) <7f7eb9>; proxy; proxy_milter_finish_handler: finished milter connection
Набързо смятам да поясня, защото надолу ще берете ядове, ако не обърнете внимание на това което ще покажа, а именно етапите през които преминава проверката. set pre-result to 'reject' (15.00) - писмото е отхвърлено защото е набрало от теста 15 точки, по-късно ще поясня. (default: S (reject): [15.00/15.00] - отново имаме 15 от 15 точки и писмото е отхвърлено. 172 regexps total - общо сме събрали 172 точки. Непременно запомнете това число, много е важно. Повечето публични сървъри не от ранга на GMail събират 172 точки. Примерно mail.bg, abv.bg.
Точки за степенуване на спама (score metrics)
RSpamd няма да отхвърли всички спам мейли. Той ще ги изчисли и в зависимост от процента вероятност за спам ще вземе решение. Да разгледаме файла /etc/rspamd/actions.conf
nano /etc/rspamd/actions.conf actions { reject = 15; # Reject when reaching this score add_header = 6; # Add header when reaching this score greylist = 4; # Apply greylisting when reaching this score (will emit `soft> #unknown_weight = 1.0; # Enable if need to set score for all symbols implic> # Each new symbol is added multiplied by gf^N, where N is the number of spa> #grow_factor = 1.1; # Set rewrite subject to this value (%s is replaced by the original subject) #subject = "***SPAM*** %s" .include(try=true; priority=1; duplicate=merge) "$LOCAL_CONFDIR/local.d/act> .include(try=true; priority=10) "$LOCAL_CONFDIR/override.d/actions.conf" }
Това са действия по подразбиране. RSpamd изчислява и оценява. Когато достигне точки: - 15 - отхвъля мейла (както в горния случай на Gtube шаблона) - 6 и нагоре - добавя заглавна линия "X-Spam" - 4 и нагоре - ще задейства greylisting механизма който временно ще отхвърли мейла и ще чака за нов опит. Ако си мислите, че сте открили топлата вода, много се лъжете. Зловредния софтуер ако праща мейла оценен на 4 точки по Gtube, само веднъж ще задейства greylist-ата и успешно ще отхвърли спама, но хакерите правят след няколко минути нов опит и я заобикалят прослоутата greylist-ата. Ако искате да си направите свое точкуване, а не да ползвате това по подразбиране.
nano /etc/rspamd/local.d/actions.conf reject = 150; add_header = 6; greylist = 4;
Това на практика никога няма да отхвърли писмото. Другите две стойности обаче са доста разумни по подразбиране. Лично аз използвам тази настройка през цялото време, така че потребителите да могат да намерят нежелана поща в папката си с нежелана поща , но не трябва да ме питат дали сървърът за електронна поща го е отхвърлил. Внимание!!! reject = 150; - ако съберете повече от 150 точки няма да получите нищо, писмото просто ще бъде отрязано и няма да имате никакво уведомяване. А помните ли какво казах малко по-горе? "Публични сървъри като mail.bg, abv.bg и от този ранг се точкуват с 172 точки." Това значи, че никога няма да получите от тях писмо, даже уведомяване няма да имате, че са пратили писмо. Просто ще се отреже и това е. Извода е, че reject = 175; за да получите писмо от по-малко оторизирани сървъри. По-надолу в тестовете ще се види. Между другото, можете да пратите писмо примерно от mail.bg и ще видите, че нищо няма да пристигне. Когато вдигнете на 175 точки, писмата ще почнат да пристигат. Настройката на rspamd може да се променя в /etc/rspamd/override.d/… и ще промени цели секции, а ако променим в /etc/rspamd/local.d/… ще се променят само части от конфигурацията. За повече информация можете да прегледате Writing Rspamd rules. Каквото и да правите – никога не променяйте файловете /etc/rspamd/* директно, защото софтуерна актуализация ще се опита да ги замени. След всяка промяна в конфигурацията задължително трябва да се рестартира rspamd.
systemctl restart rspamd
Проверка дали rspamd е усвоил конфигурацията си
rspamadm configdump | grep -e add_header -e reject -e greylist soft_reject_on_timeout = false; description = "DMARC reject policy"; add_header = 6; reject = 150; greylist = 4; greylist { action = "soft reject"; "/etc/rspamd/local.d/greylist-whitelist-domains.inc", "/etc/rspamd/local.d/maps.d/greylist-whitelist-domains.inc", reject_message = "Spam message rejected"; discard_on_reject = false; quarantine_on_reject = false;
Конфигурацията може да се тества чрез:
rspamadm configtest syntax OK
Може да проверим и кои процси вървят:
pgrep -a rspam 6373 rspamd: main process 6374 rspamd: rspamd_proxy process (localhost:11332) 6375 rspamd: controller process (localhost:11334) 6376 rspamd: normal process (localhost:11333) 6377 rspamd: normal process (localhost:11333) 6378 rspamd: hs_helper process
Добавяне на заглавие
Както знаете всеки мейл има заглавие и тяло. В заглавието влизат неша като изпращач, получател, дата, час и предмет. По принцип в заглавието има много повече неша. Тези допълнителни заглавия rspamd може да ги добавя като започват с "X-". За тази цел създаваме следния файл:
nano /etc/rspamd/override.d/milter_headers.conf extended_spam_headers = true; systemctl restart rspamd
Това ще добави нови заглавия, които може да видите ТУК. Добавката в заглавието ни е нужна за да можем писмото определено като спам след това да го манипулираме (примерно да се премести в папката Junk).
Прехвърляне на спама в папка Junk
Потребителите нямат за цел постоянно да следят логовете и да гледат кой мейл е спам и кой колко е маркиран. Нормалното състояние е да се влезе в пощата и да види какви писме има, а системата сама да каже кое писмо е спам и да го сложи в папка с рискови/нежалани писма. За целта Dovecot поддръжа sieve филтри
nano /etc/dovecot/conf.d/90-sieve.conf # Identical to sieve_before, only the specified scripts are executed after the # user's script (only when keep is still in effect!). Multiple script # locations can be specified by appending an increasing number. #sieve_after = sieve_after = /etc/dovecot/sieve-after #sieve_after2 = #sieve_after2 = (etc...) systemctl restart dovecot
Така казваме, че sieve филтрите ще ги поместваме в /etc/dovecot/sieve-after Да създадем и директорията за начало
mkdir /etc/dovecot/sieve-after
Сега в тази директория да създадем файл(филтър) spam-to-folder.sieve
nano /etc/dovecot/sieve-after/spam-to-folder.sieve require ["fileinto"]; if header :contains "X-Spam" "Yes" { fileinto "Junk"; stop; }
require - включват функционалност за преместване на имейли в определени папки (fileinto) и за създаване на папки, ако все още не съществуват в (пощенска кутия). Тогава, ако rspamd маркира имейл като спам, той се премества в папката INBOX.Junk, която просто се показва като „Junk“ на потребителя под неговата входяща кутия. Dovecot обаче не разбира така написани файлове. Трябва да се конвертират във вид който може да ги чете. Затова ще компилираме файла.
sievec /etc/dovecot/sieve-after/spam-to-folder.sieve
Това генерира машинно четим файл /etc/dovecot/sieve-after/spam-to-folder.svbin. Рестартираме Dovecot
service dovecot restart
Автоматично изтриване
Анди Олсен посочи, че Dovecot е въвел функция за автоматично изтриване на имейли в папка, които достигат определена възраст. Това е особено полезно за папките „Trash“ и „Junk“.
nano /etc/dovecot/conf.d/15-mailboxes.conf mailbox Junk { special_use = \Junk auto = subscribe autoexpunge = 30d } mailbox Trash { # auto = create special_use = \Trash auto = subscribe autoexpunge = 30d } service dovecot restart
auto = subscribe - гарантира, че папките „Junk“ и „Trash“ се създават автоматично за всеки потребител. В противен случай спам имейлите не могат да бъдат преместени в папката „Junk“ по-късно. И вече ако се пробвате да пращате писма от не високо защитени сървъри писмата Ви ще пристигат в папката Спам. Най-накрая ще кажа как сървъра да изглежда надежден за другите сървъри. Сега да вдигнем прага от 150 точки при които се възприема подателя за сигурен.
nano /etc/rspamd/local.d/actions.conf # reject = 150; reject = 175; add_header = 6; greylist = 4; service rspamd restart
Наново пращаме писмо от не толкова надежден съръвър. Писмата пристигат нормално. Тук искам обаче да уточня нещо. Ако искате висока защита на сървъра си ще се наложи да смъкнете прага при което ще загубите връзка към несигурните сървъри. Лично Ваш избор кое да е.
Относно Redis
Много функции в Rspamd използват Redis, за да запазят своите данни. Redis е вид система от бази данни. Тя е много по-ограничена от традиционната SQL база данни, защото просто съхранява ключове и стойности. Няма няколко полета/колони като в SQL. Но това е светкавично бързо, както работи. На моя стар сървър той обработва около 50 000 заявки в секунда. Получава скорост от своята простота и от запазването на данните в RAM. Така че няма достъп до диска, за да извлече информация. (Но той често копира данните си на диск, за да предотврати загуба на данни.) Хората използват Redis като кеш или за много бързо търсене на прости структури от данни. Както и rspamd . Вие инсталирахте пакета „redis-server“ по-рано. И това е всичко, което трябваше да направите. Той стартира автоматично и прослушва много входящи връзки на TCP порт 6379 на localhost. В Rspamd бекендът на Redis е активиран по подразбиране. Просто трябва да му кажете IP адреса на вашия Redis сървър.
nano /etc/rspamd/override.d/redis.conf servers = "127.0.0.1"; systemctl restart rspamd
Обучение за откриване на спам
Една от характеристиките на rspamd е анализирането на модели на думи с помощта на теория на вероятностите. Тази функционалност се съдържа в неговия „ статистически модул “. (Да, името е доста подвеждащо.) По същество вие показвате на rspamd много хам (добри) и спам (лоши) имейли и тяхното откриване се подобрява с течение на времето. Rspamd препоръчва (и по подразбиране) използването на Redis за съхраняване на данни за обучение за спам. Това е, което ще използваме сега.
Автоматично обучение
Можете да започнете с празна база данни за обучение. Това не е толкова лошо, колкото звучи. rspamd има много повече функционалност, за да определи дали даден имейл е хам или спам. Автоматичното обучение приема имейли, които вероятно са хам или спам, и ги използва за обучение на филтъра за спам. Документацията на rspamd съдържа допълнителни примери за фина настройка на автоматичното обучение. След няколкостотин имейла обучението ще допринесе за по-добър процент на откриване. Ако искате да използвате автоматично обучение, просто създайте нов файл.
nano /etc/rspamd/override.d/classifier-bayes.conf autolearn = [-5, 10];
Това ще обучи имейли със спам резултат по-малък от -5 като (добро). И имейли със спам резултат над 10 като спам (нежелан). Можете да дадете други стойности по желание.
Мигриране на данни за обучение от предишен имейл сървър
Използвали ли сте стария базиран на SQLite обучителен файл на стария сървър? Потърсете файлове като /var/lib/rspamd/*.sqlite на стария сървър. В такъв случай, моля, следвайте тези прости инструкции от документацията на rspamd, за да ги конвертирате в данни в Redis. Ако вместо това вече сте използвали Redis, тогава просто трябва да копирате базата данни на Redis от стария сървър. Спрете Redis на новия сървър. Копирайте /var/lib/redis/dump.rdb от стария сървър на новия сървър. Стартирайте Redis отново. И рестартирайте rspamd.
systemctl stop redis scp root@old-server:/var/lib/redis/dump.rdb /var/lib/redis systemctl start redis systemctl restart rspamd
За да проверите дали това работи, можете да попитате Rspamd с помощта на rspamc stat
rspamc stat Statfile: BAYES_SPAM type: redis; length: 0; free blocks: 0; total blocks: 0; free: 0.00%; learned: 21164; users: 214; languages: 0 Statfile: BAYES_HAM type: redis; length: 0; free blocks: 0; total blocks: 0; free: 0.00%; learned: 1411; users: 62; languages: 0
Обучение от вашите съществуващи радиолюбители и спам имейли
Работили ли сте преди с пощенски сървър с пощенски кутии в структура Malidir , но без rspamd? Тогава вероятно имате голямо количество нормални и спам писма. Нека ги използваме, за да обучим rspamd. Важно е да обучите и имейлите с хам и спам. Командата rspamc ще ви позволи да захранвате цели директории/папки с имейли в учебния процес. Пример за обучение на спам от tachko@tachko.com:
rspamc learn_spam /var/vmail/tachko.com/tachko/Maildir/.Junk/cur
Можете да тренирате за нормални писма на определен потребител, в случая tachko
rspamc learn_ham /var/vmail/tachko.com/tachko/Maildir/cur
Разбира се, качеството на откриването на спам ще зависи от това колко добри са изходните данни. Ако потребителите поставят имейли в своята папка за нежелана поща, които не са типичен спам, те ще замърсят откриването. За да проверим броя на писмата които сме научили:
rspamc stat Statfile: BAYES_SPAM type: redis; length: 0; free blocks: 0; total blocks: 0; free: 0.00%; learned: 21164; users: 214; languages: 0 Statfile: BAYES_HAM type: redis; length: 0; free blocks: 0; total blocks: 0; free: 0.00%; learned: 1411; users: 62; languages: 0
Проверката за спам по метода Bayes няма да работи, преди да научи поне 200 имейла със спам и хам. Преподаването на rspamd на по-малко имейли или само на спам имейли няма да работи. Това се определя от променливата min_learns , дефинирана в /etc/rspamd/statistic.conf.
Обучение за спам за всеки потребител
rspamd ви позволява да тренирате откриването на спам за всеки потребител. Няма да поддържа глобална база данни за обучение, която да се прилага за всички потребители. Вместо това всеки потребител получава собствено обучение. Предимство: потребителите работят по различен начин. Някои са се абонирали за бюлетин за продажби и сега смятат, че отбелязването му като спам ги кара да се отпишат. Да, това е глупаво, но може напълно да обърка откриването на спам. Също така може да се интересувате много от информацията за продукта viagr*, докато други не. Недостатък: обучението все още изисква много радиолюбители и спам съобщения, преди да има ефект. Така че освен ако потребителят не получи 200 проби от добри и зли имейли, откриването на спам не може да работи. Много потребители няма да получат толкова много имейли, така че поради липсата на обучение за спам откриването няма да се подобри. Ако решите, че искате да използвате обучение за спам за всеки потребител, добавете/редактирайте файла /etc/rspamd/local.d/classifier-bayes.conf и вмъкнете:
nano /etc/rspamd/local.d/classifier-bayes.conf users_enabled = true;
Учене от действията на потребителите
Сега стигаме до нещо наистина страхотно. Нека кажем на Dovecot, че преместването на имейли в папката Junk учи незабавно rspamd, че имейлът е спам. И обучете имейл като хам, ако бъде преместен от папката Junk поща. Ще добавим тригери (всъщност „ сито скриптове “) към действието на преместване на имейли през IMAP. Понастоящем препоръчваният начин е вместо това да използвате приставката „ IMAPSieve “. Няма нищо за инсталиране – идва с пакетите Dovecot. Просто трябва да го конфигурираме.
nano /etc/dovecot/conf.d/20-imap.conf protocol imap { # Space separated list of plugins to load (default is global mail_plugins). #mail_plugins = $mail_plugins mail_plugins = $mail_plugins quota imap_sieve # Maximum number of IMAP connections allowed for a user from each IP address. # NOTE: The username is compared case-sensitively. #mail_max_userip_connections = 10 }
Също така трябва да редактираме конфигурацията на Sieve на Dovecot, за да активираме два плъгина, които са необходими за нашата задача. Sieve е скриптов език, който автоматизира нещата във връзка с имейли и папки.
nano /etc/dovecot/conf.d/90-sieve.conf ### Почти накрая: # Enables showing byte code addresses in the trace output, rather than only # the source line numbers. #sieve_trace_addresses = no # From elsewhere to Junk folder imapsieve_mailbox1_name = Junk imapsieve_mailbox1_causes = COPY imapsieve_mailbox1_before = file:/etc/dovecot/sieve/learn-spam.sieve # From Junk folder to elsewhere imapsieve_mailbox2_name = * imapsieve_mailbox2_from = Junk imapsieve_mailbox2_causes = COPY imapsieve_mailbox2_before = file:/etc/dovecot/sieve/learn-ham.sieve sieve_pipe_bin_dir = /etc/dovecot/sieve sieve_global_extensions = +vnd.dovecot.pipe sieve_plugins = sieve_imapsieve sieve_extprograms } service dovecot restart
Първото правило казва на Dovecot да изпълнява правилата на Sieve, както е дефинирано във /etc/dovecot/sieve/learn-spam.sieve файла, когато имейл се премести в папка „Junk“ на потребителя. Ще създадем този скрипт Sieve след минута. Второто правило определя другия начин. Всеки път, когато имейл се премести от папката „Junk“ в произволна (*) папка, /etc/dovecot/sieve/learn-ham.sieveсе извиква скриптът Sieve. sieve_pipe_bin_dir - определя къде е разрешено да се намират изпълними скриптове. Ще поставим нашите прости скриптове за обучение там. sieve_global_extensions - активира плъгина за тръба, който позволява изпращане на имейл до външни команди. След това нека създадем скриптовете Sieve, за които казахме на Dovecot в директория /etc/dovecot/sieve, за да поставим нашите нови файлове.
mkdir /etc/dovecot/sieve nano /etc/dovecot/sieve/learn-spam.sieve ### Sieve за СПАМ писма require ["vnd.dovecot.pipe", "copy", "imapsieve"]; pipe :copy "rspamd-learn-spam.sh"; nano /etc/dovecot/sieve/learn-ham.sieve ### Sieve за HАМ (нормални) писма require ["vnd.dovecot.pipe", "copy", "imapsieve", "variables"]; if string "${mailbox}" "Trash" { stop; } pipe :copy "rspamd-learn-ham.sh";
Горният скрипт Sieve избягва обучението на имейл като хам , ако потребителят го премести в папката Кошче . В края на краищата, ако изчистите папката си с нежелана поща , не искате да обучавате нежеланата си поща като обикновени имейли. Рестартираме Dovecot.
systemctl restart dovecot
Горните два скрипта трябва да бъдат компилирани за да може Dovecot да ги чете.
sievec /etc/dovecot/sieve/learn-spam.sieve sievec /etc/dovecot/sieve/learn-ham.sieve
Това създава два нови файла learn-ham.svbin и learn-spam.svbin, които вътре изглеждат като безсмислици, но вече са във формат, който плъгинът Sieve на Dovecot може да разбере. Нека поправим и разрешенията на тези файлове, докато сме там:
chmod u=rw,go= /etc/dovecot/sieve/learn-{spam,ham}.{sieve,svbin} chown vmail:vmail /etc/dovecot/sieve/learn-{spam,ham}.{sieve,svbin}
И последната стъпка е да създадете прости скриптове на обвивката, които извършват действителното обучение за спам/хам.
nano /etc/dovecot/sieve/rspamd-learn-spam.sh #!/bin/sh exec /usr/bin/rspamc learn_spam
Това изглежда просто, нали? Нищо повече всъщност не е необходимо. Спам имейлът се предава на този скрипт и rspamd го научава като спам имейл и съответно коригира своята база данни за откриване на спам. Вторият скрипт учи хам и се нарича /etc/dovecot/sieve/rspamd-learn-ham.sh.
nano /etc/dovecot/sieve/rspamd-learn-ham.sh #!/bin/sh exec /usr/bin/rspamc learn_ham
Тези два шел скрипта трябва да бъдат направени изпълними:
chmod u=rwx,go= /etc/dovecot/sieve/rspamd-learn-{spam,ham}.sh chown vmail:vmail /etc/dovecot/sieve/rspamd-learn-{spam,ham}.sh
Надявам се, че още не си си загубил ума. Това наистина е просто верига от неща, които трябва да се случат. Нека повторим как работи този процес: ● потребителят премества спам имейл в своята папка „Junk“. ● Dovecot осъзнава, че това задейства правилото на Sieve „imapsieve_mailbox1“, така че извиква скрипта на Sieve /etc/dovecot/sieve/learn-spam.sieve (всъщност *.svbin версията на скрипта) ● Sieve ще вземе имейла и ще го изпрати („препрати“) към изпълнимия шел скрипт rspamd-learn-spam.sh ● скриптът от своя страна изпълнява имейла чрез командата “/usr/bin/rspamc learn_spam” Това работи еднакво и за другия начин или за изучаване на имейли с хам, разбира се. Сигурен съм, че нямате търпение да го изпробвате. За да видите обаче, че наистина работи, ви предлагам да редактирате файла /etc/dovecot/conf.d/10-logging.conf и да зададете „mail_debug=yes“. Това ще добави много повече подробности към файла /var/log/mail.log, но на натоварен сървър може също да доведе до главоболия. 🙂
nano /etc/dovecot/conf.d/10-logging.conf #mail_debug = no mail_debug = yes
Рестартираме Dovecot.
systemctl restart dovecot
Отваряме втори терминал и вътре пишем:
tail -f /var/log/mail.log
През Roundcube преместваме писмо в папката Junk (СПАМ) Във втория терминал трябва да се покажат много неща. И съдържание от рода на:
imapsieve: Static mailbox rule [1]: mailbox=`Junk' from=`*' causes=(COPY) => before=`file:/etc/dovecot/sieve/learn-spam.sieve' after=(none) imapsieve: Static mailbox rule [2]: mailbox=`*' from=`Junk' causes=(COPY) => before=`file:/etc/dovecot/sieve/learn-ham.sieve' after=(none) imapsieve: Matched static mailbox rule [1] sieve: file storage: script: Opened script `learn-spam' from `/etc/dovecot/sieve/learn-spam.sieve' sieve: action pipe: running program: rspamd-learn-spam.sh program exec:/etc/dovecot/sieve/rspamd-learn-spam.sh: Pass environment: USER=john@example.org program exec:/etc/dovecot/sieve/rspamd-learn-spam.sh: Pass environment: HOME=/var/vmail/example.org/john program exec:/etc/dovecot/sieve/rspamd-learn-spam.sh: Pass environment: HOST=narnia Mailbox Junk: UID 1: Opened mail because: mail stream sieve: uid=1: Execute storing into mailbox 'Junk'
Логове
rspamd поддържа подробен регистър на своите действия в /var/log/rspamd/rspamd.log. Ако потребител се оплаче, че определен имейл е бил блокиран или поне маркиран като спам, тогава погледнете този дневник. Можете да сравните /var/log/mail.log с него, като сравните ID на опашката на Postfix. Това са 12-цифрените шестнадесетични числа като „ 95CE05A00547 “. Тези идентификатори могат да бъдат намерени и в rspamd.log:
Уеб интерфейсът
rspamd идва с добра бонус функция: уеб интерфейс. Тя ви позволява да проверявате имейлите за спам, да получавате статистически данни и да прецизирате резултатите. Той вече е инсталиран и активиран по подразбиране и очаква HTTP заявки на порт 11334 на интерфейса localhost. Предлагам ви да добавите проста прокси конфигурация към вашата вече работеща конфигурация за уеб поща с активиран HTTPS, за да получите достъп. Първо трябва да активирате модулите на Apache за HTTP прокси и пренаписване:
a2enmod proxy_http a2enmod rewrite
Можете или да създадете нова конфигурация на виртуален хост, или просто да редактирате /etc/apache2/sites-available/tachko.com-ssl.conf файл. Навсякъде в маркерите VirtualHost добавете:
nano /etc/apache2/sites-available/tachko.com-ssl.conf <VirtualHost *:443> ServerName tachko.com ServerAlias mail.tachko.com tachko.com www.tachko.com DocumentRoot /var/www/tachko.com/ SSLEngine on Include /etc/letsencrypt/options-ssl-apache.conf SSLCertificateFile /etc/letsencrypt/live/tachko.com/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/tachko.com/privkey.pem Header always set Strict-Transport-Security "max-age=31536000" SSLUseStapling on <Location /rspamd> Require all granted </Location> RewriteEngine On RewriteRule ^/rspamd$ /rspamd/ [R,L] RewriteRule ^/rspamd/(.*) http://localhost:11334/$1 [P,L] </VirtualHost> <IfModule mod_ssl.c> SSLStaplingCache shmcb:/var/run/apache2/stapling_cache(128000) </IfModule>
Тази част от конфигурацията ще препраща всички заявки към https://tachko.com/rspamd към localhost:11334 и по този начин ви дава достъп до уеб интерфейса на rspamd. Интерфейса е защитен с парола, която можете да поставите в конфигурационен файл на rspamd. Нека създадем хеш парола:
rspamadm pw Enter passphrase: Iceman $2$ngti745qgtnfybho3ozxu8cdwzydgjdc$zrpouz9mu5syrsrxztboboweuspojfruuff8ky7f7yk7yy84jyyb
Да създадем нов конфигурационен файл.
nano /etc/rspamd/local.d/worker-controller.inc password = "$2$ngti745qgtnfybho3ozxu8cdwzydgjdc$zrpouz9mu5syrsrxztboboweuspojfruuff8ky7f7yk7yy84jyyb" systemctl restart rspamd systemctl restart apache2
ВНИМАНИЕ !!! След като инсталирахме Let's Encrypt's виртуалния сайт /etc/apache2/sites-available/tachko.com-ssl.conf бе деактивиран и бе създаден /etc/apache2/sites-available/tachko.com-le-ssl.conf. Проверете кой е активния файл при Вас. Ако файла е както при мен /etc/apache2/sites-available/tachko.com-le-ssl.conf, то трябва той да се ремонтира:
nano /etc/apache2/sites-available/tachko.com-le-ssl.conf <IfModule mod_ssl.c> SSLStaplingCache shmcb:/var/run/apache2/stapling_cache(128000) <VirtualHost *:443> ServerAdmin tachko@tachko.com ServerName tachko.com ServerAlias mail.tachko.com www.tachko.com DocumentRoot /var/www/tachko.com ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined Include /etc/letsencrypt/options-ssl-apache.conf SSLCertificateFile /etc/letsencrypt/live/tlan.net/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/tlan.net/privkey.pem Header always set Strict-Transport-Security "max-age=31536000" SSLUseStapling on <Location /rspamd> Require all granted </Location> RewriteEngine On RewriteRule ^/rspamd$ /rspamd/ [R,L] RewriteRule ^/rspamd/(.*) http://localhost:11334/$1 [P,L] </VirtualHost> </IfModule>
Ако всичко върви според очакванията, сега трябва да имате достъп до уеб интерфейса на rspamd на https://tachko.com/rspamd.
Въвеждаме паролата Iceman която създадохме по-рано.
Тук ще можете да правите статистика на сървъра и да следите състоянието му. С това приключваме първата част от настройването на RSpamD.
Настройка на DNS записи
Тази тема я подхващам защото все по-често сървърите за електронна поща изискват Вие да имате както прав MX запис на домейна така и реверсивен. Пример: tachko.com MX preference = 10, mail exchanger = mail.tachko.com tachko.com A 185.163.245.186 185.163.245.186 PTR tachko.com Това беше важно уточнение защото оценката на сървъра произтича от много неща и едно от тях е наличието на реверсна зона. Също е необходимо наличието на DKIM, SPF както и DMARK.
Предотвратяване на подправяне с помощта на DKIM
Подправянето на изпращача на имейл е действието на преструване, че контролирате имейл адреса на някой друг. Това е често срещан проблем при фишинга . Измамниците изпращат имейли с адрес на изпращача примерно something@paypal.com и се надяват, че получателят ще падне по него и ще им се довери. Всъщност SMTP не се интересува кой е адреса на изпращача. Много доставчици на пощенски услуги налагат да изпращате имейли само с вашия собствен имейл адрес. Но някои не го правят. А на спамерите и измамниците очевидно не им пука въобще.
Спуфинг случай без DKIM
И така, преди приблизително десет години беше замислен нов метод, който добавяше криптографски подпис към заглавната част на имейла, който получателят можеше да провери, за да провери автентичността на подателя и целостта на имейла. Подписът се създава с помощта на частен ключ, който има само изпращащият имейл сървър. След това може да бъде проверен от получателя чрез изтегляне на съответния публичен ключ от DNS зоната на изпращащия домейн и извършване на проверка на подписа. Това работи много подобно на PGP или S/MIME подписване – само на ниво домейн. Вашият пощенски сървър може автоматично да подписва всички изходящи имейли. Методът, който се използва днес, се нарича Domain Keys Identified Mail – или накратко: DKIM . Да вземем пример. Току-що изпратих имейл от GMail до личния си имейл акаунт на собствения си имейл сървър. Google използва DKIM подписване, така че имейлът получи тази допълнителна заглавка от пощенските сървъри на Google:
Received: by mail-lj1-f180.google.com with SMTP id 38308e7fff4ca-2e242b1df60so13255061fa.1 for <tachko@tachko.com>; Sun, 05 May 2024 04:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714909283; x=1715514083; darn=tachko.com; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=FrAj/Bua85Zw/uU5cXA7aBmqGiCYVacze3wOEZAEyWk=; b=YpSFSyozoHNlmx5Ol75QNjrwqHP10Wg14JdGSgYZJGQoQ2kM3iALyb90U86vFccmDL /zlVmrUZ7yEcu3YDssvDn7BxytdP81zJnEqspVe/ktpXk5Lt4q9nV6pWbN2iYn78tazP mym/seQEg9JUw7uhJwq7k3981iVdUpDlwmeF09YStyR5KY0edfiHW803Pi88LK8iH5B/ WZyVK8U4I/F6A1xh8HSAig4xsMdBUt6upyEzFS7N1l4Q1L2eQxWtrJQFRfzxuZIYTkQ+ Z6y33DKoNgwxmFkmqvVlFpH7V3NYhLiBoA7xQV6dX8jxft2hz4HLGKvKdHPfAmErao/p 1x+A==
Трябва ми публичният DKIM ключ на Google, за да проверя този подпис. Той се съхранява в тяхната DNS зона като TXT запис на „ 20230601._domainkey.google.com“. „ 20230601 “ е ключът за избор, който е споменат в подписа като „s= 20230601 “. Можете да използвате произволен брой ключове, стига да създадете подписите със съвпадащия частен ключ. Частта „_domainkey“ е стандартният поддомейн за DKIM ключове. Така че нека вземем този TXT запис:
dig +short 20230601._domainkey.google.com txt "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4zd3nfUo......................."
Това е публичният ключ, който мога да използвам за проверка на подписа. Автоматизирана проверка може да се извърши с помощта на инструмента „opendkim-testmsg“, както е описано по-късно. Мога да го стартирам и да поставя целия имейл, включително заглавките и тялото в него. Ако не се оплаква със съобщение за грешка, значи подписът е правилен. Звучи добре? Тогава нека приложим това и за нашия имейл домейн.
Създаване на двойка ключове
Както обяснихме по-горе, имате нужда от частен ключ, който ще използва за сървъра за електронна поща, и публичен ключ, който се добавя към DNS зоната. RSpamd вече може да създава DKIM ключове. Има вграден модул за подписване на DKIM, активиран по подразбиране. Ако поставите своя ключов файл в /var/lib/rspamd/dkim/, като използвате определена схема за именуване, той ще го вземе автоматично. Да създадем директория и права върху нея, за да съхраняване на ключове.
mkdir /var/lib/rspamd/dkim chown _rspamd:_rspamd /var/lib/rspamd/dkim
Създаваме двойка ключове:
rspamadm dkim_keygen -d tachko.com -s 2024052301 -----BEGIN PRIVATE KEY----- MIICdgIBADANBgkqhkiG9w0BAQEFAASCAmAwggJcAgEAAoGBALyglRWYmEniONZu..... .....Wvzq5+yMFEFA/w== -----END PRIVATE KEY----- 2024052301._domainkey IN TXT ( "v=DKIM1; k=rsa; " "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8oJUVmJhJ4jjWbk5....." ) ;
-s 2024052301 - това число е произволно и се явява селектор. В случая го създадох на 23 май 2024 год и защото е първия генериран ключ, затова селектора се получи 2024052301. Тук няма твърди изисквания за селектора (избраното число). Селектора може да е дори „dkim“ което на по-късен етап може да спести малко работа, като не се нуждаете от DKIM карти, които определят кой ключ трябва да се използва за всеки домейн. “dkim” е селекторът по подразбиране, ако не използвате карти. Но вероятно някой ден ще искате или ще трябва да смените ключа, така че ви препоръчвам по-скоро да използвате карти, както е обяснено по-долу. Това ви дава повече гъвкавост и е доста лесно за изпълнение. Сега да видим резултата. Първата част е частният ключ. И това включва редовете от „-----BEGIN PRIVATE KEY-----“ до „-----END PRIVATE KEY-----“. Не съм го показал целия защото е много дълъг, а този който ще генерирате ще е друг. Ключа трябва да се пази в тайна и ще се използва само от вашия пощенски сървър за подписване на изходящи писма. Втората част е DNS записът, който трябва да добавите към DNS зоната на вашия домейн. Да започнем с това. А сега да генерираме ключовете във файлове:
rspamadm dkim_keygen -d my.tlan.net -s 2024052301 -k /var/lib/rspamd/dkim/my.tlan.net.2024052301.key | tee -a /var/lib/rspamd/dkim/my.tlan.net.2024052301.pub nano /var/lib/rspamd/dkim/my.tlan.net.2024052301.key -----BEGIN PRIVATE KEY----- MIICdwIBADANBgkqhkiG9w0BAQEFAASCAmEwggJdAgEAAoGBAPaE8jtGiTd40Zur 3uveZxMpE9qRE5JTgTIQNhoTX9QCB9RDzukRG318grkCGgOFttaK5YZeBrFJHYay dCWuHWSO66gWzsTdMiJycF5+jCP3SicX83LXdFh4K3z+yHQd+yxgidTVv4jM8Bx9 6n87SGh/AyTpsAcRYWBZ/rmnKiL1AgMBAAECgYAWUTDQtvEDKZfoPOYAenDgZi6a 8dlQvOiMTLVpJOne+pQU3lKj/N19PcFj2FHckcVcpNRklqyKbjETGaK0KpAUdfOF DheHWgP6bkl419CrN/qCfdlSQ+R9S3T71Lq2a0tKKkEL2cBo96ZZM6QcSZVs+vsc w7aQwl6SXEyNB/TG3QJBAPxOkEfECBn/Qsr2148vpiNzhaUWDo8wVOJbHvY7WbC6 8A4UhUWB5UR6LdjvLYbMXCSE1NgFKV8gsg+jXn1hsccCQQD6ILIU1L1MyPfOUAM7 wVP9GZ63AR0fBrwtQMzDysyWKxK0GBsEbazZvSI1FY54pmVO4ekUwoi9XuV7ouHO yoVjAkA9u287z+/3hGgwRtMZGpx4whQp/0qSqE2skITz1DOutR51I3o0NoMFDSvY jzTBbZEB8motbJ3hw5stjlhZLyUTAkEA34PAHyVMVAVyjAasHQXRy+bNEbQJFeSq 27WARaY/1CGBgTXZTsfDIoAExXMR8XagKTFvW4HLN45Je4Y+StBnCQJBAJ/pfjGg JPN+luS3BigmR1Og9/0OZUKS/ZC1JrXimyilx40KkEZu6ySHgiD4QkvDRiXqBE2X Y6vK4R9qgvaQMEU= -----END PRIVATE KEY----- nano /var/lib/rspamd/dkim/my.tlan.net.2024052301.pub 2024052301._domainkey IN TXT ( "v=DKIM1; k=rsa; " "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQD2hPI7Rok3eNGbq97r3mcTKRPakR......." ) ;
Съдържанието на /var/lib/rspamd/dkim/my.tlan.net.2024052301.pub трябва да се сложи във ващата зона.
Добавяне на DNS запис
Преди да започнете да подписвате имейлите си, трябва да се уверите, че публичният ключ присъства правилно във вашата DNS зона за домейна, от който изпращате имейли. В противен случай получателят няма да може да провери подписа и може неправилно да приеме, че имейлът е подправен. Да създадем TXT записа. Вариант 1. Управляваме DNS-a през WEB. Записа трябва да изглежда:
###=== NAME === 2024052301._domainkey.tachko.com ### Тип запис TXT ###=== TTL === 3600 ###=== Data === p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCZnRcZG5wowV4zTMScc3r3rrx+.....................
Вариант 2. Ползваме собствен BIND - DNS сървър.
nano /etc/bind/tachko.com.db IN NS mail.tachko.com. IN MX 10 mail.tachko.com. IN A 185.163.245.186 ns1 IN A 185.163.245.186 mail IN A 185.163.245.186 www IN A 185.163.245.186 2024052301._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQD2hPI7Ro.............."; service named restart
Ако се сещате файла който генерирахме е малко по различен, а по-точно съдържанието беше в скоби. Тук ползваме само кавички. Просто синтаксиса на BIND е такъв. Не е грешка и ползването на скоби но този начин се актуализира по-бързо от сървърите. Имайте предвид, че низът, който сте получили, съдържа два низа „…“ и още един „…“, които трябва да бъдат обединени в един, за да работят. (Синтаксисът с кавички е предназначен за файл на DNS зона, ако стартирате свой собствен сървър за имена като bind .) Обикновено не трябва да има кавички в данните за записа. В зависимост от вашия интернет доставчик може да отнеме известно време, докато новият запис стане видим в интернет. Можете да използвате dig, за да проверите, че ТХТ записа е активен в зоната.
dig 2024052301._domainkey.tachko.com txt ;; ANSWER SECTION: 2024052301._domainkey.tachko.com. 600 IN TXT "v=DKIM1; k=rsa; " "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8oJUV......................................"
Или:
dig 2024052301._domainkey.tachko.com txt +short "v=DKIM1; k=rsa; " "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8oJUVmJhJ4jjWbk5P....................."
Също така може да проверим и пътя на наследяване.
dig 2024052301._domainkey.tachko.com txt +trace | grep TXT ..... много символи и стигаме до: 2024052301._domainkey.tachko.com. 600 IN TXT "v=DKIM1; k=rsa; " "p=MIGfMA0GCS qGSIb3DQEBAQUAA4GNADCBiQKBgQC8oJUVmJhJ4jjWbk5PEkTc4M2T3+tgfFLXUJz63mKVZ6PjywMnej /Q0QATOhGcNsHudn/Q3j7dI0cDsstOnOnv8fjtuA6D+qmE+DUBs+UezK4uxBDuAWsBMI+pmqg6WFDZ6Z s0tNCTEXFOfajSAg5JiiUvYiFYZoUhYZLaFIWDGwIDAQAB" tachko.com. 600 IN NS mail.tachko.com. ;; Received 383 bytes from 185.163.245.186#53(mail.tachko.com) in 11 ms
Ако всичко което показахме като TXT запис го имате, значи сме готови да активираме DKIM подписване в RSpamd за този домейн.
Активиране на DKIM карти в rspamd
Както е обяснено по-горе, препоръчително е да използвате DKIM карти . Не е нищо изискано. Просто прост файл, определящ кой селектор искате да използвате за определен домейн. rspamd ще приеме, че вашият селектор винаги е „dkim“, освен ако не е указано друго в карта. Ако сте използвали „dkim“, тогава може да имате проблеми, когато по-късно искате да смените ключа си. DNS е бавна система и разпространяването на нов публичен ключ DKIM може да отнеме един ден. Имейлите, подписани с по-нов ключ, може да бъдат отхвърлени, докато DNS записът все още не е известен навсякъде по света. Използването на карти е лесно. Първо трябва да променим настройката selector_map на модула dkim_signing. За да направите това, създайте нов файл /etc/rspamd/local.d/dkim_signing.confи го направете да съдържа само тези два реда:
nano /etc/rspamd/local.d/dkim_signing.conf path = "/var/lib/rspamd/dkim/$domain.$selector.key"; selector_map = "/etc/rspamd/dkim_selectors.map";
Конфигурацията е доста разбираема. rspamd ще потърси съпоставянето на домейн към ключ във файла dkim_selectors.map. Създайте този файл и го накарайте да съдържа този ред:
nano /etc/rspamd/dkim_selectors.map tachko.com 2024052301
rspamd вече знае, че всеки път, когато види изходящ имейл от някой@my.tlan.net, ще получи частния ключ DKIM от /var/lib/rspamd/dkim/my.tlan.net.2024052301.key за да подпишете писмото. Презареждаме конфигурацията:
systemctl restart rspamd
Този метод работи добре, ако имате само няколко домейна, които практически никога не се променят. Ако предпочитате да обслужвате произволни потребителски домейни, трябва да обмислите поставянето на ключовете в база данни на Redis, както е описано в документацията . Все още няма начин за управление на DKIM ключове в база данни като MySQL.
Добавяне на ключа на домейна към rspamd
Вземете частния ключ, който е създаден по-рано (многоредовия низ, включително „ …BEGIN PRIVATE KEY…“ и „ …END PRIVATE KEY…“) и го поставете във файл на мястото, където rspamd ще го търси:
nano /var/lib/rspamd/dkim/tachko.com.2024052301.key -----BEGIN PRIVATE KEY----- MIICdgIBADANBgkqhkiG9w0BAQEFAASCAmAwggJcAgEAAoGBALyglRWYmEn..... ................................................................ .....wqEh1b53Ra794vy1KioicYWRiQzKOk/D2VxAOGoLjwVHg6dt17SAwrQdoR4 Wvzq5+yMFEFA/w== -----END PRIVATE KEY-----
Името на файла трябва да бъде във вида {DOMAIN}.{SELECTOR}.{key}. Ако именувате файла неправилно, ще получите грешка във вашия файл rspamd.log като “lua_dkim_sign_handler: cannot load dkim key /var/lib/rspamd/dkim/my.tlan.net.dkim.key“. Уверете се, че само _rspamd може да го прочете:
chown _rspamd /var/lib/rspamd/dkim/* chmod u=r,go= /var/lib/rspamd/dkim/*
rspamd автоматично ще вземе файловете и не е необходимо да се рестартира.
Изпратете тестов имейл
Да изпратим тестово писмо от tachko@tachko.com до tachko@mail.bg. И да проверим заглавната част на писмото:
Return-Path: <tachko@tachko.com> Delivered-To: tachkot@mail.bg Received: from mx3.mail.bg ([10.0.0.119]) by stor6 with LMTP id sFFLEvm5WGaQ3AAAo7j+FQ (envelope-from <tachko@tachko.com>) for <tachkot@mail.bg>; Thu, 30 May 2024 20:40:09 +0300 Received-SPF: pass (tachko.com: 109.160.80.230 is authorized to use 'tachko@tachko.com' in 'mfrom' identity (mechanism 'ip4:109.160.80.230' matched)) receiver=mx3.mail.bg; identity=mailfrom; envelope-from="tachko@tachko.com"; helo=mail.tachko.com; client-ip=109.160.80.230 Authentication-Results: mx3.mail.bg; dkim=pass (1024-bit key) header.i=@tachko.com; dkim-adsp=none Received: from mail.tachko.com (unknown [109.160.80.230]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx3.mail.bg (Postfix) with ESMTPS id 0BC4C4114E57 for <tachkot@mail.bg>; Thu, 30 May 2024 20:40:08 +0300 (EEST) Received: from tachko.com (unknown [109.160.80.230]) by mail.tachko.com (Postfix) with ESMTPSA id 67DC4881A75 for <tachkot@mail.bg>; Thu, 30 May 2024 20:40:04 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tachko.com; s=2024052301; t=1717090804; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=QIbV4Cc9SPJYhStCKqEYkBnrucoH7okk/IaU+x6Kpv0=; b=JlooV66rdvQVbV0CxiZIldLaFiYy51wUPL9XrfplI7H26HjgMZgj2yTmZ++xCCAgtyVr71 kOtgeVilmFb1nrx3EeWQ2Bfiywv2tMdPAp+3O5sNgABNF5H64CxuJIjc9AjeBEA7tR1u5S O60lQE+J0KvvkyzNde1rEhU+YLOeq5s= MIME-Version: 1.0 Date: Thu, 30 May 2024 20:40:03 +0300 From: tachko@tachko.com To: tachkot@mail.bg Subject: test asd Message-ID: <b71cfb3e0a79c85125debee3345b4f79@tachko.com> X-Sender: tachko@tachko.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit
За да проверите подписа, инсталирайте пакета opendkim-tools
apt install opendkim-tools
Копирайте целия тестов имейл (включително заглавките и тялото), стартирайте opendkim-testmsg във вашата обвивка и поставете имейла (завършете с CTRL-D). Ако не получите резултат, тогава подписът е проверен правилно. Но ако получите нещо като „opendkim-testmsg: dkim_eom(): Unable to verify“, тогава проверете своя DNS запис. Можете също да използвате уебсайтове като dkimvalidator.com, isnotspam.com или услугата mail-tester.com, за да проверите дали вашите подписи работят добре.
SPF и DMARC
Добавянето на DKIM подписи е добра първа стъпка. Но можете да продължите, като кажете на получаващите пощенски сървъри, че не трябва да приемат никакви имейли от вашия домейн без валиден подпис или от сървъри, които не управлявате. Има две концепции, които могат да помогнат. По-старият SPF и по-новият DMARC . Всяко от тях означава създаване на машинночетим низ в предварително дефиниран формат и добавяне на TXT запис към вашата DNS зона. Получаващият пощенски сървър може да провери тези записи и да вземе съвета ви (като собственик на домейн) какво да направите, ако критериите на имейла не са изпълнени. Той може да приеме имейла така или иначе или да го маркира като спам или да го отхвърли напълно.
SPF
Вариант 1:
###=== NAME === tachko.com ### Тип запис TXT ###=== TTL === 3600 ###=== Data === v=spf1 ip4:109.160.80.230 mx ~all
Вариант 2:
nano /etc/bind/tachko.com.db IN A 185.163.245.186 ns1 IN A 185.163.245.186 mail IN A 185.163.245.186 www IN A 185.163.245.186 2024052301._domainkey IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQD2..................."; tachko.com. IN TXT "v=spf1 ip4:185.163.245.186 mx ~all"
● v=spf1 - това е SPF запис на версия 1 на стандарта (в момента няма друга версия) ● ip4:185.163.245.186 - моля, приемайте имейли от IP адрес 185.163.245.186 ● mx ~all - алтернативно приемайте имейли от всеки сървър, който е споменат в MX записа на нашия домейн (сървърът(ите), които получават имейли за вашия домейн) всеки друг имейл трябва да се счита за подозрителен - може да е спам или по-лошо. Има WEB сайтове като SPFwizard, които ви помагат да създадете своя SPF низ, който да добавите към вашия DNS домейн. Трябва да знаете кои пощенски сървъри изпращат имейли от вашия домейн. Не забравяйте да включите пощенски списък или услуги за бюлетин, които изпращат от ваше име. Започнете с „~all“, за да маркирате имейли като спам, които не отговарят на критериите. Ако всичко върви добре, превключете на „-all“ след няколко седмици, ако желаете. Имайте предвид, че препращането на имейли от вашия домейн може да наруши SPF, тъй като внезапно изглежда, че имейлът идва от IP адрес, който не е оторизиран. Това е често срещан проблем за пощенските списъци и постепенно се коригира чрез повторно изпращане на имейла от домейна на услугата за пощенски списъци.
DMARC
Споменах, че DMARC е по-новият стандарт. Така че защо все пак да използвате SPF? Тъй като някои доставчици на имейл оценяват усилията ви, ако използвате и SPF. Технически е достатъчно да посочите DMARC запис. Според мен ограничаването на разрешените за изпращане IP адреси е малко опасно и малко негъвкаво. Много по-интересно е да изисквате имейлите от вашия домейн да имат валиден DKIM подпис. Такъв запис може да изглежда така:
"v=DMARC1; p=reject; adkim=s; ruf=postmaster@tachko.com"
За да създадете правилен запис в DMARC, ви предлагам да използвате един от уеб сайтовете. https://www.kitterman.com, https://dmarcian.com, https://www.zerobounce.net и https://www.agari.com/.
Използвана литература: https://workaround.org/ispmail-bookworm/
Если вы делаете рассылки, вам нужно прописать DMARC так, чтобы вы получали отчёт об отправках. Политику лучше указать none, так как вы пока не знаете, какие еще письма отправляются с вашего домена. Если вы поставите quarantine, можете отправить хорошие, но неправильно настроенные письма в «Спам». "v=DMARC1; p=none; sp=none; rua=mailto:postmaster@domain.tld" Это один из самых популярных вариантов записи. Тег «rua» с адресом означает, что на эту почту будет приходить отчёт. Упростить чтение отчётов можно с помощью сервиса Uriports. https://www.unisender.com/ru/blog/putevoditel-po-dmarc-chto-eto-zachem-nuzhno-i-kak-propisat/ Часто используемые записи DMARC Чтобы вам не ломать голову, приведем ниже четыре самые распространенные DMARC-записи: v=DMARC1;p=none Самая простая DMARC-запись. По сути, она не призывает сервер получателя ни к каким действиям по отношению к неаутентифицированным письмам. Мы рекомендуем её внести, чтобы проверить, что всё работает исправно. v=DMARC1;p=none;rua=mailto:postmaster@yourdomain.com Показывает получателю, что не надо отклонять никаких писем, но вам на указанный адрес будет отправляться письмо. В письме — агрегированный отчёт об отправленных письмах и серверах, откуда они ушли. Такая запись нужна, если вы хотите увидеть, идёт ли от вас нежелательный трафик. Ещё это промежуточный вариант перед включением политики reject (полного отклонения неаутентифицированных сообщений). v=DMARC1;p=quarantine;rua=mailto:postmaster@yourdomain.com Вариант-середнячок, один из самых распространённых. Письма, которые не аутентифицированы, будут помечаться вашим почтовым сервисом как спам или как нежелательные (зависит от сервиса). v=DMARC1;p=reject;pct=25;rua=mailto:postmaster@yourdomain.com Это уже строгая политика DMARC относительно неаутентифицированных сообщений. Мы рекомендуем вам постепенно наращивать процент отклонения таких писем: начиная с 25%, понемногу переходить к 100%. Например, когда мы в UniSender вводили DMARC, мы перешли на 100% за полтора месяца. Ниже описываю синтаксис и значение тэгов.