🥇Debian + Postfix + Dovecot + Multidomain + SSL + IPv6 + OpenVPN + Multi-interfícies + SpamAssassin-learn + Bind

Aquest article tracta sobre com configurar un servidor de correu modern.
Postfix + Colom. SPF + DKIM + rDNS. Amb IPv6.
Amb xifratge TSL. Amb suport per a diversos dominis, part amb un certificat SSL real.
Amb protecció antispam i una alta qualificació antispam d'altres servidors de correu.
Admet múltiples interfícies físiques.
Amb OpenVPN, la connexió a la qual es fa mitjançant IPv4, i que proporciona IPv6.

Si no voleu aprendre totes aquestes tecnologies, però voleu configurar aquest servidor, aquest article és per a vosaltres.

L'article no intenta explicar tots els detalls. L'explicació va al que no està configurat com a estàndard o és important des del punt de vista del consumidor.

La motivació per configurar un servidor de correu ha estat un somni meu des de fa temps. Això pot semblar estúpid, però IMHO, és molt millor que somiar amb un cotxe nou de la teva marca preferida.

Hi ha dues motivacions per configurar IPv6. Un especialista en informàtica necessita aprendre noves tecnologies constantment per sobreviure. M'agradaria fer la meva modesta contribució a la lluita contra la censura.

La motivació per configurar OpenVPN és només aconseguir que IPv6 funcioni a la màquina local.
La motivació per configurar diverses interfícies físiques és que al meu servidor tinc una interfície "lenta però il·limitada" i una altra "ràpida però amb tarifa".

La motivació per configurar la configuració de Bind és que el meu ISP proporciona un servidor DNS inestable i, de vegades, Google també falla. Vull un servidor DNS estable per a ús personal.

Motivació per escriure un article: vaig escriure un esborrany fa 10 mesos i ja l'he mirat dues vegades. Fins i tot si l'autor ho necessita regularment, hi ha una gran probabilitat que altres també ho necessitin.

No hi ha una solució universal per a un servidor de correu. Però intentaré escriure alguna cosa com "feu això i després, quan tot funcioni com hauria de ser, llenceu les coses addicionals".

L'empresa tech.ru té un servidor de col·locació. És possible comparar amb OVH, Hetzner, AWS. Per resoldre aquest problema, la cooperació amb tech.ru serà molt més efectiva.

Debian 9 està instal·lat al servidor.

El servidor té 2 interfícies `eno1` i `eno2`. El primer és il·limitat i el segon és ràpid, respectivament.

Hi ha 3 adreces IP estàtiques, XX.XX.XX.X0 i XX.XX.XX.X1 i XX.XX.XX.X2 a la interfície `eno1` i XX.XX.XX.X5 a la interfície `eno2` .

Disponible XXXX:XXXX:XXXX:XXXX::/64 un grup d'adreces IPv6 que s'assignen a la interfície `eno1` i des d'aquesta XXXX:XXXX:XXXX:XXXX:1:2::/96 es va assignar a `eno2` a petició meva.

Hi ha 3 dominis `domain1.com`, `domain2.com`, `domain3.com`. Hi ha un certificat SSL per a "domain1.com" i "domain3.com".

Tinc un compte de Google al qual m'agradaria enllaçar la meva bústia de correu[protegit per correu electrònic]` (rebre i enviar correu directament des de la interfície de gmail).
Hi ha d'haver una bústia'[protegit per correu electrònic]`, una còpia del correu electrònic des del qual vull veure al meu gmail. I és estrany poder enviar alguna cosa en nom de `[protegit per correu electrònic]` mitjançant la interfície web.

Hi ha d'haver una bústia'[protegit per correu electrònic]`, que Ivanov utilitzarà des del seu iPhone.

Els correus electrònics enviats han de complir tots els requisits antispam moderns.
Hi ha d'haver el nivell més alt de xifratge proporcionat a les xarxes públiques.
Hi hauria d'haver suport IPv6 tant per enviar com per rebre cartes.
Hi hauria d'haver un SpamAssassin que mai suprimirà els correus electrònics. I rebotarà o saltarà o s'enviarà a la carpeta "Correu brossa" d'IMAP.
S'ha de configurar l'aprenentatge automàtic de SpamAssassin: si mou una carta a la carpeta de correu brossa, n'aprendrà; si mou una carta de la carpeta de correu brossa, n'aprendrà. Els resultats de la formació de SpamAssassin haurien d'influir en si la carta acaba a la carpeta de correu brossa.
Els scripts PHP han de poder enviar correu en nom de qualsevol domini d'un servidor determinat.
Hi hauria d'haver un servei openvpn, amb la possibilitat d'utilitzar IPv6 en un client que no tingui IPv6.

