🥇Debian + Postfix + Dovecot + Multidomínio + SSL + IPv6 + OpenVPN + Multi-interfaces + SpamAssassin-learn + Bind

Este artigo é sobre como configurar um servidor de e-mail moderno.
Postfix + Pombal. FPS + DKIM + rDNS. Com IPv6.
Com criptografia TSL. Com suporte para vários domínios - parte com um certificado SSL real.
Com proteção antispam e alta classificação antispam de outros servidores de e-mail.
Suporta múltiplas interfaces físicas.
Com OpenVPN, cuja conexão é via IPv4, e que fornece IPv6.

Se você não deseja aprender todas essas tecnologias, mas deseja configurar tal servidor, então este artigo é para você.

O artigo não tenta explicar todos os detalhes. A explicação vai para o que não se configura como padrão ou é importante do ponto de vista do consumidor.

A motivação para configurar um servidor de e-mail é um sonho meu de longa data. Isso pode parecer estúpido, mas IMHO, é muito melhor do que sonhar com um carro novo da sua marca favorita.

Existem duas motivações para configurar o IPv6. Um especialista em TI precisa aprender constantemente novas tecnologias para sobreviver. Gostaria de dar a minha modesta contribuição para a luta contra a censura.

A motivação para configurar o OpenVPN é apenas fazer com que o IPv6 funcione na máquina local.
A motivação para configurar várias interfaces físicas é que no meu servidor tenho uma interface “lenta mas ilimitada” e outra “rápida mas com tarifa”.

A motivação para definir as configurações do Bind é que meu ISP fornece um servidor DNS instável e o Google às vezes também falha. Quero um servidor DNS estável para uso pessoal.

Motivação para escrever um artigo - escrevi um rascunho há 10 meses e já o li duas vezes. Mesmo que o autor precise dele regularmente, há uma grande probabilidade de que outros também precisem dele.

Não existe uma solução universal para um servidor de e-mail. Mas tentarei escrever algo como “faça isso e então, quando tudo funcionar como deveria, jogue fora o material extra”.

A empresa tech.ru possui um servidor Colocation. É possível comparar com OVH, Hetzner, AWS. Para resolver este problema, a cooperação com tech.ru será muito mais eficaz.

O Debian 9 está instalado no servidor.

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

Existem 3 endereços 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` .

Disponível XXXX:XXXX:XXXX:XXXX::/64 um conjunto de endereços IPv6 que são atribuídos à interface `eno1` e a partir dela XXXX:XXXX:XXXX:XXXX:1:2::/96 foi atribuído a `eno2` a meu pedido.

Existem 3 domínios `domain1.com`, `domain2.com`, `domain3.com`. Existe um certificado SSL para `domain1.com` e `domain3.com`.

Tenho uma conta do Google à qual gostaria de vincular minha caixa de correio[email protegido]` (receber e enviar e-mails diretamente da interface do Gmail).
Deve haver uma caixa de correio'[email protegido]`, uma cópia do email que desejo ver no meu Gmail. E é raro conseguir enviar algo em nome de `[email protegido]` através da interface web.

Deve haver uma caixa de correio'[email protegido]`, que Ivanov usará em seu iPhone.

Os e-mails enviados devem cumprir todos os requisitos antispam modernos.
Deve haver o mais alto nível de criptografia fornecido nas redes públicas.
Deve haver suporte IPv6 para envio e recebimento de cartas.
Deveria haver um SpamAssassin que nunca excluiria e-mails. E ele será devolvido ou ignorado ou enviado para a pasta “Spam” do IMAP.
O auto-aprendizado do SpamAssassin deve ser configurado: se eu mover uma carta para a pasta Spam, ela aprenderá com isso; se eu mover uma carta da pasta Spam, ela aprenderá com isso. Os resultados do treinamento do SpamAssassin devem influenciar se a carta vai parar na pasta Spam.
Os scripts PHP devem ser capazes de enviar mensagens em nome de qualquer domínio em um determinado servidor.
Deveria haver um serviço openvpn, com capacidade de usar IPv6 em um cliente que não possui IPv6.

