Debian + Postfix + Dovecot + Multidomain + SSL + IPv6 + OpenVPN + Multi-interfaces + SpamAssassin-learn + Bind

Den här artikeln handlar om hur man konfigurerar en modern e-postserver.
Postfix + Dovecot. SPF + DKIM + rDNS. Med IPv6.
Med TSL-kryptering. Med stöd för flera domäner - del med ett giltigt SSL-certifikat.
Med skräppostskydd och högt skräppostbetyg hos andra e-postservrar.
Med stöd för flera fysiska gränssnitt.
Med OpenVPN, som ansluts via IPv4 och som ger IPv6.

Om du inte vill lära dig alla dessa teknologier men vill konfigurera en sådan server - då är den här artikeln för dig.

Artikeln innehåller inga försök att förklara varje detalj. Förklaringen går till att det som konfigurerats inte är standard eller är viktigt ur konsumentens synvinkel.

Motivationen att konfigurera en e-postserver är min långvariga dröm. Det kanske låter dumt, men IMHO, det är mycket bättre än att drömma om en ny bil av min favorittyp.

Motivationen att konfigurera IPv6 är två. IT-specialister måste ständigt lära sig nya teknologier för att överleva. Jag vill göra min blygsamma insats i kampen mot censur.

Motivationen att konfigurera OpenVPN är endast för att IPv6 ska fungera på den lokala maskinen.
Motivationen att konfigurera flera fysiska gränssnitt är att jag har en "långsam, men obegränsad" gränssnitt på servern och en "snabb, men med begränsning".

Motivationen att konfigurera Bind är att min leverantör tillhandahåller en instabil DNS-server, och Google ger också ibland fel. Jag vill ha en stabil DNS-server för personligt bruk.

Motivationen att skriva artikeln är att kladden skrevs för 10 månader sedan, och jag har redan tittat på den två gånger. Om även författaren behöver det regelbundet, är det en stor möjlighet att andra också behöver det.

Det finns ingen universell lösning för en e-postserver. Men jag ska försöka skriva något i stil med "gör så här, och när allt fungerar som det ska - släng det överflödiga."

Jag har en Colocation-server hos företaget tech.ru. Det finns möjlighet att jämföra med OVH, Hetzner, AWS. För att lösa detta problem kommer samarbetet med just tech.ru att vara mycket mer effektivt.

Debian 9 är installerat på servern.

Servern har 2 gränssnitt `eno1` och `eno2`. Den första är obegränsad och den andra snabb, respektive.

Det finns 3 statiska IP-adresser, XX.XX.XX.X0 och XX.XX.XX.X1 och XX.XX.XX.X2 på gränssnittet `eno1` och XX.XX.XX.X5 på gränssnittet `eno2`.

Det finns XXXX:XXXX:XXXX:XXXX::/64 pool med IPv6-adresser, som har tilldelats gränssnittet `eno1` och från det XXXX:XXXX:XXXX:XXXX:1:2::/96 på min begäran har tilldelats `eno2`.

Det finns 3 domäner `domain1.com`, `domain2.com`, `domain3.com`. För `domain1.com` och `domain3.com` finns det ett SSL-certifikat.

Det finns ett Google-konto som jag vill koppla till e-postlådan `vasya.pupkin@domain1.com` (ta emot och skicka e-post direkt från Gmail-gränssnittet).
Det ska finnas en e-postlåda `support@domain2.com`, vars kopia jag vill se i min Gmail. Och sällan vilja kunna skicka något från `support@domain2.com` via webgränssnittet.

Det ska finnas en e-postlåda `ivanov@domain3.com`, som Ivanov kommer att använda från sin iPhone.

Skickade e-postmeddelanden måste uppfylla alla moderna krav på anti-spam.
Det ska finnas den högsta nivån av kryptering som är tillgänglig i offentliga nätverk.
Det ska finnas stöd för IPv6 både för att skicka och ta emot e-post.
Det ska finnas SpamAssassin som aldrig kommer att ta bort e-postmeddelanden. Istället ska det antingen göra en bounce, eller släppa igenom, eller skicka till IMAP-mappen "Spam".
SpamAssassin ska vara konfigurerad för auto-inlärning: om jag flyttar ett e-postmeddelande till "Spam" ska det lära sig av det; om jag flyttar ett e-postmeddelande från mappen "Spam" ska det lära sig av det. Resultaten av SpamAssassins inlärning ska påverka om e-postmeddelandet hamnar i "Spam"-mappen.
PHP-skript ska kunna skicka e-post å namnet av vilken domän som helst på denna server.
Det ska finnas en OpenVPN-tjänst som möjliggör användning av IPv6 på en klient som inte har IPv6.

