🥇Debian + Postfix + Dovecot + Multi-domain + SSL + IPv6 + OpenVPN + Multi-interfaces + SpamAssassin-lær + Bind

Denne artikel handler om, hvordan man konfigurerer en moderne mailserver.
Postfix + Dovecot. SPF + DKIM + rDNS. Med IPv6.
Med TSL-kryptering. Med support til flere domæner — en del med et gyldigt SSL-certifikat.
Med spam-beskyttelse og en høj spam-rating i forhold til andre mailservere.
Med support til flere fysiske grænseflader.
Med OpenVPN, hvis forbindelse er via IPv4, og som giver IPv6.

Hvis du ikke ønsker at lære alle disse teknologier, men ønsker at konfigurere en sådan server — så er denne artikel til dig.

Artiklen indeholder ikke forsøg på at forklare hver enkelt detalje. Forklaringen går på, hvad der er konfigureret på en ikke-standard måde eller er vigtigt fra et brugerperspektiv.

Motivationen for at konfigurere en mailserver — min langvarige drøm. Det lyder måske fjollet, men IMO, det er meget bedre end at drømme om en ny bil af min yndlingsmærke.

Motivationen for at konfigurere IPv6 — der er to. En IT-specialist skal konstant lære nye teknologier for at overleve. Jeg ønsker at bidrage minimalt til kampen mod censur.

Motivationen for at konfigurere OpenVPN — kun for at få IPv6 til at fungere på den lokale maskine.
Motivationen for at konfigurere flere fysiske grænseflader — jeg har én grænseflade på serveren, 'langsom, men ubegribelig', og en anden 'hurtig, men med takst'.

Motivationen for at konfigurere Bind — min udbyder leverer en ustabil DNS-server, og Google har også sine nedbrud. Jeg ønsker en stabil DNS-server til personlig brug.

Motivationen for at skrive artiklen — udkastet blev skrevet for 10 måneder siden, og jeg har allerede kigget i det to gange. Hvis selv forfatteren har brug for det regelmæssigt — er der stor sandsynlighed for, at andre også vil have brug for det.

Der findes ikke en universel løsning til en mailserver. Men jeg vil forsøge at skrive noget i stil med 'gør sådan her, og derefter, når alt fungerer som det skal — smid det overflødige væk'.

Serveren har Colocation hos firmaet tech.ru. Det er muligt at sammenligne med OVH, Hetzner, AWS. For at løse denne opgave vil det være langt mere effektivt at samarbejde med netop tech.ru.

Der er installeret Debian 9 på serveren.

Serveren har 2 grænseflader `eno1` og `eno2`. Den første er ubegribelig, mens den anden er hurtig.

Der er 3 statiske IP-adresser, XX.XX.XX.X0, XX.XX.XX.X1 og XX.XX.XX.X2 på grænsefladen `eno1`, og XX.XX.XX.X5 på grænsefladen `eno2`.

Der er et XXXX:XXXX:XXXX:XXXX::/64 IPv6-adressepul, der er tildelt grænsefladen `eno1`, og fra denne XXXX:XXXX:XXXX:XXXX:1:2::/96 blev tildelt til `eno2` efter min anmodning.

Der er 3 domæner `domain1.com`, `domain2.com`, `domain3.com`. For `domain1.com` og `domain3.com` er der et SSL-certifikat.

Der er en Google-konto, som jeg gerne vil knytte til e-mailkontoen `vasya.pupkin@domain1.com` (modtagelse og afsendelse af e-mails direkte fra Gmail-grænsefladen).
Der skal være en e-mailkonto `support@domain2.com`, hvor jeg gerne vil se en kopi af e-mails i min Gmail. Og sjældent have mulighed for at sende noget fra `support@domain2.com` via webgrænsefladen.

Der skal være en e-mailkonto `ivanov@domain3.com`, som Ivanov vil bruge fra sin iPhone.

Afsendte e-mails skal overholde alle moderne krav til anti-spam.
Der skal være det højeste niveau af kryptering, der er muligt i offentlige netværk.
Der skal være understøttelse af IPv6 både til afsendelse og modtagelse af e-mails.
Der skal være SpamAssassin, som aldrig vil slette e-mails. Den vil enten foretage en bounce, lade det gå igennem eller sende det til IMAP-mappen "Spam".
SpamAssassin skal være indstillet til automatisk læring: hvis jeg flytter en e-mail til mappen "Spam" - skal den lære af det; hvis jeg flytter en e-mail fra mappen "Spam" - skal den lære af det. Resultaterne af SpamAssassins læring skal påvirke, om en e-mail havner i "Spam"-mappen.
PHP-scripts skal kunne sende e-mails på vegne af ethvert domæne på denne server.
Der skal være en OpenVPN-service, med mulighed for at bruge IPv6 på klienter, som ikke har IPv6.