Primeiro você precisa configurar interfaces e roteamento, incluindo IPv6.
Em seguida, você precisará configurar o OpenVPN, que se conectará via IPv4 e fornecerá ao cliente um endereço IPv6 estático-real. Este cliente terá acesso a todos os serviços IPv6 no servidor e acesso a quaisquer recursos IPv6 na Internet.
Então você precisará configurar o Postfix para enviar cartas + SPF + DKIM + rDNS e outras coisinhas semelhantes.
Então você precisará configurar o Dovecot e configurar o Multidomain.
Então você precisará configurar o SpamAssassin e configurar o treinamento.
Finalmente, instale o Bind.

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

Para configurar interfaces, você precisa escrever isso em “/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

Essas configurações podem ser aplicadas em qualquer servidor em tech.ru (com um pouco de coordenação com o suporte) e funcionarão imediatamente como deveria.

Se você tem experiência em configurar coisas semelhantes para Hetzner, OVH, lá é diferente. Mais difícil.

eno1 é o nome da placa de rede nº 1 (lenta, mas ilimitada).
eno2 é o nome da placa de rede nº 2 (rápida, mas com tarifa).
tun0 é o nome da placa de rede virtual do OpenVPN.
XX.XX.XX.X0 - IPv4 #1 em eno1.
XX.XX.XX.X1 - IPv4 #2 em eno1.
XX.XX.XX.X2 - IPv4 #3 em eno1.
XX.XX.XX.X5 - IPv4 #1 em eno2.
XX.XX.XX.1 - Gateway IPv4.
XXXX:XXXX:XXXX:XXXX::/64 - IPv6 para todo o servidor.
XXXX:XXXX:XXXX:XXXX:1:2::/96 - IPv6 para eno2, todo o resto de fora vai para eno1.
XXXX:XXXX:XXXX:XXXX::1 — Gateway IPv6 (vale a pena notar que isso pode/deve ser feito de forma diferente. Especifique o switch IPv6).
DNS-Nameservers - 127.0.0.1 é indicado (porque o bind é instalado localmente) e 213.248.1.6 (isto é de tech.ru).

“tabela eno1t” e “tabela eno2t” - o significado dessas regras de rota é que o tráfego que entra por eno1 -> sairia por ele, e o tráfego que entra por eno2 -> sairia por ele. E também as conexões iniciadas pelo servidor passariam pelo eno1.

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

Com este comando especificamos que qualquer tráfego incompreensível que se enquadre em qualquer regra marcada como “tabela eno1t” -> seja enviado para a interface eno1.

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

Com este comando especificamos que qualquer tráfego iniciado pelo servidor deve ser direcionado para a interface eno1.

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

Com este comando definimos as regras de marcação de tráfego.

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 bloco especifica um segundo IPv4 para a interface eno1.

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

Com este comando definimos a rota dos clientes OpenVPN para IPv4 local exceto XX.XX.XX.X0.
Ainda não entendo porque este comando é suficiente para todo IPv4.

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

É aqui que definimos o endereço da própria interface. O servidor irá usá-lo como um endereço de “saída”. Não será usado de forma alguma novamente.

Por que ":1:1::" é tão complicado? Para que o OpenVPN funcione corretamente e somente para isso. Mais sobre isso mais tarde.

Sobre o tema gateway - é assim que funciona e tudo bem. Mas a forma correta é indicar aqui o IPv6 do switch ao qual o servidor está conectado.

No entanto, por algum motivo, o IPv6 para de funcionar se eu fizer isso. Provavelmente é algum tipo de problema do tech.ru.

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

Isso está adicionando um endereço IPv6 à interface. Se você precisar de cem endereços, isso significa cem linhas neste arquivo.

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

