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

Este artigo trata sobre como configurar un servidor de correo moderno.
Postfix + Pomba. SPF + DKIM + rDNS. Con IPv6.
Con cifrado TSL. Con soporte para varios dominios, parte cun certificado SSL real.
Con protección antispam e unha alta clasificación antispam doutros servidores de correo.
Soporta múltiples interfaces físicas.
Con OpenVPN, cuxa conexión é a través de IPv4, e que proporciona IPv6.

Se non queres aprender todas estas tecnoloxías, pero queres configurar un servidor deste tipo, este artigo é para ti.

O artigo non intenta explicar todos os detalles. A explicación vai para o que non está configurado como estándar ou é importante desde o punto de vista do consumidor.

A motivación para configurar un servidor de correo foi un meu soño dende hai moito tempo. Isto pode parecer estúpido, pero en mi humilde opinión, é moito mellor que soñar cun coche novo da túa marca favorita.

Hai dúas motivacións para configurar IPv6. Un especialista en TI necesita aprender novas tecnoloxías constantemente para sobrevivir. Gustaríame facer a miña modesta contribución á loita contra a censura.

A motivación para configurar OpenVPN é só conseguir que IPv6 funcione na máquina local.
A motivación para configurar varias interfaces físicas é que no meu servidor teño unha interface "lenta pero ilimitada" e outra "rápida pero con tarifa".

A motivación para configurar a configuración de Bind é que o meu ISP proporciona un servidor DNS inestable e Google tamén falla ás veces. Quero un servidor DNS estable para uso persoal.

Motivación para escribir un artigo: escribín un borrador hai 10 meses e xa o mirei dúas veces. Aínda que o autor o necesite regularmente, hai unha alta probabilidade de que outros tamén o necesiten.

Non existe unha solución universal para un servidor de correo. Pero tentarei escribir algo así como "fai isto e despois, cando todo funcione como debería, tira o material extra".

A empresa tech.ru ten un servidor de colocación. É posible comparar con OVH, Hetzner, AWS. Para resolver este problema, a cooperación con tech.ru será moito máis eficaz.

Debian 9 está instalado no servidor.

O servidor ten 2 interfaces `eno1` e `eno2`. O primeiro é ilimitado e o segundo é rápido, respectivamente.

Hai 3 enderezos IP estáticos, XX.XX.XX.X0 e XX.XX.XX.X1 e XX.XX.XX.X2 na interface `eno1` e XX.XX.XX.X5 na interface `eno2` .

Dispoñible XXXX:XXXX:XXXX:XXXX::/64 un conxunto de enderezos IPv6 que se asignan á interface `eno1` e dende ela asignouse XXXX:XXXX:XXXX:XXXX:1:2::/96 a `eno2` a miña petición.

Hai 3 dominios `domain1.com`, `domain2.com`, `domain3.com`. Hai un certificado SSL para `domain1.com` e `domain3.com`.