Først skal grænsefladerne og routingen indstilles, inklusive IPv6.
Derefter skal OpenVPN konfigureres, så den forbinder via IPv4 og tildeler klienten en statisk, reel IPv6-adresse. Denne klient skal have adgang til alle IPv6-tjenester på serveren og til enhver IPv6-ressource på internettet.
Derefter skal Postfix konfigureres til at sende e-mails + SPF + DKIM + rDNS og andre lignende småting.
Derefter skal Dovecot konfigureres og Multidomain indsættes.
Derefter skal SpamAssassin konfigureres og træning indstilles.
Til slut skal Bind installeres.

============= Multi-grænseflader =============

For at konfigurere grænsefladerne skal det skrives sådan i "\/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

Disse indstillinger kan anvendes på enhver server i tech.ru (med lidt samtykke fra supporten), og det vil straks fungere som det skal.

Hvis du har erfaring med at konfigurere lignende ting for Hetzner, OVH - er det anderledes. Mere kompliceret.

eno1 - er navnet på netværkskort #1 (langsomt, men ubegribelig).
eno2 - er navnet på netværkskort #2 (hurtigt, men med takst).
tun0 — navnet på det virtuelle netværkskort fra OpenVPN.
XX.XX.XX.X0 — IPv4 #1 på eno1.
XX.XX.XX.X1 — IPv4 #2 på eno1.
XX.XX.XX.X2 — IPv4 #3 på eno1.
XX.XX.XX.X5 — IPv4 #1 på eno2.
XX.XX.XX.1 — IPv4 gateway.
XXXX:XXXX:XXXX:XXXX::/64 — IPv6 for hele serveren.
XXXX:XXXX:XXXX:XXXX:1:2::/96 — IPv6 for eno2, alt andet kommer udefra via eno1.
XXXX:XXXX:XXXX:XXXX::1 — IPv6 gateway (det skal bemærkes, at dette kan/skal gøres anderledes. Angiv IPv6 switchens adresse).
dns-nameservers — angivet som 127.0.0.1 (fordi bind er installeret lokalt) og 213.248.1.6 (denne er fra tech.ru).

«table eno1t» og «table eno2t» — meningen med disse route-rule er, at trafik, der kommer ind gennem eno1 -> skal forlade via det samme, mens trafik, der kommer ind gennem eno2 -> skal forlade via det samme. Også forbindelser initieret af serveren skal forlade gennem eno1.

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

Med denne kommando angiver vi, at al ukendt trafik, der falder ind under en hvilken som helst regel, der er markeret med «table eno1t» -> skal sendes til interface eno1.

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

Med denne kommando angiver vi, at al trafik initieret af serveren skal sendes til interface eno1.

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

Med denne kommando angiver vi selv reglerne for mærkning af trafik.

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

Denne blok angiver det andet IPv4 for interface eno1.

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

Med denne kommando angiver vi ruten fra OpenVPN-klienter til lokale IPv4 undtagen XX.XX.XX.X0.
Hvorfor denne kommando er tilstrækkelig for alle IPv4 — det forstår jeg stadig ikke.

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

Her sætter vi adressen for selve interfacet. Serveren vil bruge det som en «udgående» adresse. Det vil ikke blive brugt til noget andet.

Hvorfor der står «:1:1::» så besværligt? For at OpenVPN fungerer korrekt og kun til dette formål. Mere om dette senere.

Om gateway — så længe det virker, er det fint. Men korrekt set — her skal den IPv6 switches adresse angives, som serveren er tilsluttet.

Men af en eller anden grund stopper IPv6 med at fungere, hvis jeg gør det sådan. Måske er det nogle særheder fra tech.ru.

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

Dette er tilføjelsen af en IPv6-adresse til interfacet. Hvis der er behov for hundrede adresser — så betyder det hundrede linjer i denne fil.

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