Anotei os endereços e sub-redes de todas as interfaces para deixar claro.
eno1 - deve ser "/64" - porque este é todo o nosso conjunto de endereços.
tun0 - a sub-rede deve ser maior que eno1. Caso contrário, não será possível configurar um gateway IPv6 para clientes OpenVPN.
eno2 - a sub-rede deve ser maior que tun0. Caso contrário, os clientes OpenVPN não conseguirão acessar endereços IPv6 locais.
Para maior clareza, escolhi uma etapa de sub-rede de 16, mas se desejar, você pode até executar a etapa “1”.
Conseqüentemente, 64+16 = 80 e 80+16 = 96.

Para maior clareza:
XXXX:XXXX:XXXX:XXXX:1:1:YYYY:YYYY são endereços que devem ser atribuídos a sites ou serviços específicos na interface eno1.
XXXX:XXXX:XXXX:XXXX:1:2:YYYY:YYYY são endereços que devem ser atribuídos a sites ou serviços específicos na interface eno2.
XXXX:XXXX:XXXX:XXXX:1:3:YYYY:YYYY são endereços que devem ser atribuídos a clientes OpenVPN ou usados como endereços de serviço OpenVPN.

Para configurar a rede, deverá ser possível reiniciar o servidor.
As alterações IPv4 são detectadas quando executadas (certifique-se de envolvê-las na tela - caso contrário, este comando simplesmente travará a rede no servidor):

/etc/init.d/networking restart

Adicione ao final do arquivo “/etc/iproute2/rt_tables”:

100 eno1t
101 eno2t

Sem isso, você não pode usar tabelas personalizadas no arquivo “/etc/network/interfaces”.
Os números devem ser exclusivos e menores que 65535.

As alterações do IPv6 podem ser alteradas facilmente sem reinicialização, mas para fazer isso você precisa aprender pelo menos três 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 são as configurações "sysctl" do meu servidor. Deixe-me apontar algo importante.

net.ipv4.ip_forward = 1

Sem isso, o OpenVPN não funcionará.

net.ipv6.ip_nonlocal_bind = 1

Qualquer pessoa que tentar vincular o IPv6 (por exemplo, nginx) imediatamente após a interface ser ativada receberá um erro. Que este endereço não está disponível.

Para evitar tal situação, tal configuração é feita.

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

Sem essas configurações IPv6, o tráfego do cliente OpenVPN não sai para o mundo.

Outras configurações não são relevantes ou não me lembro para que servem.
Mas, por precaução, deixo “como está”.

Para que as alterações neste arquivo sejam detectadas sem reinicializar o servidor, você precisa executar o comando:

sysctl -p

Mais detalhes sobre regras de “tabela”: habr.com/post/108690

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

OpenVPN IPv4 não funciona sem iptables.

Meus iptables são assim 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 é meu endereço IPv4 estático da máquina local.
10.8.0.0/24 - Rede IPv4 openvpn. Endereços IPv4 para clientes openvpn.
A consistência 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 é uma limitação para que somente eu possa usar o OpenVPN do meu IP estático.

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 encaminhar pacotes IPv4 entre clientes OpenVPN e a Internet, você precisa registrar um destes comandos.

Para casos diferentes, uma das opções não é adequada.
Ambos os comandos são adequados para o meu caso.
Depois de ler a documentação, escolhi a primeira opção porque usa menos CPU.

Para que todas as configurações do iptables sejam selecionadas após a reinicialização, você precisa salvá-las em algum lugar.

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

Tais nomes não foram escolhidos por acaso. Eles são usados pelo pacote "iptables-persistent".

apt-get install iptables-persistent

Instalando o pacote OpenVPN principal:

apt-get install openvpn easy-rsa

Vamos configurar um modelo para certificados (substitua seus valores):

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

Vamos editar as configurações 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"
...

Crie um certificado de servidor:

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

Vamos preparar a capacidade de criar os arquivos 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

Vamos preparar um script que irá mesclar todos os arquivos em um único arquivo 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

Criando o primeiro cliente OpenVPN:

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

O arquivo “~/client-configs/files/client-name.ovpn” é enviado para o dispositivo do cliente.