Primer heu de configurar les interfícies i l'encaminament, inclòs IPv6.
Aleshores, haureu de configurar OpenVPN, que es connectarà mitjançant IPv4 i proporcionarà al client una adreça IPv6 estàtica i real. Aquest client tindrà accés a tots els serveis IPv6 del servidor i accés a qualsevol recurs IPv6 a Internet.
Aleshores, haureu de configurar Postfix per enviar cartes + SPF + DKIM + rDNS i altres petites coses semblants.
Aleshores haureu de configurar Dovecot i configurar Multidomini.
Aleshores, haureu de configurar SpamAssassin i configurar l'entrenament.
Finalment, instal·leu Bind.

============= Multi-interfícies ==============

Per configurar les interfícies, heu d'escriure això a "/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

Aquests paràmetres es poden aplicar a qualsevol servidor de tech.ru (amb una mica de coordinació amb el suport) i funcionarà immediatament com cal.

Si tens experiència configurant coses semblants per a Hetzner, OVH, allà és diferent. Més difícil.

eno1 és el nom de la targeta de xarxa #1 (lenta però il·limitada).
eno2 és el nom de la targeta de xarxa #2 (ràpida, però amb tarifa).
tun0 és el nom de la targeta de xarxa virtual d'OpenVPN.
XX.XX.XX.X0 - IPv4 #1 a eno1.
XX.XX.XX.X1 - IPv4 #2 a eno1.
XX.XX.XX.X2 - IPv4 #3 a eno1.
XX.XX.XX.X5 - IPv4 #1 a eno2.
XX.XX.XX.1: passarel·la IPv4.
XXXX:XXXX:XXXX:XXXX::/64 - IPv6 per a tot el servidor.
XXXX:XXXX:XXXX:XXXX:1:2::/96 - IPv6 per a eno2, tota la resta de l'exterior passa a eno1.
XXXX:XXXX:XXXX:XXXX::1 — Passarel·la IPv6 (val la pena assenyalar que això es pot/ha de fer de manera diferent. Especifiqueu el commutador IPv6).
dns-nameservers: s'indica 127.0.0.1 (perquè bind s'instal·la localment) i 213.248.1.6 (això és de tech.ru).

"taula eno1t" i "taula eno2t": el significat d'aquestes regles de ruta és que el trànsit que entra per eno1 -> sortiria per ella, i el trànsit que entra per eno2 -> sortiria per ella. I també les connexions iniciades pel servidor passarien per eno1.

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

Amb aquesta ordre especifiquem que qualsevol trànsit incomprensible que caigui sota qualsevol regla marcada "taula eno1t" -> s'enviarà a la interfície eno1.

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

Amb aquesta ordre especifiquem que qualsevol trànsit iniciat pel servidor s'ha de dirigir a la interfície eno1.

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

Amb aquesta ordre establim les regles per marcar el trànsit.

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

Aquest bloc especifica un segon IPv4 per a la interfície eno1.

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

Amb aquesta ordre establim la ruta dels clients OpenVPN a IPv4 local, excepte XX.XX.XX.X0.
Encara no entenc per què aquesta ordre és suficient per a tots els IPv4.

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

Aquí és on establim l'adreça de la interfície en si. El servidor l'utilitzarà com a adreça "sortint". No es tornarà a utilitzar de cap manera.

Per què ":1:1::" és tan complicat? Perquè OpenVPN funcioni correctament i només per a això. Més sobre això més endavant.

Pel que fa al tema de la passarel·la, així és com funciona i està bé. Però la manera correcta és indicar aquí l'IPv6 del commutador al qual està connectat el servidor.

Tanmateix, per algun motiu IPv6 deixa de funcionar si faig això. Probablement això sigui algun tipus de problema de tech.ru.

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

Això és afegir una adreça IPv6 a la interfície. Si necessiteu cent adreces, això significa cent línies en aquest fitxer.

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