Jeg har markeret adresserne og subnettene for alle interfacene for at gøre det mere overskueligt.
eno1 — skal uden undtagelse være «/64» — fordi det er hele vores pool af adresser.
tun0 — subnettet skal uden undtagelse være større end eno1. Ellers vil det ikke være muligt at konfigurere en IPv6 gateway for klienter af OpenVPN.
eno2 — subnettet skal uden undtagelse være større end tun0. Ellers vil OpenVPN-klienter ikke kunne få adgang til lokale IPv6-adresser.
For tydelighedens skyld har jeg valgt en subnetmæssig blok på 16, men man kan endda bruge en blok på «1», hvis man ønsker det.
Sammenhængende 64+16 = 80, og 80+16 = 96.
For endnu mere tydelighed:
XXXX:XXXX:XXXX:XXXX:1:1:YYYY:YYYY — disse adresser skal tildeles specifikke websteder eller tjenester på interface eno1.
XXXX:XXXX:XXXX:XXXX:1:2:YYYY:YYYY — disse adresser skal tildeles specifikke websteder eller tjenester på interface eno2.
XXXX:XXXX:XXXX:XXXX:1:3:YYYY:YYYY — disse adresser skal tildeles OpenVPN-klienter eller bruges som servicemeddelelser til OpenVPN.

For at konfigurere netværket — skal der være mulighed for at genstarte serveren.
IPv4 ændringer fanges ved udførelse (det skal være indpakket i screen — ellers vil denne kommando bare bringe netværket ned på serveren):

/etc/init.d/networking restart

Tilføj til slutningen af filen «/etc/iproute2/rt_tables»:

100 eno1t
101 eno2t

Uden dette kan der ikke bruges brugerdefinerede tabeller i filen «/etc/network/interfaces».
Tallene skal være unikke og mindre end 65535.

IPv6 ændringer kan let ændres uden genstart, men for dette skal man lære mindst tre kommandoer:

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

Indstilling af «/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

Dette er «sysctl» indstillingerne for min server. Vær opmærksom på det vigtige.

net.ipv4.ip_forward = 1

Uden dette vil OpenVPN ikke fungere overhovedet.

net.ipv6.ip_nonlocal_bind = 1

Enhver, der forsøger at binde IPv6 (f.eks. nginx) straks efter at interfacet er blevet tildelt — vil få en fejl. At adressen ikke er tilgængelig.

For at undgå sådan en situation, laves denne indstilling.

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

Uden disse indstillinger kommer IPv6 trafik fra OpenVPN-klienten ikke ud i verden.

Andre indstillinger er enten irrelevante eller jeg husker ikke, hvorfor de er der.
Men for en sikkerheds skyld efterlader jeg dem «som de er».

For at ændringerne i denne fil kan træde i kraft uden genstart af serveren — skal kommandoen udføres:

sysctl -p

Mere detaljeret om «table» regler: habr.com/post/108690

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

OpenVPN IPv4 fungerer ikke uden iptables.

Jeg har sådan en iptables til 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 — dette er min statiske IPv4-adresse for den lokale maskine.
10.8.0.0/24 — IPv4-netværk for openvpn. IPv4-adresser til openvpn-klienter.
Reglernes rækkefølge er vigtig.

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

Dette er en begrænsning, så kun jeg kan bruge OpenVPN fra min statiske IP.

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

For at videresende IPv4-pakker mellem OpenVPN-klienter og internettet er det nødvendigt at angive en af disse kommandoer.

I forskellige tilfælde passer en af mulighederne ikke.
Begge kommandoer passer til mit tilfælde.
Efter at have læst dokumentationen, valgte jeg den første mulighed, fordi den bruger mindre CPU.

For at alle iptables-indstillinger kan blive anvendt efter genstart, skal de gemmes et sted.

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

Disse navne er valgt med omhu. De bruges af pakken "iptables-persistent".

apt-get install iptables-persistent

Installation af hovedpakken OpenVPN:

apt-get install openvpn easy-rsa

Lad os konfigurere skabelonen til certifikaterne (indsæt dine egne værdier):

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

Lad os redigere indstillingerne for certifikat-skabelonen:

mcedit vars

...
# Disse er standardværdier for felter
# som vil blive indsat i certifikatet.
# Lad ingen af disse felter være tomme.
export KEY_COUNTRY="RU"
export KEY_PROVINCE="Krasnodar"
export KEY_CITY="Dinskaya"
export KEY_ORG="Own"
export KEY_EMAIL="admin@domain1.com"
export KEY_OU="VPN"

# X509 Emne Felt
export KEY_NAME="server"
...

Oprettelse af servercertifikat:

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

Lad os forberede muligheden for at oprette de endelige "client-name.opvn" filer:

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

Lad os forberede et script, der vil samle alle filer til en enkelt opvn-fil.

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}/${1}.crt 
    <(echo -e '</cert>n<key>') 
    ${KEY_DIR}/${1}.key 
    <(echo -e '</key>n<tls-auth>') 
    ${KEY_DIR}/ta.key 
    <(echo -e '</tls-auth>') 
    > ${OUTPUT_DIR}/${1}.ovpn

