A cél létrehozni egy olyan mail szervert, ami az alábbi összetevőkből áll:
- Frontend Roundcube Webmail
- SSL Certbot
- MTA Postfix
- MDA/LDA Dovecot Imap
- Dovecot ManageSieve Server
- Backend SQL
- Spamassasin
- Amavis
- Clamav
- Content filterek
- DKIM
- DMARC
- SPF
- Tesztelés
Bevezetés
Didaktikai okból úgy tervezem bemutatni a feladatot, hogy az időnként hibára fusson. Szándékom bevezetni az olvasót ezzel a hibák feltárásába, a logfájlok megismerésébe és értelmezésébe. Elnézést azoktól akik haladóbbak, bár a leírás nekik is segítség lehet (ahogy nekem is az lesz, mert ritkán csinálok ilyet). A cél az, hogy ez a leírás bárkinek érthető legyen (és nekem is majd évek múlva). Az ok amiért e leírás készül, hogy dokumentáljam magamnak a lépéseket (mivel ritkán állítok be mail szervert). Továbbá fáj a szívem amiatt, hogy egyre kevesebben veszik a fáradságot saját levelező szerver létrehozására. Jó móka, sok munka, még több tanulás mire összeáll a dolog. Saját levelező szervert nem ad készen az Ubuntu, azt neked kell összerakni, különböző szolgáltatások összedrótozásával. Nem mindenkinek való a feladat, nekik találta fel Isten a gmailt, az outlookot. 🙂
Azokat, akik belebuktak egy mailserver elkészítésébe, teljesen megértem. Nem triviális feladat. Számos buktató és nehezen érthető hiba keletkezik menet közben, amivel meg kell küzdeni. Igazi odüsszeuszi utazás ez, aminek a vége az, hogy dagadni fog a mell a büszkeségtől, útközben pedig feltárul előtted az, amiért anno sokakat megragadott a Linux. Az az erősség, ahogy a részekből létrejön az egész, ahogyan megépítesz valamit. Olyan ez az egész, mintha legóznál. Csak annyival jobb, hogy utána „magától” fog működni, teszi a dolgát és te uralni fogod. Sok régi Linuxos, akik nem tanulnak új terméket/technológiát ebben a varázslatban maradtak, amit teljesen megértek. Ők nem kíváncsiak termékekre, mert maga a technológia érdekes számukra. Amikor megismertem a Linuxot huszonéves fejjel, pont olyan varázslatban éltem, mint 4 évesen az első legóautómtól vagy kicsit később a C64-től. Ez a varázslat nálam több, mint 25 éve tart. Remélem, mire ezen leíráson átküzdöd magad, addigra ez az érzés neked is a sajátod lesz, ha még nem az. Ehhez szinte biztos, hogy egy-egy résztémához további ismereteket kell szerezned. De hajrá! Ígérem a leírás végére érezni fogod, hogy a tudás hatalom és te rendelkezel vele.
Ha el akarsz kerülni pár buktatót, amit ez a leírás didaktikai okból tartalmaz, akkor javaslom először olvasd végig, majd utána kezdj neki. Ilyen buktató az is, hogy a Roundcube default db-nek más nevet adtam meg, így a konfig fájlban ezt át kellett írnom. Van aki ezt hibának látja, van aki előnynek.
Az semmiképpen ne szegje kedved, hogy ebben a leírásban SQL a backend. Mire ennek a dokumentumnak a végére érsz már tetszőleges backended lehet, mert érteni fogsz hozzá annyira, hogy az már ne legyen kihívás.
Kezdjünk neki!
Linuxon egy komplett levelezési rendszert menedzselni, olyan mint irányítani egy focicsapatot. Különböző tudású és funkciójú játékosok csapatjátéka az egész. Ha érteni akarsz hozzá, akkor nem egy alkalmazást telepítesz fel, ami megold helyetted mindent, hanem magad építed meg az egész rendszert. Mi most ezt fogjuk tenni. Nem lesz könnyű dolgod elsőre, de ne aggódj! Idővel kitisztul majd minden.
Kezdjük egy webes kliens telepítésével, hogy legyen mivel tesztelnünk. Választásom a Roundcube.
Először a környezetet telepítsük fel:
oregon@mailserver:/$ sudo apt install apache2 php php-imap php-mbstring php-mysql php-intl php-zip mariadb-serverEzt követően az SQL szerveren beállítjuk a root jelszavát:
oregon@mailserver:/$ sudo mysql_secure_installationLépjünk be az SQL szerverünkre:
oregon@mailserver:/$ mysql -uroot -prootjelszavaHozzunk létre egy felhasználót és egy adatbázist a Roundcube számára, majd töltessük újra a jogokat az SQL szerverünkkel:
CREATE USER roundcube@'localhost' IDENTIFIED BY 'roundpassword';
CREATE DATABASE roundcube;
GRANT ALL privileges ON roundcube.* TO 'roundcube'@'localhost' identified by 'roundpassword';
FLUSH privileges;
exit <ENTER>Teszteljük az új felhasználónkat authentikációval:
oregon@mailserver:/$ mysql -uroundcube -proundpassword
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 44
Server version: 10.6.12-MariaDB-0ubuntu0.22.04.1 Ubuntu 22.04
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]>USE roundcube;
Database changed
MariaDB [roundcube]>exit
ByeEddig minden rendben. Van felhasználónk és adatbázisunk, a kapcsolat is működik.
A korábbi telepítések miatt indítsuk újra az Apache webszervert (mivel lehet nálad már fent volt):
oregon@mailserver:/$ sudo systemctl restart apache2.serviceEzen a VPS-en nekem nem lesz más csak mail, így az Apache webroot könyvtárába telepítettem a Roundcube-ot. Az aktuális verziót leszedtem a https://roundcube.net/download/ oldalról wgettel a home könyvtáramba, majd kicsomagoltam /var/www/html alá. Tegyél te is így, vagy ahogy jónak látod.
Szokásom teszteléskor / hibakereséskor az Apache log-ot figyelni, hogy lássam mit kell majd beállítanom, miközben egy böngészőben megnyitom az IP címet / Roundcube url-t:
oregon@mailserver:/$ tail -f /var/log/apache2/error.log
[Thu Apr 27 18:14:24.055510 2023] [php:warn] [pid 10324] [client 192.168.125.1:57546] PHP Warning: file_put_contents(/var/www/html/logs/errors.log): Failed to open stream: Permission denied in /var/www/html/program/lib/Roundcube/rcube.php on line 1380
[Thu Apr 27 18:14:24.055712 2023] [php:warn] [pid 10324] [client 192.168.125.1:57546] PHP Warning: SQLSTATE[HY000] [1045] Access denied for user 'roundcube'@'localhost' (using password: NO) in /var/www/html/program/lib/Roundcube/rcube.php on line 1503A hibaüzenetben látható, hogy a /var/www/html/logs alatt nem elégéségesek a jogok. Érdemes átadni ezt a könyvtárat a www-data usernek és csoportnak rekurzívan.
oregon@mailserver:/$ sudo chown www-data:www-data -R /var/www/html/logs/Most töltsük újra az oldalt és nézzük meg, mi még a gond. Mivel az előbb adtunk jogot a Roundcube saját logs könyvtárára, emiatt innentől már ebben a könyvtárban kell figyelnünk az error logot.
oregon@mailserver:/$ tail -f /var/www/html/logs/errors.log
[27-Apr-2023 18:19:51 +0000]: <go674cq5> DB Error: SQLSTATE[HY000] [1045] Access denied for user 'roundcube'@'localhost' (using password: NO) in /var/www/html/program/lib/Roundcube/rcube_db.php on line 201 (GET /)Azt láthatjuk, hogy nem tud csatlakozni az adatbázishoz. Ennek az oka, hogy nincs megadva jelszó. Adjuk meg! Másoljuk át a config sample-t és szerkesszük:
oregon@mailserver:/$ cd /var/www/html/config/
oregon@mailserver:/$ sudo cp config.inc.php.sample config.inc.php
oregon@mailserver:/$ sudo mcedit config.inc.phpSzerkesztésnél az adatbázis nevet is át kell írni, mert roundcubemail-t keres és én korábban roundcube-ot adtam meg. Ezt követően frissítsük az oldalt, ekkor egy újabb hibaüzenet érkezik a logba:
oregon@mailserver:/$ tail -f /var/www/html/logs/errors.log
27-Apr-2023 18:26:25 +0000]: <go674cq5> DB Error: [1146] Table 'roundcube.session' doesn't exist (SQL Query: SELECT `vars`, `ip`, `changed`, now() AS ts, CASE WHEN `changed` < now() - INTERVAL 600 SECOND THEN 1 ELSE 0 END AS expired FROM `session` WHERE `sess_id` = 'go674cq5ldqm5bn9sfthtd3ukk') in /var/www/html/program/lib/Roundcube/rcube_db.php on line 567 (GET /)Az adatbázis létezik, de nincs benne semmi. Akkor importáljuk be Roundcube SQL dumpot:
oregon@mailserver:/$ mysql -uroundcube -proundpassword roundcube < /var/www/html/SQL/mysql.initial.sqlFuttassuk a böngészőt is figyeljük a logot:
oregon@mailserver:/$ tail -f /var/www/html/logs/errors.log
[27-Apr-2023 18:29:24 UTC] PHP Fatal error: Uncaught Error: Class "DOMDocument" not found in /var/www/html/program/lib/Roundcube/html.php:367
Stack trace:
#0 /var/www/html/program/include/rcmail_output_html.php(1113): html::parse_attrib_string()
#1 /var/www/html/program/include/rcmail_output_html.php(824): rcmail_output_html->parse_conditions()
#2 /var/www/html/program/include/rcmail_output_html.php(654): rcmail_output_html->parse()
#3 /var/www/html/index.php(265): rcmail_output_html->send()
#4 {main}
thrown in /var/www/html/program/lib/Roundcube/html.php on line 367Egy újabb fatális hiba a DOMDocument-ben, amit nem talál a rendszer. Orvosoljuk:
oregon@mailserver:/$ sudo apt install php-xml
oregon@mailserver:/$ sudo systemctl restart apache2.serviceFrissítve az oldalt ezt kapjuk:
Wow! Hibaüzenet a logban nincs. Beírva a rendszerfelhasználónkat és a jelszavunkat már a logban meg is kapjuk az újabb hibaüzenetet:
oregon@mailserver:/$ tail -f /var/www/html/logs/errors.log
[27-Apr-2023 18:43:24 +0000]: <go674cq5> IMAP Error: Login failed for oregon against localhost from 192.168.125.1. Could not connect to localhost:143: Connection refused in /var/www/html/program/lib/Roundcube/rcube_imap.php on line 211 (POST /?_task=login&_action=login)Ó igen. Nincs még IMAP kiszolgálónk. Telepítsük a dovecot-imapd csomagot:
oregon@mailserver:/$ sudo apt install dovecot-imapdÉn felszoktam rakni az nmap-ot is, ami egy portscanner. Vele gyorsabb tudom ellenőrizni a portokat.
oregon@mailserver:/$ sudo apt install nmap
oregon@mailserver:/$ sudo nmap localhost
Starting Nmap 7.80 ( https://nmap.org ) at 2023-04-27 18:46 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000050s latency).
Not shown: 995 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
143/tcp open imap
993/tcp open imaps
3306/tcp open mysql
Nmap done: 1 IP address (1 host up) scanned in 0.11 secondsSokan szentségtörésnek tartják felrakni a szerverre egy ilyen eszközt, mint az nmap. Ezt azzal magyarázzák, nehogy már tool-t adjuk egy behatoló számára. Rég hallottam ezt az érvet, már akkor sem értettem. Nem mindegy, ha már bent van? Megoldja másként. Ha már root, akkor az nmap futtatása előtt, fel tudja telepíteni magának. Vagy használhat mást is a helyi portok felderítésére:
Például az ss parancs segítségével (1):
oregon@mailserver:/$ ss -tulpn
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp UNCONN 0 0 127.0.0.53%lo:53 0.0.0.0:*
tcp LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:*
tcp LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
tcp LISTEN 0 100 0.0.0.0:993 0.0.0.0:*
tcp LISTEN 0 80 127.0.0.1:3306 0.0.0.0:*
tcp LISTEN 0 100 0.0.0.0:143 0.0.0.0:*
tcp LISTEN 0 128 [::]:22 [::]:*
tcp LISTEN 0 100 [::]:993 [::]:*
tcp LISTEN 0 100 [::]:143 [::]:*
tcp LISTEN 0 511 *:80 *:*Például az lsof segítségével (2):
oregon@mailserver:/$ sudo lsof -i -P -n | grep LISTEN
systemd-r 745 systemd-resolve 14u IPv4 13017 0t0 TCP 127.0.0.53:53 (LISTEN)
sshd 816 root 3u IPv4 21848 0t0 TCP *:22 (LISTEN)
sshd 816 root 4u IPv6 21850 0t0 TCP *:22 (LISTEN)
mariadbd 10127 mysql 20u IPv4 42672 0t0 TCP 127.0.0.1:3306 (LISTEN)
apache2 13377 root 4u IPv6 59032 0t0 TCP *:80 (LISTEN)
apache2 13378 www-data 4u IPv6 59032 0t0 TCP *:80 (LISTEN)
apache2 13379 www-data 4u IPv6 59032 0t0 TCP *:80 (LISTEN)
apache2 13380 www-data 4u IPv6 59032 0t0 TCP *:80 (LISTEN)
apache2 13381 www-data 4u IPv6 59032 0t0 TCP *:80 (LISTEN)
apache2 13382 www-data 4u IPv6 59032 0t0 TCP *:80 (LISTEN)
apache2 13390 www-data 4u IPv6 59032 0t0 TCP *:80 (LISTEN)
dovecot 16672 root 33u IPv4 68739 0t0 TCP *:143 (LISTEN)
dovecot 16672 root 34u IPv6 68740 0t0 TCP *:143 (LISTEN)
dovecot 16672 root 35u IPv4 68741 0t0 TCP *:993 (LISTEN)
dovecot 16672 root 36u IPv6 68742 0t0 TCP *:993 (LISTEN)Szóval ne féljünk az nmap-tól. A behatoló biztosan fel tudja tenni magának, nyugodtan lehetünk vele előzékenyek. 🙂
Közben kiderül, hogy a 143 és a 993-as portunk nyitva, így van imapunk is. Ezt követően már beenged minket a Roundcube a 143-as porton. Az authentikációt ugyanis a Dovecot végzi.
Tesztelni nem tudjuk még a webkliensünket, mert a @localhost-ra (.tld nélküli címre) nem enged a roundcube levelet küldeni alapból. További nehézség, hogy nincs felrakva MTA (postfix, exim, etc…). Pótoljuk ezt a hiányosságot és rakjuk fel a postfixet és mailutils-t a parancssori levélküldéshez.
oregon@mailserver:/$ sudo apt install mailutils postfixMost már tudunk parancssorból levelet küldeni. Próbáljuk ki!
oregon@mailserver:/$ echo "Levél törzse" | mail -s "Subject" oregon@localhostA levélnek egyből meg kellett érkeznie a postaládádba, amit a Roundcube-ban ellenőrizz le. Ha mindent úgy csináltál, ahogy írtam, akkor a saját leveledet olvashatod a Roundcube felületén. Ha ez nem sikerült, akkor keresd meg hibát mielőtt folytatnád ezt a leírást.
Az elküldött levelet a 25-ös porton fogadta a szerver. Ezen a porton a Postfix alapértelmezetten, authentikáció nélkül csak azokat a leveleket fogadja, amelyek a te gépeden vagy felügyeleted alatt vannak. Minden mást elutasít és nem küldi tovább. Ha mindent elfogadna és tovább küldene azt hívnánk openrelay-nek. A spammerek maximum pár óra alatt megtalálnák a gépedet és ontanák róla a szemetet.
Vissza a Roundcube-hoz. Keressük meg miért nem tudunk levelet küldeni. Nézzünk bele a /var/www/html/config/config.inc.php állományban, ahol keressük meg az alábbi részt:
// SMTP server host (for sending mails).
// See defaults.inc.php for the option description.
$config['smtp_host'] = 'localhost:587';Mint láthatjuk az 587-es portra akar a kliensünk küldeni levelet, de nekünk ott nincs semmilyen szolgáltatásunk. Első körben engedélyezzük. Ezt az /etc/postfix/master.cf fájlban tehetjük meg, az alábbi két sorban az első # eltávolításával.
Figyelem! Ez nem a végleges konfig, mert a korlátozásokat (restrictions) még nem aktiváltuk benne:
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=$mua_client_restrictions
# -o smtpd_helo_restrictions=$mua_helo_restrictions
# -o smtpd_sender_restrictions=$mua_sender_restrictions
# -o smtpd_recipient_restrictions=
# -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
# -o milter_macro_daemon_name=ORIGINATINGIndítsuk újra a postfixet.
oregon@mailserver:/$ sudo systemctl restart postfixEllenőrizzük a submission portját:
oregon@mailserver:/$ sudo nmap -p 587 localhost
tarting Nmap 7.80 ( https://nmap.org ) at 2023-04-30 05:22 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00012s latency).
PORT STATE SERVICE
587/tcp open submission
Nmap done: 1 IP address (1 host up) scanned in 0.09 secondsSzuper. Bár levelet még mindig nem tudunk küldeni, mert még be kell állítani az authentikáció módját. A Postfix önmagában nem tud authentikálni. Erre ő egy másik service szolgáltatásasit veszi igénybe, ami esetünkben a saslauthd. Megoldható például az is, hogy Dovecot tokent-használjon. Ekkor levél küldés előtt a Dovecot letesz egy tokent, amit a Postfix tud olvasni és így engedélyezi a levélküldést. (Erről bővebben majd később írok.) A lényeg az, hogy a Postfixnek segítség kell ehhez.
Postfixnak meg kell mondani ki fog authentikálni. Így mielőtt elfelejtenénk az alábbi állományt hozzuk létre, az alább látható tartalommal: /etc/postfix/sasl/smtpd.conf
pwcheck_method: saslauthd
mech_list: PLAIN LOGINTelepítsük a sasl2-bin csomagot, ebben van a saslauth démon, ami különböző authentikációkat kezel egyidejűleg:
oregon@mailserver:/$ sudo apt install sasl2-binKövetkező lépésként symlinkkel kell helyettesítenünk a sasl munkakönyvtárát. Ennek az oka, hogy a Postfix chroot környezetben fut. Abba bele tudunk menni link által, onnan ki jönni meg nem. A cél, hogy a Postfix elérje a saslauthd állományokat. Ezért, mielőtt elindítanánk a saslauthd-t:
oregon@mailserver:/$ sudo rm -rf /var/run/saslauthd/
oregon@mailserver:/$ sudo ln -s /var/spool/postfix/var/run/saslauthd /var/run/saslauthdHa most tesztelnénk a rendszert hibaüzeneteket kapnánk. Csináljuk meg ezt a tesztet csak azért, hogy tudjuk mi, miért van.
# service elindítása
oregon@mailserver:/$ sudo systemctl start saslauthd.service
# user teszt
oregon@mailserver:/$ testsaslauthd -u oregon -p oregon_password
connect() : Permission denied
# user teszt sudo-val
oregon@mailserver:/$ sudo testsaslauthd -u oregon -p oregon_password
connect() : No such file or directoryElég nehéz hozzáférni egy olyan könyvtárhoz ami nem is létezik. Orvosoljuk ezt és még néhány problémát az /etc/default/saslauthd fájban:
# Example: MECHANISMS="pam"
MECHANISMS="pam rimap shadow"A pam az default (lásd Example:), a rimap igazából majd a Dovecot imap szerverünk lesz, a shadow pedig a rendszerünk valós felhasználói, lásd /etc/passwd.
Az /etc/default/saslauthd fáj végén még szerkesszük az alábbiakat:
#OPTIONS="-c -m /var/run/saslauthd"
OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"
PARAMS="-m ${PWDIR}"
PIDFILE="${PWDIR}/saslauthd.pid"Most jöhet a service engedélyezése és indítása vagy újraindítása. Az egyik megoldás, hogy az /etc/default/saslauthd fájl elejére bevarázsolod az alábbit (22.04 alatt nekem már nem volt ott a default konfigban):
# Should saslauthd run automatically on startup? (default: no)
START=yesA másik lehetőség meg ez:
oregon@mailserver:/$ sudo systemctl enable saslauthd.serviceIndítsuk újra a service-t:
oregon@mailserver:/$ sudo systemctl restart saslauthd.serviceTeszteljük amit csináltunk:
oregon@mailserver:/$ testsaslauthd -u oregon -p oregon_password
connect() : Permission denied
0:
oregon@mailserver:/$ sudo testsaslauthd -u oregon -p oregon_password
0: OK "Success."Amiatt most ne aggódjunk, hogy userként nem megy az authentikáció. A sasl szolgáltatást, más szolgáltatások fogják használni, akikkel viszont közös csoportban kell lenniük. Ha belegondolunk, mit szeretnénk magunkon authentikálni saját magunk számára? Semmit. Na ugye! Viszont, ha egy kifelé publikált szolgáltatás a mi nevünkben futna, akkor meg kellene oldanunk ezt a problémát.
Indítsuk újra a postfix-et:
oregon@mailserver:/$ sudo systemctl restart postfixEgy dolgot még nem tettünk meg. A Postfix nincs benne a sasl csoportban. Ellenőrizzük:
oregon@mailserver:/$ id postfix
uid=117(postfix) gid=123(postfix) groups=123(postfix)Igazunk lett. Vegyük fel a Postfixet a sasl csoportba és indítsuk újra a Postfixet.
oregon@mailserver:/$ sudo usermod -a -G sasl postfix
Adding user `postfix' to group `sasl' ...
Adding user postfix to group sasl
Done.
oregon@mailserver:/$ id postfix
uid=117(postfix) gid=123(postfix) groups=123(postfix),45(sasl)Indítsuk újra a Postfix és a sasl szolgáltatásokat.
oregon@mailserver:/$ sudo systemctl restart saslauthd.service
oregon@mailserver:/$ sudo systemctl restart postfixMost, ha belépünk a Roundcube-ba (ha bent voltunk lépjünk ki) és küldünk egy levelet magunknak a saját_user@localhost.localdomain címre, akkor a levél elmegy és meg is kapjuk. Nálam telepített Roundcube aktuális verziója (1.6.1) ami megköveteli az email címeknél a tld-t, emiatt kell a localdomain végződés.
Hol tartunk most?
Megy az smtp 25, imap 143, submission 587-es portok és megy az submission-on az authentikáció saslauthd-n keresztül. Működik a levél küldés-fogadás local usereknek. Ha most létrehozunk pár felhasználót, akkor már tudunk levelezni egymással. Ezt még ne kapkodjuk el, max teszt jelleggel.
Kapcsolódjunk a világhoz!
Felteszem a szándékod az, hogy ne csak kis közösségeddel levelezhess localhoston, hanem az egész világgal. Első körben egy minimális védelmet kell kiépíteni, mielőtt a világot magunkra eresztjük és magunkat a világra.
Védelem kialakítása spamtől, vírustól, nem kívánt gépektől
Az alábbi lépéseket a Kernel Pánik youtube csatornája alapján csinálom. Korábban már ajánlottam muszashi kolléga ezen blogját, mert ismereteink halmaza ebben a témában elég nagy metszetett képeznek, valamint ugyanazokat az alkalmazásokat használjuk. Láttam tőle új dolgokat. Hála neki érte.
Először is telepítsük fel az Amavist, a Clamavot, és Spamassasint és néhány tömörítőt, amit majd a víruskeresőnk fog használni.
oregon@mailserver:/$ sudo apt install amavisd-new clamav-daemon spamassassin arj bzip2 cpio unzip zip unrar unrar-freeMielőtt tovább haladnánk, nagyon fontos, hogy egymás csoportjába felvegyük a szolgáltatások felhasználóit. Enélkül kicsit körülményesebb lenne használni, egymás szolgáltatásait.
oregon@mailserver:/$ sudo adduser clamav amavis
Adding user `clamav' to group `amavis' ...
Adding user clamav to group amavis
Done.
oregon@mailserver:/$ sudo adduser amavis clamav
Adding user `amavis' to group `clamav' ...
Adding user amavis to group clamav
Done.Szerkesszük az Amavis-ban a gépünk host nevét az /etc/amavis/conf.d/05-node_id fájban:
# To manually set $myhostname, edit the following line with the correct Fully
# Qualified Domain Name (FQDN) and remove the # at the beginning of the line.
#
$myhostname = "mail.yourdomain.tld";Erre amiatt van szükség, mert az Amavis beleírja a magát a leveleink fejlécébe az alábbi módon:
X-Virus-Scanned: Debian amavisd-new at mail.yourdomain.tldMost szerkesszük a /etc/amavis/conf.d/15-content_filter_mode fájlt, amiben első körben a Clamav-ot engedélyezzük:
# Default antivirus checking mode
# Please note, that anti-virus checking is DISABLED by.
# default.
# If You wish to enable it, please uncomment the following lines:
@bypass_virus_checks_maps = (\%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re);Szerkesszük még a /etc/amavis/conf.d/20-debian_defaults amiben az alábbi részt, amivel azt mondjuk meg mi legyen a sorsa a spam-nel és a vírusos levélnek. A discard (eldobás) jó választás lehet. Legfeljebb a szintekkel kell majd játszanunk később, hogy mennyi ponttól történjen meg az eldobás.
# You should:
# Use D_DISCARD to discard data (viruses)
# Use D_BOUNCE to generate local bounces by amavisd-new
# Use D_REJECT to generate local or remote bounces by the calling MTA
# Use D_PASS to deliver the message
#
# Whatever you do, *NEVER* use D_REJECT if you have other MTAs *forwarding*
# mail to your account. Use D_BOUNCE instead, otherwise you are delegating
# the bounce work to your friendly forwarders, which might not like it at all.
#
# On dual-MTA setups, one can often D_REJECT, as this just makes your own
# MTA generate the bounce message. Test it first.
#
# Bouncing viruses is stupid, always discard them after you are sure the AV
# is working correctly. Bouncing real SPAM is also useless, if you cannot
# D_REJECT it (and don't D_REJECT mail coming from your forwarders!).
$final_virus_destiny = D_DISCARD; # (data not lost, see virus quarantine)
$final_banned_destiny = D_DISCARD;
$final_spam_destiny = D_DISCARD;
$final_bad_header_destiny = D_DISCARD; # False-positive prone (for spam)Ha most újraindítjuk az Amavis-t és nézünk egy státuszt:
oregon@mailserver:/ $ sudo systemctl restart amavis.service
oregon@mailserver:/ $ sudo systemctl status amavis.service
● amavis.service - Interface between MTA and virus scanner/content filters
Loaded: loaded (/lib/systemd/system/amavis.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2023-04-30 07:56:30 UTC; 1s ago
Docs: http://www.ijs.si/software/amavisd/#doc
Process: 27742 ExecStartPre=/usr/bin/find /var/lib/amavis -maxdepth 1 -name amavis-* -type d -exec rm -rf {} ; (code=exited, status=0/SUCCESS)
Process: 27743 ExecStartPre=/usr/bin/find /var/lib/amavis/tmp -maxdepth 1 -name amavis-* -type d -exec rm -rf {} ; (code=exited, status=0/SUCCESS)
Main PID: 27744 (/usr/sbin/amavi)
Tasks: 3 (limit: 19063)
Memory: 72.9M
CPU: 858ms
CGroup: /system.slice/amavis.service
├─27744 "/usr/sbin/amavisd-new (master)"
├─27761 "/usr/sbin/amavisd-new (virgin child)"
└─27762 "/usr/sbin/amavisd-new (virgin child)"
ápr 30 07:56:31 mailserver amavis[27744]: No decoder for .jar
ápr 30 07:56:31 mailserver amavis[27744]: No decoder for .lha
ápr 30 07:56:31 mailserver amavis[27744]: No decoder for .lrz
ápr 30 07:56:31 mailserver amavis[27744]: No decoder for .lz4
ápr 30 07:56:31 mailserver amavis[27744]: No decoder for .lzo
ápr 30 07:56:31 mailserver amavis[27744]: No decoder for .rpm
ápr 30 07:56:31 mailserver amavis[27744]: No decoder for .swf
ápr 30 07:56:31 mailserver amavis[27744]: No decoder for .zoo
ápr 30 07:56:31 mailserver amavis[27744]: Using primary internal av scanner code for ClamAV-clamd
ápr 30 07:56:31 mailserver amavis[27744]: Found secondary av scanner ClamAV-clamscan at /usr/bin/clamscan…akkor láthatjuk, mely tömörítő hiányzik. Ha akarjuk pótoljuk.
Amavis újraindítása után megjelent a 10024-es portunk, ezen a porton fut a szolgáltatás:
oregon@mailserver:/$ sudo nmap -p 10024 localhost
Starting Nmap 7.80 ( https://nmap.org ) at 2023-04-30 08:01 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000063s latency).
PORT STATE SERVICE
10024/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 0.09 secondsMindeközben a beavatkozásunk nélkül települt és elindult a clamav-freshclam.service. Ő felel azért, hogy lehúzza a legfrissebb vírus adatbázisokat. Ellenőrizzük őket:
oregon@mailserver:/ $ sudo systemctl status clamav-freshclam.service
● clamav-freshclam.service - ClamAV virus database updater
Loaded: loaded (/lib/systemd/system/clamav-freshclam.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2023-04-30 07:37:22 UTC; 26min ago
Docs: man:freshclam(1)
man:freshclam.conf(5)
https://docs.clamav.net/
Main PID: 25326 (freshclam)
Tasks: 1 (limit: 19063)
Memory: 226.3M
CPU: 26.690s
CGroup: /system.slice/clamav-freshclam.service
└─25326 /usr/bin/freshclam -d --foreground=true
ápr 30 07:37:50 mailserver systemd[1]: /lib/systemd/system/clamav-freshclam.service:11: Standard output type syslog is obsolete, automatically updating to jour>
ápr 30 07:37:51 mailserver systemd[1]: /lib/systemd/system/clamav-freshclam.service:11: Standard output type syslog is obsolete, automatically updating to jour>
ápr 30 07:38:26 mailserver freshclam[25326]: Sun Apr 30 07:38:26 2023 -> Testing database: '/var/lib/clamav/tmp.ed3eebc156/clamav-1fd706f54917c95485057a3adc2e0>
ápr 30 07:38:34 mailserver freshclam[25326]: Sun Apr 30 07:38:34 2023 -> Database test passed.
ápr 30 07:38:34 mailserver freshclam[25326]: Sun Apr 30 07:38:34 2023 -> main.cvd updated (version: 62, sigs: 6647427, f-level: 90, builder: sigmgr)
ápr 30 07:38:34 mailserver freshclam[25326]: Sun Apr 30 07:38:34 2023 -> bytecode database available for download (remote version: 334)
ápr 30 07:38:34 mailserver freshclam[25326]: Sun Apr 30 07:38:34 2023 -> Testing database: '/var/lib/clamav/tmp.ed3eebc156/clamav-e65e9ca37c0c15258baae01b3ad84>
ápr 30 07:38:34 mailserver freshclam[25326]: Sun Apr 30 07:38:34 2023 -> Database test passed.
ápr 30 07:38:34 mailserver freshclam[25326]: Sun Apr 30 07:38:34 2023 -> bytecode.cvd updated (version: 334, sigs: 91, f-level: 90, builder: anvilleg)
ápr 30 07:38:34 mailserver freshclam[25326]: Sun Apr 30 07:38:34 2023 -> ^Clamd was NOT notified: Can't connect to clamd through /var/run/clamav/clamd.ctl: No >
oregon@mailserver:/ $ sudo ls -la /var/lib/clamav/
total 226588
drwxr-xr-x 1 clamav clamav 84 ápr 30 07:38 .
drwxr-xr-x 1 root root 744 ápr 30 07:37 ..
-rw-r--r-- 1 clamav clamav 291965 ápr 30 07:38 bytecode.cvd
-rw-r--r-- 1 clamav clamav 61239611 ápr 30 07:37 daily.cvd
-rw-r--r-- 1 clamav clamav 69 ápr 30 07:37 freshclam.dat
-rw-r--r-- 1 clamav clamav 170479789 ápr 30 07:38 main.cvdLáthatunk egy hibaüzenetet :
^Clamd was NOT notified: Can't connect to clamd through /var/run/clamav/clamd.ctl: No >Amíg a clamav adatbázisa nem frissül, illetve nem létezik lokálban, addig a clamav-daemont nem fog elindulni. Emiatt nem tudott elindulni telepítés után. Orvosoljuk a gondot. Normális nettel és, ha nem vagy lekorlátozva a Clamav által, akkor mostanra befrissült az adatbázis. Ellenőrizzük, hogy fut-e a clamav-daemon.service:
oregon@mailserver:/var/www/html $ sudo systemctl status clamav-daemon.service
○ clamav-daemon.service - Clam AntiVirus userspace daemon
Loaded: loaded (/lib/systemd/system/clamav-daemon.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/clamav-daemon.service.d
└─extend.conf
Active: inactive (dead)
Condition: start condition failed at Sun 2023-04-30 07:37:25 UTC; 28min ago
Docs: man:clamd(8)
man:clamd.conf(5)
https://docs.clamav.net/
ápr 30 07:37:26 mailserver systemd[1]: /lib/systemd/system/clamav-daemon.service:12: Standard output type syslog is obsolete, automatically updating to journal>
ápr 30 07:37:27 mailserver systemd[1]: /lib/systemd/system/clamav-daemon.service:12: Standard output type syslog is obsolete, automatically updating to journal>
ápr 30 07:37:48 mailserver systemd[1]: /lib/systemd/system/clamav-daemon.service:12: Standard output type syslog is obsolete, automatically updating to journal>
ápr 30 07:37:48 mailserver systemd[1]: /lib/systemd/system/clamav-daemon.service:12: Standard output type syslog is obsolete, automatically updating to journal>
ápr 30 07:37:49 mailserver systemd[1]: /lib/systemd/system/clamav-daemon.service:12: Standard output type syslog is obsolete, automatically updating to journal>
ápr 30 07:37:49 mailserver systemd[1]: /lib/systemd/system/clamav-daemon.service:12: Standard output type syslog is obsolete, automatically updating to journal>
ápr 30 07:37:50 mailserver systemd[1]: /lib/systemd/system/clamav-daemon.service:12: Standard output type syslog is obsolete, automatically updating to journal>
ápr 30 07:37:50 mailserver systemd[1]: /lib/systemd/system/clamav-daemon.service:12: Standard output type syslog is obsolete, automatically updating to journal>
ápr 30 07:37:50 mailserver systemd[1]: /lib/systemd/system/clamav-daemon.service:12: Standard output type syslog is obsolete, automatically updating to journal>
ápr 30 07:37:51 mailserver systemd[1]: /lib/systemd/system/clamav-daemon.service:12: Standard output type syslog is obsolete, automatically updating to journal>
lines 1-20/20 (END)
oregon@mailserver:/ $ sudo systemctl restart clamav-daemon.service
oregon@mailserver:/ $ sudo systemctl status clamav-daemon.service
● clamav-daemon.service - Clam AntiVirus userspace daemon
Loaded: loaded (/lib/systemd/system/clamav-daemon.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/clamav-daemon.service.d
└─extend.conf
Active: active (running) since Sun 2023-04-30 08:06:12 UTC; 1s ago
Docs: man:clamd(8)
man:clamd.conf(5)
https://docs.clamav.net/
Process: 27964 ExecStartPre=/bin/mkdir -p /run/clamav (code=exited, status=0/SUCCESS)
Process: 27965 ExecStartPre=/bin/chown clamav /run/clamav (code=exited, status=0/SUCCESS)
Main PID: 27966 (clamd)
Tasks: 1 (limit: 19063)
Memory: 143.6M
CPU: 1.971s
CGroup: /system.slice/clamav-daemon.service
└─27966 /usr/sbin/clamd --foreground=true
ápr 30 08:06:12 mailserver systemd[1]: Starting Clam AntiVirus userspace daemon...
ápr 30 08:06:12 mailserver systemd[1]: Started Clam AntiVirus userspace daemon.Lekérdeztem a szolgáltatás státuszát, majd újraindítás, majd státusz lekérdezés. Mivel ment, nem mentem bele mélyebben a debug-ba.
Lett egy olyan warnigunk a Clamav szerint, hogy a „syslog is obsolate” eközben az Amavis /etc/amavis/conf.d/20-debian_defaults -ban azt találjuk, hogy előnyben részesített a syslog. Na ilyenkor az ember vagy utána mászik, vagy azt mondja egy meg a fene. Mi azért nézzünk utána. Tudjuk meg mi, hogyan van beállítva:
Amavis loggolás:
oregon@mailserver:/ $ sudo grep syslog /etc/amavis/conf.d/20*
$DO_SYSLOG = 1; # log via syslogd (preferred)
$syslog_ident = 'amavis'; # syslog ident tag, prepended to all messages
$syslog_facility = 'mail';
$syslog_priority = 'debug'; # switch to info to drop debug output, etcClamav loggolása:
oregon@mailserver:/ $ sudo grep log /etc/clamav/clamd.conf
LogSyslog false
LogFile /var/log/clamav/clamav.logA fene se érti, de több időt egyelőre nem szánok rá. A figyelmeztetés és a konfig fájl tartalma nekem ellenmondásos, de fix me.
Visszatérve a clamav-daemon.service-hez a státusza szerint nem futott. Újraindítottam és újra megnéztem, most már minden rendben van.
A clamav-freshclam.service-t is indítsuk újra, majd nézzük meg a státuszát:
oregon@mailserver:/ $ sudo systemctl restart clamav-freshclam.service
oregon@mailserver:/ $ sudo systemctl status clamav-freshclam.service
● clamav-freshclam.service - ClamAV virus database updater
Loaded: loaded (/lib/systemd/system/clamav-freshclam.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2023-04-30 08:09:48 UTC; 1s ago
Docs: man:freshclam(1)
man:freshclam.conf(5)
https://docs.clamav.net/
Main PID: 28043 (freshclam)
Tasks: 1 (limit: 19063)
Memory: 2.1M
CPU: 23ms
CGroup: /system.slice/clamav-freshclam.service
└─28043 /usr/bin/freshclam -d --foreground=true
ápr 30 08:09:48 mailserver systemd[1]: Started ClamAV virus database updater.
ápr 30 08:09:48 mailserver freshclam[28043]: Sun Apr 30 08:09:48 2023 -> ClamAV update process started at Sun Apr 30 08:09:48 2023
ápr 30 08:09:48 mailserver freshclam[28043]: Sun Apr 30 08:09:48 2023 -> daily.cvd database is up-to-date (version: 26892, sigs: 2032828, f-level: 90, builder:>
ápr 30 08:09:48 mailserver freshclam[28043]: Sun Apr 30 08:09:48 2023 -> main.cvd database is up-to-date (version: 62, sigs: 6647427, f-level: 90, builder: sig>
ápr 30 08:09:48 mailserver freshclam[28043]: Sun Apr 30 08:09:48 2023 -> bytecode.cvd database is up-to-date (version: 334, sigs: 91, f-level: 90, builder: anv>
lines 1-18/18 (END)Szuper, már ő sem visít a clamav-daemon hiánya miatt. Láthatjuk a logban, hogy szépen húzza le a vírus adatbázisokat. Ellenőrizzük meglétüket és dátumaikat:
oregon@mailserver:/ $ sudo ls -la /var/lib/clamav/
total 226588
drwxr-xr-x 1 clamav clamav 84 ápr 30 08:09 .
drwxr-xr-x 1 root root 744 ápr 30 07:37 ..
-rw-r--r-- 1 clamav clamav 291965 ápr 30 07:38 bytecode.cvd
-rw-r--r-- 1 clamav clamav 61239611 ápr 30 07:37 daily.cvd
-rw-r--r-- 1 clamav clamav 69 ápr 30 07:37 freshclam.dat
-rw-r--r-- 1 clamav clamav 170479789 ápr 30 07:38 main.cvdA dátumokból látható, hogy minden friss.
Most már van víruskeresés szolgáltatás a szerveren. Innentől csak az kell, hogy valaki használja. Például a Postfix.
A Postfix alá először integráljuk a szoláltatást. Ezt a /etc/postfix/master.cf -ben tudjuk megtenni. Adjuk hozzá az alábbi sorokat. Akár a végére is lehet.
smtp-amavis unix - - - - 2 smtp
-o smtp_data_done_timeout=1200
-o smtp_send_xforward_command=yes
-o disable_dns_lookups=yes
-o max_use=20
127.0.0.1:10025 inet n - - - - smtpd
-o content_filter=
-o local_recipient_maps=
-o relay_recipient_maps=
-o smtpd_restriction_classes=
-o smtpd_delay_reject=no
-o smtpd_client_restrictions=permit_mynetworks,reject
-o smtpd_helo_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o smtpd_data_restricitions=reject_unauth_pipelining
-o smtpd_end_of_data_restrictions=
-o mynetworks=127.0.0.0/8
-o smtpd_error_sleep_time=0
-o smtpd_soft_error_limit=1001
-o smtpd_hard_error_limit=1000
-o smtpd_client_connection_count_limit=0
-o smtpd_client_connection_rate_limit=0
-o receive_override_options=no_header_body_checks,no_unknown_recipient_checksEz igazából ez két sor, a -o az opció, vagy kiterjesztés, vagy modul. A két sor ennyi:
smtp-amavis unix - - - - 2 smtp
127.0.0.1:10025 inet n - - - - smtpdMinden más csak beállítások, megkötések, korlátozások. Amikor pl valami nem megy, akkor ezeket szoktuk kikapcsolni. Ilyen eset az, amikor túl szigorúra sikerül egy szervert beállítani és már a tulajdonos sem tud levelezni. Van ez így.
Szolgáltatást már integráltuk, de még nem aktiváltuk Postfix alatt. Most tegyük meg ezt is a /etc/postfix/main.cf -hez adjuk hozzá az alábbi sort, tetszőleges helyre:
content_filter = smtp-amavis:[127.0.0.1]:10024Postfix main.cf és master.cf szerkesztés után érdemes futtatni a postconf parancsot. Ha minden jó, akkor visszaadja a configot. Ha hiba van, akkor azt is megmutatja hol.
Ezt követően egy postfix restart és elvileg működik a víruskereső a levelezésünkben.
systemctl restart postfix.serviceEddig nem említettem, pedig szerintem hasznos dolog. A Postfix main.cf -ben nem számít a sorok sorrendje (kivéve az egybefüggőké, lásd.: -o). Emiatt én azt a stratégiát alkalmazom, hogy minden olyan változót, amit módosítok vagyis nem default használok, az oldal aljára viszek le. A Postfix warningot dob, ha egy változó kétszer szerepel a main.cf- ben. Ettől még megy, csak gazdagabb lesz a /var/log/mail.log fájl tartalma. Amikor Postfixet állítgatok, nekem minimálisan fut egy másik ablakban a
tail -f /var/log/mail.log parancs. Ami elkapja default a fájl végi utolsó 10 sort, majd a -f kapcsoló miatt minden más új sort.
Közben küldtem magamnak egy teszt levelet:
Return-Path: <oregon@localhost>
X-Original-To: oregon@localhost.localdomain
Delivered-To: oregon@localhost.localdomain
Received: from localhost (localhost [127.0.0.1])
by mailserver (Postfix) with ESMTP id BE2AC24D34
for <oregon@localhost.localdomain>; Sun, 30 Apr 2023 08:59:39 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at
Received: from mailserver ([127.0.0.1])
by localhost (mail.yourdomain.tld [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id PAtBbnbNhIj4 for <oregon@localhost.localdomain>;
Sun, 30 Apr 2023 08:59:39 +0000 (UTC)
Received: from mail.yourdomain.tld (localhost [127.0.0.1])
by mailserver (Postfix) with ESMTPA id 8B14624D29
for <oregon@localhost.localdomain>; Sun, 30 Apr 2023 08:59:39 +0000 (UTC)
MIME-Version: 1.0
Date: Sun, 30 Apr 2023 10:59:39 +0200
From: oregon <oregon@localhost>
To: oregon@localhost.localdomain
Subject: Teszt
Message-ID: <a3f0f77b2456ef864d679df872b4a4ff@mail.ikarus.cleancenter.hu>
X-Sender: oregon@localhost
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
Teszt levélÚgy látom szépen átsuhan az Amavison a levél. Itt az ideje, hogy küldjek egy vírusosat is. Az alábbi dolgot én nem használtam eddig, a Kernel Pánik videójából tanultam meg. Van egy oldal az www.eicar.org, melyen vannak teszt vírusok. Nem igaziak, de arra jók (sőt! csak arra), hogy egy víruskeresőt leteszteljünk. Muszashit (Kernel Pánik) követve a dot com-os vírus tartalmát beraktam egy levélbe és elküldtem magamnak. Nem kaptam meg a levelet. Helyette a vírusos levelem bekerült a /var/lib/amavis/tmp/ könyvtár alá. A vírus szűrés az MTA-n (Postfix) áthaladó minden levelet szűr, így a belső levelezésünket is. Emiatt, ha valamely kliensünk vírust kíván terjeszteni a mail szerverünkön keresztül, akkor az nem fog menni neki feltéve, hogy a Clamav felismeri a vírust.
Ezzel vírus beállítással és teszteléssel végeztünk. Most állítsuk be a spam-szűrést.
A spamassassint korábban az Amavis-sel egyidejűleg felraktuk. A spamassassin spam szűrését az Amavison keresztül fogjuk megcsinálni. Lényegében az Amavis, mint szolgáltatást fogja használni a Spamassassint. Ehhez állítsuk be az Amavis-t. Szerkesszük a /etc/amavis/conf.d/15-content_filter_mode fájlt:
# Default SPAM checking mode
# Please note, that anti-spam checking is DISABLED by.
# default.
# If You wish to enable it, please uncomment the following lines:
@bypass_spam_checks_maps = (
\%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re);Indítsuk újra az Amavist:
sudo systemctl restart amavisSpam-es levélhez elég egy kód. Ezt a kódot rákeresve Apache SpamAssasin Gtube-oldalon megtalálod Ezt tedd bele a teszt leveledbe és küldd el. Közben figyeld a mail.logot.
oregon@mailserver:~ $ tail -f /var/log/mail.log
Apr 30 10:09:01 mailserver amavis[29878]: (29878-01) Blocked SPAM {DiscardedInbound,Quarantined}, [127.0.0.1]:55748 <oregon@localhost> -> <oregon@localhost.localdomain>, quarantine: 0/spam-0SeoJkz6o3db.gz, Queue-ID: 9836A24E64, Message-ID: <83b16489c9fea4f98ba27b9da661febd@mail.yourdomain.tld>, mail_id:0SeoJkz6o3db, Hits: 999, size: 662, 187 ms
Apr 30 10:09:01 mailserver postfix/smtp[29977]: 9836A24E64: to=<oregon@localhost.localdomain>, relay=127.0.0.1[127.0.0.1]:10024, delay=0.27, delays=0.06/0.02/0.01/0.18, dsn=2.7.0, status=sent (250 2.7.0 Ok, discarded, id=29878-01 - spam)
Apr 30 10:09:01 mailserver postfix/qmgr[29172]: 9836A24E64: removedA levél karanténba került, ide: /var/lib/amavis/virusmails/0/spam-0SeoJkz6o3db.gz , mint ahogyan írja is a log fájl.
Ha már itt tartunk érdemes megemlíteni, hogy a spam szűrés pontozás alapú. A korlátokat te állíthatod be. Amavis alatt a /etc/amavis/conf.d/20-debian_defaults fájlban.
$sa_spam_subject_tag = '***SPAM*** ';
$sa_tag_level_deflt = 2.0; # add spam info headers if at, or above that level
$sa_tag2_level_deflt = 6.31; # add 'spam detected' headers at that level
$sa_kill_level_deflt = 6.31; # triggers spam evasive actions
$sa_dsn_cutoff_level = 10; # spam level beyond which a DSN is not sentUgyanebben a fájlban tudod a barátaidat negatívan pontozni, hogy ők semmi esetre se minősüljenek spam-nek. Ezen a részen:
# This are some examples for whitelists, since envelope senders can be forged
# they are not enabled by default..
{ # a hash-type lookup table (associative array)
#'nobody@cert.org' => -3.0,
#'cert-advisory@us-cert.gov' => -3.0,
#'owner-alert@iss.net' => -3.0,
#'slashdot@slashdot.org' => -3.0,
#'securityfocus.com' => -3.0,
#'ntbugtraq@listserv.ntbugtraq.com' => -3.0,
#'security-alerts@linuxsecurity.com' => -3.0,
#'mailman-announce-admin@python.org' => -3.0,
#'amavis-user-admin@lists.sourceforge.net'=> -3.0,
#'amavis-user-bounces@lists.sourceforge.net' => -3.0,
#'spamassassin.apache.org' => -3.0,
#'notification-return@lists.sophos.com' => -3.0,
#'owner-postfix-users@postfix.org' => -3.0,
#'owner-postfix-announce@postfix.org' => -3.0,
#'owner-sendmail-announce@lists.sendmail.org' => -3.0,
#'sendmail-announce-request@lists.sendmail.org' => -3.0,
#'donotreply@sendmail.org' => -3.0,
#'ca+envelope@sendmail.org' => -3.0,
#'noreply@freshmeat.net' => -3.0,
#'owner-technews@postel.acm.org' => -3.0,
#'ietf-123-owner@loki.ietf.org' => -3.0,
#'cvs-commits-list-admin@gnome.org' => -3.0,
#'rt-users-admin@lists.fsck.com' => -3.0,
#'clp-request@comp.nus.edu.sg' => -3.0,
#'surveys-errors@lists.nua.ie' => -3.0,
#'emailnews@genomeweb.com' => -5.0,
#'yahoo-dev-null@yahoo-inc.com' => -3.0,
#'returns.groups.yahoo.com' => -3.0,
#'clusternews@linuxnetworx.com' => -3.0,
#lc('lvs-users-admin@LinuxVirtualServer.org') => -3.0,
#lc('owner-textbreakingnews@CNNIMAIL12.CNN.COM') => -5.0,
# soft-blacklisting (positive score)
#'sender@example.net' => 3.0,
#'.example.net' => 1.0,
},Spamszűrés is egy nagyon nagy téma. Vannak cégek akik csak ebből élnek. Amennyiben érdekel, vagy túl sok spamet kapsz, javaslom járj utána ennél alaposabban. Ezek a default beállítások már kb 99% hatékonyságúak. A 100%-ot felejtsd el házilag, ha azt elérnéd, akkor az már járna áldozatokkal is. Kivéve, ha te vagy a gmail.
Az én szerverem, amin ezt a beállítást csinálom, egy publikus ip címen lóg. Ha megpróbálnék levelet küldeni kívülről magamnak, akkor a küldő szerveren a mailq-ban maradna a levelem:
C6F4F56053F 2804 Sun Apr 30 12:22:32 oregon_igazi@oregon_masik_eles.tld
(host mail.yourdomain.tld[0.0.0.0] said: 454 4.7.1 <oregon@mail.yourdomain.tld>: Relay access denied (in reply to RCPT TO command))
oregon@mail.yourdomain.tldEnnek az oka, hogy az új szerverünk, még nem fogadja a mail.yourdomain.tld emaileket. Szerkesszük a Postfix main.cf-et és adjuk hozzá a domainünket a sorhoz:
mydestination = $myhostname, mailserver, localhost.localdomain, localhost, mail.yourdomain.tld, yourdomain.tldIndítsuk újra a Postfixünket ezen a gépen.
sudo systemctl restart postfixA másik szerveren, ahonnan levelet akartunk küldeni ide, küldjük ki újra a beragadt leveleket.
sudo postqueue -fMost figyeljük az új jelenlegi szerverünk mail-logját:
Apr 30 10:27:48 mailserver postfix/qmgr[30758]: 30C4B25086: from=<oregon@oregon_masik_eles.tld>, size=4166, nrcpt=1 (queue active)
Apr 30 10:27:48 mailserver amavis[29879]: (29879-01) Passed CLEAN {RelayedInbound}, [192.168.125.1]:39066 <oregon@oregon_masik_eles.tld> -> <oregon@mail.yourdomain.tld>, Queue-ID: 81D4F25076, Message-ID: <bb276f13bb42cc068f8faee160c06caa@oregon_masik_eles.tld>, mail_id: kFMQz41uEvmN, Hits: -1.198, size: 3510, queued_as: 30C4B25086, dkim_sd=mail:oregon_masik_eles.tld, 650 ms
Apr 30 10:27:48 mailserver postfix/smtp[30771]: 81D4F25076: to=<oregon@mail.yourdomain.tld>, relay=127.0.0.1[127.0.0.1]:10024, delay=0.7, delays=0.02/0.0
2/0.01/0.64, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 30C4B25086)
Apr 30 10:27:48 mailserver postfix/qmgr[30758]: 81D4F25076: removedEz a log részlet mutatja be a beérkező levél útját a kézbesítésig. Minden rendben vele, a levelet megkaptam.
Ezen a ponton még eszedbe ne jusson kifelé levelet küldeni. Elméletileg ez lehetséges volna gyakorlatilag a legtöbb esetben nem. Ezen a ponton az interneten lévő hírnevedet ronthatod le nagyon, felkerülhetsz RBL-ekre, kibannolhatnak más hálózatokból.
Kezdetnek telepítsük fel a certbot-ot, amivel a Let’s Encryptől tudunk ingyenes cert-tet beszerezni, https-hez, smtp-hez, imap-hoz.
oregon@mailserver:/ $ sudo snap install --classic certbotSzerezzük be a certet:
oregon@mailserver:/ $ sudo certbot -d mail.yourdomain.tldNálam egyből az Apache-ot is beállította, pedig nem használtam –apache kapcsolót. Van –nginx kapcsoló is.
Adjuk a cert-et hozzá a levelezésünkhöz. Szerkesszük a Postfix main.cf-et:
# TLS parameters
#smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
#smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_security_level=may
smtpd_tls_cert_file=/etc/letsencrypt/live/mail.yourdomain.tld/cert.pem
smtpd_tls_key_file=/etc/letsencrypt/live/mail.yourdomain.tld/privkey.pem
smtpd_tls_CAfile=/etc/letsencrypt/live/mail.yourdomain.tld/chain.pemIndítsuk újra a Postfix-et:
sudo systemctl restart postfixTeszteljük az SSL beállításainkat:
openssl s_client -connect localhost:25 -starttls smtp
openssl s_client -connect localhost:587 -starttls smtpHa jól mindent csináltunk, egy hosszú választ kapunk, valami ilyesmit:
root@mailserver:/# openssl s_client -connect localhost:587 -starttls smtp
CONNECTED(00000003)
Can't use SSL_get_servername
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = mail.yourdomain.tld
yourdomain.tld
verify return:1
---
Certificate chain
0 s:CN = mail.yourdomain.tld
i:C = US, O = Let's Encrypt, CN = R3
a:PKEY: id-ecPublicKey, 256 (bit); sigalg: RSA-SHA256
v:NotBefore: Apr 30 17:35:43 2023 GMT; NotAfter: Jul 29 17:35:42 2023 GMT
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
v:NotBefore: Sep 4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT
2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
i:O = Digital Signature Trust Co., CN = DST Root CA X3
a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
v:NotBefore: Jan 20 19:14:03 2021 GMT; NotAfter: Sep 30 18:14:03 2024 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMzA0MzAxNzM1NDNaFw0yMzA3MjkxNzM1NDJaMCUxIzAhBgNVBAMT
Gm1haWwuaWthcnVzLmNsZWFuY2VudGVyLmh1MFkwEwYHKoZIzj0CAQYIKoZIzj0D
MA0GCSqGSIb3DQEBCwUAA4IBAQAuzgwj01c+peuskQUUJXKjkFbIYX21M/9IufgN
GTfe61X3qdwmapYvpqgCAdT3JYzdljfyc1rHQ6M9cZeyI2dvjBb74Le2n21XWcdn
k17MTfOdFyqcqLypotwbQlA54KnRn55ABoBlUM4pUGdpqDfB
-----END CERTIFICATE-----
subject=CN = mail.yourdomain.tld
issuer=C = US, O = Let's Encrypt, CN = R3
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 4437 bytes and written 406 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
250 CHUNKING
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_AES_256_GCM_SHA384
Session-ID: 005B6120E394BA3AA8FFAEC910D33389CF6813A4B07480E7582F07BB8AC51D6F
Session-ID-ctx:
Resumption PSK: B65C8827CB80A063E2308AEC9755591C7CDE4B215CE403DCE4EBA1DC9C7218395E4EB56F0FF422E100D8730F89405C2E
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - f7 53 0c 70 b4 b8 c6 86-70 3d 74 34 e4 a7 f8 c0 .S.p....p=t4....
0010 - 48 6e b7 8a f3 25 52 fe-4c fd d9 42 6e 3d 28 8f Hn...%R.L..Bn=(.
0020 - 70 1c d5 d1 d8 7e d1 88-ce ff 53 a6 9b 92 13 ad p....~....S.....
0030 - d7 cc 61 8c 2f 00 37 48-c2 1b 80 8c b4 9a d1 ba ..a./.7H........
0040 - 57 15 bd f3 11 a6 e9 2d-4f 48 04 e3 b5 9d 36 12 W......-OH....6.
0050 - 81 95 b3 b1 f5 18 93 c6-90 de fa 64 8b 65 d3 aa ...........d.e..
0060 - e1 30 8c 21 14 c7 91 2d-60 04 27 a7 b8 3b 96 d0 .0.!...-`.'..;..
0070 - 72 28 f1 df dc 73 c8 0f-a6 88 12 ef f5 7b 24 20 r(...s.......{$
0080 - 0a 77 96 9f 47 eb 80 1c-d3 a8 44 22 a9 ea 26 59 .w..G.....D"..&Y
0090 - 98 6c 44 27 33 29 8b 25-c1 1e a7 8d bc 77 08 c1 .lD'3).%.....w..
00a0 - 27 df 1d 34 39 bd 10 bb-88 25 7b ea 80 db 20 cb '..49....%{... .
00b0 - 93 02 96 8d e2 5c c5 50-1f a9 c3 68 ed ef f7 0e .....\.P...h....
00c0 - 55 1b 2a 55 d6 ff a2 a0-a8 26 b1 cb f8 db b6 48 U.*U.....&.....H
Start Time: 1682885115
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCKMi kell ahhoz, hogy sikeresen tudjunk küldeni levelet?
- Minél öregebb jó hírnevű domain (=nincs rossz híre)
- IP címünk korábban nem volt fent RBL-en, illetve tartományunk tagjai sem tróger spamelők. Ehhez egy drágább hosting, vagy ahol csak rack-ek vannak többnyire Magyarországon már elég szűrő, így megfelelő. A legtöbb VPS szolgáltató is nagyon ügyel a jó hírnevére. Kisebb-nagyobb sikerrel.
- DMARC, SPF, DKIM beállítások a domained védelme érdekében.
- Domain DNS bejegyzésében egy MX rekord ami a szerverünkre mutat.
- Reverse DNS amit az ISP állít be nekünk.
A részletekkel senkit sem untatnék, mert a CloudFlare remek leírást csinált a témában és a google is jól fordítja. Inkább essünk neki a beállításoknak.
DMARC
Avagy Domain-based Message Authentication Reporting and Conformance
A DMARC egy DNS TXT record az alábbi értékekkel:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.tldv= mint verzió
p= (none, quarantine, reject) vagyis mi történjen, ha sem az SPF sem a DKIM nem stimmel. Kezdetben ezt mindenképpen hagyjuk none állapotban. Ennek oka, hogy a DNS-ben adjuk át az információkat és az nem azonnal frissül a világháló összes szereplőjénél. Amikor már szépen belaktuk a dolgot, akkor szigoríthatunk, de kezdéskor csak magunkat tesszük fel vele a szopórollerre.
rua= nem kötelező megadni, ha raksz bele email címet, akkor azon mailserverek, akik ezt kezelik riportolnak rá. Én az elején bekapcsolom, készítek hozzá egy dmarc@yourdomain.tld-s címet és figyelem. Aki nagyobb szervezetnél van, amelyiknél több gép küldhet levelet, annak ez kötelező. A riport sokat segít majd neki.
SPF
Avagy Sender Policy Framework, szintén egy DNS TXT rekord, ami kb így néz ki:
v=spf1 +mx +a ip4:0.0.0.1 ip4:0.0.0.2 ip4:0.0.0.3 -allv= verzió
+mx jelentése, akire MX rekord mutat a DNS-ben
+a jelentése, akire A rekord mutat a DNS-ben
ip4: jelentése, akinek az IP címe követi e bejegyzést
-all: jelentése senki más
SPF ellenőrzés a Postfixben
Ha már az SPF szóba került, akkor állítsuk be a Postfix-ben ennek ellenőrzését.
Telepítsük fel a csomagot:
sudo apt install postfix-policyd-spf-perlAddjuk hozzá ezt az egy sort a Postfix master.cf fájhoz:
policy unix - n n - 0 spawn user=nobody argv=/usr/bin/perl /usr/sbin/postfix-policyd-spf-perlAktiváljuk a szolgáltatást a Postfix main.cf-ben a smtpd_client_restrictions-nél:
smtpd_client_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
check_policy_service unix:private/policyIndítsuk újra a Postfixet.
Ha hozzám hasonlóan a mail szervered egy Proxy mögött van és ennek a proxy-nak az IP címe nincs benne a mynetworks-ben, akkor nem fogod megkapni az SPF-es leveleket. Ugyanis a te kliensed a Proxy és nem küldő. Megoldásként eszedbe ne jusson a mynetworks-be a felvenni a belső hálódat vagy a Proxy IP címét, mert egyből Open Relay leszel.
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128Összefoglalva, ha Proxy mögött vagy, akkor ez a védelem lényegében nem működik. Bárki küld neked levelet, az a Proxy-tól fog jönni.
DKIM
Avagy DomainKeys Identified Mail
Állítsuk be Linuxon az opendkim-et. Telepítés:
oregon@mailserver:~ $ sudo apt install opendkim opendkim-toolsAbból indulok ki, hogy nem csak egy domain fogsz kiszolgálni, hanem többet. Kezdetnek, csak megszokásból linkelem a beállítások könyvtárát, mert az adott programnévvel legyen azonos nevű könyvtárban a beállítófájlok (OCD):
oregon@mailserver:~ $ sudo ln -s /etc/dkimkeys /etc/opendkimKészítsük el az első két domaint:
oregon@mailserver:~ $ sudo mc /etc/opendkim
root@mailserver:/etc/opendkim# opendkim-genkey --domain=yourdomain1.tld --selector=mail --verbose
opendkim-genkey: generating private key
opendkim-genkey: private key written to mail.private
opendkim-genkey: extracting public key
opendkim-genkey: DNS TXT record written to mail.txt
root@mailserver:/etc/opendkim# mv mail.
mail.private mail.txt
root@mailserver:/etc/opendkim# mv mail.private yourdomain1.tld.key
root@mailserver:/etc/opendkim# mv mail.txt yourdomain1.tld.dns
root@mailserver:/etc/opendkim# opendkim-genkey --domain=yourdomain2.tld --selector=mail --verbose
opendkim-genkey: generating private key
opendkim-genkey: private key written to mail.private
opendkim-genkey: extracting public key
opendkim-genkey: DNS TXT record written to mail.txt
root@mailserver:/etc/opendkim# mv mail.txt yourdomain2.tld.dns
root@mailserver:/etc/opendkim# mv mail.private yourdomain2.tld.keyMint láthatjuk, mindkét generálás után ugyanazokba a fájlokba tette a kulcsokat, emiatt volt az átnevezés menet közben.
Most létre kell hoznunk két táblát. Egyiket hívjuk KeyTablenek a másikat meg SigningTable-nek. Kezdjük a /etc/dkimkeys/KeyTable-lel:
yourdomain1.key yourdomain1.hu:mail:/etc/dkimkeys/yourdomain1.hu.key
yourdomain2.key yourdomain2.hu:mail:/etc/dkimkeys/yourdomain2.hu.keyKicsit zavaróak lehetnek az elnevezések. Ezért elmagyarázom.
yourdomain.key bármi lehetne, ez egy hivatkozási név későbbre, de így nekem könnyebb sok domain esetén. Lehetne a neve yourdomain1.id is.
A többi rész azt írja le, hogy melyik domain, milyen selector névvel, és hol található a privátkulcs a titkosításhoz.
Jöhet a /etc/dkimkeys/SigningTable, ami már ezekre az azonosítókra fog hivatkozni :
*@yourdomain1.tld yourdomain1.key
*@yourdomain3.tld yourdomain2.keyEzzel a könyvtárral meg is volnánk. Még annyi, hogy minden fájl legyen opendkim user és csoport tulajdona, valamint permission 600 vagyis csak a tulajdonos olvassa és írja őket, másnak ne legyen hozzáférése.
Szerkesszük a /etc/opendkim.conf fájlt. Adjuk hozzá a hiányzókat:
# Signing domain, selector, and key (required). For example, perform signing
# for domain "example.com" with selector "2020" (2020._domainkey.example.com),
# using the private key stored in /etc/dkimkeys/example.private. More granular
# setup options can be found in /usr/share/doc/opendkim/README.opendkim.
#Domain example.com
#Selector 2020
#KeyFile /etc/dkimkeys/example.private
KeyTable /etc/dkimkeys/KeyTable
SigningTable refile:/etc/dkimkeys/SigningTableIndítsuk újra az opendkim szolgáltatást:
oregon@mailserver:~ $ sudo systemctl restart opendkim.serviceHa a domain szolgáltatónknál DNS rekordunkhoz hozzáadtuk a yourdomain1.tld.dns bejegyzést, akkor az alábbi tesztelés és eredményt kell látnunk a szerverünkön:
sudo opendkim-testkey -d yourdomain1.tld -s mail -vvv
opendkim-testkey: using default configfile /etc/opendkim.conf
opendkim-testkey: checking key 'mail._domainkey.yourdomain1.tld'
opendkim-testkey: key secure
opendkim-testkey: key OKHa nem ezt látjuk, akkor keressük meg a hibát, majd folytassuk.
Állítsuk be két helyen is az opendkim-et.
Szerkesszük az /etc/default/opendkim -et, amiben az alábbi két változó értékét állítsuk át:
RUNDIR=/var/spool/postfix/run/opendkim
SOCKET=inet:8891Ugyanezt a socket-et valamiért az /etc/opendkim.conf -ban is be kell állítani:
Socket inet:8891Azok akiknél hibamentesen lefutott minden, szerkeszthetik a Postfix main.cf-et, mert hozzá kell adnunk az opendkim szolgáltatást a Postfixhez. Az alábbi sorokat tegyük a main.cf fájl végére.
# DKIM
milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891Indítsuk újra a Postfixet:
oregon@mailserver:~ $ sudo systemctl restart postfix.serviceJó hírem van, ez ennyi volt. Van DKIM a Postfix alatt. Minden új domainhez kell majd kulcs, és annak a publikus részét, hozzá kell adnunk az adott domain DNS rekordjához.
Hol tartunk most?
Mostanra, már nem utálhatnak minket a neten. Van DMARC, SPF, DKIM, Clamav, Spamassassin, Reverse DNS bejegyzésünk (ISP állítja be) valamint egy authentikált mail szerverünk, ami nem openrelay a világ felé. Most már tudunk levelet küldeni és fogadni is bárkitől. Innentől már féllábbal is végig csináljuk ezt a leírást. 🙂
Mit nem oldottunk még meg?
Kellenek felhasználók, aliasok, domainek, lokális szűrő a levelek leválogatásához, valamint pár megszorítás vagy könnyítés azon barátaink felé, akiket amúgy elutasítana a jelenleg közepesen szigorú rendszerünk. Szükségünk van még imaps-re is.
Állítsuk be a Dovecot-hoz az SSL-t
Elsőnek szerkesszük a /etc/dovecot/conf.d/10-ssl.conf fájt.
# SSL/TLS support: yes, no, required. <doc/wiki/SSL.txt>
ssl = yes
# PEM encoded X.509 SSL/TLS certificate and private key. They're opened before
# dropping root privileges, so keep the key file unreadable by anyone but
# root. Included doc/mkcert.sh can be used to easily generate self-signed
# certificate, just make sure to update the domains in dovecot-openssl.cnf
#ssl_cert = </etc/dovecot/private/dovecot.pem
#ssl_key = </etc/dovecot/private/dovecot.key
ssl_cert = </etc/letsencrypt/live/mail.yourdomain.tld/cert.pem
ssl_key = </etc/letsencrypt/live/mail.yourdomain.tld/privkey.pem
# If key file is password protected, give the password here. Alternatively
# give it when starting dovecot with -p parameter. Since this file is often
# world-readable, you may want to place this setting instead to a different
# root owned 0600 file by using ssl_key_password = <path.
#ssl_key_password =
# PEM encoded trusted certificate authority. Set this only if you intend to use
# ssl_verify_client_cert=yes. The file should contain the CA certificate(s)
# followed by the matching CRL(s). (e.g. ssl_ca = </etc/ssl/certs/ca.pem)
#ssl_ca =.
ssl_ca = </etc/ssl/certs/ca-certificates.crt
A tesztelést Thunderbird alól végeztem, sikeresen lefutott. Tudtam levelet írni és olvasni, loginolni. Bevallom 993-as portra nekem nem sikerült csatlakoznom Roundcube alól. Kis időt eltöltöttem vele, de feladtam, mert igazából szükségtelen a localhost-on lévő kommunikációhoz. Oda tökéletes a 143-as port is.
Postfix szűkítések, megszorítások, korlátozások
A main.cf -ben a több értékkel rendelkező változók értékei szeparálhatóak. Használhatsz space-t, vesszőt és spacet, entert majd a sor elején 1 db space a szeparáláshoz.
Első szigorítás ami felveszek a main.cf-be a helo megkövetelése. Ennek oka, hogy mindenféle kóbor programmal ne kelljen a szervernek beszélgetnie. Csak azokkal álljon szóba, akik levelezési szándékkal érkeznek.
smtpd_helo_required = yesHa az előbbi érték nálad is yes, akkor megadhatsz további korlátozásokat is.
smtpd_helo_restrictions =Szabályozhatjuk, ki küldhet rajtunk keresztül levelet, alapértelmezett értékek:
smtpd_relay_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
defer_unauth_destinationKitől fogadunk el levelet, alapértelmezetten üres:
smtpd_sender_restrictions = Készítsük el az első táblánkat a helo táblát. Ehhez én készítek egy könyvtárat a postfix alá access néven, és beleteszek pár adatot:
sudo mkdir /etc/postfix/access
sudo touch /etc/postfix/access/heloSzerkesszük ezt a helo fájlt, itt egy minta:
kikuldve.com REJECT
kezbesitve.com REJECT
rendesember-jobarat.tld PERMITHash-eljük el a postmap parancssal:
sudo postmap hash:/etc/postfix/access/heloMost létre jött egy helo.db állomány a helo mellett.
Adjuk hozzá ezt a megszorítást az smtp démon helo megszorításhoz a main.cf-ben:
smtpd_helo_restrictions = check_helo_access hash:/etc/postfix/access/heloIndítsuk újra a Postfixet és gratuláljunk magunknak, mert elkészült az első megszorításunk! Mostantól már köszönésnél eldönthetjük, hogy kivel akarunk és kivel nem beszélgetni. Sok esetben ezzel nagyon megkönnyítjük az életünket, mert terhelést vehetünk el a szerverünkről. Láthattuk a levelezőrendszer üzemeltetés egy közös csapatjáték a szolgáltatásokkal. Minek kellene egy oda nem való dologgal foglalkoznia mindenkinek, ha már a Postfix is eldobhatja?
Használjunk RBL-t!
Mi az RBL? Van aki szerint Remote Block List, mások szerint Realtime Blackhole List. A lényeg az, hogy ez egy DNS alapú feketelista azokról, akik túl sok szemetet toltak ki a netre. Magyarul spammerek. Nem minden spam szándékos, van amikor elég egy fertőzött gép a hálózaton, ami már ontja is a szemetet a világ felé. Húsz éve történt, amikor csak Linux kliensek voltak a hálózatomon simán openrelay voltam befelé a védett hálózat felé. A hálózatba később bekerült (DTP miatt) egy Windows, ami vírusos lett és ontotta a spamet. Akkor megtanultam, ha nem szabályozhatom a klienseket, akkor a belső hálózaton is authentikálni kell.
Állítsuk be küldőknél az első pár RBL megszorításunkat!
smtpd_sender_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
#check_sender_access hash:/etc/postfix/access/sender_access,
#check_client_access hash:/etc/postfix/access/rbl_override,
reject_rbl_client sbl-xbl.spamhaus.org,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client bl.spamcop.net,
reject_rbl_client bl.spameatingmonkey.net,
reject_rhsbl_sender fresh.spameatingmonkey.net,
reject_rhsbl_client fresh.spameatingmonkey.net,
reject_rhsbl_sender fresh30.spameatingmonkey.net,
reject_rhsbl_client fresh30.spameatingmonkey.net,
permit Ezt az utolsó permit-et örököltem még a 2000-es évek elején. Nem vagyok benne biztos, hogy szükséges. Sőt! A korlátozás tudtommal úgy működik, hogy az első találat kielégíti őt, akkor abbahagyja az egyezés keresését. Tehát, ha nincs találat, akkor az lényegében permit. Emiatt is kezdjük magunkkal az engedélyezéseket, hogy véletlen se zárjuk ki saját magunkat a levelezésből.
Check Sender Access:
A szemfüles olvasó észrevehette a #check_sender_access sort az előbbi konfigban. A parancs a levél MAIL FROM címét értékeli ki, tartományát, szülőtartományát vagy egy részt@ keres, és végrehatja a fájlban megadott műveletet.
Nézzünk egy példát a /etc/postfix/access/sender_access fájlra:
baddomain1.tld REJECT
baddomain2.tld REJECT
gooddomain1.tld OK
gooddomain2.tld OKKérdezheti a kedves olvasó mi a különbség a helo check és e között? pl az, hogy RBL listán lévő, de köszönni tudó jó barátokat, be tudunk engedni hozzánk levelezni.
Ha sender_access-t használunk, akkor ne felejtsük el, minden változásnál / szerkesztést követően kiadni, az alábbi parancsot:
sudo postmap hash:/etc/postfix/access/sender_access
sudo systemctl restart postfixCheck Client Access
A hely ahonnan csatlakozni kívánnak hozzánk, ő a kliensünk. Ő is fent lehet bármely RBL-en . Kérdezheti a kedves olvasó, miért még egy lista? Két okból. Egy: így lesz jól adminisztrálva a rendszerünk. Kettő: ha bármi más okból nem tud nekünk küldeni levelet a kliens gép, ilyen lehet az is, hogy nincs neki FQDN-je. Lásd alább:
username.asuscomm.com OK
username.duckdns.org OKHa rbl_override-ot használunk, akkor ne felejtsük el, minden változásnál / szerkesztést követően kiadni, az alábbi parancsot:
sudo postmap hash:/etc/postfix/access/rbl_override
sudo systemcetl restart postfixPCRE – Perl Compatible Regular Expressions
A Postfix tud kezelni pcre szűrést. Azok kezében, akik szeretik a reguláris kifejezéseket, ez egy nagyon hasznos tool lesz. Postfix alatt ezt is használhatjuk tartalomszűrésre. Lényegében a levél fejlécét és testét (body) olvashatjuk vele. Kezdjük a telepítéssel.
oregon@mailserver:/ $ sudo apt install postfix-pcreAdjuk hozzá a main.cf-hez az alábbi sorokat:
header_checks = pcre:/etc/postfix/access/header_checks
body_checks = pcre:/etc/postfix/access/body_checksPélda a header_checks -re:
/^X-Mailer: Webgalamb/ REJECT
/^X-Mailer: MailChimp/ REJECT
/\/ru\/unsubscribe\/do?/ REJECT
/www.directmail.hu/ REJECT
/listamester.hu/ REJECT
/MailPoet/ REJECT
/mailpoet.com/ REJECT
/NapiNet/ REJECT
/szallasguru.hu/ REJECT
/diszkont-plaza.eu/ REJECTHa a fenti domainek ismerősnek tűnnek, akkor az nem a véletlen műve. 🙂
Példa a body_checks-re:
/\/00\.jpg/ REJECT
/\/ub.php\?/ REJECT
/\/aa.php\?/ REJECT
/targito.com/ REJECTVolt egy időszak, amikor egy levél mindig átcsúszott. Egy dolog közös volt benne, a fenti fájlhivatkozások. Meguntam, ekkor írtam bele a body_checks-be.
Miután beállítottad ezt is, ne felejts el egy Postfix restart-ot nyomni. Mivel rohadt sokat kell a Postfixet restartolni, nálam így néz ki a script rá, ami a /etc/postfix/postfix.restart:
#!/bin/bash
sudo postmap hash:/etc/postfix/access/sender_access
sudo postmap hash:/etc/postfix/access/rbl_override
sudo postmap hash:/etc/postfix/access/helo
sudo postmap hash:/etc/postfix/tls_policy
sudo systemctl restart postfixAmikor szennyezett IP-d van
Vannak esetek, amikor az IP tartományod spammelőktől szennyezett és az istennek nem tudsz levelet küldeni bizonyos tartományokba. Ilyenkor egy dolgot tehetsz, mail transportot használsz. Ez azt jelenti, hogy bizonyos tartományokba más smtp-n keresztül küldesz ki levelet és nem direktben. Erről én csak hallottam, soha nem volt dolgom vele. Ha te a Digi, Upc, Invitel ügyfél voltál az elmúlt több, mint 15 évben, akkor lehet a probléma érintett téged is. Erre a problémára is van megoldás, lásd.:
https://www.postfix.org/transport.5.html
Hol vannak a leveleim?
Azt hiszem ennyi idő után már időszerű erről is beszélnünk. 🙂 Az alaptelepítésben a Postfix és a Dovecot egy közös helyre teszi őket, a /var/spool/mail alá, mailbox fájlformátumban:
oregon@mailserver:/ $ sudo ls -la /var/spool/mail/
total 40
drwxrwsr-x 1 root mail 38 máj 1 09:05 .
drwxr-xr-x 1 root root 114 ápr 27 17:42 ..
-rw------- 1 root mail 2566 ápr 29 19:40 root
-rw------- 1 oregon mail 33813 máj 1 09:05 oregonLáthatjuk, a csoport mail, a felhasználó pedig a levelek tulajdonosa. A levelekhez joga, csak a tulajdonosnak van. Ma már a mailbox fájlformátum nem a legszerencsésebb dolog. Több gigás levelezés esetén, hamar érezni fogjuk a nehézséget vele.
Először oldjuk meg, hogy a Dovecot kezelje kizárólagosan a leveleket. A Postfix is neki adja át őket.
Telepítsük fel a Dovecot Lmtpd-t.
oregon@mailserver:~ $ sudo apt install dovecot-lmtpdSzerkesszük a /etc/dovecot/conf.d/10-master.conf fájl ezen részét (service lmtp):
service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
mode = 0660
user = postfix
group = postfix
}
#unix_listener lmtp {
# mode = 0666
##}
# Create inet listener only if you can't use the above UNIX socket
inet_listener lmtp {
# Avoid making LMTP visible for the entire internet
#address =
port = 24
}
}Ugyanennek a fájlnak az aljához adjuk hozzá az alábbi részt, különben az LDA nem fogja tudni írni a /run/dovecot/stats-writer-t , ha pedig nem tudja írni, akkor levelet sem fog tudni kézbesíteni:
service stats {
unix_listener stats-writer {
mode = 0666
}
}Indítsuk újra a Dovecot-ot.
Ellenőrizzük a 24-es protot, ahol mostanra ott kell figyelnie a Dovecot LMTPD-nek:
root@mailserver:~# lsof -i :24
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
dovecot 78940 root 26u IPv4 520228 0t0 TCP *:24 (LISTEN)
dovecot 78940 root 27u IPv6 520229 0t0 TCP *:24 (LISTEN)
root@mailserver:~# nmap -p 24 localhost
Starting Nmap 7.80 ( https://nmap.org ) at 2023-05-01 19:27 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000065s latency).
PORT STATE SERVICE
24/tcp open priv-mail
Nmap done: 1 IP address (1 host up) scanned in 0.07 secondsMost mondjuk meg a Postfixnek, hogy mostantól ne ő, hanem a Dovecot kezelje a leveleinket. Adjuk hozzá az alábbi sort a main.cf-hez.
mailbox_command = /usr/lib/dovecot/deliver -c /etc/dovecot/dovecot.conf -m "${EXTENSION}"Postfix restart, majd mehet egy teszt levél. A levél fenakad a mailq-ban. Ennek az oka, hogy a Dovecot hozzá csapja a full domaint és így keresi a felhasználót. Ez nem bug, hanem feature, hiszen Dovecot arra van felkészítve, hogy n cégnél lehet m számú Szabó János.
Próbaképpen, hogy megint tanuljunk valamit, küldjük újra el a leveleket a mailq-ból. Ehhez két parancs kell. A postsuper ami megjelöli a leveleket újraküldésre és a postqueue ami elküldi.
root@mailserver:~# postsuper -r ALL
postsuper: Requeued: 3 messages
root@mailserver:~# postqueue -fNem csináltunk semmi hasznosat, csak tanultunk valamit. Sorkezelést. Ugyanis levelek nem fognak elmenni, amíg az ismertetett hibát el nem hárítottuk. Ehhez a legjobb lesz, ha most egyből egy nagy témára térünk át, a virtuális felhasználókra. Ideje elengednünk a rendszer felhasználókat. Elég belőle bőven egy, te magad. Ha fáradt vagy, pihenj, egyél, igyál, mozogj, és ne kezdj bele a következő részbe.
Megnyugtatásként elmondom. Nagyon jól állunk. Ha ideáig eljutottál és minden működik nálad. Ja bocs! Ezen a ponton a mailq-ban ragadnak a levelek. 🙂 Szóval most úgy érzed, semmi sem működik. Ettől függetlenül már most nagyon elégedett lehetsz magaddal. Ha az eddigiek újak voltak, akkor sokat tanulhattál belőle.
Dovecot Auth módok
Ha végigbújtad már a /etc/dovecot tartalmát, akkor mostanra jól össze lehetsz zavarodva. Ennek az oka, hogy minden fájlban hasonló dolgok vannak és te keresed ennek az értelmét. Hidd el van, két perc és neked is tiszta lesz minden.
Kezdjük az alábbi listázással:
root@mailserver:~# ls -ls /etc/dovecot/conf.d/auth-* | awk {'print $10'}
/etc/dovecot/conf.d/auth-checkpassword.conf.ext
/etc/dovecot/conf.d/auth-deny.conf.ext
/etc/dovecot/conf.d/auth-dict.conf.ext
/etc/dovecot/conf.d/auth-master.conf.ext
/etc/dovecot/conf.d/auth-passwdfile.conf.ext
/etc/dovecot/conf.d/auth-sql.conf.ext
/etc/dovecot/conf.d/auth-static.conf.ext
/etc/dovecot/conf.d/auth-system.conf.extCsupa authentikációs fájl. Igazából ezek csak minták, de nem klasszikus értelemben. Inkább olyan félkész ételek. Ugyanis te kitalálod, hogyan akarsz authentikálni, majd azt az egyetlen egyet engedélyezed a /etc/dovecot/conf.d/10-auth.conf-ban. Ezután az kiválasztott auth-* fájt szerkeszted kedvedre. Nem tudom, hogy lehet-e több auth fájt használni egyszerre, inkább a nemre szavaznék, mert a logika azt mondja, hogy változók egymást felülírják. Amúgy sem szerencsés két dudás egy csárdába.
A conf.d alatt a többi *.conf fájl, ami nem más csak szeparált beállító fájlok. Peched-re a nevükkel ellentétben, nem mindig ott van amit keresel, ahogyan a fájt hívják. Jó példa erre a korábbi lmpt szerkesztés a master alatt. Ez egy igazi agyfasz. Legyél türelmes, nem kell ilyet mindennap csinálnod, vagy ha majd igen, akkor kérlek bloggolj róla vagy kommentelj majd ide, mert szívesen tanulok.
Virtuális felhasználók, domainek, aliasok SQL-ben
Kezdem egy kedvcsinálóval. A bejegyzés témáját lassan 20 éve üzemeltetem egyetlen egy db szerveren. (A másodikat most csinálom, ez az apropó.) Eddig egyszer kellett újra raknom. Ez a mostani a második alkalom, de mindegyik esetben ráment egy hetem. 🙂 Emiatt is csinálom ezt a bejegyzést, de e bejegyzés is megizzaszt. Most szembesülök azzal, mennyi mindenről van téves infó a fejemben. A kedvcsináló, amit ígértem az, hogy az így összerakott rendszer adminját elkészítettem modulként és integráltam az általam fejlesztett ERP rendszerbe. Íme egy screenshot róla:
Ebben a rendszerben mindent meg tudok csinálni ami a domain, emailcímek, felhasználókkal kapcsolatos. Nem egy nagy dolog, egyetemen egy sima ZH témája is lehetne.
Kezdjük a Maildir-re való átállással!
Átállást követően átmenetileg nem fogod látni az eddigi mailbox fájlban lévő leveleidet. Ezt később megoldhatod van rá tool minden disztribúcióban. Most állítsuk át a Dovecot-ot mailbox-ról maildirre. Ehhez szerkesszük a /etc/dovecot/conf.d/10-mail.conf fájlt:
# See doc/wiki/Variables.txt for full list. Some examples:
#
# mail_location = maildir:~/Maildir
# mail_location = mbox:~/mail:INBOX=/var/mail/%u
# mail_location = mbox:/var/mail/%d/%1n/%n:INDEX=/var/indexes/%d/%1n/%n
#
# <doc/wiki/MailLocation.txt>
#
#mail_location = mbox:~/mail:INBOX=/var/mail/%u
mail_location = maildir:/var/mail/vhosts/%d/%nHozzunk létre egy vmail felhasználót és csoportot a levelek kezelésére. Erre azért van szükség, mert később a virtuális felhasználóink nem részük a Linux rendszerünknek, nincsen emiatt saját id-jük a rendszeren. Emiatt a Linux fájlrendszerén egy közös felhasználó, a vmail képzi le őket. Mint korábban láthattuk a mailbox fájlokat, mindig a tulajdonos felhasználó birtokolja. A virtuális felhasználóknál ezt helyettesíti a közös vmail felhasználó.
A vmail felhasználó és csoport létrehozása:
sudo groupadd -g 5000 vmail
sudo useradd -m -d /var/mail/vhosts -s /bin/false -u 5000 -g vmail vmail
sudo mkdir /var/mail/vhosts
sudo chown vmail:vmail -R /var/mail/vhostsMost, hogy van vmail userünk és csoportunk, módosítsuk a Dovecot-ot, hogy a leveleket vmail felhasználó nevében tárolja a fájlrendszeren. Ehhez két fájlt kell szerkesztenünk.
Szerkesszük /dovecot/conf.d/auth-sql.conf.ext fájt. Kommenteljük ki mindent amit benne találunk és adjuk hozzá a fájl végéhez az alábbi sorokat:
passdb {
driver = sql
args = /etc/dovecot/dovecot-sql.conf.ext
}
userdb {
driver = static
args = uid=vmail gid=vmail home=/var/mail/vhosts/%d/%n
}Ezzel megadtam, hogy mi a levelek home könyvtára és ki a tulajdonosa. Valamint a %d a domain a %n pedig a @ előtti rész lesz. Ha nincs domain, pl rendszerfelhasználó belépésekor a %n = %u azonos értéket vesz fel. (Közben említésre sem méltattam, de már az SQL auth-ot készítjük elő.)
Mire jó ez?
Szépen szeparálva lesznek a felhasználók és csoportosítva domain-ek alá. Így:
/var/mail/vhosts/domain1/user1
/var/mail/vhosts/domain1/user2
/var/mail/vhosts/domain1/user3
/var/mail/vhosts/domain2/user1
/var/mail/vhosts/domain2/user2
/var/mail/vhosts/domain2/user3Az pedig, hogy erre egy külön felhasználót hoztunk létre (vmail) arra jó, hogy ez a felhasználó és az általa kezelt tartalom jól el lett különítve a root kivételével, minden más felhasználó által írható tartalomtól.
Telepítsük a Dovecot alá az SQL authentikációs driverét:
oregon@mailserver:/# sudo apt install dovecot-mysql Aktiváljuk az SQL authentikációt
Szerkesszük a /etc/dovecot/conf.d/10-auth.conf fájl végén található részt:
#!include auth-system.conf.ext
!include auth-sql.conf.ext
#!include auth-ldap.conf.ext
#!include auth-passwdfile.conf.ext
#!include auth-checkpassword.conf.ext
#!include auth-static.conf.extEddig auth-system volt beállítva. Ha most újraindítanánk a Dovecot-ot (még ne tegyük, felesleges), akkor nem tudunk belépni, mert nincs még virtuális felhasználónk.
Állítsuk be az SQL szerver típusát!
Ehhez szerkesszük a /etc/dovecot/dovecot-sql.conf.ext fájlt:
# Database driver: mysql, pgsql, sqlite
driver = mysql
#connect =
connect = host=localhost dbname=mailserver user=mailuser password=mailpassword
#default_pass_scheme = MD5
default_pass_scheme = SHA512-CRYPT
# Ez mehet a végére
password_query = SELECT email as user, password FROM virtual_users WHERE email='%u';
Az előbb beállítottunk egy SQL kapcsolatot, egy nem létező adatbázishoz, egy nem létező accounttal.
Lépjünk be a mysql-be:
oregon@mailserver:/$ mysql -uroot -prootjelszavaHozzunk létre egy felhasználót és egy adatbázist a Dovecot/Postfix számára, majd töltessük újra a jogokat az SQL szerverünkkel:
CREATE USER mailuser@'localhost' IDENTIFIED BY 'mailpassword';
CREATE DATABASE mailserver;
GRANT ALL privileges ON mailserver.* TO 'mailuser'@'localhost' identified by 'mailpassword';
FLUSH privileges;
exit <ENTER>Hozzuk létre a a szükséges tábláinkat, ehhez felraktam ide a szükséges *.sql állományt:
oregon@mailserver:/$ mysql -uroot -prootjelszava mailserver < mailserver_linuxuser.sqlHozzuk létre az első domainünket a yourdomain.tld-t az sql-ben:
root@mailserver:/# mysql
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 6781
Server version: 10.6.12-MariaDB-0ubuntu0.22.04.1 Ubuntu 22.04
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]> use mailserver;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
MariaDB [mailserver]> INSERT INTO virtual_domains(name) VALUES('yourdomain.tld');
Query OK, 1 row affected (0,004 sec)Megnézem mi a domain id-ja:
MariaDB [mailserver]> SELECT * FROM virtual_domains WHERE name = 'yourdomain.tld';
+----+----------------+
| id | name |
+----+----------------+
| 1 | yourdomain.tld |
+----+----------------+
1 row in set (0,001 sec)
Most hozzáadom az első felhasználót, jelszavát sózom és hashelem:
MariaDB [mailserver]> INSERT INTO virtual_users(domain_id, email, password) VALUES('1', 'oregon@yourdomain.tld', ENCRYPT('oregonjelszava', CONCAT('$6$'
, SUBSTRING(SHA(RAND()), -16))));
Query OK, 1 row affected (0,011 sec)Ha nem hagytam ki semmit (ha bármi nem megy, akkor kommentelj) és te mindent úgy csináltál ahogyan leírtam, akkor a Dovecot restart után már be tudsz lépni a virtuális felhasználóddal.
Abból kiindulva, hogy te vagy a domain gazdája, hozzunk létre egy aliast az abuse@-nak:
MariaDB [mailserver]> INSERT INTO virtual_aliases(domain_id, source, destination) VALUES('1', 'abuse@yourdomain.tld', 'oregon@yourdomain.tld');
Query OK, 1 row affected (0,003 sec)
Azt szeretném, ha az a néhány rendszer felhasználó mostantól a leveleit az oregon@yourdomain.tld -re küldené. Ehhez szerkesszük az /etc/alias fájlt:
oregon@mailserver:~ $ cat /etc/aliases
# See man 5 aliases for format
oregon: oregon@yourdomain.tld
postmaster: oregon
clamav: oregon
root: oregonAzt követően amikor ezt a fájlt szerkeszted, mindig ki kell adni a newaliases parancsot:
oregon@mailserver:~ $ sudo newaliasesEzzel a Dovecot SQL párosítással egyelőre végeztünk. Térjünk át kicsit a Postfixre:
A Postfix összebarátkoztatása az SQL-lel
Szerkesszük a /etc/postfix/sasl/smtpd.conf fájlt:
pwcheck_method: saslauthd auxprop
mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 NTLM
auxprop_plugin: sql
sql_engine: mysql
sql_hostnames: localhost
sql_user: mailuser
sql_passwd: mailpassword
sql_database: mailserver
sql_select: SELECT password FROM virtual_users WHERE email = '%u'@'%r' AND smtp_disabled = 0
#password_format: [crypt|crypt_trad|plaintext]
password_format:crypt
sql_verbose: yesA main.cf szerkesztésével folytassuk. Adjuk, hozzá az alábbi sorokat a fájl végéhez:
# VIRTUAL
virtual_mailbox_domains = mysql:/etc/postfix/mysql/virtual-mailbox-domains.cf
virtual_alias_maps = mysql:/etc/postfix/mysql/virtual-alias-maps.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql/virtual-mailbox-maps.cf
virtual_transport = lmtp:127.0.0.1:24A hivatkozott fájlok tartalma (azokat neked kell létrehozni):
root@mailserver:~# cat /etc/postfix/mysql/virtual-mailbox-domains.cf
user = mailuser
password = mailpassword
hosts = 127.0.0.1
dbname = mailserver
query = SELECT 1 FROM virtual_domains WHERE name='%s'root@mailserver:~# cat /etc/postfix/mysql/virtual-alias-maps.cf
user = mailuser
password = mailpassword
hosts = 127.0.0.1
dbname = mailserver
query = SELECT destination FROM virtual_aliases WHERE source='%s' ORDER BY source DESCroot@mailserver:~# cat /etc/postfix/mysql/virtual-mailbox-maps.cf
user = mailuser
password = mailpassword
hosts = 127.0.0.1
dbname = mailserver
query = SELECT 1 FROM virtual_users WHERE email='%s'És most jön a feketeleves. A Postfixet újraindítjuk és a Roundcube alól nem megy a levélküldés, sőt a tesztelésre használt Thunderbird sem enged már be rendszer felhasználóként. Ugye a Thunderbird-ben beállított oregon user már nem létezik a jelenlegi kontextusban, mivel a Dovecot authentikációját átállítottuk SQL alapúra. Eközben a Postfix sasl alapú authentikációval rendelkezik, miközben mi egy virtuális felhasználóval akarunk bejelentkezni.
Ne csüggedjünk, van megoldás. Mint korábban utaltam rá, a Dovecot tud olyat, hogy login után lerak egy token-t amit a Postfix tud olvasni. Cseles módja az authentikációnak. Kapcsoljuk be!
Kezdjük a Dovecot-tal, szerkesszük a /etc/dovecot/conf.d/10-master.conf fájban :
service auth {
# Postfix smtp-auth
unix_listener /var/spool/postfix/private/auth {
mode = 0666
user=postfix
group=postfix
}
}A Postfix main.cf végéhez adjuk hozzá az alábbi sorokat:
# DOVECOT AUTH
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yesIndítsuk újra a Dovecot-ot, majd a Postfix-et. Gratulálok! Mostanra van egy teljesen jól működő mailszervered!
Dovecot finomhangolás, kényelmi beállítások
Az alapértelmezett levelezési könyvtárakat létre tudja hozni a Dovecot. Ezt a /etc/dovecot/conf.d/15-mailboxes.conf fájban tudod beállítani. Ha ezen beállításokhoz, hozzáadjuk az auto = subscribe -t, akkor nem kell a felhasználónak feliratkoznia az adott könyvtárra. Így alapból megjelenik neki a kliens szoftverében, ami lehet akár a Roundcube is.
mailbox Sent {
auto = subscribe
special_use = \Sent
}Ilyen könyvtárak pl.: Drafts, Junk, Trash, Sent
Managesieve használata
A sieve egy szerveroldali levélszűrő. Ő az imapok procmailje! 🙂 A Roundcube alapból kezeli, mint levélszűrőt.
Kezdjük a telepítéssel:
oregon@mailserver:~ $ sudo apt install dovecot-managesieved Amúgy ennyi, de ahhoz, hogy a Roundcube is kezelni tudja a managesieve-t, be kell húznunk a Roundcube configjába a plugin-t. Ez a plugin a Roundcube default telepítés része, csak nincs aktiválva benne. Szerkesszük a /var/www/html/config/config.inc.php fájt (Tudod: nekem a /var/www/html a Roundcube home-ja):
// List of active plugins (in plugins/ directory)
$config['plugins'] = [
'archive',
'zipdownload',
'managesieve',
];Mentés után, a Roundcube-ban megjelenik az „Üzenetszűrők” funkció:
A szűrőket a Roundcube-ban tudod sorba rendezni drag&drop-pal.
Ezzel a képpel búcsúzom, fenntartva a jogot e bejegyzés frissítésére. Minden visszajelzésnek örülök. Használd a kommentelési lehetőséget. Köszönöm az eddigi türelmet és figyelmet. Engedd meg, hogy elsőként gratuláljak a kitartásodhoz azért, mert ezt az egészet végigolvastad. Ha végig is csináltad, akkor az egy megariszpekt! Gratulálok hozzá!
Utószó
Amikor ezt a leírást készítettem az volt a szándékom, hogy meghozzam az emberek kedvét a saját mailszerver felállításához. Végigolvasva újra és újra, valószínűleg kontra-produktív voltam. 🙂 Nagyon sok egyéb ismeret szükséges ahhoz, hogy valaki mailszervert üzemeltessen. Ez a leírás is messze nem teljes, inkább csak elégséges. Ahhoz mindenképpen elegendő, hogy megjelenhess a szolgáltatással az interneten a bejegyzés keltének pillanatában, de erre azért garanciát ne várj tőlem. Ezt a leírást tekintsd úgy, mintegy műkedvelő művét. Tekintsd esettanulmánynak, mely szerint van olyan cég az interneten, aki így oldotta meg ezt a feladatot, de semmiképpen ne ez legyen a bibliád. Maradj kritikus, olvass mindennek utána. Én nagyon határozottan tudok hülyeséget mondani és ez megtévesztő lehet számodra.
Ez a leírás megmutatta az olvasónak azt, amiért a Linux szerelmese lettem. Olyan az egész, mint a Lego. Kellő fantáziával és szorgalommal, bármit megépíthetsz belőle. Az alkalmazások és a szolgáltatások ehhez az építőelemek. Az építőmester te magad vagy.
Nmap… hát az pont erre nem igazán jó.
Itt egy pici python program:
—————–
Ezt elindítod, akkor vár arra, hogy valaki küldjön valamit a gép bármely interface-én a 1989-es TCP portra.
Nézd meg, ebből mit látsz egy sima nmap localhost paranccsal! 🙂
Az nmap az ismert szolgáltatások portjait nézi meg külön paraméterek nélkül. Esetleg megadhatod neki, hogy 0-65535 közt minden portot nézzen végig, de nem egyszerűbb egy ss/netstat, akár lsof is vagy végső esetben a /proc alatt körülnézni? 🙂