Först måste gränssnitt och routing konfigureras, inklusive IPv6.
Sedan måste OpenVPN konfigureras så att den ansluter via IPv4 och tillhandahåller klienten en statisk verklig IPv6-adress. Denna klient kommer få tillgång till alla IPv6-tjänster på servern och till alla IPv6-resurser på internet.
Därefter måste Postfix konfigureras för att skicka e-post + SPF + DKIM + rDNS och andra liknande detaljer.
Sedan måste Dovecot konfigureras och Multi-domän ställas in.
Till slut installera Bind.
============= Multi-interfaces =============

För att konfigurera gränssnitten måste följande skrivas i "\/etc\/network\/interfaces".

Dessa inställningar kan tillämpas på vilken server som helst i tech.ru (efter ett litet samråd med supporten) och de kommer att fungera som de ska.

# 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

Om erfarenhet av att konfigurera liknande saker för Hetzner, OVH — där är det annorlunda. Mer komplicerat.

eno1 — det är namnet på nätverkskort #1 (långsam, men obegränsad).

eno2 — det är namnet på nätverkskort #2 (snabb, men med en plan).
eno2 — det är namnet på nätverkskort #2 (snabb, men med en plan).
tun0 — namnet på det virtuella nätverksgränssnittet från 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 för hela servern.
XXXX:XXXX:XXXX:XXXX:1:2::/96 — IPv6 för eno2, medan allt annat går via eno1.
XXXX:XXXX:XXXX:XXXX::1 — IPv6 gateway (det är värt att notera att detta kan/detta bör göras annorlunda. Ange IPv6 för switchen).
dns-nameservers — anges som 127.0.0.1 (eftersom bind är installerat lokalt) och 213.248.1.6 (detta är från tech.ru).

«table eno1t» och «table eno2t» — syftet med dessa route-rule är att trafik som kommer in genom eno1 -> ska gå tillbaka genom samma gränssnitt, och trafik som kommer in genom eno2 -> ska gå tillbaka genom eno2. Dessutom ska serverinitierade anslutningar gå ut genom eno1.

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

Med det här kommandot anger vi att all oidentifierad trafik som faller under en regel där «table eno1t» är markerad -> ska dirigeras till gränssnittet eno1.

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

Med det här kommandot anger vi att all trafik som initieras av servern ska dirigeras till gränssnittet eno1.

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

Med det här kommandot definierar vi själva reglerna för trafikmärkning.

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

Detta block definierar en andra IPv4 för gränssnittet eno1.

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

Med det här kommandot anger vi rutten från OpenVPN-klienter till lokala IPv4, förutom XX.XX.XX.X0.
Varför detta kommando är tillräckligt för alla IPv4 — förstår jag fortfarande inte.

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

Här anger vi adressen för gränssnittet. Servern kommer att använda den som «utgående» adress. Den kommer inte att användas på något annat sätt.

Varför anges «:1:1::» så komplicerat? För att OpenVPN ska fungera korrekt och bara för det. Mer om detta senare.

Angående gateway — det fungerar så och så är det. Men i praktiken borde vi ange IPv6 för switchen till vilken servern är ansluten.

Men av någon anledning slutar IPv6 att fungera när jag gör så. Kanske är det några konstigheter från tech.ru.

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

Detta lägger till en IPv6-adress på gränssnittet. Om det behövs hundra adresser — då behövs hundra rader i den här filen.

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

Jag har markerat adresserna och subnäten för alla gränssnitt för tydlighetens skull.
eno1 — måste alltid vara «/64» — eftersom det är hela vårt adresspool.
tun0 — nätverket måste alltid vara större än eno1. Annars går det inte att konfigurera IPv6-gatewayen för OpenVPN-kunder.
eno2 — nätverket måste alltid vara större än tun0. Annars kan inte OpenVPN-kunder nå lokala IPv6-adresser.
För tydlighetens skull har jag valt subnet-storlek 16, men om du vill kan du till och med använda storlek «1».
Således 64+16 = 80, och 80+16 = 96.