Oprettelse af den første OpenVPN-klient:

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

Filen "~/client-configs/files/client-name.ovpn" sendes til klientens enhed.

For iOS clients, you'll need to take a trick:
The content of the 'tls-auth' tag must be without comments.
And also place 'key-direction 1' immediately before the 'tls-auth' tag.

Let's configure the OpenVPN server:

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

This is needed to assign a static address to each client (not mandatory, but I use it):

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

The most complicated and critical detail.

Unfortunately, OpenVPN is still unable to automatically configure the IPv6 gateway for clients.
You have to manually forward this for each client.

# 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"

File '/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

File '/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

Both scripts use the file '/etc/openvpn/variables':

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

Why it is written this way — I can't recall.

It currently looks strange netmask = 112 (it should be 96 here).
And the prefix is strange, not corresponding to the tun0 network.
But okay, I'll leave it 'as is'.

cipher DES-EDE3-CBC

It's a matter of taste — I chose this method of connection encryption.

More details on setting up OpenVPN for IPv4.

More details on setting up OpenVPN for IPv6.

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

Installing the main package:

apt-get install postfix

When installing, select 'internet-site'.

My '/etc/postfix/main.cf' looks like this:

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

# at tilføje .domain er MUA's opgave.
append_dot_mydomain = no

readme_directory = no

# Se http://www.postfix.org/COMPATIBILITY_README.html -- standardværdien er 2 på
# friske installationer.
compatibility_level = 2

# TLS parametre
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

# Lagringstype
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 indstillinger
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-adresse pr. domæne
sender_dependent_default_transport_maps = pcre:/etc/postfix/sdd_transport.pcre

Lad os se nærmere på detaljerne i denne konfiguration.

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