Teño unha conta de Google á que me gustaría vincular a miña caixa de correo[protexido por correo electrónico]` (recibir correo e enviar correo directamente desde a interface de gmail).
Debe haber unha caixa de correo`[protexido por correo electrónico]`, unha copia do correo electrónico do que quero ver no meu gmail. E é raro poder enviar algo en nome de `[protexido por correo electrónico]` a través da interface web.

Debe haber unha caixa de correo`[protexido por correo electrónico]`, que Ivanov usará desde o seu iPhone.

Os correos electrónicos enviados deben cumprir todos os requisitos antispam modernos.
Debe haber o maior nivel de cifrado proporcionado nas redes públicas.
Debe haber compatibilidade con IPv6 tanto para enviar como para recibir cartas.
Debería haber un SpamAssassin que nunca eliminará os correos electrónicos. E rebotará ou saltará ou enviarase ao cartafol "Spam" de IMAP.
Debe configurarse a aprendizaxe automática de SpamAssassin: se movo unha carta ao cartafol Spam, aprenderá disto; se movo unha carta do cartafol Spam, aprenderá disto. Os resultados do adestramento de SpamAssassin deberían influír sobre se a carta acaba no cartafol Spam.
Os scripts PHP deben poder enviar correo en nome de calquera dominio nun servidor determinado.
Debería haber un servizo openvpn, coa posibilidade de usar IPv6 nun cliente que non teña IPv6.

Primeiro cómpre configurar as interfaces e o enrutamento, incluído o IPv6.
A continuación, terá que configurar OpenVPN, que se conectará a través de IPv4 e proporcionará ao cliente un enderezo IPv6 real estático. Este cliente terá acceso a todos os servizos IPv6 do servidor e acceso a calquera recurso IPv6 en Internet.
Despois terás que configurar Postfix para enviar cartas + SPF + DKIM + rDNS e outras pequenas cousas similares.
Despois terás que configurar Dovecot e configurar Multidominio.
Despois terás que configurar SpamAssassin e configurar o adestramento.
Finalmente, instala Bind.

============= Multi-interfaces =============

Para configurar interfaces, cómpre escribir isto en "/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

Esta configuración pódese aplicar en calquera servidor de tech.ru (cun pouco de coordinación co soporte) e funcionará inmediatamente como debería.

Se tes experiencia configurando cousas similares para Hetzner, OVH, aí é diferente. Máis difícil.

eno1 é o nome da tarxeta de rede número 1 (lenta pero ilimitada).
eno2 é o nome da tarxeta de rede #2 (rápida, pero cunha tarifa).
tun0 é o nome da tarxeta de rede virtual de OpenVPN.
XX.XX.XX.X0 - IPv4 #1 en eno1.
XX.XX.XX.X1 - IPv4 #2 en eno1.
XX.XX.XX.X2 - IPv4 #3 en eno1.
XX.XX.XX.X5 - IPv4 #1 en eno2.
XX.XX.XX.1 - Pasarela IPv4.
XXXX:XXXX:XXXX:XXXX::/64 - IPv6 para todo o servidor.
XXXX:XXXX:XXXX:XXXX:1:2::/96 - IPv6 para eno2, todo o resto do exterior entra en eno1.
XXXX:XXXX:XXXX:XXXX::1 — Pasarela IPv6 (convén ter en conta que isto pode/debe facerse de forma diferente. Especifique o interruptor IPv6).
dns-nameservers - indícase 127.0.0.1 (porque bind está instalado localmente) e 213.248.1.6 (isto é de tech.ru).

“táboa eno1t” e “táboa eno2t”: o significado destas regras de ruta é que o tráfico que entra por eno1 -> sairía por el e o tráfico que entra por eno2 -> sairía por el. E tamén as conexións iniciadas polo servidor pasarían por eno1.

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

Con este comando especificamos que calquera tráfico incomprensible que caia baixo calquera regra marcada como “table eno1t” -> se envíe á interface eno1.

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

Con este comando especificamos que calquera tráfico iniciado polo servidor debe dirixirse á interface eno1.

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

Con este comando establecemos as regras para marcar o tráfico.

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

Este bloque especifica un segundo IPv4 para a interface eno1.

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

Con este comando establecemos a ruta dos clientes OpenVPN a IPv4 local excepto XX.XX.XX.X0.
Aínda non entendo por que este comando é suficiente para todos os IPv4.

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

Aquí é onde establecemos o enderezo da propia interface. O servidor empregarao como enderezo "saínte". Non se volverá utilizar de ningún xeito.

Por que ":1:1::" é tan complicado? Para que OpenVPN funcione correctamente e só para iso. Máis sobre isto despois.

No tema da pasarela: así funciona e está ben. Pero o xeito correcto é indicar aquí o IPv6 do switch ao que está conectado o servidor.

Non obstante, por algún motivo o IPv6 deixa de funcionar se fago isto. Probablemente este sexa algún tipo de problema de tech.ru.

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

Isto é engadir un enderezo IPv6 á interface. Se necesitas cen enderezos, isto significa cen liñas neste ficheiro.

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

Observei os enderezos e subredes de todas as interfaces para que quede claro.
eno1 - debe ser "/64"- porque este é todo o noso conxunto de enderezos.
tun0: a subrede debe ser maior que eno1. En caso contrario, non será posible configurar unha pasarela IPv6 para os clientes OpenVPN.
eno2: a subrede debe ser maior que tun0. En caso contrario, os clientes OpenVPN non poderán acceder aos enderezos IPv6 locais.
Para máis claridade, escollín un paso de subrede de 16, pero se o desexa, incluso pode facer o paso "1".
En consecuencia, 64+16 = 80 e 80+16 = 96.

Para unha maior claridade:
XXXX:XXXX:XXXX:XXXX:1:1:YYYY:YYYY son enderezos que se deben asignar a sitios ou servizos específicos na interface eno1.
XXXX:XXXX:XXXX:XXXX:1:2:YYYY:YYYY son enderezos que se deben asignar a sitios ou servizos específicos na interface eno2.
XXXX:XXXX:XXXX:XXXX:1:3:YYYY:YYYY son enderezos que se deben asignar aos clientes OpenVPN ou usar como enderezos de servizo OpenVPN.

Para configurar a rede, debería ser posible reiniciar o servidor.
Os cambios de IPv4 recóllense cando se executan (asegúrese de envolvelos na pantalla; se non, este comando simplemente bloqueará a rede no servidor):

/etc/init.d/networking restart

Engadir ao final do ficheiro "/etc/iproute2/rt_tables":

100 eno1t
101 eno2t

Sen isto, non pode usar táboas personalizadas no ficheiro "/etc/network/interfaces".
Os números deben ser únicos e inferiores a 65535.

Os cambios de IPv6 pódense cambiar facilmente sen reiniciar, pero para facelo necesitas aprender polo menos tres comandos:

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

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

Estas son as opcións "sysctl" do meu servidor. Permítanme sinalar algo importante.

net.ipv4.ip_forward = 1

Sen isto, OpenVPN non funcionará en absoluto.

net.ipv6.ip_nonlocal_bind = 1

Calquera persoa que intente vincular IPv6 (por exemplo, nginx) inmediatamente despois de que a interface estea activada, recibirá un erro. Que este enderezo non está dispoñible.

Para evitar tal situación, realízase tal configuración.

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

Sen esta configuración de IPv6, o tráfico do cliente OpenVPN non sae ao mundo.

Outras opcións non son relevantes ou non lembro para que serven.
Pero por se acaso, déixoo "tal como está".

Para que se poidan recoller os cambios neste ficheiro sen reiniciar o servidor, cómpre executar o comando:

sysctl -p

Máis detalles sobre as regras da "táboa": habr.com/post/108690

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

OpenVPN IPv4 non funciona sen iptables.

Os meus iptables son así para 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 é o meu enderezo IPv4 estático da máquina local.
10.8.0.0/24 - Rede IPv4 openvpn. Enderezos IPv4 para clientes openvpn.
A coherencia das regras é importante.

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

Esta é unha limitación para que só eu poida usar OpenVPN desde a miña 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

Para reenviar paquetes IPv4 entre clientes OpenVPN e Internet, cómpre rexistrar un destes comandos.

Para diferentes casos, unha das opcións non é adecuada.
Ambos comandos son axeitados para o meu caso.
Despois de ler a documentación, escollín a primeira opción porque usa menos CPU.

Para que todas as opcións de iptables sexan recollidas despois do reinicio, cómpre gardalas nalgún lugar.

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

Tales nomes non foron elixidos por casualidade. Son usados polo paquete "iptables-persistent".

apt-get install iptables-persistent

Instalando o paquete principal OpenVPN:

apt-get install openvpn easy-rsa

Imos configurar un modelo para certificados (substituír os seus valores):

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

Editemos a configuración do modelo de certificado:

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

Crear un certificado de servidor:

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

Imos preparar a posibilidade de crear os ficheiros finais "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

Imos preparar un script que combinará todos os ficheiros nun único ficheiro 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

Creando o primeiro cliente OpenVPN:

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

O ficheiro "~/client-configs/files/client-name.ovpn" envíase ao dispositivo do cliente.

Para os clientes de iOS, terás que facer o seguinte truco:
O contido da etiqueta "tls-auth" debe estar sen comentarios.
E tamén pon "key-direction 1" inmediatamente antes da etiqueta "tls-auth".

Imos configurar a configuración do 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

Isto é necesario para establecer un enderezo estático para cada cliente (non é necesario, pero úsoo):

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

O detalle máis difícil e clave.

Desafortunadamente, OpenVPN aínda non sabe como configurar de forma independente unha pasarela IPv6 para os clientes.
Ten que reenviar isto "manualmente" para cada 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"

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

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

Ambos scripts usan o ficheiro "/etc/openvpn/variables":

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

Resúltame difícil recordar por que está escrito así.

Agora a máscara de rede = 112 parece estraño (debería ser 96 alí mesmo).
E o prefixo é estraño, non coincide coa rede tun0.
Pero vale, deixarino como está.

cipher DES-EDE3-CBC

Isto non é para todos: escollín este método de cifrado da conexión.

Obtén máis información sobre como configurar OpenVPN IPv4.

Obtén máis información sobre como configurar OpenVPN IPv6.

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

Instalación do paquete principal:

apt-get install postfix

Durante a instalación, seleccione "sitio de Internet".

O meu "/etc/postfix/main.cf" ten este aspecto:

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

Vexamos os detalles desta configuración.

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

Segundo os veciños de Khabrovsk, este bloque contén "desinformación e teses incorrectas".Só 8 anos despois do comezo da miña carreira comecei a entender como funciona SSL.

Polo tanto, tomarei a liberdade de describir como usar SSL (sen responder ás preguntas "Como funciona?" e "Por que funciona?").

A base do cifrado moderno é a creación dun par de claves (dúas cadeas moi longas de caracteres).

Unha "chave" é privada, a outra é "pública". Mantemos a chave privada en segredo con moito coidado. Repartimos a chave pública para todos.

Usando unha chave pública, pode cifrar unha cadea de texto para que só o propietario da chave privada poida descifrala.
Ben, esa é toda a base da tecnoloxía.

Paso 1: sitios https.
Ao acceder a un sitio, o navegador aprende polo servidor web que o sitio é https e, polo tanto, solicita unha chave pública.
O servidor web dá a chave pública. O navegador usa a clave pública para cifrar a solicitude http e enviala.
O contido dunha solicitude http só o poden ler aqueles que teñan a chave privada, é dicir, só o servidor ao que se realiza a solicitude.
Http-request contén polo menos un URI. Polo tanto, se un país está tentando restrinxir o acceso non a todo o sitio, senón a unha páxina específica, isto é imposible para os sitios https.

Paso #2: resposta cifrada.
O servidor web ofrece unha resposta que se pode ler facilmente na estrada.
A solución é moi sinxela: o navegador xera localmente o mesmo par de chaves públicas e privadas para cada sitio https.
E xunto coa solicitude da chave pública do sitio, envía a súa clave pública local.
O servidor web lémbrao e, ao enviar a resposta http, cífraa coa clave pública dun cliente específico.
Agora http-response só pode ser descifrado polo propietario da clave privada do navegador do cliente (é dicir, o propio cliente).

Paso número 3: establecer unha conexión segura a través dunha canle pública.
Hai unha vulnerabilidade no exemplo número 2: nada impide que os simpatizantes intercepten unha solicitude http e editen información sobre a chave pública.
Así, o intermediario verá claramente todo o contido das mensaxes enviadas e recibidas ata que cambie a canle de comunicación.
Tratar isto é moi sinxelo: só tes que enviar a clave pública do navegador como unha mensaxe cifrada coa clave pública do servidor web.
O servidor web envía primeiro unha resposta como "a túa clave pública é así" e cifra esta mensaxe coa mesma clave pública.
O navegador mira a resposta -se se recibe a mensaxe "a túa chave pública é así" - entón esta é unha garantía do 100 % de que esta canle de comunicación é segura.
Que seguro é?
A propia creación dunha canle de comunicación tan segura prodúcese a unha velocidade de ping*2. Por exemplo, 20 ms.
O atacante debe ter previamente a clave privada dunha das partes. Ou atopa unha clave privada nun par de milisegundos.
Hackear unha chave privada moderna levará décadas nun superordenador.

Paso #4: base de datos pública de claves públicas.
Obviamente, en toda esta historia hai unha oportunidade para que un atacante se sente na canle de comunicación entre o cliente e o servidor.
O cliente pode pretender ser o servidor e o servidor pode pretender ser o cliente. E emula un par de teclas en ambas direccións.
Entón o atacante verá todo o tráfico e poderá "editar" o tráfico.
Por exemplo, cambia o enderezo onde enviar diñeiro ou copia o contrasinal da banca en liña ou bloquea o contido "obxectable".
Para combater estes atacantes, crearon unha base de datos pública con claves públicas para cada sitio https.
Cada navegador "coñece" a existencia dunhas 200 bases de datos deste tipo. Isto vén preinstalado en todos os navegadores.
O "coñecemento" está apoiado por unha chave pública de cada certificado. É dicir, non se pode falsificar a conexión con cada autoridade de certificación específica.

Agora hai unha comprensión sinxela de como usar SSL para https.
Se usas o teu cerebro, quedará claro como os servizos especiais poden piratear algo nesta estrutura. Pero custarálles esforzos monstruosos.
E organizacións máis pequenas que a NSA ou a CIA - é case imposible piratear o nivel de protección existente, mesmo para os VIP.

Tamén engadirei sobre conexións ssh. Non hai chaves públicas alí, entón que podes facer? O problema resólvese de dúas formas.
Opción ssh-by-password:
Durante a primeira conexión, o cliente ssh debería avisar de que temos unha nova chave pública do servidor ssh.
E durante máis conexións, se aparece o aviso "nova clave pública do servidor ssh", significará que están tentando escoitalo.
Ou escoitaches a túa primeira conexión, pero agora te comunicas co servidor sen intermediarios.
En realidade, debido ao feito de que o feito de escoitas telefónicas se revela de forma sinxela, rápida e sen esforzo, este ataque úsase só en casos especiais para un cliente específico.

Opción ssh-by-key:
Collemos unha unidade flash, escribimos nela a clave privada do servidor ssh (hai termos e moitos matices importantes para iso, pero estou escribindo un programa educativo, non instrucións de uso).
Deixamos a chave pública na máquina onde estará o cliente ssh e tamén a mantemos en segredo.
Levamos a unidade flash ao servidor, introducimos, copiamos a clave privada e queimamos a unidade flash e esparexemos as cinzas ao vento (ou polo menos formatámola con ceros).
Iso é todo: despois de tal operación, será imposible cortar unha conexión ssh así. Por suposto, dentro de 10 anos será posible ver o tráfico nun superordenador, pero esa é unha historia diferente.

Pido desculpas polo offtopic.

Entón, agora que se coñece a teoría. Vouche falar sobre o fluxo de creación dun certificado SSL.

Usando "openssl genrsa" creamos unha clave privada e "espacios" para a clave pública.
Enviamos os "en branco" a unha empresa de terceiros, á que pagamos aproximadamente 9 dólares polo certificado máis sinxelo.

Despois dun par de horas, recibimos a nosa clave "pública" e un conxunto de varias claves públicas desta empresa de terceiros.

Por que debería pagar unha empresa de terceiros polo rexistro da miña chave pública é unha cuestión aparte, non o consideraremos aquí.

Agora está claro cal é o significado da inscrición:

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

O cartafol "/etc/ssl" contén todos os ficheiros para problemas con ssl.
domain1.com — nome de dominio.
2018 é o ano da creación de chaves.
"chave" - designación de que o ficheiro é unha clave privada.

E o significado deste ficheiro:

smtpd_tls_cert_file=/etc/ssl/domain1.com.2018.chained.crt
domain1.com — nome de dominio.
2018 é o ano da creación de chaves.
encadeado - designación de que hai unha cadea de claves públicas (a primeira é a nosa clave pública e o resto son as que proviñan da empresa que emitiu a clave pública).
crt - designación de que hai un certificado listo (chave pública con explicacións técnicas).

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

Este axuste non se usa neste caso, pero está escrito como exemplo.

Porque un erro neste parámetro levará a enviar correo non desexado desde o teu servidor (sen a túa vontade).

Despois demostra a todos que non es culpable.

recipient_delimiter = +

É posible que moitas persoas non o saiban, pero este é un carácter estándar para clasificar os correos electrónicos e é compatible coa maioría dos servidores de correo modernos.

Por exemplo, se tes unha caixa de correo "[protexido por correo electrónico]"tente enviar a"[protexido por correo electrónico]"- mira o que sae.

inet_protocols = ipv4

Isto pode ser confuso.

Pero non é só así. Cada dominio novo é por defecto só IPv4, entón activo IPv6 para cada un por separado.

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í especificamos que todo o correo entrante vai a dovecot.
E as regras para o dominio, caixa de correo, alias - mira na base de datos.

/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

Agora, Postfix sabe que só se pode aceptar correo para o seu posterior envío despois da autorización con pombal.

Realmente non entendo por que isto se duplica aquí. Xa especificamos todo o necesario en “transporte_virtual”.

Pero o sistema de postfix é moi antigo, probablemente sexa un retroceso dos vellos tempos.

smtpd_recipient_restrictions =
        ...

smtpd_helo_restrictions =
        ...

smtpd_client_restrictions =
        ...

Isto pódese configurar de forma diferente para cada servidor de correo.

Teño 3 servidores de correo á miña disposición e estas configuracións son moi diferentes debido aos diferentes requisitos de uso.

Debes configuralo con coidado; se non, o correo lixo chegará a ti ou, peor aínda, o spam sairá de ti.

# SPF
policyd-spf_time_limit = 3600

Configurando algún complemento relacionado coa comprobación do SPF das cartas entrantes.

# 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

A configuración é que debemos proporcionar unha sinatura DKIM con todos os correos electrónicos saíntes.

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

Este é un detalle clave no enrutamento de cartas cando se envían cartas desde scripts PHP.

Ficheiro "/etc/postfix/sdd_transport.pcre":

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

Á esquerda están as expresións regulares. Á dereita hai unha etiqueta que marca a letra.
Postfix de acordo coa etiqueta - terá en conta algunhas liñas de configuración máis para unha carta específica.

Como se reconfigurará exactamente o postfix para unha letra específica indicarase en "master.cf".

As liñas 4, 5, 6 son as principais. En nome de que dominio estamos enviando a carta, poñemos esta etiqueta.
Pero o campo "de" non sempre se indica nos scripts PHP no código antigo. Entón o nome de usuario vén ao rescate.

O artigo xa é extenso: non me gustaría distraerme configurando nginx+fpm.

Brevemente, para cada sitio establecemos o seu propio propietario de usuario de Linux. E en consecuencia o teu fpm-pool.

Fpm-pool usa calquera versión de php (é xenial cando no mesmo servidor podes usar diferentes versións de php e incluso diferentes php.ini para sitios veciños sen problemas).

Así, un usuario de Linux específico "www-domain2" ten un sitio web domain2.com. Este sitio ten un código para enviar correos electrónicos sen especificar o campo de.

Así, mesmo neste caso, as cartas enviaranse correctamente e nunca acabarán no correo lixo.

O meu "/etc/postfix/master.cf" ten este aspecto:

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

O ficheiro non se proporciona na súa totalidade - xa é moi grande.
Só notei o que cambiou.

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}

Estas son configuracións relacionadas con spamassasin, máis sobre isto máis adiante.

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

Permitimos que se conecte ao servidor de correo a través do porto 587.
Para facelo, debes iniciar sesión.

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

Activar a verificación SPF.

apt-get install postfix-policyd-spf-python

Imos instalar o paquete para as comprobacións SPF anteriores.

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

E isto é o máis interesante. Esta é a capacidade de enviar cartas para un dominio específico desde un enderezo IPv4/IPv6 específico.

Isto faise polo ben do rDNS. rDNS é o proceso de recibir unha cadea por enderezo IP.
E para o correo, esta función úsase para confirmar que o helo coincide exactamente co rDNS do enderezo desde o que se enviou o correo electrónico.

Se o helo non coincide co dominio de correo electrónico en nome de quen se enviou a carta, outórganse puntos de spam.

Helo non coincide con rDNS: concédense moitos puntos de spam.
En consecuencia, cada dominio debe ter o seu propio enderezo IP.
Para OVH - na consola é posible especificar rDNS.
Para tech.ru: o problema resólvese mediante soporte.
Para AWS, o problema resólvese mediante soporte.
“inet_protocols” e “smtp_bind_address6”: activamos a compatibilidade con IPv6.
Para IPv6 tamén cómpre rexistrar rDNS.
"syslog_name" - e isto é para facilitar a lectura dos rexistros.

Comprar certificados Recomendo aquí.

Configurando a ligazón postfix+dovecot aquí.

Configuración de SPF.

============= Pombal =============

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

Configurando mysql, instalando os propios paquetes.

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

disable_plaintext_auth = yes
auth_mechanisms = plain login

A autorización só está cifrada.

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

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

Aquí indicamos o lugar de almacenamento das letras.

Quero que se almacenen en ficheiros e se agrupen por dominio.

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

Este é o ficheiro de configuración principal de dovecot.
Aquí desactivamos as conexións non seguras.
E activa conexións seguras.

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

Configurando ssl. Indicamos que é necesario o ssl.
E o propio certificado. E un detalle importante é a directiva “local”. Indica que certificado SSL usar cando se conecta a que IPv4 local.

Por certo, IPv6 non está configurado aquí, corrixirei esta omisión máis tarde.
XX.XX.XX.X5 (dominio2): sen certificado. Para conectar clientes, cómpre especificar domain1.com.
XX.XX.XX.X2 (dominio3): hai un certificado, podes especificar domain1.com ou domain3.com para conectar clientes.

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

protocol lda {
  mail_plugins = $mail_plugins sieve
}

Isto será necesario para spamassassin no futuro.

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

protocol imap {
  mail_plugins = $mail_plugins antispam
}

Este é un complemento antispam. Necesario para adestrar spamassasin no momento da transferencia a/desde o cartafol "Spam".

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

protocol pop3 {
}

Só hai un ficheiro deste tipo.

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

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

Configurando lmtp.

Ficheiro "/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ón do adestramento de Spamassasin no momento da transferencia a/desde o cartafol Spam.

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

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

Un ficheiro que especifica que facer coas cartas entrantes.

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

require ["fileinto", "mailbox"];

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

Debe compilar o ficheiro: "sievec default.sieve".

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

Especificando ficheiros sql para a autorización.
E o propio ficheiro úsase como método de autorización.

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

Isto corresponde a configuracións similares para postfix.

Ficheiro "/etc/dovecot/dovecot.conf"

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

Ficheiro de configuración principal.
O importante é que indicamos aquí - engadir protocolos.

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

apt-get install spamassassin spamc

Imos instalar os paquetes.

adduser spamd --disabled-login

Engademos un usuario en cuxo nome.

systemctl enable spamassassin.service

Activamos o servizo spamassassin de carga automática ao cargar.

Ficheiro "/etc/default/spamassassin":

CRON=1

Ao activar a actualización automática das regras "por defecto".

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

Debes crear unha base de datos "sa" en mysql co usuario "sa" co contrasinal "contrasinal" (substitúeo por algo adecuado).

report_safe: enviará un informe de correo electrónico non desexado en lugar dunha carta.
use_bayes son configuracións de aprendizaxe automática de spamassassin.

As restantes configuracións de spamassassin utilizáronse anteriormente no artigo.

Configuración xeral "spamassassin".
Acerca de mover novos correos electrónicos de spam ao cartafol IMAP "Spam"..
Sobre unha combinación sinxela de Dovecot + SpamAssassin.
Recomendo ler a teoría da aprendizaxe de spamassasin ao mover letras en cartafoles imap (e non recomendo usala).

============= Chamar á comunidade ==============

Tamén me gustaría lanzar unha idea á comunidade sobre como aumentar o nivel de seguridade das cartas reenviadas. Xa que estou profundamente inmerso no tema do correo.

Para que o usuario poida crear un par de claves no seu cliente (outlook, thunderbird, browser-plugin,...). Público e privado. Público: enviar a DNS. Privado: aforra no cliente. Os servidores de correo poderían usar unha chave pública para enviar a un destinatario específico.

E para protexerse contra o spam con tales cartas (si, o servidor de correo non poderá ver o contido) - terás que introducir 3 regras:

Sinatura DKIM real obrigatoria, SPF obrigatorio, rDNS obrigatorio.
Unha rede neuronal sobre o tema do adestramento antispam + unha base de datos para ela no lado do cliente.
O algoritmo de cifrado debe ser tal que o lado emisor debe gastar 100 veces máis potencia da CPU en cifrado que o lado receptor.

Ademais das cartas públicas, desenvolve unha carta de proposta estándar "para comezar unha correspondencia segura". Un dos usuarios (buzón de correo) envía unha carta cun anexo a outra caixa de correo. A carta contén unha proposta de texto para iniciar unha canle de comunicación segura para a correspondencia e a clave pública do propietario da caixa de correo (cunha clave privada no lado do cliente).

Incluso podes facer un par de claves especificamente para cada correspondencia. O usuario destinatario pode aceptar esta oferta e enviar a súa clave pública (tamén feita expresamente para esta correspondencia). A continuación, o primeiro usuario envía unha carta de control de servizo (cifrada coa clave pública do segundo usuario), tras a recepción da cal o segundo usuario pode considerar fiable a canle de comunicación formada. A continuación, o segundo usuario envía unha carta de control e, a continuación, o primeiro usuario tamén pode considerar segura a canle formada.

Para combater a interceptación de chaves na estrada, o protocolo debe prever a posibilidade de transmitir polo menos unha chave pública mediante un pendrive.

E o máis importante é que todo funciona (a pregunta é "quen pagará por iso?"):
Introduce certificados postais a partir de 10 $ durante 3 anos. O que permitirá ao remitente indicar no dns que "as miñas chaves públicas están aí". E daránche a oportunidade de iniciar unha conexión segura. Ao mesmo tempo, aceptar tales conexións é gratuíto.
gmail está finalmente monetizando os seus usuarios. Por 10 USD por 3 anos: dereito a crear canles de correspondencia seguras.

============= Conclusión ==============

Para probar todo o artigo, ía alugar un servidor dedicado durante un mes e mercar un dominio cun certificado SSL.

Pero as circunstancias da vida desenvolvéronse polo que este problema prolongouse durante 2 meses.
E así, cando volvín a ter tempo libre, decidín publicar o artigo tal e como está, en lugar de arriscarme a que a publicación se prolongase un ano máis.

Se hai moitas preguntas como "pero isto non se describe con suficiente detalle", entón probablemente haxa forza para tomar un servidor dedicado cun novo dominio e un novo certificado SSL e describilo aínda máis detalladamente e, a maioría é importante identificar todos os detalles importantes que faltan.

Tamén me gustaría recibir comentarios sobre ideas sobre certificados postais. Se che gusta a idea, intentarei atopar a forza para escribir un borrador para rfc.

Cando copie grandes partes dun artigo, proporcione unha ligazón a este.
Ao traducir a calquera outro idioma, proporcione unha ligazón a este artigo.
Tentarei traducilo eu mesmo ao inglés e deixarei referencias cruzadas.

Fonte: www.habr.com

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