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

Questo articolo tratta di come configurare un moderno server di posta.
Postfix + Dovecot. SPF + DKIM + rDNS. Con IPv6.
Con crittografia TSL. Con supporto per più domini - parte con un vero certificato SSL.
Con protezione antispam e un alto punteggio antispam rispetto ad altri server di posta.
Con supporto per più interfacce fisiche.
Con OpenVPN, a cui ci si connette tramite IPv4, e che fornisce IPv6.

Se non vuoi studiare tutte queste tecnologie, ma desideri configurare un server del genere - allora questo articolo è per te.

L'articolo non tenta di spiegare ogni dettaglio. Le spiegazioni sono riservate a ciò che è configurato in modo non standard o è importante dal punto di vista dell'utente.

La motivazione per configurare un server di posta è un mio sogno di lunga data. Potrebbe sembrare stupido, ma IMHO, è molto meglio che sognare un'auto nuova del marchio preferito.

La motivazione per configurare IPv6 è duplice. Un professionista IT deve studiare continuamente nuove tecnologie per sopravvivere. Vorrei dare il mio modesto contributo nella lotta contro la censura.

La motivazione per configurare OpenVPN è solo per far funzionare IPv6 sulla macchina locale.
La motivazione per configurare più interfacce fisiche è che sul mio server c'è un'interfaccia "lenta, ma illimitata", e un'altra "veloce, ma con tariffa".

La motivazione per configurare Bind è che il mio fornitore offre un server DNS instabile, e a volte anche Google ha dei problemi. Vorrei avere un server DNS stabile per uso personale.

La motivazione per scrivere un articolo è che ho scritto una bozza 10 mesi fa, e ci ho già dato un'occhiata due volte. Se anche l'autore ha bisogno di questo regolarmente, è molto probabile che anche ad altri possa servire.

Non esiste una soluzione universale per un server di posta. Ma cercherò di scrivere qualcosa come "fate in questo modo e poi, quando tutto funzionerà come dovrebbe, eliminate il superfluo".

Ho un server di colocation con l'azienda tech.ru. È possibile confrontare con OVH, Hetzner, AWS. Per risolvere questo compito, sarà molto più efficace collaborare con tech.ru.

Sul server è installato Debian 9.

Sul server ci sono 2 interfacce `eno1` e `eno2`. La prima è illimitata, mentre la seconda è veloce.

Ho 3 indirizzi IP statici, XX.XX.XX.X0, XX.XX.XX.X1 e XX.XX.XX.X2 sull'interfaccia `eno1`, e XX.XX.XX.X5 sull'interfaccia `eno2`.

Ho un pool di indirizzi IPv6 XXXX:XXXX:XXXX:XXXX::/64, assegnati all'interfaccia `eno1`, e su mia richiesta, XXXX:XXXX:XXXX:XXXX:1:2::/96 è stato assegnato a `eno2`.

Ci sono 3 domini `domain1.com`, `domain2.com`, `domain3.com`. Per `domain1.com` e `domain3.com` è presente un certificato SSL.