För ännu mer tydlighet:
XXXX:XXXX:XXXX:XXXX:1:1:YYYY:YYYY — det här är adresser som ska tilldelas specifika webbplatser eller tjänster på gränssnittet eno1.
XXXX:XXXX:XXXX:XXXX:1:2:YYYY:YYYY — det här är adresser som ska tilldelas specifika webbplatser eller tjänster på gränssnittet eno2.
XXXX:XXXX:XXXX:XXXX:1:3:YYYY:YYYY — det här är adresser som ska tilldelas OpenVPN-kunder eller användas som OpenVPN-tjänstadresser.

För att konfigurera nätverket — måste det finnas möjlighet att starta om servern.
IPv4-ändringar upptas vid körning (viktigt att köra i screen — annars kommer detta kommando helt enkelt att fälla nätverket på servern):

/etc/init.d/networking restart

Lägg till i slutet av filen «/etc/iproute2/rt_tables»:

100 eno1t
101 eno2t

Utan detta kan man inte använda anpassade tabeller i filen «/etc/network/interfaces».
Siffrorna måste vara unika och mindre än 65535.

IPv6-ändringar ändras enkelt utan omstart, men för detta behöver man lära sig minst tre kommandon:

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

Konfigurering av «/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

Detta är inställningar för «sysctl» på min server. Jag vill betona det viktiga.

net.ipv4.ip_forward = 1

Utan detta kommer OpenVPN inte att fungera alls.

net.ipv6.ip_nonlocal_bind = 1

Den som försöker binda IPv6 (t.ex. nginx) direkt efter att gränssnittet har tilldelats — kommer att få ett fel. Att en sådan adress inte är tillgänglig.

För att undvika en sådan situation görs denna konfiguration.

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

Utan dessa inställningar kommer IPv6-trafik från OpenVPN-kunder inte att nå världen.

Andra inställningar är antingen irrelevanta eller minns jag inte varför de är där.
Men för säkerhets skull lämnar jag det «som det är».

För att dessa ändringar i filen ska träda i kraft utan att starta om servern — måste kommandot utföras:

sysctl -p

Mer detaljerat om «tabell» regler: habr.com/post/108690

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

OpenVPN IPv4 fungerar inte utan iptables.

Jag har följande iptables för 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 är min statiska IPv4-adress för den lokala maskinen.
10.8.0.0/24 är IPv4-nätverket för openvpn. IPv4-adresser för openvpn-klienter.
Reglernas sekvens är viktig.

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

Detta är en begränsning så att endast jag med min statiska IP kan använda OpenVPN.

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

För att vidarebefordra IPv4-paket mellan OpenVPN-klienterna och internet måste en av dessa kommandon anges.

För olika scenarier kanske en av alternativen inte passar.
Båda kommandona passar för mitt fall.
Efter att ha läst dokumentationen valde jag det första alternativet eftersom det använder mindre CPU.

För att alla iptables-inställningar ska tillämpas efter omstart måste de sparas någonstans.

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

Sådana namn valdes inte av en slump. De används av paketet "iptables-persistent".

apt-get install iptables-persistent

Installation av OpenVPN:s huvudpaket:

apt-get install openvpn easy-rsa

Låt oss ställa in en mall för certifikaten (ersätt med dina värden):

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

Låt oss redigera inställningarna för certifikatmallen:

mcedit vars

...
# Dessa är standardvärden för fälten
# som kommer att placeras i certifikatet.
# Lämna inte något av dessa fält tomma.
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 Subject Field
export KEY_NAME="server"
...

Vi skapar ett servercertifikat:

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

Vi förbereder möjligheten att skapa de slutgiltiga "client-name.opvn"-filerna:

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

Vi förbereder ett skript som kommer att sammanfoga alla filer till en enhetlig 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

Vi skapar den första OpenVPN-klienten:

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

Filen "~/client-configs/files/client-name.ovpn" skickas till klientens enhet.

För iOS-kunder måste vi göra ett trick:
Innehållet i taggen «tls-auth» ska vara utan kommentarer.
Och även sätta «key-direction 1» direkt före taggen «tls-auth».