Vaig assenyalar les adreces i les subxarxes de totes les interfícies per deixar-ho clar.
eno1 - ha de ser "/64"- perquè aquest és tot el nostre conjunt d'adreces.
tun0: la subxarxa ha de ser més gran que eno1. En cas contrari, no serà possible configurar una passarel·la IPv6 per als clients OpenVPN.
eno2: la subxarxa ha de ser més gran que tun0. En cas contrari, els clients OpenVPN no podran accedir a les adreces IPv6 locals.
Per a més claredat, vaig triar un pas de subxarxa de 16, però si voleu, fins i tot podeu fer el pas "1".
En conseqüència, 64+16 = 80 i 80+16 = 96.

Per a una major claredat encara:
XXXX:XXXX:XXXX:XXXX:1:1:YYYY:YYYY són adreces que s'han d'assignar a llocs o serveis específics a la interfície eno1.
XXXX:XXXX:XXXX:XXXX:1:2:YYYY:YYYY són adreces que s'han d'assignar a llocs o serveis específics a la interfície eno2.
XXXX:XXXX:XXXX:XXXX:1:3:YYYY:YYYY són adreces que s'han d'assignar als clients OpenVPN o utilitzar-les com a adreces de servei OpenVPN.

Per configurar la xarxa, hauria de ser possible reiniciar el servidor.
Els canvis d'IPv4 es recullen quan s'executen (assegureu-vos d'embolicar-los a la pantalla; en cas contrari, aquesta ordre simplement bloquejarà la xarxa al servidor):

/etc/init.d/networking restart

Afegiu al final del fitxer "/etc/iproute2/rt_tables":

100 eno1t
101 eno2t

Sense això, no podeu utilitzar taules personalitzades al fitxer "/etc/network/interfaces".
Els números han de ser únics i inferiors a 65535.

Els canvis d'IPv6 es poden canviar fàcilment sense reiniciar, però per fer-ho heu d'aprendre almenys tres ordres:

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

Configuració de "/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

Aquests són els paràmetres "sysctl" del meu servidor. Permeteu-me assenyalar una cosa important.

net.ipv4.ip_forward = 1

Sense això, OpenVPN no funcionarà en absolut.

net.ipv6.ip_nonlocal_bind = 1

Qualsevol persona que intenti vincular IPv6 (per exemple, nginx) immediatament després que la interfície estigui activada rebrà un error. Que aquesta adreça no està disponible.

Per evitar aquesta situació, es fa una configuració d'aquest tipus.

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

Sense aquesta configuració IPv6, el trànsit del client OpenVPN no surt al món.

Altres paràmetres no són rellevants o no recordo per a què serveixen.
Però per si de cas, ho deixo "tal com està".

Per tal que els canvis en aquest fitxer es recullin sense reiniciar el servidor, heu d'executar l'ordre:

sysctl -p

Més detalls sobre les regles de la "taula": habr.com/post/108690

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

OpenVPN IPv4 no funciona sense iptables.

Els meus iptables són així per a 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 és la meva adreça IPv4 estàtica de la màquina local.
10.8.0.0/24: xarxa IPv4 openvpn. Adreces IPv4 per a clients openvpn.
La coherència de les regles és important.

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

Aquesta és una limitació perquè només jo pugui utilitzar OpenVPN des de la meva IP estàtica.

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

Per reenviar paquets IPv4 entre clients OpenVPN i Internet, heu de registrar una d'aquestes ordres.

Per a diferents casos, una de les opcions no és adequada.
Les dues ordres són adequades per al meu cas.
Després de llegir la documentació, vaig triar la primera opció perquè utilitza menys CPU.

Per tal que tots els paràmetres d'iptables es recullin després del reinici, cal que els deseu en algun lloc.

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

Aquests noms no van ser escollits per casualitat. Són utilitzats pel paquet "iptables-persistent".

apt-get install iptables-persistent

Instal·lació del paquet principal OpenVPN:

apt-get install openvpn easy-rsa

Configurem una plantilla per als certificats (substituïu els vostres valors):

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

Editem la configuració de la plantilla de certificat:

mcedit vars

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

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

Creeu un certificat de servidor:

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

Preparem la possibilitat de crear els fitxers finals "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

Preparem un script que combinarà tots els fitxers en un únic fitxer opvn.

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

#!/bin/bash

# First argument: Client identifier

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

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

Creació del primer client OpenVPN:

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

El fitxer "~/client-configs/files/client-name.ovpn" s'envia al dispositiu del client.

Per als clients iOS, haureu de fer el truc següent:
El contingut de l'etiqueta "tls-auth" ha de ser sense comentaris.
I també poseu "key-direction 1" immediatament abans de l'etiqueta "tls-auth".

Configurem la configuració del servidor 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

Això és necessari per establir una adreça estàtica per a cada client (no és necessari, però la faig servir):

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

El detall més difícil i clau.

Malauradament, OpenVPN encara no sap com configurar de manera independent una passarel·la IPv6 per als clients.
Heu de reenviar-ho "manualment" per a cada client.

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

Fitxer "/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

Fitxer “/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

Tots dos scripts utilitzen el fitxer "/etc/openvpn/variables":

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

Em costa recordar per què està escrit així.

Ara la màscara de xarxa = 112 sembla estrany (hauria de ser 96 allà mateix).
I el prefix és estrany, no coincideix amb la xarxa tun0.
Però bé, ho deixaré tal com està.

cipher DES-EDE3-CBC

Això no és per a tothom: vaig triar aquest mètode per xifrar la connexió.

Més informació sobre com configurar OpenVPN IPv4.

Més informació sobre com configurar OpenVPN IPv6.

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

Instal·lació del paquet principal:

apt-get install postfix

En instal·lar, seleccioneu "lloc d'Internet".

El meu "/etc/postfix/main.cf" té aquest aspecte:

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

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

readme_directory = no

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

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

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

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

internal_mail_filter_classes = bounce

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

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

smtpd_helo_restrictions =
        #reject_invalid_helo_hostname,
        #reject_non_fqdn_helo_hostname,
        reject_unknown_helo_hostname

smtpd_client_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        reject_non_fqdn_helo_hostname,
        permit

# SPF
policyd-spf_time_limit = 3600

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

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

Vegem els detalls d'aquesta configuració.

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

Segons els residents de Khabrovsk, aquest bloc conté "informació errònia i tesis incorrectes".Només 8 anys després de l'inici de la meva carrera vaig començar a entendre com funciona SSL.

Per tant, em faré la llibertat de descriure com utilitzar SSL (sense respondre les preguntes "Com funciona?" i "Per què funciona?").

La base del xifratge modern és la creació d'un parell de claus (dues cadenes de caràcters molt llargues).

Una "clau" és privada, l'altra clau és "pública". Mantenim la clau privada en secret amb molta cura. Distribuïm la clau pública a tothom.

Amb una clau pública, podeu xifrar una cadena de text de manera que només el propietari de la clau privada la pugui desxifrar.
Bé, aquesta és tota la base de la tecnologia.

Pas #1: llocs https.
En accedir a un lloc, el navegador s'assabenta del servidor web que el lloc és https i per tant sol·licita una clau pública.
El servidor web dóna la clau pública. El navegador utilitza la clau pública per xifrar la sol·licitud http i enviar-la.
El contingut d'una sol·licitud http només pot ser llegit per aquells que tinguin la clau privada, és a dir, només el servidor al qual es fa la sol·licitud.
Http-request conté almenys un URI. Per tant, si un país intenta restringir l'accés no a tot el lloc, sinó a una pàgina específica, això és impossible per als llocs https.

Pas #2: resposta xifrada.
El servidor web proporciona una resposta que es pot llegir fàcilment a la carretera.
La solució és extremadament senzilla: el navegador genera localment el mateix parell de claus públiques-privades per a cada lloc https.
I juntament amb la sol·licitud de la clau pública del lloc, envia la seva clau pública local.
El servidor web el recorda i, quan envia http-response, el xifra amb la clau pública d'un client concret.
Ara la resposta http només la pot desxifrar el propietari de la clau privada del navegador del client (és a dir, el propi client).

Pas núm. 3: establir una connexió segura mitjançant un canal públic.
Hi ha una vulnerabilitat a l'exemple núm. 2: res impedeix que els simpatitzants interceptin una sol·licitud http i editin informació sobre la clau pública.
Així, l'intermediari veurà clarament tot el contingut dels missatges enviats i rebuts fins que canviï el canal de comunicació.
Fer-ho és extremadament senzill: només cal enviar la clau pública del navegador com a missatge xifrat amb la clau pública del servidor web.
Aleshores, el servidor web envia primer una resposta com "la vostra clau pública és així" i xifra aquest missatge amb la mateixa clau pública.
El navegador mira la resposta: si es rep el missatge "la vostra clau pública és així", això és una garantia del 100% que aquest canal de comunicació és segur.
Què tan segur és?
La mateixa creació d'un canal de comunicació tan segur es produeix a una velocitat de ping*2. Per exemple 20 ms.
L'atacant ha de tenir prèviament la clau privada d'una de les parts. O trobeu una clau privada en un parell de mil·lisegons.
Hackejar una clau privada moderna trigarà dècades en un superordinador.

Pas #4: base de dades pública de claus públiques.
Òbviament, en tota aquesta història hi ha una oportunitat perquè un atacant se senti al canal de comunicació entre el client i el servidor.
El client pot pretendre ser el servidor, i el servidor pot pretendre ser el client. I emuleu un parell de tecles en ambdues direccions.
Aleshores, l'atacant veurà tot el trànsit i podrà "editar" el trànsit.
Per exemple, canvieu l'adreça on enviar diners o copieu la contrasenya de la banca en línia o bloquegeu el contingut "objetable".
Per combatre aquests atacants, van crear una base de dades pública amb claus públiques per a cada lloc https.
Cada navegador "sap" de l'existència d'unes 200 bases de dades d'aquest tipus. Això ve preinstal·lat a tots els navegadors.
El "coneixement" està recolzat per una clau pública de cada certificat. És a dir, no es pot falsificar la connexió amb cada autoritat de certificació específica.

Ara hi ha una comprensió senzilla de com utilitzar SSL per a https.
Si feu servir el vostre cervell, quedarà clar com els serveis especials poden piratejar alguna cosa en aquesta estructura. Però els costarà esforços monstruosos.
I organitzacions més petites que la NSA o la CIA: és gairebé impossible piratejar el nivell de protecció existent, fins i tot per als VIP.

També afegiré sobre les connexions ssh. No hi ha claus públiques, així que què pots fer? El problema es resol de dues maneres.
Opció ssh-by-password:
Durant la primera connexió, el client ssh hauria d'avisar que tenim una nova clau pública del servidor ssh.
I durant més connexions, si apareix l'avís "nova clau pública del servidor ssh", vol dir que estan intentant escoltar-vos.
O et van escoltar la teva primera connexió, però ara et comuniques amb el servidor sense intermediaris.
De fet, a causa del fet que el fet de les escoltes telefòniques es revela fàcilment, ràpidament i sense esforç, aquest atac només s'utilitza en casos especials per a un client específic.

Opció ssh-per-key:
Agafem una unitat flaix, hi escrivim la clau privada del servidor ssh (hi ha termes i molts matisos importants per a això, però estic escrivint un programa educatiu, no instruccions d'ús).
Deixem la clau pública a la màquina on estarà el client ssh i també la mantenim en secret.
Portem la unitat flaix al servidor, la inserim, copiem la clau privada i cremem la unitat flaix i escampem les cendres al vent (o almenys la formatem amb zeros).
Això és tot: després d'aquesta operació, serà impossible piratejar una connexió ssh així. Per descomptat, d'aquí a 10 anys serà possible veure el trànsit en un superordinador, però aquesta és una història diferent.

Demano disculpes per l'offtopic.

Així que ara que es coneix la teoria. Us explicaré el flux de creació d'un certificat SSL.

Utilitzant “openssl genrsa” creem una clau privada i “buits” per a la clau pública.
Enviem els "espais en blanc" a una empresa de tercers, a la qual paguem aproximadament 9 dòlars pel certificat més senzill.

Al cap d'un parell d'hores, rebem la nostra clau "pública" i un conjunt de diverses claus públiques d'aquesta empresa de tercers.

Per què hauria de pagar una empresa de tercers pel registre de la meva clau pública és una qüestió a part, no ho considerarem aquí.

Ara està clar quin és el significat de la inscripció:

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

La carpeta "/etc/ssl" conté tots els fitxers per a problemes ssl.
domain1.com — nom de domini.
El 2018 és l'any de la creació de claus.
"clau" - designació que el fitxer és una clau privada.

I el significat d'aquest fitxer:

smtpd_tls_cert_file=/etc/ssl/domain1.com.2018.chained.crt
domain1.com — nom de domini.
El 2018 és l'any de la creació de claus.
encadenat - designació que hi ha una cadena de claus públiques (la primera és la nostra clau pública i la resta són les que provenen de l'empresa que va emetre la clau pública).
crt - designació que hi ha un certificat ja preparat (clau pública amb explicacions tècniques).

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

Aquesta configuració no s'utilitza en aquest cas, però s'escriu com a exemple.

Perquè un error en aquest paràmetre farà que s'enviï correu brossa des del vostre servidor (sense la vostra voluntat).

Aleshores demostra a tothom que no ets culpable.

recipient_delimiter = +

És possible que molta gent no ho sàpiga, però aquest és un caràcter estàndard per classificar correus electrònics i és compatible amb la majoria de servidors de correu moderns.

Per exemple, si teniu una bústia "[protegit per correu electrònic]"Intenta enviar a"[protegit per correu electrònic]"- mira què en surt.

inet_protocols = ipv4

Això pot ser confús.

Però no és només així. Cada domini nou només és IPv4 de manera predeterminada, llavors encenc IPv6 per a cadascun per separat.

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

Aquí especifiquem que tot el correu entrant va a dovecot.
I les regles per a domini, bústia, àlies: busqueu a la base de dades.

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

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

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

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

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

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

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

Ara Postfix sap que només es pot acceptar correu per a un posterior enviament després de l'autorització amb Colomer.

Realment no entenc per què això es duplica aquí. Ja hem especificat tot el que es necessita a “transport_virtual”.

Però el sistema de postfix és molt antic, probablement sigui un retrocés dels vells temps.

smtpd_recipient_restrictions =
        ...

smtpd_helo_restrictions =
        ...

smtpd_client_restrictions =
        ...

Això es pot configurar de manera diferent per a cada servidor de correu.

Tinc 3 servidors de correu a la meva disposició i aquests paràmetres són molt diferents a causa dels diferents requisits d'ús.

Heu de configurar-lo amb cura; en cas contrari, us abocarà correu brossa, o encara pitjor: us sortirà correu brossa.

# SPF
policyd-spf_time_limit = 3600

Configuració d'algun connector relacionat amb la comprovació del SPF de les cartes entrants.

# 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

La configuració és que hem de proporcionar una signatura DKIM amb tots els correus electrònics sortints.

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

Aquest és un detall clau en l'encaminament de cartes quan s'envien cartes des de scripts PHP.

Fitxer “/etc/postfix/sdd_transport.pcre”:

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

A l'esquerra hi ha expressions regulars. A la dreta hi ha una etiqueta que marca la lletra.
Postfix d'acord amb l'etiqueta: tindrà en compte algunes línies de configuració més per a una lletra específica.

Com es reconfigurarà exactament el postfix per a una lletra específica s'indicarà a "master.cf".

Les línies 4, 5, 6 són les principals. En nom de quin domini estem enviant la carta, posem aquesta etiqueta.
Però el camp "de" no sempre s'indica als scripts PHP del codi antic. Aleshores, el nom d'usuari ve al rescat.

L'article ja és extens; no voldria distreure'm configurant nginx+fpm.

Breument, per a cada lloc establim el seu propi propietari d'usuari de Linux. I en conseqüència el vostre fpm-pool.

Fpm-pool utilitza qualsevol versió de php (és fantàstic quan al mateix servidor podeu utilitzar diferents versions de php i fins i tot diferents php.ini per a llocs veïns sense problemes).

Per tant, un usuari de Linux específic "www-domain2" té un lloc web domain2.com. Aquest lloc té un codi per enviar correus electrònics sense especificar el camp de.

Així, fins i tot en aquest cas, les cartes s'enviaran correctament i mai no acabaran en correu brossa.

El meu "/etc/postfix/master.cf" té aquest aspecte:

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

El fitxer no es proporciona sencer, ja és molt gran.
Només vaig observar el que havia canviat.

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}

Aquests són paràmetres relacionats amb spamassasin, sobre això més endavant.

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

Us permetem connectar-vos al servidor de correu mitjançant el port 587.
Per fer-ho, heu d'iniciar sessió.

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

Activa la comprovació SPF.

apt-get install postfix-policyd-spf-python

Instal·lem el paquet per a les comprovacions SPF anteriors.

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

I això és el més interessant. Aquesta és la capacitat d'enviar cartes per a un domini específic des d'una adreça IPv4/IPv6 específica.

Això es fa pel bé de rDNS. rDNS és el procés de rebre una cadena per adreça IP.
I per al correu, aquesta funció s'utilitza per confirmar que l'helo coincideix exactament amb l'rDNS de l'adreça des de la qual s'ha enviat el correu electrònic.

Si l'helo no coincideix amb el domini de correu electrònic en nom de qui s'ha enviat la carta, s'atorguen punts de correu brossa.

Helo no coincideix amb rDNS: s'atorguen molts punts de correu brossa.
En conseqüència, cada domini ha de tenir la seva pròpia adreça IP.
Per a OVH - a la consola és possible especificar rDNS.
Per a tech.ru: el problema es resol mitjançant el suport.
Per a AWS, el problema es resol mitjançant el suport.
"inet_protocols" i "smtp_bind_address6": activem el suport IPv6.
Per a IPv6 també cal registrar rDNS.
"syslog_name" - i això és per facilitar la lectura dels registres.

Comprar certificats Recomano aquí.

Configurant l'enllaç postfix+dovecot aquí.

Configuració SPF.

============= Palomar ==============

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

Configurant mysql, instal·lant els propis paquets.

Fitxer "/etc/dovecot/conf.d/10-auth.conf"

disable_plaintext_auth = yes
auth_mechanisms = plain login

L'autorització només està xifrada.

Fitxer "/etc/dovecot/conf.d/10-mail.conf"

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

Aquí us indiquem la ubicació d'emmagatzematge de les cartes.

Vull que s'emmagatzemin en fitxers i s'agrupin per domini.

Fitxer "/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 {
  }
}

