🥇Debian + Postfix + Dovecot + Multidomain + SSL + IPv6 + OpenVPN + Multi-интерфейси + SpamAssassin-learn + Bind

Тази статия е за това как да настроите модерен пощенски сървър.
Postfix + Dovecot. SPF + DKIM + rDNS. С IPv6.
С TSL криптиране. С поддръжка за множество домейни - част с истински SSL сертификат.
С антиспам защита и висок антиспам рейтинг от други пощенски сървъри.
Поддържа множество физически интерфейси.
С OpenVPN, връзката към която е чрез IPv4 и която осигурява IPv6.

Ако не искате да научите всички тези технологии, но искате да настроите такъв сървър, тогава тази статия е за вас.

Статията не се опитва да обясни всеки детайл. Обяснението се отнася до това, което не е конфигурирано като стандарт или е важно от гледна точка на потребителя.

Мотивацията да създам пощенски сървър беше моя отдавнашна мечта. Това може да звучи глупаво, но IMHO е много по-добре, отколкото да мечтаете за нова кола от любимата си марка.

Има две мотивации за настройка на IPv6. ИТ специалистът трябва постоянно да учи нови технологии, за да оцелее. Бих искал да дам своя скромен принос в борбата срещу цензурата.

Мотивацията за настройка на OpenVPN е просто IPv6 да работи на локалната машина.
Мотивацията за настройка на няколко физически интерфейса е, че на моя сървър имам един интерфейс „бавен, но неограничен“ и друг „бърз, но с тарифа“.

Мотивацията за настройване на настройките за свързване е, че моят интернет доставчик предоставя нестабилен DNS сървър, а google също понякога се проваля. Искам стабилен DNS сървър за лична употреба.

Мотивация да напиша статия - написах чернова преди 10 месеца и вече я прегледах два пъти. Дори ако авторът редовно се нуждае от него, има голяма вероятност и други да имат нужда от него.

Няма универсално решение за пощенски сървър. Но ще се опитам да напиша нещо като „направете това и след това, когато всичко работи както трябва, изхвърлете допълнителните неща.“

Компанията tech.ru разполага със сървър за колокация. Възможно е сравнение с OVH, Hetzner, AWS. За да разрешите този проблем, сътрудничеството с tech.ru ще бъде много по-ефективно.

Debian 9 е инсталиран на сървъра.

Сървърът има 2 интерфейса `eno1` и `eno2`. Първият е неограничен, а вторият е бърз, съответно.

Има 3 статични IP адреса, XX.XX.XX.X0 и XX.XX.XX.X1 и XX.XX.XX.X2 на интерфейса „eno1“ и XX.XX.XX.X5 на интерфейса „eno2“ .

Наличен XXXX:XXXX:XXXX:XXXX ::/64 набор от IPv6 адреси, които са присвоени на интерфейса `eno1` и от него XXXX:XXXX:XXXX:XXXX:1:2::/96 беше присвоен на `eno2` по моя заявка.

Има 3 домейна `domain1.com`, `domain2.com`, `domain3.com`. Има SSL сертификат за `domain1.com` и `domain3.com`.