Låt oss konfigurera OpenVPN-servern:

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

Detta behövs för att tilldela en statisk adress till varje kund (inte nödvändigt, men jag använder det):

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

Den mest komplexa och nyckelfrågan.

Tyvärr kan inte OpenVPN än automatiskt konfigurera IPv6-gateway för kunder.
Vi måste «manuellt» vidarebefordra detta för varje kund.

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

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

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

Båda skripten använder filen «/etc/openvpn/variables»:

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

Jag har svårt att minnas varför det står så här.

Det ser nu konstigt ut netmask = 112 (det borde vara 96).
Och prefixet är konstigt, det överensstämmer inte med nätverket tun0.
Men jaja, jag behåller det «som det är».

cipher DES-EDE3-CBC

Detta är en smaksak — jag valde denna krypteringsmetod för anslutningen.

Mer detaljerad information om konfiguration av OpenVPN IPv4.

Mer detaljerad information om konfiguration av OpenVPN IPv6.

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

Installation av huvudpaketet:

apt-get install postfix

Välj «internet-site» vid installation.

Min «/etc/postfix/main.cf» ser ut så här:

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

# att lägga till .domain är MUA:s jobb.
append_dot_mydomain = no

readme_directory = no

# Se http://www.postfix.org/COMPATIBILITY_README.html -- standardinställning är 2 på
# nya installationer.
compatibility_level = 2

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

# Lagringstyp
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 inställningar
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-adress per domän
sender_dependent_default_transport_maps = pcre:/etc/postfix/sdd_transport.pcre

Låt oss titta på detaljerna i denna konfiguration.

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

Enligt medlemmar på Habr är denna sektion fylld med `desinformation och felaktiga påståenden`.Först efter åtta år av min karriär började jag förstå hur SSL fungerar.

Därför tar jag mig friheten att beskriva hur man använder SSL (utan att svara på frågorna "Hur fungerar det?" och "Varför fungerar det?").

Grunden för modern encryption är att skapa ett nyckelpar (två väldigt långa strängar av tecken).

En "nyckel" är privat, den andra nyckeln är "offentlig". Den privata nyckeln förvaras noga i hemlighet. Den offentliga nyckeln delas ut till alla som vill ha den.

Med hjälp av den offentliga nyckeln kan man kryptera en textrad så att endast ägaren av den privata nyckeln kan dekryptera den.
Och det är grunden för teknologin.

Steg №1 — https-sajter.
När webbläsaren begär en webbplats får den veta av webbservern att webbplatsen är https och därför begär den den offentliga nyckeln.
Webbservern skickar den offentliga nyckeln. Webbläsaren använder den offentliga nyckeln för att kryptera http-förfrågan och skickar den.
Innehållet i http-förfrågan kan endast läsas av den som har den privata nyckeln, det vill säga endast servern som anropas.
Http-förfrågan innehåller åtminstone ett URI. Så om ett land försöker begränsa åtkomsten inte till hela webbplatsen, utan till en specifik sida — är det omöjligt att göra det för https-webbplatser.

Steg #2 — krypterat svar.
Webbservern ger ett svar som enkelt kan läsas längs vägen.
Lösningen är extremt enkel — webbläsaren skapar lokalt ett par privat-offentlig nyckel för varje https-webbplats.
Och tillsammans med begäran om webbplatsens offentliga nyckel skickar den sin lokala offentliga nyckel.
Webbservern kommer ihåg den och vid sändning av http-svar krypterar den med just denna offentliga nyckel för den specifika klienten.
Nu kan http-svaret endast dekrypteras av innehavaren av den privata nyckeln för klientens webbläsare (det vill säga själva klienten).

Steg #3 — etablering av en säker anslutning över en offentlig kanal.
I exempel #2 finns en sårbarhet — inget hindrar illvilliga aktörer från att avlyssna http-förfrågan och redigera informationen om den offentliga nyckeln.
Således kan en mellanhand se allt innehåll i skickade och mottagna meddelanden så länge som kommunikationskanalen inte ändras.
Att bekämpa detta är ganska enkelt — det räcker med att skicka webbläsarens offentliga nyckel som ett meddelande krypterat med webbserverns offentliga nyckel.
Webbservern skickar då först ett svar av typen "din offentliga nyckel ser ut så här" och krypterar detta meddelande med samma offentliga nyckel.
Webbläsaren granskar svaret — om meddelandet "din offentliga nyckel ser ut så här" kommer, så är det en 100% garanti för att denna kommunikationskanal är säker.
Hur säker är den?
Själva skapandet av en så säker kommunikationskanal sker med hastigheten ping*2. Till exempel 20 ms.
En illvillig aktör måste antingen ha den privata nyckeln för en av parterna i förväg. Eller knäcka den privata nyckeln på några millisekunder.
Att bryta ett modernt privat nyckel skulle ta decennier på en superdator.