Aquest és el fitxer de configuració principal de dovecot.
Aquí desactivem les connexions no segures.
I habiliteu connexions segures.

Fitxer "/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
}

Configuració de ssl. Indiquem que cal ssl.
I el propi certificat. I un detall important és la directiva “local”. Indica quin certificat SSL s'ha d'utilitzar quan es connecta a quin IPv4 local.

Per cert, IPv6 no està configurat aquí, corregiré aquesta omissió més endavant.
XX.XX.XX.X5 (domini2) - sense certificat. Per connectar clients, heu d'especificar domini1.com.
XX.XX.XX.X2 (domini3): hi ha un certificat, podeu especificar domini1.com o domini3.com per connectar clients.

Fitxer "/etc/dovecot/conf.d/15-lda.conf"

protocol lda {
  mail_plugins = $mail_plugins sieve
}

Això serà necessari per a Spamassassin en el futur.

Fitxer "/etc/dovecot/conf.d/20-imap.conf"

protocol imap {
  mail_plugins = $mail_plugins antispam
}

Aquest és un connector antispam. Necessari per entrenar spamassasin en el moment de la transferència a/des de la carpeta “Spam”.

Fitxer "/etc/dovecot/conf.d/20-pop3.conf"

protocol pop3 {
}

Només hi ha un fitxer així.