Para clientes iOS, você precisará fazer o seguinte truque:
O conteúdo da tag "tls-auth" deve estar sem comentários.
E também coloque “key-direction 1” imediatamente antes da tag “tls-auth”.

Vamos definir a configuração 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

Isso é necessário para definir um endereço estático para cada cliente (não é necessário, mas eu uso):

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

O detalhe mais difícil e importante.

Infelizmente, o OpenVPN ainda não sabe como configurar de forma independente um gateway IPv6 para clientes.
Você tem que encaminhar isso “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"

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

Arquivo “/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 os scripts usam o arquivo “/etc/openvpn/variables”:

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

Acho difícil lembrar por que está escrito assim.

Agora netmask = 112 parece estranho (deveria ser 96 ali mesmo).
E o prefixo é estranho, não corresponde à rede tun0.
Mas tudo bem, vou deixar como está.

cipher DES-EDE3-CBC

Isso não é para todos - escolhi esse método para criptografar a conexão.

Saiba mais sobre como configurar o OpenVPN IPv4.

Saiba mais sobre como configurar o OpenVPN IPv6.

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

Instalando o pacote principal:

apt-get install postfix

Ao instalar, selecione “site da internet”.

Meu "/etc/postfix/main.cf" fica assim:

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

Vejamos os detalhes desta configuração.

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

Segundo os residentes de Khabrovsk, este bloco contém “desinformação e teses incorretas”.Apenas 8 anos após o início da minha carreira comecei a entender como funciona o SSL.

Portanto, tomarei a liberdade de descrever como utilizar SSL (sem responder às perguntas “Como funciona?” e “Por que funciona?”).

A base da criptografia moderna é a criação de um par de chaves (duas sequências de caracteres muito longas).

Uma “chave” é privada, a outra chave é “pública”. Mantemos a chave privada cuidadosamente secreta. Distribuímos a chave pública para todos.

Usando uma chave pública, você pode criptografar uma sequência de texto para que somente o proprietário da chave privada possa descriptografá-la.
Bem, essa é toda a base da tecnologia.

Etapa 1 – sites https.
Ao acessar um site, o navegador aprende com o servidor web que o site é https e, portanto, solicita uma chave pública.
O servidor web fornece a chave pública. O navegador usa a chave pública para criptografar a solicitação http e enviá-la.
O conteúdo de uma solicitação http só pode ser lido por quem possui a chave privada, ou seja, apenas o servidor para o qual a solicitação é feita.
A solicitação HTTP contém pelo menos um URI. Portanto, se um país está tentando restringir o acesso não ao site inteiro, mas a uma página específica, isso é impossível de fazer para sites https.

Etapa 2 – resposta criptografada.
O servidor web fornece uma resposta que pode ser facilmente lida em trânsito.
A solução é extremamente simples: o navegador gera localmente o mesmo par de chaves pública-privada para cada site https.
E junto com a solicitação da chave pública do site, ele envia sua chave pública local.
O servidor web lembra e, ao enviar a resposta http, criptografa-a com a chave pública de um cliente específico.
Agora, a resposta http só pode ser descriptografada pelo proprietário da chave privada do navegador do cliente (ou seja, o próprio cliente).

Etapa número 3 - estabelecer uma conexão segura por meio de um canal público.
Há uma vulnerabilidade no exemplo nº 2 - nada impede que simpatizantes interceptem uma solicitação http e editem informações sobre a chave pública.
Assim, o intermediário verá com clareza todo o conteúdo das mensagens enviadas e recebidas até que o canal de comunicação mude.
Lidar com isso é extremamente simples – basta enviar a chave pública do navegador como uma mensagem criptografada com a chave pública do servidor web.
O servidor web primeiro envia uma resposta como “sua chave pública é assim” e criptografa esta mensagem com a mesma chave pública.
O navegador analisa a resposta - se a mensagem “sua chave pública é assim” for recebida - isso é 100% garantido que este canal de comunicação é seguro.
Quão seguro é isso?
A própria criação de um canal de comunicação seguro ocorre a uma velocidade de ping*2. Por exemplo 20ms.
O invasor deve ter antecipadamente a chave privada de uma das partes. Ou encontre uma chave privada em alguns milissegundos.
Hackear uma chave privada moderna levará décadas em um supercomputador.