Steg #4 — offentlig databas för offentliga nycklar.
Det är uppenbart att det i hela denna historia finns möjlighet för en illvillig aktör som sitter på kommunikationskanalen mellan klienten och servern.
Möjligheten för kunden att framställas som server och för servern att framställas som kund. Och att simulera ett par nycklar åt båda håll.
Då kommer angriparen att se all trafik och ha möjlighet att "redigera" trafiken.
Till exempel ändra adressen dit pengarna ska skickas eller kopiera lösenordet till internetbanken eller blockera "misshagligt" innehåll.
För att bekämpa sådana angripare har en offentlig databas med publika nycklar skapats för varje https-webbplats.
Varje webbläsare "vet" om existensen av cirka 200 sådana databaser. Detta är förinstallerat i varje webbläsare.
"Kunskapen" bekräftas av den publika nyckeln från varje certifikat. Det vill säga, det är omöjligt att förfalska en anslutning till varje specifik certifieringsmyndighet.

Nu finns det en enkel förståelse för hur man använder SSL för https.
Om man anstränger sig en smula blir det klart hur specialtjänster kan hacka något i denna konstruktion. Men det kommer att kosta dem enorma ansträngningar.
För organisationer mindre än NSA eller CIA är det praktiskt taget omöjligt att hacka den befintliga skyddsnivån, även för VIP.

Jag tillägger också om ssh-anslutningar. Där finns det inga publika nycklar, hur ska man göra? Frågan löses på två sätt.
SSH-lösenord alternativet:
Vid första anslutningen måste ssh-klienten varna att vi har en ny publik nyckel från ssh-servern.
Och vid framtida anslutningar, om det dyker upp en varning "ny publik nyckel från ssh-servern" — betyder det att någon försöker avlyssna.
Eller vid första anslutningen avlyssnades du, och nu kommunicerar du med servern utan mellanhänder.
Faktum är att eftersom avlyssning kan upptäckas enkelt, snabbt och utan ansträngning — används denna attack endast i speciella fall under specifika kunder.

SSH-nycklarnas alternativ:
Vi tar en USB-enhet, skriver den privata nyckeln för ssh-servern på den (det finns termer och massor av betydelsefulla nyanser, men jag skriver en allmän översikt, inte en användarmanual).
Den publika nyckeln lämnar vi på maskinen där ssh-klienten kommer att vara och håller den också hemlig.
Vi tar USB-enheten till servern, sätter i den, kopierar den privata nyckeln, och bränner sedan USB-enheten och sprider aska i vinden (eller åtminstone formaterar den med nollor).
Det är allt — efter en sådan operation kommer det att vara omöjligt att hacka en sådan ssh-anslutning. Naturligtvis kan trafiken på en superdator efter 10 år granskas — men det är en annan historia.

Jag ber om ursäkt för offtopik.

Så nu när teorin är känd. Jag kommer att berätta om flödet för att skapa ett ssl-certifikat.

Med hjälp av "openssl genrsa" skapar vi en privat nyckel och "mallar" för den offentliga nyckeln.
"mallar" skickar vi till ett tredjepartsföretag som vi betalar ungefär $9 för det enklaste certifikatet.

Efter ett par timmar får vi från detta tredjepartsföretag vår "offentliga" nyckel och ytterligare ett set med flera offentliga nycklar.

Frågan är varför man ska betala ett tredjepartsföretag för att utfärda min offentliga nyckel — det är en separat fråga och vi ska inte gå in på det här.

Nu förstår vi meningen med inskriptionen:

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

I katalogen "/etc/ssl" finns alla filer för ssl-frågor.
domain1.com — domänens namn.
2018 — året då nycklarna skapades.
"key" — beteckningen på att filen är en privat nyckel.