Fitxer "/etc/dovecot/conf.d/20-lmtp.conf"

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

Configuració de lmtp.

Fitxer "/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
}

Configuració d'entrenament de Spamassasin en el moment de la transferència a/des de la carpeta de correu brossa.

Fitxer "/etc/dovecot/conf.d/90-sieve.conf"

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

Un fitxer que especifica què fer amb les cartes entrants.

Fitxer "/var/lib/dovecot/sieve/default.sieve"

require ["fileinto", "mailbox"];

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

Heu de compilar el fitxer: “sievec default.sieve”.

Fitxer "/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
}

Especificació de fitxers sql per a l'autorització.
I el propi fitxer s'utilitza com a mètode d'autorització.

Fitxer "/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';

Això correspon a una configuració similar per a postfix.

Fitxer "/etc/dovecot/dovecot.conf"

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

Fitxer de configuració principal.
L'important és que indiquem aquí: afegir protocols.

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

apt-get install spamassassin spamc

Instal·lem els paquets.

adduser spamd --disabled-login

Afegim un usuari en nom del qual.

systemctl enable spamassassin.service

Activem el servei spamassassin de càrrega automàtica en carregar-lo.

Fitxer "/etc/default/spamassassin":

CRON=1

Activant l'actualització automàtica de regles "per defecte".