Passo #4 – banco de dados público de chaves públicas.
Obviamente, em toda essa história existe uma oportunidade para um invasor se sentar no canal de comunicação entre o cliente e o servidor.
O cliente pode fingir ser o servidor e o servidor pode fingir ser o cliente. E emular um par de chaves em ambas as direções.
Então o invasor verá todo o tráfego e poderá “editar” o tráfego.
Por exemplo, altere o endereço para onde enviar dinheiro ou copie a senha do banco online ou bloqueie conteúdo “censurável”.
Para combater esses invasores, eles criaram um banco de dados público com chaves públicas para cada site https.
Cada navegador “sabe” da existência de cerca de 200 desses bancos de dados. Isso vem pré-instalado em todos os navegadores.
O “conhecimento” é respaldado por uma chave pública de cada certificado. Ou seja, a conexão com cada autoridade certificadora específica não pode ser falsificada.

Agora há uma compreensão simples de como usar SSL para https.
Se você usar seu cérebro, ficará claro como os serviços especiais podem hackear algo nessa estrutura. Mas isso lhes custará esforços monstruosos.
E organizações menores que a NSA ou a CIA – é quase impossível hackear o nível de proteção existente, mesmo para VIPs.

Também acrescentarei sobre conexões ssh. Não há chaves públicas lá, então o que você pode fazer? O problema é resolvido de duas maneiras.
Opção ssh por senha:
Durante a primeira conexão, o cliente ssh deverá avisar que temos uma nova chave pública do servidor ssh.
E durante outras conexões, se o aviso “nova chave pública do servidor ssh” aparecer, isso significará que eles estão tentando espionar você.
Ou você foi escutado em sua primeira conexão, mas agora se comunica com o servidor sem intermediários.
Na verdade, pelo fato de o fato da escuta telefônica ser revelado de forma fácil, rápida e sem esforço, este ataque é utilizado apenas em casos especiais para um cliente específico.

Opção ssh por chave:
Pegamos uma unidade flash USB, escrevemos nela a chave privada do servidor ssh (existem termos e muitas nuances importantes para isso, mas estou escrevendo um programa educacional, não instruções de uso).
Deixamos a chave pública na máquina onde estará o cliente ssh e também a mantemos em segredo.
Levamos o pen drive para o servidor, inserimos, copiamos a chave privada, queimamos o pen drive e espalhamos as cinzas ao vento (ou pelo menos formatamos com zeros).
Isso é tudo - depois de tal operação, será impossível hackear essa conexão ssh. É claro que em 10 anos será possível visualizar o tráfego em um supercomputador – mas isso é uma história diferente.

Peço desculpas pelo offtopic.

Então agora que a teoria é conhecida. Vou falar sobre o fluxo de criação de um certificado SSL.

Usando “openssl genrsa” criamos uma chave privada e “espaços em branco” para a chave pública.
Enviamos os “espaços em branco” para uma empresa terceirizada, à qual pagamos aproximadamente US$ 9 pelo certificado mais simples.

Depois de algumas horas, recebemos nossa chave “pública” e um conjunto de várias chaves públicas desta empresa terceirizada.

Por que uma empresa terceirizada deveria pagar pelo registro da minha chave pública é uma questão separada, não a consideraremos aqui.

Agora está claro qual é o significado da inscrição:

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

A pasta “/etc/ssl” contém todos os arquivos para problemas de SSL.
domínio1.com — nome de domínio.
2018 é o ano da criação de chaves.
“chave” – designação de que o arquivo é uma chave privada.

E o significado deste arquivo:

smtpd_tls_cert_file=/etc/ssl/domain1.com.2018.chained.crt
domínio1.com — nome de domínio.
2018 é o ano da criação de chaves.
chained - designação de que existe uma cadeia de chaves públicas (a primeira é a nossa chave pública e as restantes são as que vieram da empresa que emitiu a chave pública).
crt - designação de que existe um certificado pronto (chave pública com explicações técnicas).

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

Esta configuração não é usada neste caso, mas é escrita como exemplo.

Porque um erro neste parâmetro fará com que o spam seja enviado do seu servidor (sem a sua vontade).

Então prove a todos que você não é culpado.

recipient_delimiter = +

Muitas pessoas podem não saber, mas este é um caractere padrão para classificação de e-mails e é suportado pela maioria dos servidores de e-mail modernos.

Por exemplo, se você tiver uma caixa de correio "[email protegido]"tente enviar para"[email protegido]"- olha o que acontece.

inet_protocols = ipv4

Isso pode ser confuso.

Mas não é só assim. Cada novo domínio é por padrão apenas IPv4, então eu ligo o IPv6 para cada um separadamente.

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

Aqui especificamos que todas as mensagens recebidas vão para o pombal.
E as regras para domínio, caixa de correio, alias - procure no banco de dados.

/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 o postfix sabe que o correio só pode ser aceito para envio posterior após autorização do dovecot.

Eu realmente não entendo por que isso está duplicado aqui. Já especificamos tudo o que é necessário em “virtual_transport”.

Mas o sistema postfix é muito antigo - provavelmente é um retrocesso dos velhos tempos.

smtpd_recipient_restrictions =
        ...

smtpd_helo_restrictions =
        ...

smtpd_client_restrictions =
        ...

Isto pode ser configurado de forma diferente para cada servidor de correio.

Tenho 3 servidores de e-mail à minha disposição e essas configurações são muito diferentes devido aos diferentes requisitos de uso.

Você precisa configurá-lo com cuidado - caso contrário, o spam chegará até você ou, pior ainda, o spam sairá de você.

# SPF
policyd-spf_time_limit = 3600

Configurando algum plugin relacionado à verificação do SPF das cartas recebidas.

# 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 configuração é que devemos fornecer uma assinatura DKIM com todos os e-mails enviados.

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

Este é um detalhe importante no roteamento de cartas ao enviar cartas de scripts PHP.

Arquivo “/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ão as expressões regulares. À direita está uma etiqueta que marca a letra.
Postfix de acordo com a etiqueta - levará em consideração mais algumas linhas de configuração para uma letra específica.

Como exatamente o postfix será reconfigurado para uma letra específica será indicado em “master.cf”.

As linhas 4, 5, 6 são as principais. Em nome do domínio para o qual enviamos a carta, colocamos esta etiqueta.
Mas o campo “de” nem sempre é indicado em scripts PHP no código antigo. Então o nome de usuário vem em socorro.

O artigo já é extenso - eu não gostaria de me distrair configurando o nginx+fpm.

Resumidamente, para cada site definimos seu próprio proprietário de usuário Linux. E, consequentemente, seu pool fpm.

O Fpm-pool usa qualquer versão do php (é ótimo quando no mesmo servidor você pode usar versões diferentes do php e até php.ini diferentes para sites vizinhos sem problemas).

Portanto, um usuário Linux específico “www-domain2” possui um site domain2.com. Este site possui um código para envio de e-mails sem especificar o campo de.

Assim, mesmo neste caso, as cartas serão enviadas corretamente e nunca irão parar em spam.

Meu "/etc/postfix/master.cf" fica assim:

...
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 arquivo não é fornecido na íntegra - já é muito grande.
Apenas observei o que foi alterado.

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 são configurações relacionadas ao spamassasin, falaremos mais sobre isso mais tarde.

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 você se conecte ao servidor de e-mail através da porta 587.
Para fazer isso, você deve fazer login.

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

Habilite a verificação SPF.

apt-get install postfix-policyd-spf-python

Vamos instalar o pacote para verificações SPF acima.

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 isso é o mais interessante. Esta é a capacidade de enviar cartas para um domínio específico a partir de um endereço IPv4/IPv6 específico.