Och meningen med denna fil är:

smtpd_tls_cert_file= /etc/ssl/domain1.com.2018.chained.crt
domain1.com — domänens namn.
2018 — året då nycklarna skapades.
chained — beteckningen för att här finns en kedja av offentliga nycklar (den första — vår offentliga och de andra — vad som kom från företaget som utfärdade den offentliga nyckeln).
crt — beteckningen för att här finns ett färdigt certifikat (offentlig nyckel med tekniska förklaringar).

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

Denna inställning används i detta fall inte, men den är skriven som ett exempel.

För ett fel i detta parameter kommer att leda till att spam skickas från din server (utan din vilja).

Sen får du bevisa för alla att du inte är skyldig.

recipient_delimiter = +

Många kanske inte vet, men detta är den standard symbolen för att rangordna e-post och stöds av de flesta moderna e-postservrar.

Till exempel, om du har e-postlådan "username@gmail.com" försök skicka till "username+spam@gmail.com" — se vad som händer.

inet_protocols = ipv4

Detta kan vara förvirrande.

Men det är inte utan anledning. Varje ny domän har som standard endast IPv4, sedan aktiverar jag IPv6 för varje separat domän.

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

Här anger vi att all inkommande e-post går till dovecot.
Och reglerna för domän, mailbox, alias — se i databasen.

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

användare = användarens e-post
lösenord = maillösenord
värdar = 127.0.0.1
databasnamn = servermail
fråga = VÄLJ 1 FRÅN virtuella_domäner DÄR namn='%s'

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

användare = användarens e-post
lösenord = maillösenord
värdar = 127.0.0.1
databasnamn = servermail
fråga = VÄLJ 1 FRÅN virtuella_användare DÄR e-post='%s'

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

användare = användarens e-post
lösenord = maillösenord
värdar = 127.0.0.1
databasnamn = servermail
fråga = VÄLJ destination FRÅN virtuella_alias DÄR source='%s'

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

Nu vet postfix att det endast kan ta emot e-post för vidarebefordran genom autentisering med dovecot.

Jag förstår faktiskt inte riktigt varför detta ska dupliceras här. Vi har ju redan angivit allt som behövs i "virtual_transport".

Men postfix är ett mycket gammalt system - det är nog så kallade lösningar från gamla tider.

smtpd_recipient_restrictions =
        ...

smtpd_helo_restrictions =
        ...

smtpd_client_restrictions =
        ...

Detta ska konfigureras för varje e-postserver på sitt eget sätt.

Jag har 3 e-postservrar, och dessa inställningar är mycket olika på grund av olika krav för användning.

Konfigurationen måste göras noggrant - annars kommer spam att strömma till dig eller ännu värre - spam kommer att strömma från dig.

# SPF
policyd-spf_time_limit = 3600

Inställningen för en viss plugin relaterad till kontroll av SPF för inkommande e-post.

# 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

Inställningen att alla utgående e-postmeddelanden ska försörjas med en DKIM-signatur.

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

Detta är en nyckeldetalj i ruttningen av e-post när man skickar e-post från php-skript.

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:

Till vänster - reguljära uttryck. Till höger - en etikett som märker meddelandet.
Postfix kommer enligt etiketten att ta hänsyn till ytterligare några konfigurationsrader för det specifika meddelandet.

Hur postfix kommer att rekonfigureras för det specifika meddelandet kommer att anges i "master.cf".

Raderna 4, 5, 6 - de är viktiga. I vilket namn vi skickar meddelandet från - så sätter vi etiketten.
Men inte alltid i php-skript i gammal kod anges fältet "from". Då kommer användarnamnet till hjälp.

Den här artikeln är redan omfattande - jag skulle helst inte vilja förlora fokus på att konfigurera nginx+fpm.

Kort och gott - för varje webbplats anger vi vår egen linux-användare som ägare. Och därmed sin egen fpm-pool.

Fpm-pool använder vilken php-version som helst (det är utmärkt att man kan använda olika php-versioner och även olika php.ini utan problem för angränsande webbplatser på samma server).

Så för den specifika linux-användaren "www-domain2" finns det en webbplats domain2.com. På denna webbplats finns det kod för att skicka meddelanden utan att ange "from"-fältet.