Ifølge Habr-brugerne indeholder dette blok `desinformation og forkerte udsagn`.Det var først 8 år efter starten af min karriere, at jeg forstod, hvordan SSL fungerer.
Derfor vil jeg tage mig friheden til at beskrive, hvordan man bruger SSL (uden at besvare spørgsmål som 'Hvordan fungerer det?' og 'Hvorfor fungerer det?').
Grundlaget for moderne kryptering er at skabe et nøglepar (to meget lange strenge af tegn).
En 'nøgle' er privat, mens den anden nøgle er 'offentlig'. Vi opbevarer den private nøgle meget omhyggeligt i hemmelighed. Den offentlige nøgle gives til alle interesserede.
Ved hjælp af den offentlige nøgle kan man kryptere en tekststreng, så kun ejeren af den private nøgle kan dekryptere den.
Og det er hele grundlaget for teknologien.
Trin nr. 1 — https-websteder.
Når browseren tilgår webstedet, får den at vide af webserveren, at webstedet er https, og anmoder derfor om den offentlige nøgle.
Webserveren leverer den offentlige nøgle. Browseren bruger den offentlige nøgle til at kryptere http-requesten og sender den afsted.
Indholdet af http-requesten kan kun læses af den, der har den private nøgle, altså kun serveren, som der bliver sendt en forespørgsel til.
Http-requesten indeholder mindst URI. Derfor, hvis et land forsøger at begrænse adgangen ikke til hele sitet, men til en specifik side - så er det umuligt at gøre dette for https-sider.
Trin nr. 2 - krypteret svar.
Webserveren giver et svar, som nemt kan læses undervejs.
Løsningen er meget enkel - browseren danner lokalt et tilsvarende par af privat-offentlig nøgle for hver https-side.
Og sammen med forespørgslen om webstedets offentlige nøgle sender den sin lokale offentlige nøgle.
Webserveren husker den og krypterer http-response med den specifikke klients offentlige nøgle.
Nu kan http-response kun dekrypteres af ejerens private nøgle fra klientens browser (det vil sige selve klienten).
Trin nr. 3 - etablering af en sikker forbindelse over en offentlig kanal.
I eksempel nr. 2 er der en sårbarhed - intet forhindrer en angriber i at opfange http-requesten og redigere oplysningerne om den offentlige nøgle.
Dermed vil mellemmanden kunne se alt indhold i de sendte/modtagne beskeder, indtil kommunikationskanalen ændres.
At bekæmpe dette er meget enkelt - det er tilstrækkeligt at sende browserens offentlige nøgle som en besked krypteret med webserverens offentlige nøgle.
Webserveren sender så først et svar af typen "din offentlige nøgle er sådan" og krypterer denne besked med samme offentlige nøgle.
Browseren ser svaret - hvis der kommer en besked "din offentlige nøgle er sådan" - så er det 100% garanti for, at den pågældende kommunikationskanal er sikker.
Hvor sikker er den?
Oprettelsen af en sådan sikker kommunikationskanal sker med hastigheden ping*2. For eksempel 20 ms.
En angriber skal enten have den private nøgle fra en af parterne på forhånd, eller så skal vedkommende finde den private nøgle på et par millisekunder.
At bryde en moderne privat nøgle vil tage årtier på en supercomputer.
Trin nr. 4 - offentlig database over offentlige nøgler.
Det er tydeligt, at der i hele denne historie eksisterer en mulighed for en angriber, der sidder på kommunikationskanalen mellem klienten og serveren.
Muligheden for kunden at præsentere sig som serveren, og serveren som kunden. Og simulere et par nøgler i begge retninger.
Så vil en angriber kunne se al trafik og have mulighed for at 'redigere' trafikken.
For eksempel ændre adressen, hvor man sender penge, eller kopiere adgangskoden til netbanken eller blokere 'uønsket' indhold.
For at bekæmpe sådanne angribere er der opfundet en offentlig DB med offentlige nøgler for hver https-side.
Hver browser 'ved', at der findes omkring 200 sådanne DB'er. Dette er forudinstalleret i hver browser.
Denne 'viden' er understøttet af den offentlige nøgle fra hvert certifikat. Med andre ord er det umuligt at forfalske forbindelsen til hvert specifikt certifikationscenter.
Nu er der en simpel forståelse af, hvordan man bruger SSL til https.
Hvis man tænker sig lidt om, vil det blive klart, hvordan efterretningstjenester kan hacke noget i denne konstruktion. Men det vil koste dem forfærdelige kræfter.
Og for organisationer mindre end NSA eller CIA er det næsten umuligt at hacke det eksisterende beskyttelsesniveau, selv for VIP.
Jeg vil også tilføje noget om SSH-forbindelser. Der er ingen offentlige nøgler der, hvordan skal man så forholde sig. Problemet løses på to måder.
SSH-password-metode:
Ved den første forbindelse skal SSH-klienten advare om, at vi har en ny offentlig nøgle fra SSH-serveren.
Og ved efterfølgende forbindelser, hvis der dukker en advarsel op om 'ny offentlig nøgle fra ssh-serveren' — vil det betyde, at nogen forsøger at overvåge.
Eller ved den første forbindelse blev du overvåget, og nu kommunikerer du med serveren uden mellemled.
Faktisk er det fordi, at det er let, hurtigt og uden kræfter at opdage overvågningen — at denne type angreb kun bruges i særlige tilfælde på specifikke kunder.
SSH-nøglemetode:
Tag et USB-stik, skriv den private nøgle til SSH-serveren på det (der er termer og masser af væsentlige nuancer, men jeg skriver bare en grundlæggende gennemgang, ikke en brugsanvisning).
Den offentlige nøgle efterlader vi på maskinen, hvor SSH-klienten vil være, og den holder vi også hemmelig.
Vi tager USB-stikket til serveren, sætter det i, kopierer den private nøgle, og så brænder vi USB-stikket og spreder asken for vinden (eller i det mindste formaterer det med nuller).
Og det er det — efter en sådan operation vil det være umuligt at hacke en sådan ssh-forbindelse. Selvfølgelig vil man i løbet af 10 år kunne se trafikken på en supercomputer — men det er en anden historie.
Jeg beklager for off-topic.

Så nu hvor teorien er kendt. Jeg vil fortælle om flowet til at oprette et ssl-certifikat.

Ved hjælp af "openssl genrsa" opretter vi en privat nøgle og "skabeloner" til den offentlige nøgle.
Vi sender "skabelonerne" til et tredjepartsfirma, som vi betaler omkring $9 for det enkleste certifikat.

Efter et par timer modtager vi vores "offentlige" nøgle fra dette tredjepartsfirma sammen med et sæt af flere offentlige nøgler.

Hvorfor betale et tredjepartsfirma for at udstede min offentlige nøgle — det spørgsmål vil jeg ikke diskutere her.

Nu er det klart, hvad meningen med inskriptionen er:

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

I mappen "/etc/ssl" er alle filer til ssl-anliggender opbevaret.
domain1.com — navnet på domænet.
2018 — året for nøglens oprettelse.
"key" — betegnelsen for, at filen er en privat nøgle.

Og meningen med denne fil er:

smtpd_tls_cert_file=\/etc\/ssl\/domain1.com.2018.chained.crt
domain1.com — navnet på domænet.
2018 — året for nøglens oprettelse.
chained — betegnelsen for, at dette er en kæde af offentlige nøgler (den første — vores offentlige og de øvrige er dem, der blev sendt fra firmaet, der udstedte den offentlige nøgle).
crt — betegnelsen for, at dette er et færdigt certifikat (den offentlige nøgle med tekniske forklaringer).

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

Denne opsætning bruges i dette tilfælde ikke, men er skrevet som eksempel.

Fordi en fejl i denne parameter kan føre til, at spam sendes fra din server (uden din viden).

Så skal du bevise for alle, at du ikke er skyld i det.

recipient_delimiter = +

Mange ved måske ikke dette, men det er et standardtegn til at rangere e-mails, og det understøttes af de fleste moderne mailservere.

Hvis du for eksempel har en mailboks "username@gmail.com", så prøv at sende til "username+spam@gmail.com" — se, hvad der sker.

inet_protocols = ipv4

Dette kan være forvirrende.

Men det er ikke uden grund. Hvert nyt domæne — som standard kun IPv4, så aktiverer jeg IPv6 for hver enkelt.

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

Her angiver vi, at al indgående mail går til dovecot.
Og reglerne for domæner, postkasser, aliaser — findes i databasen.

/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

Nu vet postfix, at det kun kan modtage e-mails til videre sending gennem godkendelse med dovecot.

Jeg forstår faktisk ikke rigtigt, hvorfor det her skal duplikeres. Vi har jo allerede angivet alt, hvad der er nødvendigt i 'virtual_transport'.

Men postfix-systemet er meget gammelt - det må være notater fra gamle dage.

smtpd_recipient_restrictions =
        ...

smtpd_helo_restrictions =
        ...

smtpd_client_restrictions =
        ...

Det skal konfigureres forskelligt for hver mailserver.

Jeg har tre mailservere til rådighed, og disse indstillinger er meget forskellige på grund af forskellige anvendelseskrav.

Du skal være omhyggelig med konfigurationen - ellers vil spam oversvømme dig, eller endnu værre - spam vil komme fra dig.

# SPF
policyd-spf_time_limit = 3600

Indstilling til et plugin relateret til kontrol af SPF for indkommende mail.

# 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

Indstilling om, at alle udgående e-mails skal forsynes med en DKIM-signatur.

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

Dette er en nøglekomponent i routing af e-mails, når e-mails sendes fra PHP-scripts.

Fil 'etc/postfix/sdd_transport.pcre':

/^www-domain1@domain1.com$/ domain1:
/^www-domain2@domain1.com$/ domain2:
/^www-domain3@domain1.com$/ domain3:
/@domain1.com$/             domain1:
/@domain2.com$/             domain2:
/@domain3.com$/             domain3:

Til venstre - regulære udtryk. Til højre - etiketten, som e-mailen mærkes med.
Postfix vil i henhold til etiketten tage højde for endnu et par konfigurationslinjer for den specifikke e-mail.
Hvordan postfix vil blive omkonfigureret for den specifikke e-mail, vil blive angivet i 'master.cf'.
Linjerne 4, 5, 6 - de er de vigtigste. Den etiket, vi sætter, svarer til det domæne, vi sender e-mailen fra.
Men ikke altid i PHP-scripts i den gamle kode angives feltet 'from'. Så kommer brugernavnet til hjælp.
Artiklen er allerede omfattende - jeg ville ikke have lyst til at blive distraheret af konfigurationen af nginx+fpm.
Kort sagt - vi angiver en specifik linux-bruger ejer for hver hjemmeside. Og derfor sin egen fpm-pool.
Fpm-pool bruger enhver PHP-version (det er fantastisk, når man uden problemer kan bruge forskellige PHP-versioner og endda forskellige php.ini-filer på én server for nabohjemmesider).
Så den specifikke linux-bruger 'www-domain2' har hjemmesiden domain2.com. På denne hjemmeside er der kode til at sende e-mails uden angivelse af 'from'-feltet.
Selv i dette tilfælde vil e-mails blive sendt korrekt og vil aldrig havne i spam.

Min 'etc/postfix/master.cf' ser således ud:

...
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

Filen er ikke helt komplet — det er allerede meget stort.
Jeg har kun markeret det, der er ændret.

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}

Dette er indstillinger relateret til spamassassin, mere om det senere.

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

Vi tillader tilslutning til mailserveren via port 587.
Det kræver, at man logger ind.

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