Имам акаунт в Google, с който бих искал да свържа пощенската си кутия[имейл защитен]` (получаване и изпращане на поща директно от интерфейса на gmail).
Трябва да има пощенска кутия`[имейл защитен]`, копие на имейла, от който искам да виждам в моя gmail. И е рядкост да можете да изпратите нещо от името на `[имейл защитен]` чрез уеб интерфейса.

Трябва да има пощенска кутия`[имейл защитен]`, който Иванов ще използва от своя iPhone.

Изпратените имейли трябва да отговарят на всички съвременни антиспам изисквания.
В обществените мрежи трябва да има най-високо ниво на криптиране.
Трябва да има IPv6 поддръжка както за изпращане, така и за получаване на писма.
Трябва да има SpamAssassin, който никога няма да изтрие имейли. И той или ще отскочи, или ще пропусне, или ще изпрати в папката „Спам“ на IMAP.
Автоматичното обучение на SpamAssassin трябва да бъде конфигурирано: ако преместя писмо в папката Спам, то ще се научи от това; ако преместя писмо от папката Спам, то ще се научи от това. Резултатите от обучението на SpamAssassin трябва да повлияят дали писмото ще попадне в папката за спам.
PHP скриптовете трябва да могат да изпращат поща от името на всеки домейн на даден сървър.
Трябва да има услуга openvpn с възможност за използване на IPv6 на клиент, който няма IPv6.

Първо трябва да конфигурирате интерфейси и маршрутизиране, включително IPv6.
След това ще трябва да конфигурирате OpenVPN, който ще се свързва чрез IPv4 и ще предоставя на клиента статичен-реален IPv6 адрес. Този клиент ще има достъп до всички IPv6 услуги на сървъра и достъп до всички IPv6 ресурси в Интернет.
След това ще трябва да конфигурирате Postfix за изпращане на писма + SPF + DKIM + rDNS и други подобни малки неща.
След това ще трябва да конфигурирате Dovecot и Multidomain.
След това ще трябва да конфигурирате SpamAssassin и да конфигурирате обучение.
Накрая инсталирайте Bind.

============= Мултиинтерфейси ==============

За да конфигурирате интерфейси, трябва да напишете това в “/etc/network/interfaces”.

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug eno1
iface eno1 inet static
        address XX.XX.XX.X0/24
        gateway XX.XX.XX.1
        dns-nameservers 127.0.0.1 213.248.1.6
        post-up ip route add XX.XX.XX.0/24 dev eno1 src XX.XX.XX.X0 table eno1t
        post-up ip route add default via XX.XX.XX.1 table eno1t
        post-up ip rule add table eno1t from XX.XX.XX.X0
        post-up ip rule add table eno1t to XX.XX.XX.X0

auto eno1:1
iface eno1:1 inet static
address XX.XX.XX.X1
netmask 255.255.255.0
        post-up ip rule add table eno1t from XX.XX.XX.X1
        post-up ip rule add table eno1t to XX.XX.XX.X1
        post-up   ip route add 10.8.0.0/24 dev tun0 src XX.XX.XX.X1 table eno1t
        post-down ip route del 10.8.0.0/24 dev tun0 src XX.XX.XX.X1 table eno1t

auto eno1:2
iface eno1:2 inet static
address XX.XX.XX.X2
netmask 255.255.255.0
        post-up ip rule add table eno1t from XX.XX.XX.X2
        post-up ip rule add table eno1t to XX.XX.XX.X2

iface eno1 inet6 static
        address XXXX:XXXX:XXXX:XXXX:1:1::/64
        gateway XXXX:XXXX:XXXX:XXXX::1
        up   ip -6 addr add XXXX:XXXX:XXXX:XXXX:1:1:1:1/64 dev $IFACE
        up   ip -6 addr add XXXX:XXXX:XXXX:XXXX:1:1:1:2/64 dev $IFACE
        down ip -6 addr del XXXX:XXXX:XXXX:XXXX:1:1:1:1/64 dev $IFACE
        down ip -6 addr del XXXX:XXXX:XXXX:XXXX:1:1:1:2/64 dev $IFACE

# The secondary network interface
allow-hotplug eno2
iface eno2 inet static
        address XX.XX.XX.X5
        netmask 255.255.255.0
        post-up   ip route add XX.XX.XX.0/24 dev eno2 src XX.XX.XX.X5 table eno2t
        post-up   ip route add default via XX.XX.XX.1 table eno2t
        post-up   ip rule add table eno2t from XX.XX.XX.X5
        post-up   ip rule add table eno2t to XX.XX.XX.X5
        post-up   ip route add 10.8.0.0/24 dev tun0 src XX.XX.XX.X5 table eno2t
        post-down ip route del 10.8.0.0/24 dev tun0 src XX.XX.XX.X5 table eno2t

iface eno2 inet6 static
        address XXXX:XXXX:XXXX:XXXX:1:2::/96
        up   ip -6 addr add XXXX:XXXX:XXXX:XXXX:1:2:1:1/64 dev $IFACE
        up   ip -6 addr add XXXX:XXXX:XXXX:XXXX:1:2:1:2/64 dev $IFACE
        down ip -6 addr del XXXX:XXXX:XXXX:XXXX:1:2:1:1/64 dev $IFACE
        down ip -6 addr del XXXX:XXXX:XXXX:XXXX:1:2:1:2/64 dev $IFACE

# OpenVPN network
iface tun0 inet6 static
        address XXXX:XXXX:XXXX:XXXX:1:3::/80

Тези настройки могат да се приложат на всеки сървър в tech.ru (с малко съгласуване с поддръжката) и веднага ще работи както трябва.

Ако имате опит в настройването на подобни неща за Hetzner, OVH, там е различно. По-трудно.

eno1 е името на мрежова карта №1 (бавна, но неограничена).
eno2 е името на мрежова карта №2 (бърза, но с тарифа).
tun0 е името на виртуалната мрежова карта от OpenVPN.
XX.XX.XX.X0 - IPv4 #1 на eno1.
XX.XX.XX.X1 - IPv4 #2 на eno1.
XX.XX.XX.X2 - IPv4 #3 на eno1.
XX.XX.XX.X5 - IPv4 #1 на eno2.
XX.XX.XX.1 - IPv4 шлюз.
XXXX:XXXX:XXXX:XXXX ::/64 - IPv6 за целия сървър.
XXXX:XXXX:XXXX:XXXX:1:2::/96 - IPv6 за eno2, всичко останало отвън отива в eno1.
XXXX:XXXX:XXXX:XXXX::1 — IPv6 шлюз (трябва да се отбележи, че това може/трябва да се направи по различен начин. Посочете превключвателя IPv6).
dns-nameservers - посочва се 127.0.0.1 (защото bind е инсталиран локално) и 213.248.1.6 (това е от tech.ru).

“таблица eno1t” и “таблица eno2t” - значението на тези правила за маршрут е, че трафикът, влизащ през eno1 ->, ще излиза през нея, а трафикът, влизащ през eno2 ->, ще излиза през нея. И също така връзките, инициирани от сървъра, ще минават през eno1.

ip route add default via XX.XX.XX.1 table eno1t

С тази команда указваме всеки неразбираем трафик, който попада под което и да е правило, означено с „таблица eno1t“ -> да бъде изпратен към интерфейса eno1.

ip route add XX.XX.XX.0/24 dev eno1 src XX.XX.XX.X0 table eno1t

С тази команда указваме, че всеки трафик, иницииран от сървъра, трябва да бъде насочен към интерфейса eno1.

ip rule add table eno1t from XX.XX.XX.X0
ip rule add table eno1t to XX.XX.XX.X0

С тази команда задаваме правилата за маркиране на трафика.

auto eno1:2
iface eno1:2 inet static
address XX.XX.XX.X2
netmask 255.255.255.0
        post-up ip rule add table eno1t from XX.XX.XX.X2
        post-up ip rule add table eno1t to XX.XX.XX.X2

Този блок определя втори IPv4 за интерфейса eno1.

ip route add 10.8.0.0/24 dev tun0 src XX.XX.XX.X1 table eno1t

С тази команда задаваме маршрута от OpenVPN клиенти към локален IPv4 с изключение на XX.XX.XX.X0.
Все още не разбирам защо тази команда е достатъчна за всички IPv4.

iface eno1 inet6 static
        address XXXX:XXXX:XXXX:XXXX:1:1::/64
        gateway XXXX:XXXX:XXXX:XXXX::1

Тук задаваме адреса на самия интерфейс. Сървърът ще го използва като „изходящ“ адрес. Няма да се използва по никакъв начин отново.

Защо ":1:1::" е толкова сложно? Така че OpenVPN да работи правилно и само за това. Повече за това по-късно.

По темата за портала - така работи и това е добре. Но правилният начин е да посочите тук IPv6 на комутатора, към който е свързан сървърът.

По някаква причина обаче IPv6 спира да работи, ако направя това. Това вероятно е някакъв проблем на tech.ru.

ip -6 addr add XXXX:XXXX:XXXX:XXXX:1:1:1:1/64 dev $IFACE

Това е добавяне на IPv6 адрес към интерфейса. Ако имате нужда от сто адреса, това означава сто реда в този файл.

iface eno1 inet6 static
        address XXXX:XXXX:XXXX:XXXX:1:1::/64
...
iface eno2 inet6 static
        address XXXX:XXXX:XXXX:XXXX:1:2::/96
...
iface tun0 inet6 static
        address XXXX:XXXX:XXXX:XXXX:1:3::/80

Отбелязах адресите и подмрежите на всички интерфейси, за да стане ясно.
eno1 - трябва да бъде "/64“ – защото това е целият ни набор от адреси.
tun0 - подмрежата трябва да е по-голяма от eno1. В противен случай няма да е възможно да конфигурирате IPv6 шлюз за OpenVPN клиенти.
eno2 - подмрежата трябва да е по-голяма от tun0. В противен случай OpenVPN клиентите няма да имат достъп до локални IPv6 адреси.
За по-голяма яснота избрах стъпка на подмрежата от 16, но ако желаете, можете дори да направите стъпка „1“.
Съответно 64+16 = 80 и 80+16 = 96.

За още по-голяма яснота:
XXXX:XXXX:XXXX:XXXX:1:1:YYYY:YYYY са адреси, които трябва да бъдат присвоени на конкретни сайтове или услуги в интерфейса eno1.
XXXX:XXXX:XXXX:XXXX:1:2:YYYY:YYYY са адреси, които трябва да бъдат присвоени на конкретни сайтове или услуги в интерфейса eno2.
XXXX:XXXX:XXXX:XXXX:1:3:YYYY:YYYY са адреси, които трябва да бъдат присвоени на клиенти на OpenVPN или използвани като адреси на OpenVPN услуги.

За да конфигурирате мрежата, трябва да е възможно да рестартирате сървъра.
Промените в IPv4 се улавят при изпълнение (уверете се, че сте го обвили в екрана - в противен случай тази команда просто ще срине мрежата на сървъра):

/etc/init.d/networking restart

Добавете в края на файла “/etc/iproute2/rt_tables”:

100 eno1t
101 eno2t

Без това не можете да използвате персонализирани таблици във файла „/etc/network/interfaces“.
Числата трябва да са уникални и по-малки от 65535.

Промените в IPv6 могат да се променят лесно без рестартиране, но за да направите това, трябва да научите поне три команди:

ip -6 addr ...
ip -6 route ...
ip -6 neigh ...

Настройка "/etc/sysctl.conf"

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward = 1

# Do not accept ICMP redirects (prevent MITM attacks)
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

# Do not send ICMP redirects (we are not a router)
net.ipv4.conf.all.send_redirects = 0

# For receiving ARP replies
net.ipv4.conf.all.arp_filter = 0
net.ipv4.conf.default.arp_filter = 0

# For sending ARP
net.ipv4.conf.all.arp_announce = 0
net.ipv4.conf.default.arp_announce = 0

# Enable IPv6
net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.lo.disable_ipv6 = 0

# IPv6 configuration
net.ipv6.conf.all.autoconf = 1
net.ipv6.conf.all.accept_ra = 0

# For OpenVPN
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.proxy_ndp = 1

# For nginx on boot
net.ipv6.ip_nonlocal_bind = 1

Това са настройките на моя сървър "sysctl". Нека отбележа нещо важно.

net.ipv4.ip_forward = 1

Без това OpenVPN изобщо няма да работи.

net.ipv6.ip_nonlocal_bind = 1

Всеки, който се опита да обвърже IPv6 (например nginx) веднага след като интерфейсът е готов, ще получи грешка. Че този адрес не е наличен.

За да се избегне такава ситуация, се прави такава настройка.

net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.proxy_ndp = 1

Без тези IPv6 настройки трафикът от OpenVPN клиента не излиза в света.

Другите настройки или не са подходящи, или не помня за какво са.
Но за всеки случай го оставям „както е“.

За да могат промените в този файл да бъдат взети без рестартиране на сървъра, трябва да изпълните командата:

sysctl -p

Повече подробности за правилата за „маса“: habr.com/post/108690

============== OpenVPN ==============

OpenVPN IPv4 не работи без iptables.

Моите iptables са като тези за VPN:

iptables -A INPUT -p udp -s YY.YY.YY.YY --dport 1194 -j ACCEPT
iptables -A FORWARD -i tun0 -o eno1 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eno1 -j SNAT --to-source XX.XX.XX.X0
##iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eno1 -j MASQUERADE
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -j DROP
iptables -A FORWARD -p udp --dport 1194 -j DROP

YY.YY.YY.YY е моят статичен IPv4 адрес на локалната машина.
10.8.0.0/24 - IPv4 openvpn мрежа. IPv4 адреси за openvpn клиенти.
Последователността на правилата е важна.

iptables -A INPUT -p udp -s YY.YY.YY.YY --dport 1194 -j ACCEPT
iptables -A FORWARD -i tun0 -o eno1 -j ACCEPT
...
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p udp --dport 1194 -j DROP
iptables -A FORWARD -p udp --dport 1194 -j DROP

Това е ограничение, така че само аз да мога да използвам OpenVPN от моя статичен IP.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eno1 -j SNAT --to-source XX.XX.XX.X0
  -- или --
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eno1 -j MASQUERADE

За да препращате IPv4 пакети между OpenVPN клиенти и интернет, трябва да регистрирате една от тези команди.

За различни случаи една от опциите не е подходяща.
И двете команди са подходящи за моя случай.
След като прочетох документацията, избрах първата опция, защото използва по-малко CPU.

За да могат всички настройки на iptables да бъдат взети след рестартиране, трябва да ги запазите някъде.

iptables-save > /etc/iptables/rules.v4
ip6tables-save > /etc/iptables/rules.v6

Такива имена не са избрани случайно. Те се използват от пакета "iptables-persistent".

apt-get install iptables-persistent

Инсталиране на основния OpenVPN пакет:

apt-get install openvpn easy-rsa

Нека да настроим шаблон за сертификати (заменете вашите стойности):

make-cadir ~/openvpn-ca
cd ~/openvpn-ca
ln -s openssl-1.0.0.cnf openssl.cnf

Нека редактираме настройките на шаблона на сертификата:

mcedit vars

...
# These are the default values for fields
# which will be placed in the certificate.
# Don't leave any of these fields blank.
export KEY_COUNTRY="RU"
export KEY_PROVINCE="Krasnodar"
export KEY_CITY="Dinskaya"
export KEY_ORG="Own"
export KEY_EMAIL="[email protected]"
export KEY_OU="VPN"

# X509 Subject Field
export KEY_NAME="server"
...

Създайте сървърен сертификат:

cd ~/openvpn-ca
source vars
./clean-all
./build-ca
./build-key-server server
./build-dh
openvpn --genkey --secret keys/ta.key

Нека подготвим способността за създаване на окончателните файлове „client-name.opvn“:

mkdir -p ~/client-configs/files
chmod 700 ~/client-configs/files
cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf ~/client-configs/base.conf
mcedit ~/client-configs/base.conf

# Client mode
client

# Interface tunnel type
dev tun

# TCP protocol
proto tcp-client

# Address/Port of VPN server
remote XX.XX.XX.X0 1194

# Don't bind to local port/address
nobind

# Don't need to re-read keys and re-create tun at restart
persist-key
persist-tun

# Remote peer must have a signed certificate
remote-cert-tls server
ns-cert-type server

# Enable compression
comp-lzo

# Custom
ns-cert-type server
tls-auth ta.key 1
cipher DES-EDE3-CBC

Нека подготвим скрипт, който ще обедини всички файлове в един opvn файл.

mcedit ~/client-configs/make_config.sh
chmod 700 ~/client-configs/make_config.sh

#!/bin/bash

# First argument: Client identifier

KEY_DIR=~/openvpn-ca/keys
OUTPUT_DIR=~/client-configs/files
BASE_CONFIG=~/client-configs/base.conf

cat ${BASE_CONFIG} 
    <(echo -e '<ca>') 
    ${KEY_DIR}/ca.crt 
    <(echo -e '</ca>n<cert>') 
    ${KEY_DIR}/.crt 
    <(echo -e '</cert>n<key>') 
    ${KEY_DIR}/.key 
    <(echo -e '</key>n<tls-auth>') 
    ${KEY_DIR}/ta.key 
    <(echo -e '</tls-auth>') 
    > ${OUTPUT_DIR}/.ovpn

Създаване на първия OpenVPN клиент:

cd ~/openvpn-ca
source vars
./build-key client-name
cd ~/client-configs
./make_config.sh client-name

Файлът „~/client-configs/files/client-name.ovpn“ се изпраща до устройството на клиента.

За iOS клиенти ще трябва да направите следния трик:
Съдържанието на тага "tls-auth" трябва да е без коментари.
И също така поставете „key-direction 1“ непосредствено преди маркера „tl-auth“.

Нека конфигурираме конфигурацията на OpenVPN сървъра:

cd ~/openvpn-ca/keys
cp ca.crt ca.key server.crt server.key ta.key dh2048.pem /etc/openvpn
gunzip -c /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz | tee /etc/openvpn/server.conf
mcedit /etc/openvpn/server.conf

# Listen port
port 1194

# Protocol
proto tcp-server

# IP tunnel
dev tun0
tun-ipv6
push tun-ipv6

# Master certificate
ca ca.crt

# Server certificate
cert server.crt

# Server private key
key server.key

# Diffie-Hellman parameters
dh dh2048.pem

# Allow clients to communicate with each other
client-to-client

# Client config dir
client-config-dir /etc/openvpn/ccd

# Run client-specific script on connection and disconnection
script-security 2
client-connect "/usr/bin/sudo -u root /etc/openvpn/server-clientconnect.sh"
client-disconnect "/usr/bin/sudo -u root /etc/openvpn/server-clientdisconnect.sh"

# Server mode and client subnets
server 10.8.0.0 255.255.255.0
server-ipv6 XXXX:XXXX:XXXX:XXXX:1:3::/80
topology subnet

# IPv6 routes
push "route-ipv6 XXXX:XXXX:XXXX:XXXX::/64"
push "route-ipv6 2000::/3"

# DNS (for Windows)
# These are OpenDNS
push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"

# Configure all clients to redirect their default network gateway through the VPN
push "redirect-gateway def1 bypass-dhcp"
push "redirect-gateway ipv6" #For iOS

# Don't need to re-read keys and re-create tun at restart
persist-key
persist-tun

# Ping every 10s. Timeout of 120s.
keepalive 10 120

# Enable compression
comp-lzo

# User and group
user vpn
group vpn

# Log a short status
status openvpn-status.log

# Logging verbosity
##verb 4

# Custom config
tls-auth ta.key 0
cipher DES-EDE3-CBC

Това е необходимо, за да зададете статичен адрес за всеки клиент (не е необходимо, но го използвам):

# Client config dir
client-config-dir /etc/openvpn/ccd

Най-трудният и ключов детайл.

За съжаление, OpenVPN все още не знае как да конфигурира самостоятелно IPv6 шлюз за клиенти.
Трябва „ръчно“ да препратите това за всеки клиент.

# Run client-specific script on connection and disconnection
script-security 2
client-connect "/usr/bin/sudo -u root /etc/openvpn/server-clientconnect.sh"
client-disconnect "/usr/bin/sudo -u root /etc/openvpn/server-clientdisconnect.sh"

Файл „/etc/openvpn/server-clientconnect.sh“:

#!/bin/sh

# Check client variables
if [ -z "$ifconfig_pool_remote_ip" ] || [ -z "$common_name" ]; then
        echo "Missing environment variable."
        exit 1
fi

# Load server variables
. /etc/openvpn/variables

ipv6=""

# Find out if there is a specific config with fixed IPv6 for this client
if [ -f "/etc/openvpn/ccd/$common_name" ]; then
        # Get fixed IPv6 from client config file
        ipv6=$(sed -nr 's/^.*ifconfig-ipv6-push[ t]+([0-9a-fA-F:]+).*$/1/p' "/etc/openvpn/ccd/$common_name")
        echo $ipv6
fi

# Get IPv6 from IPv4
if [ -z "$ipv6" ]; then
        ipp=$(echo "$ifconfig_pool_remote_ip" | cut -d. -f4)
        if ! [ "$ipp" -ge 2 -a "$ipp" -le 254 ] 2>/dev/null; then
                echo "Invalid IPv4 part."
                exit 1
        fi
        hexipp=$(printf '%x' $ipp)
        ipv6="$prefix$hexipp"
fi

# Create proxy rule
/sbin/ip -6 neigh add proxy $ipv6 dev eno1

Файл „/etc/openvpn/server-clientdisconnect.sh“:

#!/bin/sh

# Check client variables
if [ -z "$ifconfig_pool_remote_ip" ] || [ -z "$common_name" ]; then
        echo "Missing environment variable."
        exit 1
fi

# Load server variables
. /etc/openvpn/variables

ipv6=""

# Find out if there is a specific config with fixed IPv6 for this client
if [ -f "/etc/openvpn/ccd/$common_name" ]; then
        # Get fixed IPv6 from client config file
        ipv6=$(sed -nr 's/^.*ifconfig-ipv6-push[ t]+([0-9a-fA-F:]+).*$/1/p' "/etc/openvpn/ccd/$common_name")
fi

# Get IPv6 from IPv4
if [ -z "$ipv6" ]; then
        ipp=$(echo "$ifconfig_pool_remote_ip" | cut -d. -f4)
        if ! [ "$ipp" -ge 2 -a "$ipp" -le 254 ] 2>/dev/null; then
                echo "Invalid IPv4 part."
                exit 1
        fi
        hexipp=$(printf '%x' $ipp)
        ipv6="$prefix$hexipp"
fi

# Delete proxy rule
/sbin/ip -6 neigh del proxy $ipv6 dev eno1

И двата скрипта използват файла „/etc/openvpn/variables“:

# Subnet
prefix=XXXX:XXXX:XXXX:XXXX:2:
# netmask
prefixlen=112

Трудно ми е да си спомня защо е написано така.

Сега мрежовата маска = 112 изглежда странно (трябва да е 96 точно там).
И префиксът е странен, не съвпада с мрежата tun0.
Но добре, ще го оставя както е.

cipher DES-EDE3-CBC

Това не е за всеки - аз избрах този метод за криптиране на връзката.

Научете повече за настройката на OpenVPN IPv4.

Научете повече за настройката на OpenVPN IPv6.

============= Postfix =============

Инсталиране на основния пакет:

apt-get install postfix

Когато инсталирате, изберете „интернет сайт“.

Моят "/etc/postfix/main.cf" изглежда така:

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

readme_directory = no

# See http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
compatibility_level = 2

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/domain1.com.2018.chained.crt
smtpd_tls_key_file=/etc/ssl/domain1.com.2018.key
smtpd_use_tls=yes
smtpd_tls_auth_only = yes
smtp_bind_address = XX.XX.XX.X0
smtp_bind_address6 = XXXX:XXXX:XXXX:XXXX:1:1:1:1

smtp_tls_security_level = may
smtp_tls_ciphers = export
smtp_tls_protocols = !SSLv2, !SSLv3
smtp_tls_loglevel = 1

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = domain1.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = domain1.com
mydestination = localhost
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = ipv4

internal_mail_filter_classes = bounce

# Storage type
virtual_transport = lmtp:unix:private/dovecot-lmtp
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf

# SMTP-Auth settings
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_recipient_restrictions =
        permit_sasl_authenticated,
        permit_mynetworks,
        #reject_invalid_hostname,
        #reject_unknown_recipient_domain,
        reject_unauth_destination,
        reject_rbl_client sbl.spamhaus.org,
        check_policy_service unix:private/policyd-spf

smtpd_helo_restrictions =
        #reject_invalid_helo_hostname,
        #reject_non_fqdn_helo_hostname,
        reject_unknown_helo_hostname

smtpd_client_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_non_fqdn_helo_hostname,
        permit

# SPF
policyd-spf_time_limit = 3600

# OpenDKIM
milter_default_action = accept
milter_protocol = 6
smtpd_milters = unix:var/run/opendkim/opendkim.sock
non_smtpd_milters = unix:var/run/opendkim/opendkim.sock

# IP address per domain
sender_dependent_default_transport_maps = pcre:/etc/postfix/sdd_transport.pcre

Нека да разгледаме подробностите на тази конфигурация.

smtpd_tls_cert_file=/etc/ssl/domain1.com.2018.chained.crt
smtpd_tls_key_file=/etc/ssl/domain1.com.2018.key

Според жителите на Хабровск този блок съдържа „дезинформация и неверни тези“.Само 8 години след началото на кариерата си започнах да разбирам как работи SSL.

Затова ще си позволя да опиша как се използва SSL (без да отговарям на въпросите „Как работи?“ и „Защо работи?“).

Основата на съвременното криптиране е създаването на двойка ключове (два много дълги низа от знаци).

Единият „ключ“ е частен, а другият е „публичен“. Пазим частния ключ много внимателно в тайна. Раздаваме публичния ключ на всички.

С помощта на публичен ключ можете да шифровате низ от текст, така че само собственикът на частния ключ да може да го дешифрира.
Е, това е цялата основа на технологията.

Стъпка #1 - https сайтове.
При достъп до сайт браузърът научава от уеб сървъра, че сайтът е https и следователно изисква публичен ключ.
Уеб сървърът дава публичния ключ. Браузърът използва публичния ключ, за да шифрова http-заявката и да я изпрати.
Съдържанието на http-заявка може да бъде прочетено само от тези, които имат частния ключ, тоест само сървърът, към който е направена заявката.
Http-заявката съдържа поне URI. Следователно, ако една държава се опитва да ограничи достъпа не до целия сайт, а до конкретна страница, то това е невъзможно да се направи за https сайтове.

Стъпка #2 - криптиран отговор.
Уеб сървърът предоставя отговор, който лесно може да бъде прочетен на пътя.
Решението е изключително просто – браузърът локално генерира една и съща двойка ключове частен-публичен за всеки https сайт.
И заедно със заявката за публичния ключ на сайта, той изпраща своя локален публичен ключ.
Уеб сървърът го запомня и при изпращане на http-отговор го криптира с публичния ключ на конкретен клиент.
Сега http-отговорът може да бъде дешифриран само от собственика на частния ключ на браузъра на клиента (т.е. самия клиент).

Стъпка No3 - установяване на защитена връзка през публичен канал.
В пример № 2 има уязвимост - нищо не пречи на доброжелателите да прихванат http-заявка и да редактират информацията за публичния ключ.
По този начин посредникът ясно ще вижда цялото съдържание на изпратените и получените съобщения, докато комуникационният канал се промени.
Справянето с това е изключително лесно – просто изпратете публичния ключ на браузъра като съобщение, шифровано с публичния ключ на уеб сървъра.
След това уеб сървърът първо изпраща отговор като „вашият публичен ключ е такъв“ и криптира това съобщение със същия публичен ключ.
Браузърът разглежда отговора - ако се получи съобщението „вашият публичен ключ е такъв“ - това е 100% гаранция, че този комуникационен канал е защитен.
Колко безопасно е?
Самото създаване на такъв защитен комуникационен канал става със скорост ping*2. Например 20ms.
Нападателят трябва предварително да разполага с личния ключ на една от страните. Или намерете частен ключ за няколко милисекунди.
Хакването на един модерен частен ключ ще отнеме десетилетия на суперкомпютър.

Стъпка #4 - публична база данни с публични ключове.
Очевидно в цялата тази история има възможност нападател да седне на комуникационния канал между клиента и сървъра.
Клиентът може да се преструва, че е сървър, а сървърът може да се преструва, че е клиент. И емулирайте чифт ключове в двете посоки.
Тогава нападателят ще види целия трафик и ще може да го „редактира“.
Например, променете адреса, на който да изпратите пари или копирайте паролата от онлайн банкирането, или блокирайте „нежелателно“ съдържание.
За да се борят с такива нападатели, те излязоха с публична база данни с публични ключове за всеки https сайт.
Всеки браузър „знае“ за съществуването на около 200 такива бази данни. Това е предварително инсталирано във всеки браузър.
„Знанието“ е подкрепено от публичен ключ от всеки сертификат. Тоест връзката с всеки конкретен сертифициращ орган не може да бъде фалшифицирана.

Сега има просто разбиране как да използвате SSL за https.
Ако използвате мозъка си, ще стане ясно как специалните служби могат да хакнат нещо в тази структура. Но това ще им коства чудовищни усилия.
И организации, по-малки от NSA или CIA - почти невъзможно е да се хакне съществуващото ниво на защита, дори и за VIP персони.

Ще добавя и за ssh връзките. Там няма публични ключове, така че какво можете да направите? Въпросът се решава по два начина.
Опция ssh-по-парола:
По време на първата връзка ssh клиентът трябва да предупреди, че имаме нов публичен ключ от ssh сървъра.
И по време на следващи връзки, ако се появи предупреждението „нов публичен ключ от ssh сървъра“, това ще означава, че те се опитват да ви подслушват.
Или сте били подслушвани при първата си връзка, но сега комуникирате със сървъра без посредници.
Всъщност, поради факта, че фактът на подслушване се разкрива лесно, бързо и без усилия, тази атака се използва само в специални случаи за конкретен клиент.

Опция ssh по ключ:
Взимаме флаш устройство, записваме частния ключ за ssh сървъра върху него (има термини и много важни нюанси за това, но аз пиша образователна програма, а не инструкции за употреба).
Оставяме публичния ключ на машината, където ще бъде ssh клиента и също го пазим в тайна.
Носим флашката на сървъра, поставяме я, копираме частния ключ и изгаряме флашката и разпръсваме пепелта на вятъра (или поне я форматираме с нули).
Това е всичко - след такава операция ще бъде невъзможно да се хакне такава ssh връзка. Разбира се, след 10 години ще бъде възможно да видите трафика на суперкомпютър - но това е друга история.

Извинявам се за офтопика.

Сега, когато теорията е известна. Ще ви разкажа за процеса на създаване на SSL сертификат.

С помощта на „openssl genrsa“ създаваме частен ключ и „празни“ за публичния ключ.
Изпращаме „заготовките“ на трета компания, на която плащаме приблизително $9 за най-простия сертификат.

След няколко часа получаваме нашия „публичен“ ключ и набор от няколко публични ключа от тази трета страна.

Защо трябва трета компания да плаща за регистрацията на моя публичен ключ е отделен въпрос, няма да го разглеждаме тук.

Сега е ясно какво е значението на надписа:

smtpd_tls_key_file=/etc/ssl/domain1.com.2018.key

Папката “/etc/ssl” съдържа всички файлове за проблеми с ssl.
domain1.com — име на домейн.
2018 е годината на създаването на ключове.
“ключ” - обозначение, че файлът е частен ключ.

И значението на този файл:

smtpd_tls_cert_file=/etc/ssl/domain1.com.2018.chained.crt
domain1.com — име на домейн.
2018 е годината на създаването на ключове.
chained - обозначение, че има верига от публични ключове (първият е нашият публичен ключ, а останалите са това, което идва от компанията, която е издала публичния ключ).
crt - обозначение, че има готов сертификат (публичен ключ с технически обяснения).

smtp_bind_address = XX.XX.XX.X0
smtp_bind_address6 = XXXX:XXXX:XXXX:XXXX:1:1:1:1

Тази настройка не се използва в този случай, но е написана като пример.

Тъй като грешка в този параметър ще доведе до изпращане на спам от вашия сървър (без вашата воля).

Тогава докажете на всички, че не сте виновни.

recipient_delimiter = +

Много хора може да не знаят, но това е стандартен знак за класиране на имейли и се поддържа от повечето съвременни пощенски сървъри.

Например, ако имате пощенска кутия "[имейл защитен]"опитайте да изпратите до"[имейл защитен]"- виж какво излиза от това.

inet_protocols = ipv4

Това може да е объркващо.

Но не е просто така. Всеки нов домейн по подразбиране е само IPv4, след което включвам IPv6 за всеки поотделно.

virtual_transport = lmtp:unix:private/dovecot-lmtp
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf

Тук уточняваме, че цялата входяща поща отива в dovecot.
А правилата за домейн, пощенска кутия, псевдоним - погледнете в базата данни.

/etc/postfix/mysql-virtual-mailbox-domains.cf

user = usermail
password = mailpassword
hosts = 127.0.0.1
dbname = servermail
query = SELECT 1 FROM virtual_domains WHERE name='%s'

/etc/postfix/mysql-virtual-mailbox-maps.cf

user = usermail
password = mailpassword
hosts = 127.0.0.1
dbname = servermail
query = SELECT 1 FROM virtual_users WHERE email='%s'

/etc/postfix/mysql-virtual-alias-maps.cf

user = usermail
password = mailpassword
hosts = 127.0.0.1
dbname = servermail
query = SELECT destination FROM virtual_aliases WHERE source='%s'

# SMTP-Auth settings
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes

Сега postfix знае, че пощата може да бъде приета за по-нататъшно изпращане само след оторизация с dovecot.

Наистина не разбирам защо това се дублира тук. Вече сме посочили всичко необходимо във „virtual_transport“.

Но постфиксната система е много стара - вероятно е завръщане от старите дни.

smtpd_recipient_restrictions =
        ...

smtpd_helo_restrictions =
        ...

smtpd_client_restrictions =
        ...

Това може да се конфигурира по различен начин за всеки пощенски сървър.

Имам 3 пощенски сървъра на мое разположение и тези настройки са много различни поради различни изисквания за използване.

Трябва да го конфигурирате внимателно - в противен случай спамът ще се излее към вас или дори по-лошо - спамът ще излее от вас.

# SPF
policyd-spf_time_limit = 3600

Настройка за някакъв плъгин, свързан с проверка на SPF на входящи писма.

# OpenDKIM
milter_default_action = accept
milter_protocol = 6
smtpd_milters = unix:var/run/opendkim/opendkim.sock
non_smtpd_milters = unix:var/run/opendkim/opendkim.sock

Настройката е, че трябва да предоставим DKIM подпис с всички изходящи имейли.

# IP address per domain
sender_dependent_default_transport_maps = pcre:/etc/postfix/sdd_transport.pcre

Това е ключов детайл при маршрутизирането на писма при изпращане на писма от PHP скриптове.

Файл „/etc/postfix/sdd_transport.pcre“:

/^[email protected]$/ domain1:
/^[email protected]$/ domain2:
/^[email protected]$/ domain3:
/@domain1.com$/             domain1:
/@domain2.com$/             domain2:
/@domain3.com$/             domain3:

Отляво има регулярни изрази. Вдясно има етикет, който маркира буквата.
Postfix в съответствие с етикета - ще вземе предвид още няколко реда за конфигурация за конкретна буква.

Как точно ще бъде преконфигуриран postfix за конкретна буква, ще бъде посочено в “master.cf”.

Редове 4, 5, 6 са основните. От името на кой домейн изпращаме писмото, поставяме този етикет.
Но полето „от“ не винаги е посочено в PHP скриптовете в стария код. Тогава потребителското име идва на помощ.

Статията вече е обширна - не бих искал да се разсейвам с настройката на nginx+fpm.

Накратко, за всеки сайт ние задаваме собствен собственик на linux-user. И съответно вашият fpm-пул.

Fpm-pool използва всяка версия на php (чудесно е, когато на един и същи сървър можете да използвате различни версии на php и дори различен php.ini за съседни сайтове без проблеми).

И така, конкретен потребител на Linux „www-domain2“ има уебсайт domain2.com. Този сайт има код за изпращане на имейли без посочване на полето от.

Така че дори и в този случай писмата ще бъдат изпратени правилно и никога няма да попаднат в спам.

Моят "/etc/postfix/master.cf" изглежда така:

...
smtp      inet  n       -       y       -       -       smtpd
  -o content_filter=spamassassin
...
submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
...
policyd-spf  unix  -       n       n       -       0       spawn
    user=policyd-spf argv=/usr/bin/policyd-spf

spamassassin unix -     n       n       -       -       pipe
    user=spamd argv=/usr/bin/spamc -f -e
    /usr/sbin/sendmail -oi -f ${sender} ${recipient}
...
domain1  unix -       -       n       -       -       smtp
   -o smtp_bind_address=XX.XX.XX.X1
   -o smtp_helo_name=domain1.com
   -o inet_protocols=all
   -o smtp_bind_address6=XXXX:XXXX:XXXX:XXXX:1:1:1:1
   -o syslog_name=postfix-domain1

domain2  unix -       -       n       -       -       smtp
   -o smtp_bind_address=XX.XX.XX.X5
   -o smtp_helo_name=domain2.com
   -o inet_protocols=all
   -o smtp_bind_address6=XXXX:XXXX:XXXX:XXXX:1:2:1:1
   -o syslog_name=postfix-domain2

domain3  unix -       -       n       -       -       smtp
   -o smtp_bind_address=XX.XX.XX.X2
   -o smtp_helo_name=domain3
   -o inet_protocols=all
   -o smtp_bind_address6=XXXX:XXXX:XXXX:XXXX:1:1:5:1
   -o syslog_name=postfix-domain3

Файлът не е предоставен пълен - вече е много голям.
Отбелязах само какво е променено.

smtp      inet  n       -       y       -       -       smtpd
  -o content_filter=spamassassin
...
spamassassin unix -     n       n       -       -       pipe
    user=spamd argv=/usr/bin/spamc -f -e
    /usr/sbin/sendmail -oi -f ${sender} ${recipient}

Това са настройки, свързани със spamassasin, повече за това по-късно.

submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

Ние ви позволяваме да се свържете с пощенския сървър през порт 587.
За да направите това, трябва да влезете.

policyd-spf  unix  -       n       n       -       0       spawn
    user=policyd-spf argv=/usr/bin/policyd-spf

Активиране на SPF проверка.

apt-get install postfix-policyd-spf-python

Нека инсталираме пакета за SPF проверки по-горе.

domain1  unix -       -       n       -       -       smtp
   -o smtp_bind_address=XX.XX.XX.X1
   -o smtp_helo_name=domain1.com
   -o inet_protocols=all
   -o smtp_bind_address6=XXXX:XXXX:XXXX:XXXX:1:1:1:1
   -o syslog_name=postfix-domain1

И това е най-интересното. Това е възможността да изпращате писма за определен домейн от определен IPv4/IPv6 адрес.

Това се прави в името на rDNS. rDNS е процес на получаване на низ чрез IP адрес.
А за пощата тази функция се използва, за да потвърди, че helo съвпада точно с rDNS на адреса, от който е изпратен имейлът.

Ако helo не съвпада с имейл домейна, от чието име е изпратено писмото, се присъждат точки за спам.

Helo не отговаря на rDNS - присъждат се много спам точки.
Съответно всеки домейн трябва да има собствен IP адрес.
За OVH - в конзолата е възможно да се посочи rDNS.
За tech.ru - проблемът се решава чрез поддръжка.
За AWS проблемът се разрешава чрез поддръжка.
“inet_protocols” и “smtp_bind_address6” - разрешаваме поддръжката на IPv6.
За IPv6 също трябва да регистрирате rDNS.
“syslog_name” - и това е за по-лесно четене на регистрационни файлове.

Купете сертификати Препоръчвам тук.

Настройване на връзка postfix+dovecot тук.

Настройка на SPF.

============= Гълъбарник ==============

apt-get install dovecot-imapd dovecot-pop3d dovecot-lmtpd dovecot-mysql dovecot-antispam

Настройка на mysql, инсталиране на самите пакети.

Файл "/etc/dovecot/conf.d/10-auth.conf"

disable_plaintext_auth = yes
auth_mechanisms = plain login

Оторизацията е само криптирана.

Файл „/etc/dovecot/conf.d/10-mail.conf“

mail_location = maildir:/var/mail/vhosts/%d/%n

Тук посочваме мястото за съхранение на буквите.

Искам да се съхраняват във файлове и групирани по домейн.

Файл "/etc/dovecot/conf.d/10-master.conf"

service imap-login {
  inet_listener imap {
    port = 0
  }
  inet_listener imaps {
    address = XX.XX.XX.X1, XX.XX.XX.X2, XX.XX.XX.X5, [XXXX:XXXX:XXXX:XXXX:1:1:1:1], [XXXX:XXXX:XXXX:XXXX:1:2:1:1], [XXXX:XXXX:XXXX:XXXX:1:1:5:1]
    port = 993
    ssl = yes
  }
}
service pop3-login {
  inet_listener pop3 {
    port = 0
  }
  inet_listener pop3s {
    address = XX.XX.XX.X1, XX.XX.XX.X2, XX.XX.XX.X5, [XXXX:XXXX:XXXX:XXXX:1:1:1:1], [XXXX:XXXX:XXXX:XXXX:1:2:1:1], [XXXX:XXXX:XXXX:XXXX:1:1:5:1]
    port = 995
    ssl = yes
  }
}
service lmtp {
  unix_listener /var/spool/postfix/private/dovecot-lmtp {
    mode = 0600
    user = postfix
    group = postfix
  }
}
service imap {
}
service pop3 {
}
service auth {
  unix_listener auth-userdb {
    mode = 0600
    user = vmail
  }

  unix_listener /var/spool/postfix/private/auth {
    mode = 0666
    user = postfix
    group = postfix
  }
  user = dovecot
}
service auth-worker {
  user = vmail
}
service dict {
  unix_listener dict {
  }
}

Това е основният конфигурационен файл на dovecot.
Тук деактивираме незащитените връзки.
И активирайте сигурни връзки.

Файл "/etc/dovecot/conf.d/10-ssl.conf"

ssl = required
ssl_cert = </etc/nginx/ssl/domain1.com.2018.chained.crt
ssl_key = </etc/nginx/ssl/domain1.com.2018.key
local XX.XX.XX.X5 {
  ssl_cert = </etc/nginx/ssl/domain2.com.2018.chained.crt
  ssl_key =  </etc/nginx/ssl/domain2.com.2018.key
}

Настройка на ssl. Посочваме, че е необходим ssl.
И самият сертификат. И важен детайл е „локалната“ директива. Показва кой SSL сертификат да се използва при свързване към кой локален IPv4.

Между другото, IPv6 не е конфигуриран тук, ще коригирам този пропуск по-късно.
XX.XX.XX.X5 (domain2) - няма сертификат. За да свържете клиенти, трябва да посочите domain1.com.
XX.XX.XX.X2 (domain3) - има сертификат, можете да посочите domain1.com или domain3.com за свързване на клиенти.

Файл "/etc/dovecot/conf.d/15-lda.conf"

protocol lda {
  mail_plugins = $mail_plugins sieve
}

Това ще е необходимо за spamassassin в бъдеще.

Файл "/etc/dovecot/conf.d/20-imap.conf"

protocol imap {
  mail_plugins = $mail_plugins antispam
}

Това е антиспам плъгин. Необходим за обучение на spamassasin по време на прехвърляне към/от папка „Спам“.

Файл "/etc/dovecot/conf.d/20-pop3.conf"

protocol pop3 {
}

Просто има такъв файл.

Файл „/etc/dovecot/conf.d/20-lmtp.conf“

protocol lmtp {
  mail_plugins = $mail_plugins sieve
  postmaster_address = [email protected]
}

Настройка на lmtp.

Файл "/etc/dovecot/conf.d/90-antispam.conf"

plugin {
  antispam_backend = pipe
  antispam_trash = Trash;trash
  antispam_spam = Junk;Spam;SPAM
  antispam_pipe_program_spam_arg = --spam
  antispam_pipe_program_notspam_arg = --ham
  antispam_pipe_program = /usr/bin/sa-learn
  antispam_pipe_program_args = --username=%Lu
}

Настройки за обучение на Spamassasin по време на прехвърляне към/от папката за спам.

Файл "/etc/dovecot/conf.d/90-sieve.conf"

plugin {
  sieve = ~/.dovecot.sieve
  sieve_dir = ~/sieve
  sieve_after = /var/lib/dovecot/sieve/default.sieve
}

Файл, който указва какво да се прави с входящи писма.

Файл "/var/lib/dovecot/sieve/default.sieve"

require ["fileinto", "mailbox"];

if header :contains "X-Spam-Flag" "YES" {
        fileinto :create "Spam";
}

Трябва да компилирате файла: “sievec default.sieve”.

Файл "/etc/dovecot/conf.d/auth-sql.conf.ext"

passdb {
  driver = sql
  args = /etc/dovecot/dovecot-sql.conf.ext
}
userdb {
  driver = static
  args = uid=vmail gid=vmail home=/var/mail/vhosts/%d/%n
}

Посочване на sql файлове за оторизация.
А самият файл се използва като метод за оторизация.

Файл "/etc/dovecot/dovecot-sql.conf.ext"

driver = mysql
connect = host=127.0.0.1 dbname=servermail user=usermail password=password
default_pass_scheme = SHA512-CRYPT
password_query = SELECT email as user, password FROM virtual_users WHERE email='%u';

Това съответства на подобни настройки за postfix.

Файл "/etc/dovecot/dovecot.conf"

protocols = imap lmtp pop3
listen = *, ::
dict {
}
!include conf.d/*.conf
!include_try local.conf

Основен конфигурационен файл.
Важното е, че тук посочваме - добавяне на протоколи.

============== SpamAssassin =============

apt-get install spamassassin spamc

Да инсталираме пакетите.

adduser spamd --disabled-login

Нека добавим потребител, от чието име.

systemctl enable spamassassin.service

Разрешаваме автоматично зареждане на услугата spamassassin при зареждане.

Файл "/etc/default/spamassassin":

CRON=1

Чрез активиране на автоматично актуализиране на правилата „по подразбиране“.

Файл „/etc/spamassassin/local.cf“:

report_safe 0

use_bayes          1
bayes_auto_learn   1
bayes_auto_expire  1
bayes_store_module Mail::SpamAssassin::BayesStore::MySQL
bayes_sql_dsn      DBI:mysql:sa:localhost:3306
bayes_sql_username sa
bayes_sql_password password

Трябва да създадете база данни „sa“ в mysql с потребител „sa“ с парола „password“ (заменете с нещо подходящо).

report_safe - това ще изпрати доклад за спам имейл вместо писмо.
use_bayes са настройки за машинно обучение spamassassin.

Останалите настройки на spamassassin бяха използвани по-рано в статията.

Обща настройка "spamassassin".
Относно преместването на нови спам имейли в папката „Спам“ на IMAP.
За проста комбинация от Dovecot + SpamAssassin.
Препоръчвам да прочетете теорията за обучение на spamassasin, когато премествате букви в папки на imap (и не препоръчвам да я използвате).

============= Призив към общността =============

Бих искал също така да хвърля идея в общността за това как да се повиши нивото на сигурност на препратените писма. Тъй като съм толкова дълбоко потопен в темата за пощата.

Така че потребителят може да създаде чифт ключове на своя клиент (outlook, thunderbird, плъгин за браузър, ...). Публични и частни. Публично - изпращане до DNS. Частно - спестете на клиента. Пощенските сървъри ще могат да използват публичен ключ за изпращане до конкретен получател.

И за да се предпазите от спам с такива писма (да, пощенският сървър няма да може да преглежда съдържанието) - ще трябва да въведете 3 правила:

Задължителен реален DKIM подпис, задължителен SPF, задължителен rDNS.
Невронна мрежа на тема антиспам обучение + база данни за нея от страна на клиента.
Алгоритъмът за криптиране трябва да е такъв, че изпращащата страна да изразходва 100 пъти повече мощност на процесора за криптиране от приемащата страна.

В допълнение към публичните писма, разработете стандартно писмо с предложение „за започване на сигурна кореспонденция“. Един от потребителите (пощенска кутия) изпраща писмо с прикачен файл до друга пощенска кутия. Писмото съдържа текстово предложение за стартиране на защитен комуникационен канал за кореспонденция и публичен ключ на собственика на пощенската кутия (с частен ключ от страна на клиента).

Можете дори да направите няколко ключа специално за всяка кореспонденция. Потребителят получател може да приеме тази оферта и да изпрати своя публичен ключ (също специално направен за тази кореспонденция). След това първият потребител изпраща писмо за контрол на услугата (криптирано с публичния ключ на втория потребител) - при получаване на което вторият потребител може да счита формирания комуникационен канал за надежден. След това вторият потребител изпраща контролно писмо - след което първият потребител също може да счита образувания канал за защитен.

За да се бори с прихващането на ключове по пътя, протоколът трябва да предвижда възможност за предаване на поне един публичен ключ с помощта на флаш устройство.

И най-важното е, че всичко работи (въпросът е „кой ще плати за това?“):
Въведете пощенски сертификати, започващи от $10 за 3 години. Което ще позволи на подателя да посочи в dns, че „моите публични ключове са там“. И те ще ви дадат възможност да започнете защитена връзка. В същото време приемането на такива връзки е безплатно.
gmail най-накрая печели от своите потребители. За $10 за 3 години - правото да създавате сигурни канали за кореспонденция.

============= Заключение ==============

За да тествам цялата статия, щях да наема специален сървър за един месец и да купя домейн със SSL сертификат.

Но обстоятелствата в живота се развиха, така че този въпрос се проточи 2 месеца.
И така, когато отново имах свободно време, реших да публикувам статията такава, каквато е, вместо да рискувам публикацията да се проточи още една година.

Ако има доста въпроси като „но това не е описано достатъчно подробно“, тогава вероятно ще има сили да вземете специален сървър с нов домейн и нов SSL сертификат и да го опишете още по-подробно и повечето най-важното, идентифицирайте всички липсващи важни подробности.

Бих искал също така да получа обратна връзка относно идеи за пощенски сертификати. Ако ви харесва идеята, ще се опитам да намеря сили да напиша чернова за rfc.

Когато копирате големи части от статия, дайте връзка към тази статия.
Когато превеждате на друг език, посочете връзка към тази статия.
Ще се опитам сам да го преведа на английски и ще оставя препратки.

Източник: www.habr.com

Debian + Postfix + Dovecot + Multidomain + SSL + IPv6 + OpenVPN + Multi-интерфейси + SpamAssassin-learn + Bind