Fitxer “/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

Heu de crear una base de dades "sa" a mysql amb l'usuari "sa" amb la contrasenya "contrasenya" (substituïu-la per alguna d'adequada).

report_safe: enviarà un informe de correu brossa en lloc d'una carta.
use_bayes són configuracions d'aprenentatge automàtic de spamassassin.

La resta de configuracions de spamassassin es van utilitzar anteriorment a l'article.

Configuració general "spamassassin".
Sobre moure correus electrònics de correu brossa nous a la carpeta "Correu brossa" d'IMAP.
Sobre una combinació senzilla de Dovecot + SpamAssassin.
Recomano llegir la teoria de l'aprenentatge de l'spamassasin quan es mouen cartes a les carpetes imap (i no recomano utilitzar-la).

============= Apel·lació a la comunitat ==============

També m'agradaria llançar una idea a la comunitat sobre com augmentar el nivell de seguretat de les cartes reenviades. Com que estic molt immers en el tema del correu.

Perquè l'usuari pugui crear un parell de claus al seu client (outlook, thunderbird, navegador-plugin, ...). Públic i privat. Públic: envia a DNS. Privat: estalvia en el client. Els servidors de correu podrien utilitzar una clau pública per enviar-lo a un destinatari específic.

I per protegir-se del correu brossa amb aquestes cartes (sí, el servidor de correu no podrà veure el contingut), haureu d'introduir 3 regles:

Signatura DKIM real obligatòria, SPF obligatori, rDNS obligatori.
Una xarxa neuronal sobre el tema de la formació antispam + una base de dades per al client.
L'algorisme de xifratge ha de ser tal que el costat emissor hagi de gastar 100 vegades més potència de la CPU en xifratge que el receptor.

A més de les cartes públiques, desenvolupeu una carta de proposta estàndard "per començar una correspondència segura". Un dels usuaris (bústia) envia una carta amb un fitxer adjunt a una altra bústia. La carta conté una proposta de text per iniciar un canal de comunicació segur per a la correspondència i la clau pública del propietari de la bústia (amb clau privada a la part del client).

Fins i tot podeu fer un parell de claus específicament per a cada correspondència. L'usuari destinatari pot acceptar aquesta oferta i enviar la seva clau pública (també feta específicament per a aquesta correspondència). A continuació, el primer usuari envia una carta de control de servei (xifrada amb la clau pública del segon usuari), un cop rebuda, el segon usuari pot considerar fiable el canal de comunicació format. A continuació, el segon usuari envia una carta de control i, a continuació, el primer usuari també pot considerar segur el canal format.

Per combatre la intercepció de claus a la via, el protocol ha de preveure la possibilitat de transmetre almenys una clau pública mitjançant una unitat flash.