Så även i det här fallet kommer meddelandena att skickas korrekt och hamnar aldrig i spam.

Min "\/etc\/postfix\/master.cf" ser ut så här:

...
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 är inte helt komplett – den är redan väldigt stor.
Jag har bara noterat det som har ändrats.

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}

Detta är inställningar relaterade till spamassassin, mer om det senare.

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 tillåter anslutning till e-postservern via port 587.
För detta behöver man absolut autentisera sig.

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

Vi aktiverar SPF-kontroll.

apt-get install postfix-policyd-spf-python

Vi installerar paketet för SPF-kontroller ovan.

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

Och detta är det mest intressanta. Det är möjligheten att skicka mejl för en specifik domän från en specifik IPv4/IPv6-adress.

Detta görs för rDNS. rDNS är att få en viss sträng från IP-adressen.
Och för e-post används denna möjlighet för att bekräfta att helo exakt matchar rDNS för den adress från vilken e-post meddelandet skickades.

Om helo inte matchar domänen för den e-postadress som skickade meddelandet, tilldelas spampoäng.

Helo matchar inte rDNS – många spampoäng tilldelas.
Därför måste varje domän ha sin egen IP-adress.
För OVH – finns det möjlighet att ange rDNS i kontrollpanelen.
För tech.ru – denna fråga löses via supporten.
För AWS – denna fråga löses via supporten.
«inet_protocols» och «smtp_bind_address6» — här aktiverar vi stöd för IPv6.
För IPv6 måste också rDNS anges.
«syslog_name» — detta är för att underlätta läsningen av loggar.

Köpa certifikat jag rekommenderar här.

Konfigurera kombinationen postfix+dovecot här.

Konfigurera SPF.

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

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

Konfigurera mysql, installera paketen själva.

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

disable_plaintext_auth = yes
auth_mechanisms = plain login

Autentisering endast i krypterad form.

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

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

Här anger vi platsen för lagring av e-post.

Jag vill att de lagras i filer och grupperas efter domäner.

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

Detta är huvudkonfigurationsfilen för dovecot.
Här stänger vi av oskyddade anslutningar.
Och aktiverar skyddade anslutningar.

Filen «/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 konfigurerar ssl. Anger att ssl är obligatoriskt.
Och själva certifikatet. En viktig detalj — direktivet «local». Det anger vilket ssl-certifikat som ska användas vid anslutning till vilken lokal IPv4.

Förresten, IPv6 är inte konfigurerat här, jag ska rätta till det senare.
XX.XX.XX.X5 (domain2) — det finns inget certifikat. För klientanslutningar måste domain1.com anges.
XX.XX.XX.X2 (domain3) — det finns ett certifikat, för klientanslutningar kan domain1.com eller domain3.com anges.

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

protocol lda {
  mail_plugins = $mail_plugins sieve
}

Detta kommer senare att behövas för spamassassin.

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

protocol imap {
  mail_plugins = $mail_plugins antispam
}

Detta är antispam-plugin. Behövs för träning av spamassassin vid flytt till/från mappen «Spam».

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

protocol pop3 {
}

Det finns helt enkelt en sådan fil.

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

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

Inställning av 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
}

Inställningar för SpamAssassin-lärande vid överföring till/från 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 där det anges vad som ska göras med inkommande brev.

Fil "\/var\/lib\/dovecot\/sieve\/default.sieve"

require ["fileinto", "mailbox"];

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

Filen måste kompileras: "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 av sql-filer för autentisering.
Och filen själv – som ett sätt att autentisera.

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';

Detta motsvarar liknande inställningar för postfix.

Fil "\/etc\/dovecot\/dovecot.conf"

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

Huvudkonfigurationsfil.
Viktigt är att vi anger-lägger protokoll här.

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

apt-get install spamassassin spamc

Vi installerar paketen.

adduser spamd --disabled-login

Vi lägger till en användare i vars namn.

systemctl enable spamassassin.service

Aktiverar automatisk start av spamassassin-tjänsten vid uppstart.

Fil "\/etc\/default\/spamassassin":

CRON=1

Aktiverar automatisk uppdatering av 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

Måste göra en mysql-databas "sa" med användaren "sa" och lösenordet "password" (byt till något lämpligt).