Vi aktiverer SPF-tjek.

apt-get install postfix-policyd-spf-python

Vi vil installere pakken til SPF-tjek ovenfor.

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

Og dette er det mest interessante. Det er muligheden for at sende e-mails for et bestemt domæne fra en bestemt IPv4/IPv6 adresse.
Dette gøres for rDNS. rDNS er at få en eller anden streng baseret på IP-adressen.
Og til mail bruges denne mulighed til at bekræfte, at helo faktisk svarer til rDNS for den adresse, som emailen blev sendt fra.
Hvis helo ikke svarer til mailens domæne, fra hvilken der blev sendt emailen — tildeles spam point.
Helo svarer ikke til rDNS — der tildeles mange spam point.
Derfor skal hver domæne have sin egen IP-adresse.
For OVH — er der i kontrollen mulighed for at angive rDNS.
For tech.ru — løses spørgsmålet via support.
For AWS — løses spørgsmålet via support.
«inet_protocols» og «smtp_bind_address6» — dette aktiverer understøttelse af IPv6.
For IPv6 skal der også angives rDNS.
«syslog_name» — dette er for nemmere læsning af logfiler.

Køb certifikater anbefales her.

Konfiguration af postfix+dovecot her.

Indstilling af SPF.

============= Dovecot =============

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

Indstilling af mysql, vi installerer selv pakkerne.

Fil «/etc/dovecot/conf.d/10-auth.conf»

disable_plaintext_auth = yes
auth_mechanisms = plain login

Godkendelse kun i krypteret form.

Fil «/etc/dovecot/conf.d/10-mail.conf»

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

Her angiver vi lagerstedet for e-mails.

Jeg ønsker, at de skal gemmes i filer og grupperes efter domæner.

Fil «/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 {
  }
}

Dette er hovedkonfigurationsfilen for dovecot.
Her deaktiverer vi usikrede forbindelser.
Og aktiverer sikre forbindelser.

Fil «/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
}

Vi konfigurerer ssl. Angiver, at ssl er et krav.
Og selve certifikatet. Og en vigtig detalje — direktivet «local». Det angiver, hvilken ssl-certifikat der skal bruges for forbindelse til hvilket lokalt IPv4.
Forresten, IPv6 er ikke konfigureret her, jeg vil rette dette senere.
XX.XX.XX.X5 (domain2) — der er intet certifikat. For klientforbindelser skal domain1.com angives.
XX.XX.XX.X2 (domain3) — der er et certifikat, for klientforbindelser kan domain1.com eller domain3.com angives.

Fil «/etc/dovecot/conf.d/15-lda.conf»

protocol lda {
  mail_plugins = $mail_plugins sieve
}

Dette er yderligere nødvendigt til spamassassin.

Fil «/etc/dovecot/conf.d/20-imap.conf»

protocol imap {
  mail_plugins = $mail_plugins antispam
}

Dette er antispam-plugin. Nødvendigt til at træne spamassassin under flytning til/fra mappen «Spam».

Fil «/etc/dovecot/conf.d/20-pop3.conf»

protocol pop3 {
}

Der er blot en sådan fil.

Fil «/etc/dovecot/conf.d/20-lmtp.conf»

protokol lmtp {
  mail_plugins = $mail_plugins sieve
  postmaster_address = admin@domain1.com
}

Konfiguration af lmtp.

Fil «/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
}

Indstillinger for spamassassin træning ved flytning til/fra mappen «Spam».

Fil «/etc/dovecot/conf.d/90-sieve.conf»

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

Fil hvor der angives, hvad der skal gøres med indgående mails.

Fil «/var/lib/dovecot/sieve/default.sieve»

require ["fileinto", "mailbox"];

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

Filen skal kompilere: «sievec default.sieve».

Fil «/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
}

Angivelse af sql-filer til autentifikation.
Og selve filen — som en form for autentifikation.

Fil «/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';

Dette svarer til de tilsvarende indstillinger for postfix.

Fil «/etc/dovecot/dovecot.conf»

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

Hovedkonfigurationsfilen.
Det vigtige her er, at vi her angiver/tilføjer protokoller.

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

apt-get install spamassassin spamc

Vi installerer pakkerne.

adduser spamd --disabled-login

Vi tilføjer brugeren under, hvis navn.

systemctl enable spamassassin.service

Vi aktiverer autostart af spamassassin-tjenesten ved opstart.

Fil «/etc/default/spamassassin»:

CRON=1

Aktiverer automatisk opdatering af regler «som standard».

Fil «/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