Esiste un account Google a cui si desidera associare la casella di posta `vasya.pupkin@domain1.com` (per ricevere e inviare email direttamente dall'interfaccia di Gmail).
Deve esserci una casella di posta `support@domain2.com`, di cui voglio vedere una copia della posta nel mio Gmail. E raramente avere la possibilità di inviare qualcosa a nome di `support@domain2.com` tramite l'interfaccia web.

Deve esserci una casella di posta `ivanov@domain3.com`, che sarà utilizzata da Ivanov dal suo iPhone.

Le email inviate devono soddisfare tutti i requisiti moderni contro lo spam.
Deve esserci il livello massimo di crittografia previsto nelle reti pubbliche.
Deve esserci supporto per IPv6 sia per l'invio che per la ricezione delle email.
Deve esserci SpamAssassin, che non eliminerà mai le email. Invece farà o un bounce oppure passerà o invierà nella cartella IMAP «Spam».
Deve essere impostato l'autoapprendimento di SpamAssassin: se sposto un'email nella cartella «Spam», si addestrerà su questo; se sposto un'email dalla cartella «Spam», si addestrerà su questo. I risultati dell'apprendimento di SpamAssassin devono influenzare l'arrivo delle email nella cartella «Spam».
Gli script php devono essere in grado di inviare email a nome di qualsiasi dominio su questo server.
Deve esserci un servizio OpenVPN, con la possibilità di utilizzare IPv6 su un client che non ha IPv6.

Prima bisogna configurare le interfacce e il routing, compreso IPv6.
Poi bisognerà configurare OpenVPN, che si connetterà tramite IPv4 e fornirà al cliente un indirizzo IPv6 reale statico. Questo cliente avrà accesso a tutti i servizi IPv6 sul server e alle risorse IPv6 su Internet.
Poi bisognerà configurare Postfix per l'invio di email + SPF + DKIM + rDNS e altre piccole cose simili.
Poi bisognerà configurare Dovecot e impostare il Multidomain.
Poi bisognerà configurare SpamAssassin e configurare l'apprendimento.
Infine, installare Bind.

============= Multi-interfacce =============

Per configurare le interfacce, è necessario scrivere quanto segue in «/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

Queste impostazioni possono essere applicate su qualsiasi server in tech.ru (con una piccola concordanza con il supporto) e funzioneranno immediatamente come previsto.

Se si ha esperienza nella configurazione di cose simili per Hetzner, OVH—lì è diverso. Più difficile.

eno1 è il nome della scheda di rete #1 (lenta, ma illimitata).
eno2 è il nome della scheda di rete #2 (veloce, ma con tariffa).
tun0 — è il nome della scheda di rete virtuale di OpenVPN.
XX.XX.XX.X0 — IPv4 #1 su eno1.
XX.XX.XX.X1 — IPv4 #2 su eno1.
XX.XX.XX.X2 — IPv4 #3 su eno1.
XX.XX.XX.X5 — IPv4 #1 su eno2.
XX.XX.XX.1 — gateway IPv4.
XXXX:XXXX:XXXX:XXXX::/64 — IPv6 per l'intero server.
XXXX:XXXX:XXXX:XXXX:1:2::/96 — IPv6 per eno2, tutto il resto entra in eno1.
XXXX:XXXX:XXXX:XXXX::1 — gateway IPv6 (è importante notare che qui si può/nasce l'esigenza di specificare l'IPv6 dello switch).
dns-nameservers — sono indicati 127.0.0.1 (perché bind è installato localmente) e 213.248.1.6 (questo è di tech.ru).

«table eno1t» e «table eno2t» — il senso di queste route-rule è che il traffico entrato tramite eno1 -> deve uscire tramite lo stesso, mentre il traffico entrato tramite eno2 -> deve uscire tramite lo stesso. Anche le connessioni avviate dal server dovrebbero uscire tramite eno1.

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

Con questo comando stabiliamo che tutto il traffico non specificato, rientrante sotto qualsiasi regola contrassegnata come «table eno1t» -> deve essere instradato all'interfaccia eno1.

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

Con questo comando stabiliamo che tutto il traffico avviato dal server deve essere instradato all'interfaccia eno1.

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

Con questo comando definiamo le stesse regole di marcatura del traffico.

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

Questo blocco definisce un secondo IPv4 per l'interfaccia eno1.

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

Con questo comando stabiliamo il route dai clienti OpenVPN verso gli IPv4 locali ad eccezione di XX.XX.XX.X0.
Perché questo comando è sufficiente per tutti gli IPv4 — non lo capisco ancora.

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

Qui stabiliamo l'indirizzo per l'interfaccia stessa. Il server lo utilizzerà come indirizzo «in uscita». Non sarà utilizzato in altro modo.

Perché è stato specificato «:1:1::» in modo così complesso? Perché OpenVPN funzioni correttamente e solo per questo. Di questo parleremo più avanti.

Riguardo al gateway — funziona così ed è a posto. Ma tecnicamente — qui dovrebbe essere specificato l'IPv6 dello switch a cui è connesso il server.

Tuttavia, per qualche motivo l'IPv6 smette di funzionare se lo faccio in questo modo. Probabilmente sono stranezze di tech.ru.

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

Questo è l'aggiunta di un indirizzo IPv6 all'interfaccia. Se ne servono cento — significherà cento righe in questo file.

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

Ho contrassegnato gli indirizzi e le sottoreti di tutte le interfacce, per renderlo chiaro.
eno1 deve necessariamente essere «/64» poiché è il nostro intero pool di indirizzi.
tun0 — la sottorete deve essere necessariamente più grande di eno1. Altrimenti non sarà possibile configurare il gateway IPv6 per i clienti OpenVPN.
eno2 — la sottorete deve essere necessariamente più grande di tun0. Altrimenti i clienti OpenVPN non potranno accedere agli indirizzi IPv6 locali.
Per chiarezza, ho scelto un passo di sottorete di 16, ma se si desidera si può anche fare un passo di «1».
Di conseguenza 64+16 = 80, e 80+16 = 96.
Per maggiore chiarezza:
XXXX:XXXX:XXXX:XXXX:1:1:YYYY:YYYY — questi sono gli indirizzi che devono essere assegnati a siti o servizi specifici sull'interfaccia eno1.
XXXX:XXXX:XXXX:XXXX:1:2:YYYY:YYYY — questi sono gli indirizzi che devono essere assegnati a siti o servizi specifici sull'interfaccia eno2.
XXXX:XXXX:XXXX:XXXX:1:3:YYYY:YYYY — questi sono gli indirizzi che devono essere assegnati ai clienti OpenVPN o utilizzati come indirizzi di servizio OpenVPN.

Per configurare la rete — deve esserci la possibilità di riavviare il server.
Le modifiche IPv4 vengono applicate eseguendo (assicurati di racchiuderle in screen — altrimenti questo comando causerà semplicemente l'interruzione della rete sul server):

/etc/init.d/networking restart

Aggiungere alla fine del file «/etc/iproute2/rt_tables»:

100 eno1t
101 eno2t

Senza questo, non è possibile utilizzare le tabelle personalizzate nel file «/etc/network/interfaces».
I numeri devono essere unici e inferiori a 65535.

Le modifiche IPv6 possono essere apportate facilmente senza riavvii, ma per questo è necessario apprendere almeno tre comandi:

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

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

Queste sono le impostazioni «sysctl» del mio server. Sottolineo l'importante.

net.ipv4.ip_forward = 1

Senza questo, OpenVPN non funzionerà affatto.

net.ipv6.ip_nonlocal_bind = 1

Chiunque provi a eseguire il bind IPv6 (ad esempio nginx) subito dopo che l'interfaccia è stata creata riceverà un errore. Stessa indicazione che l'indirizzo non è disponibile.

Per evitare una situazione del genere, si effettua questa configurazione.

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

Senza queste impostazioni, il traffico IPv6 dai clienti OpenVPN non uscirà nel mondo.

Altre impostazioni o non sono pertinenti o non ricordo a cosa servono.
Ma per ogni evenienza lascio «così com'è».

Perché le modifiche di questo file vengano applicate senza riavviare il server — è necessario eseguire il comando:

sysctl -p

Maggiore dettaglio su «regole» della tabella: habr.com/post/108690

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

OpenVPN IPv4 non funziona senza iptables.

Ho iptables impostati in questo modo per VPN:

iptables -A INPUT -p udp -s YY.YY.YY.YY --dport 1194 -j ACCETTA
iptables -A FORWARD -i tun0 -o eno1 -j ACCETTA
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 ACCETTA
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCETTA
iptables -A INPUT -p udp --dport 1194 -j DROPA
iptables -A FORWARD -p udp --dport 1194 -j DROPA

YY.YY.YY.YY è il mio indirizzo IPv4 statico della macchina locale.
10.8.0.0/24 è la rete IPv4 di openvpn. Gli indirizzi IPv4 per i client di openvpn.
La sequenza delle regole è importante.

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

Questa è una limitazione affinché solo io possa utilizzare OpenVPN dal mio indirizzo IP statico.

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

Per instradare i pacchetti IPv4 tra i client OpenVPN e Internet è necessario eseguire uno di questi comandi.

Per diversi casi, una delle opzioni non è adatta.
Per il mio caso entrambe le opzioni sono adatte.
Dopo aver letto la documentazione, ho scelto la prima opzione perché consuma meno CPU.

Affinché tutte le impostazioni di iptables vengano lette dopo il riavvio, è necessario salvarle da qualche parte.

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

Tali nomi non sono stati scelti a caso. Vengono utilizzati dal pacchetto "iptables-persistent".

apt-get install iptables-persistent

Installazione del pacchetto principale OpenVPN:

apt-get install openvpn easy-rsa

Imposteremo il modello per i certificati (sostituisci i tuoi valori):

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

Modifichiamo le impostazioni del modello di certificato:

mcedit vars

...
# Questi sono i valori predefiniti per i campi
# che saranno inseriti nel certificato.
# Non lasciare vuoti nessuno di questi campi.
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"

# Campo soggetto X509
export KEY_NAME="server"
...

Creiamo il certificato del server:

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

Prepariamo la possibilità di creare file finali "client-name.opvn":

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

# Client mode
client

# Interface tunnel type
dev tun

# TCP protocol
proto tcp-client

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

# Don't bind to local port/address
nobind

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

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

# Enable compression
comp-lzo

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

Prepariamo uno script che unirà tutti i file in un unico file opvn.

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

#!/bin/bash

# First argument: Client identifier

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

cat ${BASE_CONFIG} 
    <(echo -e '<ca>') 
    ${KEY_DIR}/ca.crt 
    <(echo -e '</ca>n<cert>') 
    ${KEY_DIR}/${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

Creiamo il primo client OpenVPN:

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

Il file "~/client-configs/files/client-name.ovpn" viene inviato al dispositivo del cliente.

Per i clienti iOS sarà necessario fare un trucco:
Il contenuto del tag «tls-auth» deve essere privo di commenti.
E bisogna inserire «key-direction 1» subito prima del tag «tls-auth».

Configuriamo il file di configurazione del server OpenVPN:

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

# Listen port
port 1194

# Protocol
proto tcp-server

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

# Master certificate
ca ca.crt

# Server certificate
cert server.crt

# Server private key
key server.key

# Diffie-Hellman parameters
dh dh2048.pem

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

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

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

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

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

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

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

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

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

# Enable compression
comp-lzo

# User and group
user vpn
group vpn

# Log a short status
status openvpn-status.log

# Logging verbosity
##verb 4

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

Questo è necessario per assegnare un indirizzo statico a ciascun cliente (non obbligatorio, ma io lo utilizzo):

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

Il dettaglio più complesso e cruciale.

Sfortunatamente, OpenVPN non è ancora in grado di configurare autonomamente il gateway IPv6 per i clienti.
Bisogna passare questo manualmente per ogni cliente.

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

Il 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

Il 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

Entrambi gli script utilizzano il file «/etc/openvpn/variables»:

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

Non ricordo perché è scritto in questo modo.

Ora sembra strano netmask = 112 (qui dovrebbe essere 96).
E il prefix è strano, non corrisponde alla rete tun0.
Ma va bene, lo lascio «così com'è».

cipher DES-EDE3-CBC

Questo è per i gusti — ho scelto questo modo di crittografare la connessione.

Maggiori dettagli sulla configurazione di OpenVPN IPv4.

Maggiori dettagli sulla configurazione di OpenVPN IPv6.

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

Installazione del pacchetto principale:

apt-get install postfix

Durante l'installazione scegliere «internet-site».

Il mio «/etc/postfix/main.cf» appare così:

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

# aggiungere .domain è compito del MUA.
append_dot_mydomain = no

readme_directory = no

# Vedi http://www.postfix.org/COMPATIBILITY_README.html -- impostazione predefinita a 2 su
# nuove installazioni.
compatibility_level = 2

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

# Tipo di archiviazione
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

# Impostazioni SMTP-Auth
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

# Indirizzo IP per dominio
sender_dependent_default_transport_maps = pcre:/etc/postfix/sdd_transport.pcre

Analizziamo i dettagli di questa configurazione.

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

Secondo i membri di Habr, questo blocco contiene `disinformazione e tesi errate`.Solo dopo 8 anni all'inizio della mia carriera ho cominciato a capire come funziona SSL.
Quindi mi prenderò la libertà di descrivere come utilizzare SSL (senza rispondere a domande come «Come funziona?» e «Perché funziona?»).
La base della crittografia moderna è la creazione di una coppia di chiavi (due lunghe stringhe di caratteri).
Una chiave è privata, l'altra chiave è pubblica. La chiave privata va custodita gelosamente segreta. La chiave pubblica viene distribuita a chiunque la richieda.
Attraverso la chiave pubblica è possibile crittografare una stringa di testo in modo tale che solo il proprietario della chiave privata possa decifrarla.
Ed ecco la base della tecnologia.
Passo n. 1 — siti https.
Il browser, quando accessa un sito, informa dal server web che il sito è https e quindi richiede la chiave pubblica.
Il server web restituisce la chiave pubblica. Il browser, utilizzando la chiave pubblica, cripta la richiesta HTTP e la invia.
Il contenuto della richiesta HTTP può essere letto solo da chi possiede la chiave privata, ovvero solo dal server a cui si sta accedendo.
La richiesta HTTP contiene almeno un URI. Pertanto, se in un paese si cerca di limitare l'accesso non all'intero sito, ma a una specifica pagina, per i siti HTTPS questo è impossibile.
Passo n. 2 — risposta criptata.
Il server web fornisce una risposta che può essere facilmente letta lungo il tragitto.
La soluzione è estremamente semplice: il browser crea localmente una coppia di chiavi privata-pubblica per ogni sito HTTPS.
Insieme alla richiesta della chiave pubblica del sito, invia la propria chiave pubblica locale.
Il server web la memorizza e, quando invia la risposta HTTP, cripta con quella chiave pubblica specifica del cliente.
Ora, la risposta HTTP può essere decriptata solo dal possessore della chiave privata del browser del cliente (cioè il cliente stesso).
Passo n. 3 — stabilire una connessione sicura su un canale pubblico.
Nell'esempio n. 2 c'è una vulnerabilità: nulla impedisce a malintenzionati di intercettare la richiesta HTTP e modificare le informazioni sulla chiave pubblica.
In questo modo, un intermediario può vedere perfettamente tutto il contenuto dei messaggi inviati e ricevuti finché non cambia il canale di comunicazione.
Combattere questo problema è molto semplice: basta inviare la chiave pubblica del browser come messaggio criptato con la chiave pubblica del server web.
Il server web allora invia per primo una risposta del tipo "la tua chiave pubblica è questa" e cripta questo messaggio con la stessa chiave pubblica.
Il browser controlla la risposta: se riceve il messaggio "la tua chiave pubblica è questa", allora questo è una garanzia al 100% che il canale di comunicazione è sicuro.
Quanto è sicuro?
La creazione di un tale canale di comunicazione sicuro avviene alla velocità di ping*2. Ad esempio, 20 ms.
Il malintenzionato deve o avere preventivamente la chiave privata di una delle parti, oppure indovinare la chiave privata in pochi millisecondi.
Decifrare una chiave privata moderna richiederebbe decenni su un supercomputer.
Passo n. 4 — registro pubblico delle chiavi pubbliche.
È evidente che in tutta questa storia esiste la possibilità per un malintenzionato di trovarsi sul canale di comunicazione tra il cliente e il server.
La possibilità di far apparire il cliente come un server e il server come un cliente. E simulare una coppia di chiavi in entrambe le direzioni.
Allora l'aggressore vedrà tutto il traffico e avrà la possibilità di "modificare" il traffico.
Ad esempio, cambiare l'indirizzo dove inviare il denaro o copiare la password per l'online banking o bloccare contenuti "scomodi".
Per combattere tali aggressori è stata ideata una banca dati pubblica con chiavi pubbliche per ogni sito https.
Ogni browser "sa" dell'esistenza di circa 200 di queste banche dati. Questo è preinstallato in ogni browser.
"La conoscenza" è supportata dalla chiave pubblica di ogni certificato. Vale a dire che non è possibile falsificare la connessione con ogni singolo ente certificatore.
Ora c'è una comprensione semplice di come utilizzare SSL per https.
Se si riflette un po' — diventa chiaro come i servizi segreti possano violare qualcosa in questa struttura. Ma per loro sarà un'impresa mostruosa.
E per le organizzazioni meno dell'NSA o della CIA — è praticamente impossibile violare l'attuale livello di protezione anche per i VIP.
Aggiungo anche riguardo alle connessioni ssh. Lì non ci sono chiavi pubbliche, come fare? La questione viene risolta in due modi.
Opzione ssh-a-password:
Alla prima connessione, il client ssh deve avvisare che qui abbiamo una nuova chiave pubblica dal server ssh.
E per le connessioni successive, se appare un avviso "nuova chiave pubblica dal server ssh" — significherà che stanno cercando di intercettarti.
Oppure, nella prima connessione ti stavano intercettando e ora stai comunicando con il server senza intermediari.
In effetti, il fatto che l'intercettazione sia facilmente, rapidamente e senza sforzo rilevabile — questa tecnica viene utilizzata solo in casi particolari per specifici clienti.
Opzione ssh-a-chiave:
Prendiamo una chiavetta USB, registriamo su di essa la chiave privata per il server ssh (per questo ci sono terminologie e molte sfumature significative, ma sto scrivendo un'infarinatura e non un manuale d'uso).
La chiave pubblica la lasciamo sulla macchina dove ci sarà il client ssh e la manteniamo anche segreta.
Portiamo la chiavetta al server, la inseriamo, copiamo la chiave privata, e poi bruciamo la chiavetta e disperdiamo le ceneri nel vento (o almeno formattiamo riempiendo di zeri).
Ecco, dopo un'operazione del genere sarà impossibile violare una connessione ssh. Certamente, in 10 anni, su un supercomputer, sarà possibile esaminare il traffico, ma questa è un'altra storia.
Mi scuso per l'argomento off-topic.

Quindi, ora che conosciamo la teoria, parlerò del flusso di creazione di un certificato ssl.

Con "openssl genrsa" creiamo una chiave privata e delle "bozze" per la chiave pubblica.
Le "bozze" vengono inviate a una società esterna a cui paghiamo circa $9 per il certificato più semplice.

Dopo alcune ore riceviamo da questa società il nostro "chiave pubblica" e anche un insieme di altre chiavi pubbliche.

Perché dovrei pagare una società esterna per emettere la mia chiave pubblica è un'altra questione, qui non la considereremo.

Ora è chiaro il significato dell'iscrizione:

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

Nella cartella "/etc/ssl" sono archiviati tutti i file per questioni ssl.
domain1.com è il nome del dominio.
2018 è l'anno di creazione delle chiavi.
"key" indica che il file è una chiave privata.

E il significato di questo file:

smtpd_tls_cert_file=\/etc\/ssl\/domain1.com.2018.chained.crt
domain1.com è il nome del dominio.
2018 è l'anno di creazione delle chiavi.
chained indica che qui c'è una catena di chiavi pubbliche (la prima è la nostra chiave pubblica e le altre sono quelle ricevute dalla società che ha emesso la chiave pubblica).
crt indica che qui c'è un certificato pronto (chiave pubblica con spiegazioni tecniche).

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

Questa impostazione in questo caso non viene utilizzata, ma è scritta come esempio.

Perché un errore in questo parametro porterà all'invio di spam dal tuo server (senza la tua volontà).

Poi dovrai dimostrare a tutti che non sei colpevole.

recipient_delimiter = +

Forse molti non lo sanno, ma questo è il simbolo standard per l'assegnazione dei parametri, e viene supportato dalla maggior parte dei moderni server di posta.

Ad esempio, se hai una casella di posta "username@gmail.com", prova a inviare a "username+spam@gmail.com" — guarda cosa succede.

inet_protocols = ipv4

Potrebbe sembrare confuso.

Ma non è casuale. Ogni nuovo dominio utilizza per default solo IPv4, poi attivo IPv6 per ciascuno separatamente.

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

Qui impostiamo che tutta la posta in arrivo vada in dovecot.
E le regole per dominio, casella postale, alias — vanno verificate nel database.

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

utente = 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

utente = 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

utente = 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

Ora postfix sa che può accettare la posta per l'invio solo con autenticazione tramite dovecot.

Non capisco davvero perché duplicare queste informazioni qui. Abbiamo già specificato tutto in «virtual_transport».

Ma il sistema postfix è molto vecchio — probabilmente sono soluzioni per problemi di vecchia data.

smtpd_recipient_restrictions =
        ...

smtpd_helo_restrictions =
        ...

smtpd_client_restrictions =
        ...

Queste impostazioni devono essere configurate per ciascun server di posta in modo specifico.

Ho a disposizione 3 server di posta e queste impostazioni sono molto diverse a causa delle diverse esigenze operative.

È necessario configurare con attenzione — altrimenti lo spam arriverà a voi o, peggio ancora, partirà da voi.

# SPF
policyd-spf_time_limit = 3600

Configurazione per un qualche plugin relativo al controllo SPF delle email in arrivo.

# 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

Impostazione che prevede che tutte le email in uscita debbano essere dotate di firma DKIM.

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

Questo è un dettaglio fondamentale nella gestione della posta quando si inviano email da script PHP.

File «/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:

A sinistra — espressioni regolari. A destra — etichetta con cui contrassegnare l'email.
Postfix, in base all'etichetta, considererà ulteriori righe di configurazione per quella specifica email.
Il modo in cui postfix verrà riconfigurato per una specifica email sarà indicato in «master.cf».
Le righe 4, 5, 6 — sono le più importanti. Invii l'email a nome di quale dominio — metti quella etichetta.
Ma non sempre nei vecchi script PHP viene specificato il campo «from». Allora in aiuto viene il nome utente.
L'articolo è già abbastanza ampio — non vorrei distogliere l'attenzione sulla configurazione di nginx+fpm.
In breve — per ciascun sito impostiamo il rispettivo proprietario linux-user. E quindi il proprio fpm-pool.
Fpm-pool utilizza qualsiasi versione di PHP (è fantastico che su un singolo server si possano utilizzare senza problemi versioni diverse di PHP e anche diversi php.ini).
Ecco, per l'utente linux-specifico «www-domain2» c'è il sito domain2.com. Su questo sito c'è codice per inviare email senza specificare il campo from.
In questo caso, anche in tali circostanze, le email verranno inviate correttamente e non finiranno mai nello spam.

Il mio «/etc/postfix/master.cf» appare così:

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

Il file non è stato completamente riportato — è già molto grande.
Ho evidenziato solo le modifiche.

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}

Queste sono impostazioni relative a spamassassin, di cui parleremo più tardi.

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

Consentiamo di connettersi al server di posta tramite la porta 587.
È necessario autenticarsi.

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

Attiviamo il controllo SPF.

apt-get install postfix-policyd-spf-python

Installeremo il pacchetto per i controlli SPF.

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

Questo è il punto più interessante. È la possibilità di inviare email per un dominio specifico da un indirizzo IPv4/IPv6 specifico.
Questo viene fatto per il rDNS. Il rDNS è l'ottenimento di una certa stringa tramite l'indirizzo IP.
E per la posta, questa possibilità è utilizzata per confermare che il helo corrisponde esattamente al rDNS dell'indirizzo da cui è stata inviata l'email.
Se il helo non corrisponde al dominio della posta, a nome del quale è stata inviata l'email, vengono aggiunti punti spam.
Helo non corrisponde al rDNS — vengono aggiunti molti punti spam.
Di conseguenza, per ogni dominio deve esserci un proprio indirizzo IP.
Per OVH — nella console c'è la possibilità di specificare il rDNS.
Per tech.ru — il problema si risolve tramite il supporto.
Per AWS — il problema si risolve tramite il supporto.
«inet_protocols» e «smtp_bind_address6» - qui attiviamo il supporto per IPv6.
Per IPv6 è necessario configurare anche il rDNS.
«syslog_name» - ecco per facilitare la lettura dei log.

Acquisto certificati consiglio qui.

Configurazione della combinazione postfix+dovecot qui.

Configurazione SPF.

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

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

Configurazione di mysql, installiamo noi stessi i pacchetti.

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

disable_plaintext_auth = yes
auth_mechanisms = plain login

Autenticazione solo in modalità crittografata.

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

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

Qui indicheremo il luogo di archiviazione delle email.

Voglio che vengano archiviate in file e raggruppate per domini.

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

Questo è il file principale delle configurazioni di dovecot.
Qui disattiviamo le connessioni non protette.
E attiviamo le connessioni protette.

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

Configuriamo ssl. Indichiamo che ssl è obbligatorio.
E il certificato stesso. Un dettaglio importante è la direttiva «local». Indica quale certificato ssl utilizzare per quale IPv4 locale.
Tra l'altro, l'IPv6 non è configurato qui, sistemerò questa mancanza più avanti.
XX.XX.XX.X5 (domain2) - certificato mancante. Per le connessioni dei client è necessario indicare domain1.com.
XX.XX.XX.X2 (domain3) - certificato presente, per le connessioni dei client si può indicare domain1.com o domain3.com.

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

protocol lda {
  mail_plugins = $mail_plugins sieve
}

Questo sarà necessario in seguito per spamassassin.

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

protocol imap {
  mail_plugins = $mail_plugins antispam
}

Questo è il plugin antispam. Necessario per addestrare spamassassin durante il trasferimento in/from la cartella «Spam».

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

protocol pop3 {
}

Esiste semplicemente un file di questo tipo.

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

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

Impostazione di lmtp.

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

Impostazioni di apprendimento di spamassassin al momento del trasferimento in/da la cartella «Spam».

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

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

File in cui è indicato cosa fare con le email in ingresso.

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

require ["fileinto", "mailbox"];

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

Devi compilare il file: «sievec default.sieve».

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

Indicazioni sui file sql per l'autenticazione.
E il file stesso — come metodo di autenticazione.

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

Questo corrisponde alle impostazioni analoghe per postfix.

File «/etc/dovecot/dovecot.conf»

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

File principale di configurazione.
È importante ciò che qui specifichiamo-aggiungiamo come protocolli.

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

apt-get install spamassassin spamc

Installeremo i pacchetti.

adduser spamd --disabled-login

Aggiungiamo un utente a nome di cui.

systemctl enable spamassassin.service

Attiviamo l'avvio automatico del servizio spamassassin all'avvio.

File «/etc/default/spamassassin»:

CRON=1

Attiviamo l'aggiornamento automatico delle regole «predefinite».

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

È necessario creare nel DB mysql «sa» con l'utente «sa» e la password «password» (sostituisci con qualcosa di adeguato).

report_safe — al posto della mail verrà inviato un report sulla mail di spam.
use_bayes — queste sono le impostazioni di apprendimento automatico per spamassassin.

Le altre impostazioni di spamassassin sono state applicate in precedenza secondo l'articolo.

Impostazione generale di «spamassassin».
Riguardo al trasferimento di nuove email di spam nella cartella IMAP «Spam».
Riguardo alla semplice combinazione Dovecot + SpamAssassin.
Consiglio di leggere la teoria dell'apprendimento di spamassassin durante il movimento delle email nelle cartelle imap (e non consiglio di applicarla).

============= Appello alla comunità =============

Vorrei anche proporre un'idea alla comunità su come aumentare il livello di sicurezza delle email inviate. Dato che mi sono immerso così a fondo nel tema della posta elettronica.

In modo che l'utente possa creare un paio di chiavi sul proprio client (outlook, thunderbird, browser-plugin, …). Pubblica e privata. La pubblica — inviata nel DNS. La privata — conservata sul client. I server di posta sarebbero in grado di applicare la chiave pubblica per inviare a un destinatario specifico.

E per proteggere da spam in tali email (sì, il server di posta non sarà in grado di controllare il contenuto) — è necessario introdurre 3 regole:

Firma DKIM reale obbligatoria, SPF obbligatorio, rDNS obbligatorio.
Rete neurale per l'addestramento anti-spam + database ad essa collegato sul lato client.
L'algoritmo di crittografia deve essere tale che la parte che invia debba spendere 100 volte più potenza CPU per la crittografia rispetto a quella che riceve.

Oltre alle email pubbliche — sviluppare uno standard per l'email di proposta "iniziare una corrispondenza protetta". Uno degli utenti (casella di posta) invia a un'altra casella di posta un'email con un allegato. Nell'email, testo-con proposta di avviare un canale di comunicazione protetto per la corrispondenza e la chiave pubblica del proprietario della casella di posta (mentre la chiave privata è sul client).

Si possono anche creare un paio di chiavi appositamente per ciascuna corrispondenza. L'utente ricevente può accettare questa proposta e inviare la propria chiave pubblica (anch'essa fatta apposta per questa corrispondenza). In seguito, il primo utente invia un'email di controllo (crittografata con la chiave pubblica del secondo utente) — alla ricezione della quale il secondo utente può considerare il canale di comunicazione formato come affidabile. Successivamente il secondo utente invia un'email di controllo — e allora anche il primo utente può considerare il canale formato come protetto.

Per combattere l'intercettazione delle chiavi lungo il percorso — è necessario prevedere nel protocollo la possibilità di trasmettere almeno una chiave pubblica tramite una chiavetta USB.

E la cosa più importante — affinché tutto ciò funzioni (la domanda "chi pagherà per questo?"):
Inserire certificati di posta elettronica con un costo a partire da 10$ per 3 anni. Questi permetteranno al mittente di indicare nel DNS che "le mie chiavi pubbliche si trovano lì". E daranno la possibilità di avviare una connessione sicura. Inoltre, accetteranno tali connessioni gratuitamente.
Gmail finalmente monetizza i propri utenti. Per 10$ in 3 anni - il diritto di creare canali di comunicazione protetti.

============= Conclusione =============

Per testare tutto l'articolo intendevo affittare un server dedicato per un mese e acquistare un dominio con certificato SSL.

Ma le circostanze della vita hanno fatto sì che questa questione si prolungasse per 2 mesi.
E quando ho avuto di nuovo del tempo libero, ho deciso di pubblicare l'articolo così com'è, piuttosto che rischiare che la pubblicazione si prolungasse per un altro anno.

Se ci saranno abbastanza domande del tipo "qui non è descritto in dettaglio", allora probabilmente troverò la motivazione per affittare un server dedicato con un nuovo dominio e un nuovo certificato SSL e descrivere tutto in modo ancora più dettagliato, e soprattutto - evidenziare tutti i dettagli importanti trascurati.

Mi piacerebbe anche ricevere feedback sull'idea dei certificati di posta. Se l'idea piace, cercherò di trovare la motivazione per scrivere una bozza per l'rfc.

Nel copiare grandi parti dell'articolo, indicare un link a questo articolo.
Nel tradurre in qualsiasi altra lingua, indicare un link a questo articolo.
Cercherò di tradurre in inglese personalmente e lascerò link incrociati.

Fonte: habr.com