Isso é feito por causa do rDNS. rDNS é o processo de recebimento de uma string por endereço IP.
E para correio, esse recurso é usado para confirmar se o helo corresponde exatamente ao rDNS do endereço de onde o e-mail foi enviado.

Se o helo não corresponder ao domínio do e-mail em nome de quem a carta foi enviada, serão concedidos pontos de spam.

Helo não corresponde a rDNS - muitos pontos de spam são concedidos.
Assim, cada domínio deve ter seu próprio endereço IP.
Para OVH - na consola é possível especificar rDNS.
Para tech.ru - o problema é resolvido através do suporte.
Para AWS, o problema é resolvido por meio de suporte.
“inet_protocols” e “smtp_bind_address6” - habilitamos o suporte IPv6.
Para IPv6 você também precisa registrar o rDNS.
“syslog_name” - e isso é para facilitar a leitura dos logs.

Comprar certificados Eu recomendo aqui.

Configurando o link postfix + dovecot aqui.

Configurando FPS.

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

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

Configurando o mysql, instalando os próprios pacotes.

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

disable_plaintext_auth = yes
auth_mechanisms = plain login

A autorização é apenas criptografada.

Arquivo “/etc/dovecot/conf.d/10-mail.conf”

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

Aqui indicamos o local de armazenamento das cartas.

Quero que eles sejam armazenados em arquivos e agrupados por domínio.

Arquivo "/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 arquivo de configuração principal do dovecot.
Aqui desabilitamos conexões não seguras.
E habilite conexões seguras.

Arquivo "/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 o SSL é obrigatório.
E o próprio certificado. E um detalhe importante é a diretriz “local”. Indica qual certificado SSL usar ao conectar-se a qual IPv4 local.

Aliás, o IPv6 não está configurado aqui, corrigirei essa omissão mais tarde.
XX.XX.XX.X5 (domínio2) - sem certificado. Para conectar clientes, você precisa especificar domain1.com.
XX.XX.XX.X2 (domínio3) - existe um certificado, você pode especificar domínio1.com ou domínio3.com para conectar clientes.

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

protocol lda {
  mail_plugins = $mail_plugins sieve
}

Isso será necessário para o spamassassin no futuro.

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

protocol imap {
  mail_plugins = $mail_plugins antispam
}

Este é um plugin antispam. Necessário para treinar o spamassasin no momento da transferência de/para a pasta “Spam”.

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

protocol pop3 {
}

Existe exatamente esse arquivo.

Arquivo “/etc/dovecot/conf.d/20-lmtp.conf”

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

Configurando o lmtp.

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

Configurações de treinamento do Spamassasin no momento da transferência de/para a pasta Spam.

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

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

Um arquivo que especifica o que fazer com as cartas recebidas.

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

require ["fileinto", "mailbox"];

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

Você precisa compilar o arquivo: “sievec default.sieve”.

Arquivo "/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 arquivos SQL para autorização.
E o próprio arquivo é usado como método de autorização.

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

Isso corresponde a configurações semelhantes para o postfix.

Arquivo "/etc/dovecot/dovecot.conf"

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

Arquivo de configuração principal.
O importante que indicamos aqui é adicionar protocolos.

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

apt-get install spamassassin spamc

Vamos instalar os pacotes.

adduser spamd --disabled-login

Vamos adicionar um usuário em nome de quem.

systemctl enable spamassassin.service

Ativamos o serviço spamassassin de carregamento automático durante o carregamento.

Arquivo "/etc/default/spamassassin":

CRON=1

Ao permitir a atualização automática de regras “por padrão”.

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

Você precisa criar um banco de dados “sa” no mysql com o usuário “sa” com a senha “password” (substituir por algo adequado).

report_safe - enviará um relatório de e-mail de spam em vez de uma carta.
use_bayes são configurações de aprendizado de máquina spamassassin.

As configurações restantes do spamassassin foram usadas anteriormente neste artigo.