En MySQL DB «sa» med brugeren «sa» og password «password» (erstat med noget passende) skal oprettes.

report_safe — det betyder, at der sendes en rapport om spam-e-mail i stedet for selve brevet.
use_bayes — det er indstillinger for maskinlæring i spamassassin.

De øvrige indstillinger for spamassassin blev anvendt tidligere i artiklen.

Generel indstilling af «spamassassin».
Om flytning af nye spam-e-mails til IMAP-mappen «Spam».
Om den enkle integration af Dovecot + SpamAssassin.
Jeg anbefaler at læse teorien om træning af spamassassin ved flytning af breve i imap-mapper (og jeg fraråder at anvende det).

============= Kontakt til fællesskabet =============

Jeg vil også gerne dele en idé med samfundet om, hvordan man kan øge sikkerheden for de sendte e-mails. Da jeg har dykket så dybt ned i emnet mail.

For at brugeren kan oprette et par nøgler på sin klient (Outlook, Thunderbird, browser-plugin, …). Offentlig og privat. Den offentlige nøgle — sendes til DNS. Den private nøgle — gemmes på klienten. E-mail-servere skal være i stand til at anvende den offentlige nøgle til at sende til en bestemt modtager.

Og for at beskytte mod spam ved sådanne e-mails (ja, mailserveren vil ikke kunne se indholdet) skal der indføres 3 regler:

Obligatorisk ægte DKIM-signatur, obligatorisk SPF, obligatorisk rDNS.
Neuralt netværk til at lære om anti-spam + database til dette på klientsiden.
Krypteringsalgoritmen skal være sådan, at afsenderen skal bruge 100 gange mere CPU-kraft til kryptering end modtageren.

Udover offentlige e-mails — udvikle en standard for et tilbudsbrev til 'at starte en sikker korrespondance'. En af brugerne (e-mailkontoen) sender en e-mail til en anden e-mailkonto med et vedhæftet dokument. I e-mailen er teksten et tilbud om at starte en sikker kommunikationskanal og den offentlige nøgle for ejerens e-mailkonto (hvor den private nøgle er på klientsiden).

Man kan endda lave et par nøgler specielt til hver korrespondance. Brugeren modtager kan acceptere dette tilbud og sende sin offentlige nøgle (også lavet specielt til denne korrespondance). Derefter sender den første bruger en teknisk kontrolmail (krypteret med den anden brugers offentlige nøgle) — når den anden bruger modtager den, kan han betragte den oprettede kommunikationskanal som pålidelig. Derefter sender den anden bruger en kontrolmail — og så kan den første bruger også betragte den oprettede kanal som sikker.

For at bekæmpe aflytning af nøgler undervejs — skal protokollen forudse muligheden for at overføre mindst én offentlig nøgle ved hjælp af en USB-nøgle.

Og vigtigst af alt — at alt dette fungerer (spørgsmålet 'hvem betaler for dette?'):
Indtast mailcertifikater til en pris fra 10$ for 3 år. Certifikaterne gør det muligt for afsenderen at angive i DNS, at "mine offentlige nøgler er derovre". Og de vil muliggøre oprettelsen af en sikker forbindelse. Samtidig vil sådanne forbindelser være gratis at modtage.
Gmail monetariserer endelig sine brugere. For 10$ i 3 år - retten til at oprette sikre kommunikationskanaler.

============= Konklusion =============

For at teste hele artiklen havde jeg planlagt at leje en dedikeret server i en måned og købe et domæne med SSL-certifikat.

Men livets omstændigheder gør, at dette spørgsmål har trukket ud i 2 måneder.
Og da der igen dukkede tid op - besluttede jeg at offentliggøre artiklen som den er, i stedet for at risikere, at offentliggørelsen bliver forsinket i endnu et år.

Hvis der kommer mange spørgsmål som "her er ikke nok detaljeret beskrevet" - så vil der sikkert blive kræfter til at leje en dedikeret server med et nyt domæne og et nyt SSL-certifikat, samt beskrive det endnu mere detaljeret og vigtigst af alt - identificere alle de vigtige detaljer, der er blevet overset.

Jeg vil også gerne modtage feedback om ideen med mailcertifikater. Hvis ideen falder i god jord - vil jeg forsøge at finde kræfter til at skrive et udkast til RFC.

Ved kopiering af store dele af artiklen - angiv venligst linket til denne artikel.
Ved oversættelse til ethvert andet sprog - angiv venligst linket til denne artikel.
På engelsk vil jeg selv forsøge at oversætte og efterlade krydslinks.

Kilde: habr.com