report_safe – istället för mail kommer en rapport om spam-mailet att skickas.
use_bayes – detta är inställningar för maskininlärning i spamassassin.

Övriga inställningar för spamassassin tillämpades tidigare enligt artikeln.

Allmän inställning "spamassassin".
Om flyttning av nya spam-brev till IMAP-mappen "Spam"..
Om en enkel kombination av Dovecot + SpamAssassin..
Rekommenderar att läsa teorin om spamassassin-lärande vid flytt av brev i imap-mappar (och rekommenderar inte att använda den)..

============= Kontakt med gemenskapen =============

Jag skulle också vilja föra fram en idé till gemenskapen om hur man kan öka skyddsnivån för skickade mejl. Eftersom jag har fördjupat mig så mycket i ämnet e-post.

För att användaren ska kunna skapa ett par nycklar på sin klient (Outlook, Thunderbird, webbläsartillägg, …). En offentlig och en privat nyckel. Den offentliga nyckeln – skicka till DNS. Den privata – spara på klienten. E-postservrar skulle kunna använda den offentliga nyckeln för att skicka till en specifik mottagare.

Och för att skydda mot skräppost i sådana mejl (ja, e-postservern kan inte se innehållet) – måste tre regler införas:

1. Obligatorisk äkta DKIM-signatur, obligatorisk SPF, obligatorisk rDNS.
2. En neuralt nätverk för att lära sig att bekämpa skräppost + en databas för detta på klientsidan.
3. Krypteringsalgoritmen måste vara sådan att sändande part måste använda 100 gånger mer CPU-kapacitet för kryptering än mottagande part.

Utöver offentliga mejl – utveckla en standard för förslagsmejl "starta en säker konversation". En av användarna (e-postlåda) skickar ett mejl till en annan e-postlåda med en bilaga. I mejlet finns textförslaget att starta en säker kommunikationskanal för konversationen och den offentliga nyckeln för ägaren av e-postlådan (medan den privata nyckeln förblir på klientsidan).

Man kan till och med skapa ett par nycklar speciellt för varje konversation. Mottagande användare kan acceptera detta erbjudande och skicka sin offentliga nyckel (också skapad speciellt för denna konversation). Därefter skickar den första användaren en tjänstestyrd kontrollmejl (krypterad med den andra användarens offentliga nyckel) – vid mottagandet av denna kan den andra användaren anse att den bildade kommunikationskanalen är tillförlitlig. Därefter skickar den andra användaren en kontrollmejl – och då kan också den första användaren anse den bildade kanalen som skyddad.

För att bekämpa avlyssning av nycklar på vägen – måste protokollet tillhandahålla möjligheten att överföra åtminstone en offentlig nyckel med hjälp av en USB-enhet.

Och det viktigaste – att allt detta fungerar (frågan 'vem ska betala för detta?'):
Ange e-postcertifikat som kostar från 10 $ för 3 år. Dessa kommer att tillåta avsändaren att ange i DNS att "mina publika nycklar finns där borta". De kommer att möjliggöra början på en säker anslutning. Med detta — ta emot sådana anslutningar gratis.
Gmail monetariserar äntligen sina användare. För 10 $ under 3 år — rätten att skapa säkra kommunikationskanaler.

============= Slutsats =============

För att testa hela artikeln planerade jag att hyra en dedikerad server i en månad och köpa en domän med SSL-certifikat.

Men livsomständigheterna gjorde att denna fråga drog ut på tiden i 2 månader.
Och nu när det återigen fanns ledig tid — beslutade jag att publicera artikeln som den är, istället för att riskera att publiceringen drar ut på tiden ytterligare ett år.

Om det kommer tillräckligt med frågor som "här är inte tillräckligt beskrivet" — då kommer det troligen att finnas krafter att faktiskt ta en dedikerad server med en ny domän och ett nytt SSL-certifikat och beskriva mer detaljerat och framför allt — avslöja alla viktiga detalj som har missats.

Jag skulle också vilja få feedback om idén med e-postcertifikat. Om idén uppskattas — ska jag försöka hitta motivation att skriva ett utkast för RFC.

Vid kopiering av stora delar av artikeln — ange en länk till denna artikel.
Vid översättning till något annat språk — ange en länk till denna artikel.
Jag ska själv försöka översätta till engelska och lämna korslänkar.

Källa: habr.com