I el més important és que tot funcioni (la pregunta és "qui ho pagarà?"):
Introduïu certificats postals a partir de 10 dòlars durant 3 anys. El que permetrà al remitent indicar al dns que "les meves claus públiques són allà". I us donaran l'oportunitat d'iniciar una connexió segura. Al mateix temps, acceptar aquestes connexions és gratuït.
Gmail finalment està monetitzant els seus usuaris. Per 10 $ per 3 anys: dret a crear canals de correspondència segurs.

============= Conclusió ==============

Per provar tot l'article, anava a llogar un servidor dedicat durant un mes i comprar un domini amb un certificat SSL.

Però les circumstàncies de la vida es van desenvolupar, de manera que aquest problema es va allargar durant 2 mesos.
I així, quan vaig tornar a tenir temps lliure, vaig decidir publicar l'article tal qual, en comptes d'arriscar-me a que la publicació s'arrossegués un any més.

Si hi ha moltes preguntes com "però això no es descriu amb prou detall", llavors probablement hi haurà força per agafar un servidor dedicat amb un nou domini i un nou certificat SSL i descriure-ho encara més detalladament i, la majoria important, identifiqueu tots els detalls importants que falten.

També m'agradaria rebre comentaris sobre idees sobre certificats postals. Si t'agrada la idea, intentaré trobar la força per escriure un esborrany per a rfc.

Quan copieu grans parts d'un article, proporcioneu un enllaç a aquest article.
Quan traduïu a qualsevol altre idioma, proporcioneu un enllaç a aquest article.
Intentaré traduir-lo jo mateix a l'anglès i deixaré referències creuades.

Font: www.habr.com

Debian + Postfix + Dovecot + Multidomain + SSL + IPv6 + OpenVPN + Multi-interfícies + SpamAssassin-learn + Bind