Configuração geral "spamassassin".
Sobre mover novos e-mails de Spam para a pasta “Spam” do IMAP.
Sobre uma combinação simples de Dovecot + SpamAssassin.
Recomendo a leitura da teoria de aprendizagem spamassasin ao mover letras em pastas imap (e não recomendo usá-la).

============= Apelo à comunidade =============

Gostaria também de lançar uma ideia à comunidade sobre como aumentar o nível de segurança das cartas encaminhadas. Já que estou profundamente imerso no tópico do correio.

Para que o usuário possa criar um par de chaves em seu cliente (outlook, Thunderbird, plugin de navegador, ...). Público e privado. Público - envia para DNS. Privado - economize no cliente. Os servidores de correio seriam capazes de usar uma chave pública para enviar a um destinatário específico.

E para se proteger contra spam com essas cartas (sim, o servidor de e-mail não poderá visualizar o conteúdo) - você precisará introduzir 3 regras:

Assinatura DKIM real obrigatória, SPF obrigatório, rDNS obrigatório.
Rede neural sobre treinamento antispam + banco de dados para isso no lado do cliente.
O algoritmo de criptografia deve ser tal que o lado emissor gaste 100 vezes mais energia da CPU em criptografia do que o lado receptor.

Além das cartas públicas, desenvolva uma carta de proposta padrão “para iniciar uma correspondência segura”. Um dos usuários (caixa de correio) envia uma carta com anexo para outra caixa de correio. A carta contém uma proposta de texto para iniciar um canal de comunicação seguro para correspondência e a chave pública do proprietário da caixa de correio (com chave privada do lado do cliente).

Você pode até criar algumas chaves específicas para cada correspondência. O usuário destinatário pode aceitar esta oferta e enviar sua chave pública (também feita especificamente para esta correspondência). Em seguida, o primeiro usuário envia uma carta de controle de serviço (criptografada com a chave pública do segundo usuário) - após o recebimento da qual o segundo usuário pode considerar confiável o canal de comunicação formado. Em seguida, o segundo usuário envia uma carta de controle - e então o primeiro usuário também pode considerar o canal formado seguro.

Para combater a interceptação de chaves na estrada, o protocolo deve prever a possibilidade de transmissão de pelo menos uma chave pública por meio de um pen drive.

E o mais importante é que tudo funcione (a questão é “quem vai pagar?”):
Insira certificados postais a partir de US$ 10 por 3 anos. O que permitirá ao remetente indicar no DNS que “minhas chaves públicas estão ali”. E eles lhe darão a oportunidade de iniciar uma conexão segura. Ao mesmo tempo, aceitar tais conexões é gratuito.
O Gmail está finalmente monetizando seus usuários. Por US$ 10 por 3 anos - o direito de criar canais de correspondência seguros.

============= Conclusão =============

Para testar o artigo inteiro, eu ia alugar um servidor dedicado por um mês e comprar um domínio com certificado SSL.

Mas as circunstâncias da vida evoluíram e esse problema se arrastou por 2 meses.
E assim, quando tive tempo livre novamente, decidi publicar o artigo como está, em vez de arriscar que a publicação se arrastasse por mais um ano.

Se houver muitas perguntas como “mas isso não está descrito com detalhes suficientes”, então provavelmente haverá força para pegar um servidor dedicado com um novo domínio e um novo certificado SSL e descrevê-lo com ainda mais detalhes e, mais mais importante ainda, identifique todos os detalhes importantes que faltam.

Também gostaria de receber feedback sobre ideias sobre certificados postais. Se você gostar da ideia, tentarei encontrar forças para escrever um rascunho para o rfc.

Ao copiar grandes partes de um artigo, forneça um link para este artigo.
Ao traduzir para qualquer outro idioma, forneça um link para este artigo.
Tentarei traduzi-lo pessoalmente para o inglês e deixarei referências cruzadas.

Fonte: habr.com

Debian + Postfix + Dovecot + Multidomínio + SSL + IPv6 + OpenVPN + Multi-interfaces + SpamAssassin-learn + Bind