Introdução
A partir dessa seção vamos finalmente colocar a mão na massa e configurar um servidor de email completo. Em determinado ponto irei mostrar a configuração do Dovecot que ficou faltando nas seções anteriores, também mostrarei como configurar o RspamD e mais alguns outros serviços. Sobre o Dovecot e Rspamd, irei explicar apenas o necessário e nada mais, vou abordar assim porque teremos explicações exclusivas desses dois serviços, mas é importante termos tudo configurado agora para que possamos mexer mais com eles nas próximas documentações.
Preparando o Ambiente
Antes de iniciar a instalação do Postfix, é essencial preparar o ambiente para garantir que o servidor de e-mail funcione corretamente. Abaixo estão os passos principais:
- Configurar o Hostname
- Configurar o Firewall no servidor
- Configurar o SSH no servidor a fim de evitar acessos não autorizados
- Configurar o Sistema de Hora
- Configurar Corretamente o DNS (A, AAAA e MX)
Hostname
Um servidor de e-mail deve possuir um nome de domínio totalmente qualificado (FQDN, Fully Qualified Domain Name), como mail.example.com.br. O Postfix utiliza esse nome ao se comunicar com clientes e servidores de e-mail remotos, a menos que seja configurado para usar outro nome.
A importância do FQDN está no fato de que muitos servidores de e-mail verificam o nome anunciado pelo cliente durante a comunicação. Se o cliente não fornecer um FQDN válido, o servidor pode rejeitar a mensagem. Além disso, alguns servidores verificam se o FQDN informado resolve corretamente no DNS, adicionando uma camada de segurança. Para mais detalhes sobre a importância do FQDN, consulte o RFC 821.
Todo sistema operacional define o hostname do sistema no momento da instalação do sistema. Para ver se seu sistema já tem um FQDN, faça login e insira o nome do host:
# Utilize o comando abaixo para definir um novo hostname:
$ sudo hostnamectl set-hostname mail.hermodr.com.br
Firewall
Configurar corretamente o firewall de um servidor é fundamental para garantir sua segurança e a correta operação dos serviços que ele oferece. O firewall atua como a primeira linha de defesa contra acessos não autorizados, bloqueando tráfego malicioso e prevenindo tentativas de invasão, como ataques de força bruta ou varredura de portas.
Além disso, o firewall permite um controle rigoroso sobre o tráfego de entrada e saída. Isso significa que você pode filtrar quais tipos de dados entram e saem do servidor. Uma configuração adequada também pode proteger contra abusos de protocolos e prevenir ataques mais complexos, como negação de serviço (DDoS).
Para configuração do Firewall no Linux recomendo o uso do IPtables ou de seu sucessor o NFtables. Você pode aprender um pouco sobre o Iptables aqui. Para configuração do Firewall eu recomendo começar instalando o iptables-persistent, ele vai carregar todas as regras de Firewall sempre que o Sistema Operacional iniciar, permitindo que o sistema sempre aplique as regras de Firewall.
$ sudo apt install iptables-persistent -y
# Responda com Y para ambas as perguntas.
Para aplicar regras básicas e iniciais de Hardening, recomendo o seguinte:
# Aplicando regras para IPv4:
╼ $ cat << 'EOF' > /etc/iptables/rules.v4
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A INPUT -m udp -p udp -m multiport --dports 33434:33690 -j ACCEPT
-A INPUT -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[iptables denied]: "
COMMIT
EOF
# Aplicando regras para IPv6:
╼ $ cat << 'EOF' > /etc/iptables/rules.v6
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m rt --rt-type 0 -j DROP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 1 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 2 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 3 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 4 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 129 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 135 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 136 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 141 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 142 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 148 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 149 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -p udp -m udp -m multiport --dports 33433:33690 -j ACCEPT
COMMIT
EOF
# Para aplicar as regras use o comando abaixo, mas não faça isso ainda:
$ sudo iptables-restore /etc/iptables/rules.v4
$ sudo ip6tables-restore /etc/iptables/rules.v6
Essas regras de firewall foram escritas para uso com o iptables e se aplicam a servidores que utilizam IPv4 e IPv6. Vou explicar cada conjunto de regras separadamente, destacando as diferenças e o propósito de cada uma.
As políticas padrão são:
- INPUT DROP: Todo o tráfego de entrada é bloqueado por padrão.
- FORWARD DROP: O tráfego que passa pelo servidor, sem ser direcionado para ele, também é bloqueado por padrão.
- OUTPUT ACCEPT: Todo o tráfego de saída é permitido.
Regras Específicas para o IPv6.
-A INPUT -i lo -j ACCEPT:
Permite todo o tráfego na interface de loopback (lo), essencial para a comunicação interna do sistema.-A INPUT -m rt --rt-type 0 -j DROP:
Bloqueia pacotes IPv6 Router Alert, que são raramente usados e podem ser explorados para ataques.-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT:
Permite pacotes que fazem parte de uma conexão já estabelecida ou que estão relacionados a uma.-A INPUT -m conntrack --ctstate INVALID -j DROP:
Bloqueia pacotes inválidos, que não pertencem a nenhuma conexão conhecida.-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type [type] -j ACCEPT:
Permite pacotes ICMPv6 específicos, que são essenciais para o funcionamento do IPv6.-A INPUT -p udp -m udp -m multiport --dports 33433:33690 -j ACCEPT:
Permite pacotes UDP em uma faixa específica de portas, usada comumente para traceroute no IPv6.
Abaixo seguem os pacotes ICMPv6 que estamos Liberando:
- Type 1, 2, 3, 4: Mensagens de erro como "Destination Unreachable" e "Packet Too Big".
- Type 128, 129: Solicitações e respostas de Echo Request e Echo Reply (ping).
- Type 135, 136: Mensagens de Neighbor Solicitation e Neighbor Advertisement, usadas no protocolo de resolução de endereços no IPv6.
- Type 141, 142, 148, 149: Mensagens específicas para o gerenciamento de grupos de multicast no IPv6.
Regras Específicas para o IPv4.
-A INPUT -i lo -j ACCEPT:
Permite todo o tráfego na interface de loopback (lo).-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT:
Permite pacotes que fazem parte de uma conexão estabelecida ou relacionada.-A INPUT -m conntrack --ctstate INVALID -j DROP:
Bloqueia pacotes inválidos.-A INPUT -p icmp -m icmp --icmp-type [type] -j ACCEPT:
Permite pacotes ICMP (protocolo de mensagens de controle da internet) específicos, essenciais-A INPUT -m udp -p udp -m multiport --dports 33434:33690 -j ACCEPT:
Permite pacotes UDP em uma faixa específica de portas, normalmente usada para traceroute no IPv4.-A INPUT -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[iptables denied]: ":
Limita o número de pacotes logados para 3 por minuto, com um burst inicial de 10 pacotes, para evitar que o log seja inundado. Quando uma regra é violada, o prefixo "[iptables denied]:" será adicionado ao log.
Abaixo seguem os pacotes ICMPv4 que estamos Liberando:
- Type 3: Destination Unreachable.
- Type 4: Source Quench (descontinuado, mas ainda incluído em algumas configurações).
- Type 8: Echo Request (ping).
- Type 11: Time Exceeded.
- Type 12: Parameter Problem.
Essas regras são bastante rígidas e estão configuradas para permitir apenas o tráfego essencial para o funcionamento do servidor, enquanto bloqueiam tudo o que não foi explicitamente permitido. O foco está na segurança, aceitando somente tráfego confiável e necessário para IPv4 e IPv6. A regra de log é útil para monitorar tentativas de acesso não autorizadas, sem sobrecarregar o sistema de logs.
Vale notar que após aplicar as regras, novas conexões no SSH serão bloqueadas, por isso, faremos mais configurações no Firewall adiante, liberando não somente o SSH, mas as portas utilizadas pelo SMTP, IMAP e Submission.
Secure Shell (SSH)
O SSH (Secure Shell) é um protocolo de rede essencial para conectar-se de forma segura a servidores remotos. Através dele, é possível administrar sistemas, transferir arquivos e executar comandos à distância, garantindo a integridade e confidencialidade das informações. Ao criptografar todo o tráfego, o SSH protege seus dados contra acessos não autorizados e interceptações. Com o SSH, você tem controle total sobre seus servidores, podendo configurá-los e gerenciá-los de qualquer lugar com uma conexão à internet.
# Comece instalando o SSH:
$ sudo apt install openssh-server -y
# Após a instalação vamos criar uma configuração adicional:
╼ $ cat << EOF > /etc/ssh/sshd_config.d/default.conf
Port 60000
LogLevel VERBOSE
PasswordAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
PermitEmptyPasswords no
X11Forwarding no
AllowTcpForwarding no
UseDNS no
ChallengeResponseAuthentication no
SyslogFacility AUTH
EOF
# Crie sua chave ssh:
$ ssh-keygen -t ed25519 -b 4096 -C "seuemail@exemplo.com.br"
# Chave privada: ~/.ssh/id_ed25519 (mantenha esta chave em segredo).
# Chave pública: ~/.ssh/id_ed25519.pub (esta chave pode ser compartilhada).
# Configure o SSH para permitir acesso usando a chave privada:
$ cp ~/.ssh/id_ed25519.pub ~/.ssh/authorized_keys
# Agora reinicie o serviço do SSH:
$ sudo systemctl restart sshd
A partir desse ponto transfira a sua chave privada para a máquina segura que fará os acessos remotos. A tabela abaixo explica cada opção usada no SSH.
| Opção | Descrição |
|---|---|
| Port 60000 | Define a porta na qual o servidor SSH escuta conexões. Aqui, o servidor está configurado para usar a porta 60000 em vez da porta padrão 22. |
| LogLevel VERBOSE | Define o nível de detalhamento dos logs gerados pelo SSH. VERBOSE fornece informações mais detalhadas sobre a operação e eventos de autenticação. |
| PasswordAuthentication no | Desativa a autenticação por senha. Apenas métodos de autenticação alternativos, como chave pública, serão aceitos. |
| PubkeyAuthentication yes | Habilita a autenticação baseada em chave pública. Permite que usuários se autentiquem usando chaves públicas. |
| AuthenticationMethods publickey | Define que a autenticação deve ser realizada apenas usando chaves públicas. Outros métodos de autenticação não são permitidos. |
| PermitEmptyPasswords no | Proíbe o uso de senhas vazias. Usuários não podem se autenticar se a senha estiver vazia. |
| X11Forwarding no | Desativa o encaminhamento X11. Não permite que as aplicações gráficas remotas sejam executadas no servidor. |
| AllowTcpForwarding no | Desativa o encaminhamento de TCP. Não permite que o usuário encaminhe conexões TCP através do túnel SSH. |
| UseDNS no | Desativa a resolução de DNS para o endereço IP do cliente. O servidor SSH não faz uma verificação reversa de DNS para o IP do cliente. |
| ChallengeResponseAuthentication no | Desativa a autenticação baseada em desafios e respostas, como OTPs (One-Time Passwords). |
| SyslogFacility AUTH | Define o tipo de log enviado ao syslog. AUTH direciona os logs de autenticação para o log de autenticação padrão do sistema. |
Algumas configurações acima acabam sendo redundantes quanto ao uso de chaves na conexão, eu sempre prefiro reforçar uma boa configuração mesmo que se torne um pouco redundante.
Agora para conseguir logar no SSH temos que liberar no Firewall, para isso adicione as seguintes linhas. Vamos começar configurando o IPv4.
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A INPUT -m udp -p udp -m multiport --dports 33434:33690 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 60000 -j ACCEPT
-A INPUT -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[iptables denied]: "
COMMIT
Agora vamos configurar o IPv6.
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m rt --rt-type 0 -j DROP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 1 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 2 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 3 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 4 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 129 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 135 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 136 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 141 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 142 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 148 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 149 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -p udp -m udp -m multiport --dports 33433:33690 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 60000 -j ACCEPT
COMMIT
Perceba que em ambos os casos a regra foi adicionada em cima de COMMIT, a ordem das regras importa, então tome cuidado onde vai colocar. Agora sim podemos aplicar as regras sem ficarmos preso do lado de fora do servidor.
#
# Para aplicar as regras use o comando abaixo:
$ sudo iptables-restore /etc/iptables/rules.v4
$ sudo ip6tables-restore /etc/iptables/rules.v6
Configurar o Sistema de Hora
A configuração do tempo e sincronização de hora no servidor é essencial para garantir a precisão e consistência das operações do sistema e serviços. Vejamos como configurar corretamente.
# Desative a sincronização do NTP:
$ sudo timedatectl set-ntp false
# Configure o fuso horário:
$ sudo timedatectl set-timezone America/Sao_Paulo
# Faça a instalação do Chrony:
$ sudo apt install -y chrony
## Agora vamos configurar o chrony para usar os servidores NTP Brasileiros:
# Edite o arquivo abaixo:
$ sudo vim /etc/chrony/chrony.conf
### Comente as linhas abaixo:
#pool ntp.ubuntu.com iburst maxsources 4
#pool 0.ubuntu.pool.ntp.org iburst maxsources 1
#pool 1.ubuntu.pool.ntp.org iburst maxsources 1
#pool 2.ubuntu.pool.ntp.org iburst maxsources 2
### Adicione as linhas logo abaixo das comentadas:
pool pool.ntp.br iburst maxsources 4
# Reinicie o serviço do chrony:
$ sudo systemctl restart chrony
Nós desativamos o NTP para usar o Chrony, um serviço de sincronização de hora mais avançado.
A linhapool pool.ntp.brdefine um servidor NTP brasileiro, pool.ntp.br, que pode oferecer uma melhor sincronização para sua localização geográfica. Oiburstfaz com que o intervalo entre as quatro primeiras solicitações enviadas ao servidor será de 2 segundos ou menos, o que permite que ochronydfaça a primeira atualização do relógio logo após o início.
Configurar Corretamente o DNS
Configurar corretamente o DNS para um servidor de email é fundamental para garantir que as mensagens eletrônicas sejam entregues de forma eficaz e segura. Quando você envia um e-mail, os servidores de email consultam o DNS para descobrir o endereço IP do servidor de email de destino. Se os registros DNS estiverem incorretos ou incompletos, a mensagem pode ser perdida ou entregue com atraso.
Os registros DNS também são utilizados para verificar a autenticidade do remetente de um e-mail. Mecanismos como SPF, DKIM e DMARC se baseiam em informações do DNS para prevenir o envio de e-mails falsos (spoofing). Um DNS configurado corretamente contribui para uma boa reputação do seu domínio, reduzindo as chances de seus e-mails serem marcados como spam.
Como é muito abrangente a forma como isso pode ser feita, por exemplo, configurando usando o seu Registry ccTLDs, Registrars ou até mesmo um servidor DNS próprio, não vou abordar como configurar, mas informar que deve ser configurado.
Vamos parar e desabilitar o systemd-resolved, que é o responsável por resolver nomes de domínio e manter o cache DNS do SystemD, ele é um Resolver. Fazer isso interrompe o serviço de DNS temporariamente.
# Para o serviço:
$ sudo systemctl stop systemd-resolved
# Desativa ele para não subir mais na inicialização do servidor:
$ sudo systemctl disable systemd-resolved
Atualmente o resolv.conf é um link simbólico para obter os servidores DNS de forma automática usando systemd-resolved como backend. Ao remover esse arquivo nos "deletamos" o link existente e precisamos criar um novo arquivo com uma configuração estática, para servidores é a melhor opção fazer isso.
# Delete o arquivo:
$ sudo rm -f /etc/resolv.conf
# Configure novos servidores DNS, aqui vou usar os DNS do Google:
╼ $ cat << EOF > /etc/resolv.conf
nameserver 8.8.8.8
nameserver 8.8.4.4
EOF
# Agora arrume o nome do servidor para o endereço '127.0.1.1' e para os IPs públicos do servidor.
# O Postfix usara o 127.0.1.1 para fornecer o nome do servidor de email no cabeçalho de email.
$ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 mail.hermodr.com.br mail
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
75.119.143.187 mail.hermodr.com.br mail
2a02:c206:2120:1140::1 mail.hermodr.com.br mail
Essas etapas são realizadas para remover o gerenciamento automático de DNS fornecido pelo systemd-resolved e configurar manualmente o DNS do sistema. Isso pode ser necessário em ambientes onde você deseja um controle mais direto sobre a resolução de nomes, evita conflitos de configuração ou quando o systemd-resolved não atende às suas necessidades específicas.
Agora com a resolução de nomes interna do servidor está configurada é hora de configurar o DNS público. Inicialmente você deve configurar esses registros no DNS:
A -> Deve apontar para o IPv4 do domínio;
AAAA -> Deve apontar para o IPv6 do domínio;
MX -> O registro MX do seu domínio deve apontar para um nome de servidor com uma numeração. Ex:
exemplo.com.br 10 mail.exemplo.com.br.
exemplo.com.br é o domínio e 'mail.exemplo.com.br' é servidor responsável pelos Emails desse domínio.
O 10 é um número para diferenciar quem é o servidor de Email prioritário quando temos mais de um configurado.
CNAME -> É um nome tipo 'mail.exemplo.com.br' que deve apontar para o domínio, como 'exemplo.com.br'.
Para ficar ainda mais prático veja um exemplo:
exemplo.com.br has IPv4 192.168.0.10
exemplo.com.br has IPv6 FC00:a141::1
exemplo.com.br mail is handled by 10 mail.exemplo.com.br.
mail.exemplo.com.br is an alias for exemplo.com.br.
Não se esqueça de configurar registros PTR (reverse DNS) é extremamente importante para servidores de e-mail. A configuração adequada do PTR pode melhorar a reputação do seu servidor de e-mail e reduzir a probabilidade de seus e-mails serem marcados como spam. Algumas políticas de e-mail e regulamentações recomendam ou exigem a configuração de registros PTR para garantir a integridade e autenticidade das comunicações por e-mail.
Após configurar o PTR, use ferramentas como dig, host ou nslookup para verificar se o registro PTR está configurado corretamente.
$ dig -x 192.0.2.1
$ dig -x 2001:db8::1
Para deixar mais claro como funcionam alguns recursos do DNS, vou deixar o próximo tópico somente para falarmos de Registros de DNS para servidores de email.
Certificado de servidor
Para obter o certificado do servidor vamos usar a Let's Encrypt, ela é uma Autoridade Certificadora (CA) que emite certificados digitais gratuitos para servidores, especificamente para servidores web e de email. Os certificados permitem que o tráfego entre o servidor e os clientes seja criptografado usando o protocolo TLS, garantindo segurança e privacidade durante as comunicações entre cliente e servidor ou servidor para servidor no caso de dois MTA conversando para envio de emails.
# Instale o CertBot:
$ sudo apt install certbot -y
# Agora vamos gerar o certificado, para essa opção funcionar a porta 80 no servidor deve estar aberta.
$ sudo certbot certonly --standalone --keep --reuse-key
.
.
.
# Quando for solicitado, informe o domínio para o qual queremos os certificados:
mail.hermodr.com.br
.
.
.
Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/mail.hermodr.com.br/fullchain.pem
Key is saved at: /etc/letsencrypt/live/mail.hermodr.com.br/privkey.pem
This certificate expires on 2024-11-21.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.
Registro DNS para servidores de e-mail
Alguns registros DNS utilizados para a configuração e segurança de servidores de e-mail são cadastrados usando o tipo de registro TXT (Text Record). Esses registros são: SPF, DKIM, DMARC, DANE e ADSP. Por outro lado, registros como TLSA e MX não utilizam o formato TXT.
MX - Mail Exchangers
O registro MX define os servidores de e-mail para um domínio ou zona. Para configurar um registro MX temos que ter o seguinte:
| sintaxe | Descrição |
|---|---|
| name | Define o nome do domínio que terá o RR MX. |
| rr | É o RR em sí, nesse caso recebe MX. |
| preference | Define a prioridade do servidor de email, quanto menor um número mais priorizado será aquele servidor de email (significa que sempre será usado o com menor número), os outros caso tenha mais de um, só serão usados caso o mais prioritário não responda. |
| name | É o nome do host que será o servidor de email, se estive em branco significa que o domínio será o servidor de email. |
Vejamos um exemplo de como poderia ser configurado no Bind.
exemplo.com.br IN MX 10 exemplo.com.br.
A configuração acima informa que:
exemplo.com.br - É o nome do domínio.MX - É o RR em sí.
10 - É a prioridade.
mail.exemplo.com.br - É o servidor de email.
Uma outra técnica muito usada para esse tipo de registro é o Fail-Over. O Failover ou Fail-Over é um conceito que se refere à capacidade de um sistema alternar automaticamente para uma instância ou recurso de backup quando ocorre uma falha em uma instância principal. É uma estratégia utilizada para garantir a disponibilidade e a continuidade dos serviços sem interrupções.
Nesse nosso caso é para garantir que mais de um servidor de email esteja disponível usando o DNS. Vale ressaltar que para funcionar de acordo ambos os servidores de email (principal e backup) devem ser configurados de forma correta. Um exemplo de configuração seria:
; Configurando servidores de email:
IN MX 10 mx.exemplo.com.br
IN MX 20 mx1.exemplo.com.br
mx IN A 192.168.0.4
mx1 IN A 192.168.0.5
Se o servidor de e-mail principal (aquele com o menor número no campo preference) não estiver disponível, o e-mail será enviado para o segundo servidor, no caso o de backup, aquele com o próximo número mais alto em preference, que no nosso caso é 20. Caso os número em preference sejam o mesmos não será criado um sistema de instância principal e secundária (backup), será criado um sistema de balanceamento, onde cada servidor de email vai receber o email por vez, primeiro um servidor recebe, no próximo email ele será enviado para o outro servidor e assim por diante (isso requer que os servidores de email sejam configurados de acordo).
PTR
O registro Pointer (também conhecido apenas como PTR) é usado apenas para zonas de mapeamento reverso, ou seja, mapeia endereços IP para nome de domínio. Para configurar um registro PTR temos que ter o seguinte:
TXT
O registro TXT tem sido historicamente utilizado para definir um texto genérico a ser associado a um nome. O texto em questão pode ser qualquer coisa que o usuário deseje. Esse tipo de registro teve um papel importante no desenvolvimento de iniciativas antispam, como o Sender Policy Framework (SPF), DMARC e DKIM. Essas iniciativas utilizam o registro TXT para transportar informações que auxiliam na validação do remetente, ajudando a prevenir o envio de Spams.
Quanto mais registros TXT forem adicionados ao apex da zona, maior será o tamanho da resposta TXT. Essa expansão pode levar a respostas que ultrapassam o limite de 512 bytes UDP, o que pode representar um desafio para os clientes que não suportam EDNS0. Como resultado, pode ser necessário recorrer à comunicação TCP, o que aumenta a carga na rede e pode potencialmente causar indisponibilidade para esses clientes.
Em resumo, os pacotes DNS têm um limite de tamanho, comumente 512 bytes, para garantir que possam ser reconstituídos caso sejam fragmentados durante a transmissão. Isso é especialmente relevante em redes onde a fragmentação de pacotes pode ocorrer.
Com o uso do TCP no DNS, o tamanho do payloads pode ficar muito maior. O TCP entra em cena para transferências de zona e uso do DNSSEC. Porém, há muito mais latência quando o TCP está em uso, ao contrário do UDP, há um handshake entre o cliente e o servidor antes que qualquer dado comece a fluir. Para mais detalhes reveja Conceitos de DNS Parte 1 - O protocolo dns e para ainda mais detalhes, veja a documentação oficial.
TLSA
O registro TLSA (Transport Layer Security Authentication) é usado para fornecer informações de autenticação e validação de certificados TLS/SSL (Transport Layer Security/Secure Sockets Layer). Esse registro permite que os administradores de domínio especifiquem como os clientes devem validar os certificados de um servidor contendo TLS/SSL.
Abaixo vemos a sintaxe do TLSA:
port.prot.name ttl class rr usage selector matching-type certificate
| sintaxe | Descrição |
|---|---|
| port | A porta na qual o serviço está sendo fornecido. |
| prot | O protocolo utilizado pelo serviço (por exemplo, TCP, UDP). |
| name | O nome de domínio onde o serviço está sendo fornecido. |
| usage | Especifica como o certificado deve ser usado. |
| selector | Determina como o certificado é identificado no registro TLSA. |
| matching-type | Especifica como o certificado fornecido no registro TLSA deve corresponder ao certificado apresentado pelo servidor. |
| certificate | Contém os dados relevantes para autenticar o certificado do servidor. |
Abaixo podemos ver os valores possíveis de configuração para usage:
| Opções de Usage | Descrição |
|---|---|
| 0 | Especifica um certificado CA ou chave pública que deve ser encontrado nos caminhos de certificação PKIX para o certificado de entidade final do servidor. Propósito: Restringe quais CAs podem emitir certificados para um serviço em um host. Requisitos: O certificado apresentado deve passar pela validação do caminho de certificação PKIX e um certificado CA correspondente ao registro TLSA deve ser incluído no caminho de certificação válido. |
| 1 | Especifica um certificado de entidade final ou chave pública que deve corresponder ao certificado de entidade final fornecido pelo servidor. Propósito: Limita qual certificado de entidade final pode ser usado por um determinado serviço em um host. Requisitos: O certificado de destino deve passar pela validação do caminho de certificação PKIX e deve corresponder ao registro TLSA. |
| 2 | Especifica um certificado ou chave pública que deve ser usado como âncora de confiança ao validar o certificado de entidade final fornecido pelo servidor. Propósito: Permite que um administrador de domínio especifique uma nova âncora de confiança, independentemente das âncoras de confiança dos usuários. Requisitos: O certificado de destino deve passar pela validação do caminho de certificação PKIX, com qualquer certificado correspondente ao registro TLSA considerado uma âncora de confiança para essa validação do caminho de certificação. |
| 3 | Especifica um certificado ou chave pública que deve corresponder ao certificado de entidade final fornecido pelo servidor. É o mais comum atualmente. Propósito: Permite que um administrador de domínio emita certificados para um domínio sem envolver uma CA de terceiros. Requisitos: O certificado de destino deve corresponder ao registro TLSA. A validação PKIX não é testada para essa opção de uso. |
Os usos de certificados definidos neste documento se aplicam explicitamente apenas a certificados formatados em PKIX na codificação DER X.690.
Em servidores de email não devemos usar o tipo 0 e 1, também conhecidos como PKIX-TA e PKIX-EE respectivamente. Esses tipos de registros TLSA não são recomendados para servidores de email que recebem mensagens (como servidores MX). Isso se deve a preocupações com compatibilidade e complexidade, já que o uso desses tipos pode introduzir dificuldades adicionais na verificação de certificados, potencialmente causando falhas na entrega de emails.
Abaixo podemos ver os valores possíveis de configuração para selector:
| Opções de Selector | Descrição |
|---|---|
| 0 | O certificado é fornecido diretamente no registro TLSA. |
| 1 | Um hash da chave pública do certificado é fornecido no registro TLSA. |
Abaixo podemos ver os valores possíveis de configuração para matching-type:
| Opções de Matching Type | Descrição |
|---|---|
| 0 | Toda a informação selecionada está presente nos dados de associação do certificado. |
| 1 | Um hash SHA-256 do certificado será usado. |
| 2 | Um hash SHA-512 do certificado será usado. |
Exemplo de uso:
$ORIGIN exemplo.com.br.
_25._tcp.mail IN TLSA (3 1 1 8acf61b0fc1430213ea4cce35fe135b1594bdcfb0c79e8135b7558d739bfd800)
_443._tcp.www IN TLSA (3 1 1 8acf61b0fc1430213ea4cce35fe135b1594bdcfb0c79e8135b7558d739bfd800)
Para obter o hash do certificado, o mais correto é usar o script chaingen, esse script foi criado por Viktor Dukhovni. Para mais detalhes veja aqui.
Quem é Viktor Dukhovni?
O TLSA é descrito na RFC 6698.
Podemos testar o TLSA com o seguinte comando:
# O TLSA para o servidor de email ou para o servidor Web deve corresponder ao FQDN do servidor e não do domínio:
$ dig +dnssec +multi _25._tcp.mail.exemplo.com.br. TLSA
$ dig +dnssec +multi _443._tcp.www.exemplo.com.br. TLSA
SPF - Sender Policy Framework
O SPF é uma tecnologia utilizada no âmbito de servidores de e-mail que usa o DNS para combater a falsificação de endereços de retorno dos emails (return-path), ou seja, evita que outros domínios enviem emails não autorizados em nome de um outro domínio, basicamente evita o spoofing de e-mails (em outras palavras, evita spam). O SPF permite que os servidores de e-mail verifiquem se um determinado servidor tem permissão para enviar e-mails em nome de um domínio específico.
Funcionamento básico do SPF:
Um administrador de domínio define uma política SPF em seus registros DNS. Essa política especifica quais servidores de e-mail têm permissão para enviar e-mails em nome desse domínio.
Quando um servidor de e-mail de destino recebe uma mensagem de e-mail, ele verifica o SPF do domínio do remetente consultando os registros DNS desse domínio.
O servidor de e-mail de destino verifica se o servidor que enviou o e-mail está incluído na lista de servidores autorizados definida pelo SPF.
Com base na resposta do SPF, o servidor de e-mail de destino pode tomar diferentes ações. Se o servidor estiver autorizado, o e-mail será entregue normalmente. Caso contrário, ele pode ser marcado como spam ou até mesmo rejeitado.
Como foi dito, um domínio pode ou não autorizar que outros IP fora dele enviem e-mails em seu nome. O administrador configura esta relação na entrada TXT da zona de DNS seguindo as regras da RFC 4408. A entrada SPF pode ter 4 atributos diferentes que alteram o modo como o servidor de destino tratará mensagens enviadas de servidores que não estejam presentes na mesma.
O registro SPF possui a seguinte sintaxe:
v=versao Mecanismo_emissor Modificador-e-Mecanismo_basico
# Exemplo:
v=spf1 mx -all
Definições de Mecanismo
Como descrito na RFC 7208 existem dois tipos de mecanismos: Mecanismos de estrutura de linguagem básica e Mecanismos de remetente designado. Os Mecanismos básicos contribuem para a estrutura da linguagem e não especificam um tipo específico de esquema de autorização. Os mecanismos básicos são: all e include.
| Mecanismo básico | Descrição |
|---|---|
| all | O mecanismo all é usado como uma declaração final sobre como tratar as regras de autenticação SPF. Ele é colocado no lado mais a direita de um registro SPF e significa que sempre corresponde. Qualquer mecanismo colocado após o all nunca será testado. Exemplo: v=spf1 a mx -all. |
| include | O mecanismo include é utilizado no registro SPF para incluir as regras de autenticação SPF de outro domínio. Ele permite que você faça referência às configurações de autenticação SPF de um domínio específico e as aplique ao seu próprio domínio. Exemplo: v=spf1 include:exemplo.com -all.Ao permanecer dentro de uma autoridade administrativa, include geralmente não é a melhor escolha. Por exemplo, se exemplo.com.br e exemplo.org fossem gerenciados pela mesma entidade e se o conjunto permitido de hosts para ambos os domínios fosse mx:exemplo.com.br, seria possível para exemplo.org especificar include:exemplo.com.br, mas seria preferível especificar redirect=exemplo.com.br ou mesmo mx:exemplo.com.br.O modificador redirect é mais adequado para consolidar autorizações e políticas em um conjunto comum a ser compartilhado em um ADMD. O redirecionamento é muito mais como um elemento de código comum a ser compartilhado entre registros em um único ADMD. É possível controlar os hosts autorizados e a política para um número arbitrário de domínios a partir de um único registro. |
Já os Mecanismos de remetentes designados são usados para identificar um conjunto de endereços IP como tendo ou não permissão para usar o domínio para enviar e-mail. Os mecanismos emissores designados são os seguintes: a, mx, ptr (do not use), ip4, ip6 e exists.
| Mecanismo emissor | Descrição |
|---|---|
| a | É utilizado para verificar se um determinado endereço IP está incluído nos registros de endereço IP do nome de destino. Isso significa que o mecanismo a também considera registros AAAA, que são registros de endereço IPv6. Nesse caso, é feita uma busca de endereço usando o nome de destino usando o tipo de busca apropriado (A para IPv4 ou AAAA para IPv6) com base no tipo de conexão. O endereço IP resultante é comparado com o endereço IP fornecido. Se houver qualquer correspondência de endereço, o mecanismo a é considerado uma correspondência. |
| mx | O mecanismo mx é utilizado para verificar se um determinado endereço IP é um dos servidores MX (Mail Exchanger) de um nome de domínio especificado. Para verificar se um endereço IP está entre os servidores MX de um domínio, é realizado um processo de verificação. Primeiro, é feita uma busca de MX (Mail Exchanger) no nome de destino. Em seguida, é feita uma busca de endereço (address lookup) para cada nome de servidor MX retornado. O endereço IP fornecido é comparado com cada endereço IP retornado. Se o limite de busca de MX for excedido, será retornado um resultado "permerror" e a avaliação será encerrada. Se houver qualquer correspondência de endereço IP, o mecanismo "mx" é considerado uma correspondência. É importante observar que, se o nome de destino não tiver um registro MX, a função check_host() não deve aplicar as regras implícitas de MX descritas no RFC 5321, que envolvem a busca de registros A ou AAAA para o mesmo nome. |
| ptr (do not use) | Esse mecanismo testa se o mapeamento reverso de DNS para IP existe e aponta corretamente para um nome de domínio dentro de um domínio específico. Este mecanismo NÃO DEVE ser publicado. |
| ip4 e ip6 | Os mecanismos ip4 e ip6 no SPF são utilizados para testar se um determinado endereço IP está contido em uma determinada rede IP.No mecanismo ip4, é especificada uma rede IPv4 juntamente com um comprimento de prefixo CIDR opcional. O comprimento de prefixo CIDR indica quantos bits do endereço IP devem corresponder para que o mecanismo seja considerado uma correspondência. Se o comprimento de prefixo CIDR não for especificado, ele será assumido como /32.No mecanismo ip6, é especificada uma rede IPv6 juntamente com um comprimento de prefixo CIDR opcional. O comprimento de prefixo CIDR indica quantos bits do endereço IP devem corresponder para que o mecanismo seja considerado uma correspondência. Se o comprimento de prefixo CIDR não for especificado, ele será assumido como /128.O endereço IP fornecido é comparado à rede especificada. Se os bits de alta ordem do comprimento de prefixo CIDR corresponderem, o mecanismo será considerado uma correspondência. |
| exists | O mecanismo exists é utilizado para construir um nome de domínio arbitrário que é consultado no DNS. Ele permite esquemas complexos para determinar a permissão com base em partes específicas do envelope do e-mail. É útil para tomar decisões detalhadas com base no usuário e no endereço IP do cliente. |
Modificadores
No contexto do SPF os Modificadores são elementos adicionais que podem ser usados para alterar o resultado da avaliação de uma política SPF. Eles são usados para adicionar funcionalidades específicas ou personalizar o comportamento da política SPF.
Existem vários modificadores disponíveis no SPF, incluindo:
| Modificador | Descrição |
|---|---|
| redirect | É usado para redirecionar a consulta SPF para outro domínio. Ele permite consolidar autorizações e políticas em um conjunto comum compartilhado dentro de um único domínio. |
| exp | O modificador "exp" fornece uma explicação em caso de falha de autenticação SPF. Quando ocorre uma falha de autenticação, o modificador "exp" permite que o domínio forneça uma mensagem personalizada explicando o motivo da falha. |
| + (Pass) | Significa que o IP está autorizado a enviar mensagens em nome do domínio, sendo que o domínio consultado pode então ser considerado responsável pelo envio da mensagem. É o valor padrão, pode ser omitido. |
| – (Fail) | Significa explicitamente que o IP não está autorizado a enviar mensagens em nome do domínio consultado. Este resultado pode ser utilizado para rejeitar a mensagem. |
| ~ (SoftFail) | Deve ser tratado como um resultado intermediário entre os níveis fail e neutral. Neste caso, o domínio consultado informa que acha que o IP não está autorizado, mas que não pode fazer uma afirmação exata. A mensagem não deve ser rejeitada apenas com base neste resultado, mas é recomendável submetê-la a outros testes. |
| ? (Neutral) | O dono do domínio não tem como ou não quer definir se um determinado endereço IP está ou não autorizado a enviar mensagens em nome do domínio. Este resultado deve ser tratado exatamente como se não existisse um registro SPF. |
Exemplo de uso:
$ORIGIN exemplo.com.br.
IN TXT "v=spf1 a mx ip4:192.0.2.32/27 -all"
IN TXT "v=spf1 a mx -all"
IN TXT "v=spf1 mx -all"
Nos exemplos acima, estabelecemos quem pode enviar mensagens em nome do domínio exemplo.com.br:
v=spf1 a mx ip4:192.0.2.32/27 -all
O endereço IP deve ser um RR tipo A ou MX do domínio exemplo.com.br ou deve pertencer ao bloco de endereços IP 192.0.2.32/27.v=spf1 a mx -all
O endereço IP deve ser um RR tipo A ou MX do domínio exemplo.com.br. Usado quando temos apenas um ou dois servidores de e-mail.v=spf1 mx -all
O endereço IP deve ser um RR tipo MX do domínio exemplo.com.br. Usado quando temos apenas um servidor de e-mail.
Outros dois exemplos interessantes para se analisar são:
v=spf1 a:clone.registro.br a:fe.registro.br a:mailx.registro.br -all
Encontrado no domínio registro.br. Para enviar e-mails em nome do domínio registro.br o endereço IP deve ser um RR tipo A para o subdomínio clone.registro.br (a:clone.registro.br) ou um RR tipo A para o subdomínio fe.registro.br (a:fe.registro.br) ou um RR tipo A para o subdomínio mailx.registro.br (a:mailx.registro.br).v=spf1 include:_spf.google.com ~all
Encontrado no domínio google.com. O include indica que está sendo incluído um mecanismo de autenticação SPF de outro domínio. Nesse caso, o domínio incluído é_spf.google.com. Isso significa que as regras de autenticação SPF definidas pelo Google serão aplicadas.~allindica uma "soft fail" ou seja, se a autenticação SPF falhar (o servidor de e-mail não corresponder às regras definidas), o e-mail não será imediatamente rejeitado, em vez disso, ele será aceito, mas pode ser marcado como suspeito ou tratado de forma diferente pelo servidor de e-mail de destino.v=spf1 -all
Deve ser usado para qualquer domínio que não tenha intenção de enviar e-mails, essa configuração é feita para evitar que e-mails falsos usando este domínio circulem na Internet para os outros domínio de forma ilegítima.v=spf1 exists:%(d) -all ext=spfblock.exemplo.com.br
Essa configuração indica que o servidor de email deve verificar se o domínio atual possui registros DNS válidos (exists:%(d)). Se não houver registros válidos ou se o servidor de envio não estiver autorizado, o email será rejeitado (-all). A extensãospfblock.exemplo.com.bré aplicada (ext=spfblock.exemplo.com.br), mas sua função exata precisa ser definida pela implementação específica do domínio "exemplo.com.br", ou seja, precisa ser definida em outro registro, como podemos ver abaixo:
spfblock IN TXT "O email de %{s} usando o servidor SMTP em %{I} foi rejeitado por %{c} (%{r}) em %{t} \
porque falhou na verificacao de registros SPF para o dominio %{p}.
O contra-barra é usado para quebrar linhas na definição do TXT.
%{s}= Substituir pelo endereço de e-mail do remetente.
%{I}= O IP do remetente.
%{c}= O IP do MTA receptor.
%{r}= O nome do host, normalmente o mesmo que o MTA receptor.
%{t}= Define o timestamp atual.
%{p}= O nome de domínio validado.%{d}= É o domínio do remetente, conforme especificado no endereço de e-mail.%{h}= É o nome do host (domínio) no endereço do remetente.%{l}= É o nome local (a parte anterior ao "@" no endereço de e-mail) do remetente.%{o}= Substituído pela versão do protocolo SMTP usado para enviar o e-mail (por exemplo, "smtp" ou "esmtp").%{v}= Substituído pelo valor da versão SPF que está sendo usado (por exemplo, "spf1").
A cláusula -all informa que devem ser recusados (O - é prefixo de Fail) e-mails partindo de qualquer outro endereço IP (all).
Considerações
Usar a ao invés de ip4 ou ip6 permite que os hosts sejam renumerados facilmente ao custo de uma consulta de DNS por receptor, ou seja, o RR A pode apontar para qualquer endereço IP sem ter que alterar o registro SPF. Usar mx sobre a permite que o conjunto de hosts de e-mail seja alterado facilmente, ou seja, podemos modificar apenas o RR MX sem alterar o RR A. Mas só devemos criar registros SPF com A ou MX se tais alterações forem comuns, se não forem é melhor usar os mecanismos que consomem menos recursos, como ip4 e ip6 ao invés de a ou mx.
A publicação de registros SPF para domínios que não enviam e-mails é uma prática recomendada bem estabelecida. O registro de um domínio que não envia e-mail é:
$ORIGIN exemplo.com.br
www IN TXT "v=spf1 -all"
O registro SPF acima indica que nenhum servidor de e-mail está autorizado a enviar e-mails em nome do subdomínio
www.exemplo.com.br(indica isso porque não temAnemMX). O modificador-allindica que qualquer tentativa de envio de e-mail usando esse subdomínio deve ser considerada não autorizada.
O registro SPF padrão para um host individual envolvido no processamento de e-mails é:
$ORIGIN exemplo.com.br
relay IN TXT "v=spf1 a -all"
O registro SPF acima indica que apenas o endereço IP (RR A) do host
relay.exemplo.com.brestá autorizado a enviar e-mails em nome do domínio exemplo.com.br. Cuidado, se não for especificado o nome do host (relayno nosso exemplo) a diretivaano registro SPF especifica que o endereço IP do servidor atual do domínio (Similar aexemplo.com.br. IN A 192.168.0.10) está autorizado a enviar e-mails em nome do domínio.
$ORIGIN exemplo.com.br
IN TXT "v=spf1 a -all"
Como não há um nome de host específico no registro acima, o registro SPF se aplica diretamente ao domínio exemplo.com.br como um todo, sem restrição a um host específico. Nesse caso, qualquer endereço IP (RR A) associado ao domínio exemplo.com.br está autorizado a enviar e-mails em seu nome.
$ORIGIN exemplo.com.br
IN TXT "v=spf1 mx -all"
Isso indica que apenas os servidores de e-mail listados nos registros MX (RR mx) do domínio exemplo.com.br estão autorizados a enviar e-mails em nome desse domínio.
Além disso, podemos minimizar os recursos necessários para busca de SPF usando diretivas que requerem menos informação DNS colocando mecanismos de baixo custo no início do registro SPF. Por exemplo, considere um domínio configurado como abaixo:
exemplo.com.br. IN MX 10 mx.exemplo.com.br.
IN MX 20 mx2.exemplo.com.br.
mx.exemplo.com.br. IN A 192.0.2.1
mx2.exemplo.com.br. IN A 192.0.2.129
O Melhor registro SPF se da pela configuração abaixo:
exemplo.com.br. IN TXT "v=spf1 ip4:192.0.2.1 ip4:192.0.2.129 -all"
Essa configuração é eficiente porque não requer consultas adicionais ao servidor DNS para determinar quais hosts são permitidos.
Um bom registro
$ORIGIN exemplo.com.br.
@ IN TXT "v=spf1 a:authorized-spf.exemplo.com.br -all"
authorized-spf IN A 192.0.2.1
IN A 192.0.2.129
Essa configuração permite um controle mais granular sobre quais hosts estão autorizados a enviar e-mails e associa explicitamente os endereços IP autorizados ao host
authorized-spf.exemplo.com.br. Essa verificação requer apenas uma consulta DNS adicional para obter o endereço IP. Uma vez que o endereço IP é obtido, não são necessárias consultas adicionais para verificar a autorização SPF.
Registro caro
exemplo.com.br. IN TXT "v=spf1 mx:exemplo.com.br -all"
Essa configuração especifica que apenas servidores
mxdo domínioexemplo.com.br(mx:exemplo.com.br) podem enviar emails em nome do domínioexemplo.com.br.
Podemos consultar o campo TXT com o seguinte comando:
$ dig txt exemplo.com.br +short
"v=spf1 mx -all"
Existe um mecanismo completo para a verificação SPF que podemos usar diretamente no Postfix, ele se chama postfix-policyd-spf. Este daemon inclui uma variedade de mecanismos e opções de política para atender a uma ampla gama de requisitos do sistema. O postfix-policyd-spf-perl foi implementado em Perl, enquanto o postfix-policyd-spf-python está disponível em Python, utilizando o módulo SPF (spf). Como um módulo do Postfix, ele é compatível com o RFC 7208, que define o Sender Policy Framework (SPF). Informações adicionais são armazenadas no DNS na forma de um registro SPF.
O postfix-policyd-spf oferece uma implementação mais avançada da verificação SPF, garantindo uma análise mais precisa e confiável do que simplesmente depender da configuração de SPF do DNS. Ele pode lidar melhor com casos de falsos positivos e negativos. Podemos definir políticas específicas para como o SPF deve ser aplicado, como rejeitar e-mails de servidores não autorizados, aceitar ou rejeitar mensagens com base em regras adicionais, e muito mais.
Instale o pacote:
$ sudo apt install postfix-policyd-spf-python
Agora configure o master.cf como abaixo. Essa configuração vai integrar o serviço de verificação SPF com o Postfix.
policyd-spf unix - n n - - spawn
user=nobody argv=/usr/bin/policyd-spf
policyd-spf: Define o nome do serviço que será usado pelo Postfix. unix: Indica que o serviço será executado como um serviço UNIX. -: Os campos separados por hífens (-) são opções que são deixadas como padrão, não precisam de modificações. n: Não permite que o serviço seja iniciado em paralelo. spawn: Especifica que o serviço será iniciado por um processo pai. user=nobody: Define o usuário sobre o qual o serviço será executado. É uma prática comum executar serviços com privilégios mínimos para melhorar a segurança. argv=/usr/bin/policyd-spf: Especifica o caminho para o executável policyd-spf.
Agora no main.cf deixe como está abaixo, depois reinicie o Postfix.
policyd-spf_time_limit = 3600s
smtpd_recipient_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_unauth_destination
reject_non_fqdn_recipient
reject_unknown_recipient_domain
reject_unauth_pipelining
reject_unverified_recipient
check_policy_service unix:private/policy-spf
A configuração policyd-spf_time_limit = 3600s define o tempo máximo, em segundos, que o servidor de email esperará por uma resposta dos servidores DNS durante a verificação SPF. Já check_policy_service unix:private/policy-spf indica que o Postfix deve consultar um serviço de política externo para determinar se uma mensagem deve ser aceita ou rejeitada.
Na próxima vez que você receber um email de um domínio com um registro SPF no DNS. Você pode ver os resultados da verificação SPF no cabeçalho do e-mail RAW. O cabeçalho a seguir indica que o remetente enviou o e-mail de um host autorizado.
policyd-spf[733750]: prepend Received-SPF: Pass
DKIM - DomainKeys Identified Mail
O DKIM (DomainKeys Identified Mail) é um método de autenticação de e-mails que utiliza criptografia assimétrica (também conhecida como chave pública) para adicionar uma assinatura digital ao cabeçalho de cada e-mail enviado. Essa assinatura é gerada pelo servidor de envio com uma chave privada exclusiva para o domínio do remetente, enquanto a chave pública correspondente é publicada nos registros DNS do domínio.
Uma consulta DNS é usada para ler o registro DKIM TXT, que contém, entre outros campos, uma chave pública no domínio construído. A chave pública obtida é então usada para validar tanto a integridade da assinatura do DKIM quanto autenticar o remetente de e-mail. As chaves públicas usadas na verificação da assinatura (que são armazenadas em registros DKIM TXT) são geradas pelo administrador do servidor de email, as chaves podem ser geradas usando o OpenSSL. O OpenDKIM é outra ferramenta utilizada para gerar as chaves e configurações para o DKIM e funciona por meio da interface milter. Ainda é possível utilizar o DKIM diretamente do rspamd.
Além de um registro DKIM TXT, as especificações DKIM permitem que o proprietário do domínio defina um registro ADSP TXT (Author Domain Signing Policies), que fornece essencialmente orientações ao receptor de e-mail sobre o que fazer se um item de e-mail não estiver assinado.
Selectors
É um nome qualquer usado para identificar diferentes chaves públicas, já que várias chaves públicas podem ser usadas. Por exemplo, os selectors podem ser nomes (por exemplo, "saopaulo", "teste" e "producao"), mas o mais comum seria usar uma data (por exemplo, "20230217").
Subdomínio _domainkey
Em sistemas DKIM, as chaves DKIM são geralmente armazenadas em um subdomínio especial chamado _domainkey. Vamos usar o domínio de exemplo exemplo.com.br e o seletor 20230217 como exemplo. Quando um cabeçalho de email contém um campo DKIM-Signature, a tag d= indica o domínio do remetente, que, no nosso caso, é exemplo.com.br. A tag s= indica o seletor, que identifica a chave pública DKIM específica relacionada a esse domínio. No exemplo, o seletor é 20230217.
Para encontrar a chave pública DKIM correta, é necessário fazer uma consulta DNS específica. Essa consulta é feita concatenando o seletor (no nosso caso, 20230217) com o subdomínio especial _domainkey e o domínio do remetente (exemplo.com.br). Portanto, a consulta DNS correspondente será feita para o domínio 20230217._domainkey.exemplo.com.br. Nesse domínio específico, espera-se encontrar o registro DNS contendo a chave pública DKIM necessária para verificar a autenticidade do email.
DKIM Specific Text
O DKIM possui alguns tipos de dados específicos na formatação do TXT RR, vamos entender melhor como são e como funcionam.
| Opções | Descrição |
|---|---|
| v=(versão) | É opcional. Define o número da versão DKIM e só pode usar o valor padrão DKIM1. É uma boa prática incluí-lo. |
| g=(granularidade) | É opcional. Define a parte do usuário (local) do endereço de e-mail (tudo à esquerda do @) ao qual este DKIM TXT RR se aplica.O padrão é g=* (todos os endereços de usuários). Este valor, após qualquer processamento curinga, deve corresponder exatamente ao endereço na parte From: do usuário (local) do cabeçalho. |
| h=(hash do algoritmo) | É opcional. Define um ou mais algoritmos de hash separados por dois pontos (:) que serão usados com a finalidade de criar assinaturas digitais (em conjunto com k=) abrangendo um ou ambos os cabeçalhos de correio definidos ou o corpo do correio (incluindo, opcionalmente, anexos MIME).Os valores permitidos são do conjunto sha1 e sha256, sendo sha1 não recomendado para uso. O padrão é h=* (significa qualquer). Exemplo de uso: h=sha1:sha256;, h=sha256; ou h=*; |
| k=(algoritmo de chave) | É opcional. Define o algoritmo de chave pública que está sendo usado. O padrão é k=rsa. Como rsa é o único algoritmo atualmente suportado, ele pode ser omitido com segurança. |
| n=(anotações) | É opcional. Define o texto legível por humanos. |
| p=(chave pública) | É obrigatório. Define a chave pública (no formato base64) para o algoritmo definido pela tag k=. Os dados para a chave pública podem ser criados pelo OpenSSL. |
| s=(tipo de serviço) | É opcional. Define o tipo de serviço ao qual o DKIM é aplicado. Neste momento, o único valor válido é email. O padrão é s=*. |
| t=(flags) | É opcional. O padrão é nenhum sinalizador definido. Duas bandeiras estão definidas atualmente: y: Indica o modo de teste. Se definido, gera mensagens de diagnóstico adicionais do receptor de validação, mas ainda permite que o validador trate o e-mail normalmente. s: Se definido, esse sinalizador indica que essa chave não é válida para subdomínios do nome de domínio. Se os subdomínios nunca forem usados em endereços de e-mail de domínio, esse sinalizador deve ser definido como uma proteção adicional. |
O DKIM usa o TXT RR para passar as informações corretas ao servidores de e-mail. Essa parte de texto pode conter vários campos como tag=value separados por ponto e vírgula (;). Pode haver um ou mais DKIM TXT RRs para qualquer domínio. O formato do TXT e DKIM TXT RR, definido pela RFC 4817 e 5672, é:
selector._domainkey.domain-name. ttl class rr DKIM-specific-text
| sintaxe | Descrição |
|---|---|
| selector | Nome do selector. |
| _domainkey | Subdomínio especial chamado _domainkey. |
| domain-name | O nome de domínio onde o serviço está sendo fornecido. Deve ficar em branco ou receber um nome de domínio para configurar o DKIM para um subdomínio. |
| ttl | É o valor de TTL configurado apenas para esse RR. |
| class | IN significa que a classe é Internet. |
| rr | É o RR em sí, nesse caso é TXT. |
| DKIM-specific-text | É o texto fornecido no formado específico do DKIM. |
Exemplo de uso:
$ORIGIN exemplo.com.br.
20230217._domainkey IN TXT ( "v=DKIM1; k=rsa; "
"p=MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAmzMcpQnEJkasvTPYXc3NEGwX9v1NNwPDE0VdRvv4CGsRdXBIBThr5eEcxGm7TwxNBXciIMGFIf0ZQK/3pnNZ6yKyssiNK7rIehxZD4zFoRljY37oFqvTG8T6ZvhT21gQqaFMatRlnCVATph9a2WF8/NhxHiZaF/jTOulzo0cjroDx+jyrBtmb5qBeTEaWT/aD+89bb3RXpWpCk"
"6/yNLbw6TGBz9gqtuL0RWHBJzDLuBHMFbRsRkQxxOoxZ6uEIvIeEEhdKZuu2zm+CY4bk5uoddTu+ikA7dCgksudvB4SEOcnqvYwsXbVf1bXGsGCdQIaBWd7a1KoihoUfdhLsLb6YfGA+O0bZo2msumS+u8hNrnirLEa+YZ2LUJ0/69wygm5Iixe6pN0uCe5XCaNIz248hSjZ7IN88Lw3S0VSHnEQvQAq1wjYMWqfXUuFrdKra29npY4Qdv"
"lcyv1IrDfX+yd6LrhmdPiEJvJu50NeSu6aXlCn1kRb6oVWic7hMmnjpTd05cT6CGAZGCGAEB9oOESP5x8Yu2zxxD1I7oRDNSfyQ0mASIWHOvln36dPRolw1xG3IX0X2DC/k4QCuCof6pDjrmX2kKUIuvYcVaea/HM9maP78xNesacxuEI5F6WyNGt3sgRsKBMDZfaz7kajDhBTThF14ErE3dFHIvSoiQ1JECAwEAAQ==" ) ; ----- DKIM key 20230217 for exemplo.com.br
Agora para colocar no servidor DNS, você deve colocar tudo numa única linha e não coloque aspas ", exemplo caso use o site registro.br:
20230217._domainkey IN TXT v=DKIM1; k=rsa; p=MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAmzMcpQnEJkasvTPYXc3NEGwX9v1NNwPDE0VdRvv4CGsRdXBIBThr5eEcxGm7TwxNBXciIMGFIf0ZQK/3pnNZ6yKyssiNK7rIehxZD4zFoRljY37oFqvTG8T6ZvhT21gQqaFMatRlnCVATph9a2WF8/NhxHiZaF/jTOulzo0cjroDx+jyrBtmb5qBeTEaWT/aD+89bb3RXpWpCk6/yNLbw6TGBz9gqtuL0RWHBJzDLuBHMFbRsRkQxxOoxZ6uEIvIeEEhdKZuu2zm+CY4bk5uoddTu+ikA7dCgksudvB4SEOcnqvYwsXbVf1bXGsGCdQIaBWd7a1KoihoUfdhLsLb6YfGA+O0bZo2msumS+u8hNrnirLEa+YZ2LUJ0/69wygm5Iixe6pN0uCe5XCaNIz248hSjZ7IN88Lw3S0VSHnEQvQAq1wjYMWqfXUuFrdKra29npY4Qdvlcyv1IrDfX+yd6LrhmdPiEJvJu50NeSu6aXlCn1kRb6oVWic7hMmnjpTd05cT6CGAZGCGAEB9oOESP5x8Yu2zxxD1I7oRDNSfyQ0mASIWHOvln36dPRolw1xG3IX0X2DC/k4QCuCof6pDjrmX2kKUIuvYcVaea/HM9maP78xNesacxuEI5F6WyNGt3sgRsKBMDZfaz7kajDhBTThF14ErE3dFHIvSoiQ1JECAwEAAQ==
Para criar a chave privada usando o comando openssl com tamanho de 1024 bits, use o comando abaixo:
$ openssl genrsa -out dkim.private 1024
Agora vamos extrair a chave pública no formato PEM:
$ openssl rsa -in dkim.private -out dkim.public -pubout -outform PEM
$ cat dkim.public
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM
oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R
tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI
MmPSPDdQPNUYckcQ2QIDAQAB
-----END PUBLIC KEY-----
Podemos configurar no DNS da seguinte forma:
# Formato de uma única linha:
selector._domainkey IN TXT "v=DKIM1;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkMoGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/RtdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToIMmPSPDdQPNUYckcQ2QIDAQAB"
# Formato de várias linhas:
selector._domainkey IN TXT ("v=DKIM1;k=rsa;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwIRP/UC3SBsEmGqZ9ZJW3/DkM"
"oGeLnQg1fWn7/zYtIxN2SnFCjxOCKG9v3b4jYfcTNh5ijSsq631uBItLa7od+v/R"
"tdC2UzJ1lWT947qR+Rcac2gbto/NMqJ0fzfVjH4OuKhitdY9tf6mcwGjaNBcWToI"
"MmPSPDdQPNUYckcQ2QIDAQAB")
ADSP - Author Domain Signing Practices
O ADSP usa o TXT RR para permitir que um domínio indique suas políticas de assinatura de e-mail. O ADSP TXT RR é opcional, mas as políticas de ADSP podem ser usadas para ajudar um MTA de recebimento de validação a determinar como lidar com correspondência que não está assinada.
Existem três políticas possíveis definidas pelo ADSP.
| Política | Descrição |
|---|---|
| none | Indica que o domínio não possui uma política de assinatura específica. |
| unknown | O endereço de email do domínio pode ou não assinar todos os emails. Usado para testes. |
| discardable | Indica que o domínio assina seus emails, mas considera as assinaturas como opcionalmente válidas. Isso significa que o domínio não rejeitará emails caso as assinaturas DKIM falhem, mas eles ainda podem ser aceitos se todas as outras verificações forem bem-sucedidas. |
| all | Indica que o domínio considera as assinaturas DKIM obrigatórias para todos os seus emails. Se um email do domínio não passar na verificação da assinatura DKIM, ele deve ser rejeitado pelo servidor de destino. |
Exemplo de uso:
$ORIGIN exemplo.com.br.
_adsp._domainkey IN TXT "dkim=all;"
DMARC - Domain-based Message Authentication, Reporting, and Conformance
O DMARC (Domain-based Message Authentication, Reporting, and Conformance) é um protocolo de validação de emails que ajuda a combater fraudes por email e phishing. Ele funciona em conjunto com dois outros protocolos de segurança de email, SPF (Sender Policy Framework) e DKIM (DomainKeys Identified Mail).
Resumindo o que cada protocolo faz:
- SPF verifica se o email foi enviado de um servidor autorizado a enviar emails pelo domínio do remetente.
- DKIM adiciona uma assinatura digital criptografada ao email, garantindo que o conteúdo não foi alterado durante o envio.
O DMARC é um protocolo que reúne esses dois métodos e ainda define uma política para o receptor, incluindo a informação sobre falhas na autenticação por SPF ou DKIM, instruções sobre como lidar com e-mails não autenticados e a capacidade de fornecer relatórios aos administradores de e-mail sobre a atividade de envio de e-mail do domínio.
Resumindo:
- Informar se o email falhou na autenticação por SPF ou DKIM.
- Instruir o receptor sobre o que fazer com o email não autenticado (colocá-lo na spam, rejeitá-lo, etc.).
- Fornecer relatórios aos administradores de email sobre a atividade de envio de email do seu domínio, mesmo que venha de fontes não autorizadas.
Com o DMARC implementado, você tem mais controle sobre quem pode enviar emails usando o seu domínio e recebe relatórios sobre tentativas de fraude. Isso ajuda a proteger a reputação do seu domínio e dificulta que golpistas usem seu nome para enviar emails maliciosos.
Veja um exemplo de como configurar o DMARC:
_dmarc.exemplo.com.br IN TXT "v=DMARC1; p=reject; rua=mailto:postmaster@exemplo.com.br"
A política
pespecifica a ação a ser tomada com os emails que não passam na autenticação. A opçãononeé recomendada para começar, permitindo que os emails passem mesmo que não sejam autenticados.O campo
ruaespecifica um endereço de email para o qual relatórios de falhas DMARC serão enviados.
Podemos testar o DMARC com este site! ou usando o comando abaixo:
$ dig TXT _dmarc.exemplo.com.br
Antes de iniciar
Antes de começarmos é bom explicar como será a integração do Postfix com outros serviços. Por padrão vamos usar o LDAP para armazenar os dados dos usuários que terão acesso ao email, nesse caso não é uma autenticação centralizada, é apenas um local onde dados como email, nome de usuário, senha entre outros ficarão armazenados. Então quando o Dovecot for autenticar o usuário, ele deve pegar a senha que o cliente enviar e comparar com a senha cadastrada no LDAP, perceba que será o Dovecot quem verificará se as senhas estão corretas.
Como já mencionei, vamos usar o Dovecot como MDA para o nosso sistema, também vamos usar o Rspamd como serviço anti spam, como já mencionado, ele se conectará ao Postfix através do Milter. A escolha do Rspamd é simplesmente porque é muito popularidade e se destaca em relação a outros filtros anti-spam, além de que, com o Rspamd podemos fazer o uso de DKIM, o que já vai nos ajudar a não ter que configurar outro serviço para isso.
Vamos instalar um anti virus como o ClamAV para validar alguns anexos que os usuários possam acabar enviando, evitando propagação de virus. Nas próximas documentações sobre Dovecot e Rspamd vamos usar esse mesmo servidor de email, por isso vamos deixar ele já configurado para exemplificar o que vamos falar nessas documentações.
Instalando o Postfix
Para começar, vamos instalar alguns pacotes como o mailutils, além de instalar o postfix, também traz alguns pacotes adicionais como o mail. Vamos instalar o postfix-ldap que traz o suporte de mapas para LDAP no Postfix. O pacote postfix-policyd-spf-python vai fornecer uma camada a mais na validação de SPF, não é necessário, é algo mais opcional.
# Instale as aplicações do servidor de email:
$ sudo apt install mailutils postfix-ldap postfix-policyd-spf-python -y
Quando os pacotes estiverem sendo instalados, no momento da instalação do Postfix, o instalador fará algumas peguntas, segue uma explicação sobre a algumas delas:
1° - Tipo de servidor de email
Será perguntado o tipo de configuração geral para o servidor, normalmente temos 5 opções, a tabela abaixo demonstra o que significa cada uma. Não importa qual opção vamos usar nesse momento já que vamos configurar tudo do zero.
Opção Descrição No configuration Não vai ocorrer a configuração inicial. Internet Site Esse tipo é para um servidor de email que vai enviar e receber mensagens diretamente, é o tipo mais comum. Internet with smarthost Recebe mensagens normalmente, mas é outra máquina que vai enviar as mensagens, opção conhecida como relayhost.Satellite System A opção mais limitada que temos para o funcionamento do servidor de email. Envia email através de outra máquina e não recebe mensagens de emails, muito útil para monitorar servidores na rede interna que precisam enviar notificações por email. Local Only Usada apenas em redes de terminais leves, os emails são trocados entre os usuário na mesma máquina, é como um email, mas fica somente nesse máquina, não sai para a Internet.
2° - Nome de domínio
Aqui você deve inserir FQDN (fully qualified domain name), no qual é o nome do servidor juntamente com o domínio. Lembrando que esse nome não é o nome de domínio. Se for um ambiente de teste, pode apenas usar o nome da máquina, no meu caso deixarei como
mail.hermodr.com.brque é o nome do servidor de email com o FQDN.
Finalizado a instalação, já temos o servidor postfix rodando com configurações padrões.
Configuração do Postfix
Vamos começar configurando o Postifx e esclarecendo cada configuração usada. O arquivo principal que vamos trabalhar agora é o main.cf e master.cf, sendo esse último mais para o final da configuração do Postfix. Aqui, peço um pouco de paciência, caro leitor. Vamos explicar cada opção em detalhes, o que pode parecer um pouco tedioso à primeira vista. No entanto, é importante compreender o motivo de utilizarmos cada uma das configurações é fundamental para um entendimento completo do funcionamento do Postfix.
Primeiro vou fornecer a configuração em partes para poder explicar e ao final, fornecerei ela completa, já que a explicação já vai ter sido fornecida. Nessa primeira etapa temos configurações comuns que já vem com o Postfix, não vou mexer nelas:
smtpd_banner = $myhostname ESMTP $mail_name
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 3.6 on
# fresh installs.
compatibility_level = 3.6
# appending .domain is the MUA's job.
append_dot_mydomain = no
Agora vamos configurar o comportamento do Postfix quando ele for atuar como servidor SMTP, isso ocorre ao receber emails de outros servidores. Também vamos configurar o TLS na comunicações onde nosso servidor recebe email de outros servidores.
########################################################
### SMTPD TLS configuration for incoming connections ###
########################################################
smtpd_tls_cert_file=${config_directory}/certs/fullchain.pem
smtpd_tls_key_file=${config_directory}/certs/privkey.pem
smtpd_tls_security_level = may
smtpd_tls_loglevel = 1
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_protocols = >=TLSv1.2, <=TLSv1.3
smtpd_tls_mandatory_protocols = >=TLSv1.2, <=TLSv1.3
smtpd_tls_mandatory_ciphers = high
smtpd_tls_ciphers = high
smtpd_tls_exclude_ciphers = aNULL,eNULL,EXPORT,DES,RC4,MD5,PSK,aECDH,EDH-DSS-DES-CBC3-SHA,EDH-RSA-DES-CBC3-SHA,KRB5-DES,CBC3-SHA,DES-CBC3-SHA,AES128-SHA,AES256-SHA,AES128-SHA256,AES128-GCM-SHA256,AES256-SHA256,DHE-RSA-DES-CBC3-SHA,AES256-GCM-SHA384,ECDHE-ECDSA-DES-CBC3-SHA,ECDHE-RSA-DES-CBC3-SHA,CAMELLIA256-SHA256,CAMELLIA256-SHA,CAMELLIA128-SHA256,CAMELLIA128-SHA
smtpd_tls_dh1024_param_file = /etc/postfix/certs/ffdhe4096.pem
smtpd_helo_required = yes
smtpd_data_restrictions = reject_multi_recipient_bounce
smtpd_sender_restrictions = permit_mynetworks permit_sasl_authenticated reject_non_fqdn_sender reject_unknown_sender_domain
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_non_fqdn_recipient reject_unknown_recipient_domain reject_unauth_destination reject_unverified_recipient check_policy_service unix:private/policy-spf
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous
smtpd_tls_auth_only = yes
Explicação
Primeiro começamos configurando o certificado e a chave privada usada pelo servidor SMTP, para isso é usado o parâmetro smtpd_tls_cert_file para configurar o certificado e smtpd_tls_key_file para configurar a chave privada.
No segundo bloco estou habilitando o uso do TLS (smtpd_tls_security_level) nas comunicações entre nosso servidor SMTP e cliente/servidores, para deixar a comunicação mais segura (o cliente escolhe se vai usar ou nao TLS). Configuramos os níveis de logs para transações TLS de entrada, ou seja, quando o Postfix atua como servidor SMTP ao receber emails de outros servidores (smtpd_tls_loglevel), depois vamos melhora a geração de Chaves de Sessão ao habilitar um cache compartilhado para chaves TLS de entrada, ou seja, quando o Postfix atua como servidor SMTP ao receber emails de outros servidores (smtpd_tls_session_cache_database). Os parâmetros smtpd_tls_protocols e smtpd_tls_mandatory_protocols informam que o servidor SMTP somente vai aceitar o TLS na versão 1.2 e 1.3 onde Postfix atua como servidor SMTP ao receber emails de outros servidores.
No terceiro bloco estou configurando o nível de segurança das cifras que serão aceitas smtpd_tls_mandatory_ciphers (onde o TLS é obrigatório) e smtpd_tls_ciphers (onde o TLS é opcional) e excluindo cifras que não são consideradas seguras (smtpd_tls_exclude_ciphers). Também estou configurando smtpd_tls_dh1024_param_file para troca de chaves TLS entre cliente e servidor. Apesar de trabalhar com TLS obrigatório e opcional, verá que nossa configuração obriga o cliente a usar TLS. Essas configurações tem validade quando o Postfix atua como servidor SMTP ao receber emails de outros servidores.
No quarto bloco estou usando smtpd_helo_required para exigir que o cliente se apresente antes de enviar qualquer comando. O parâmetro smtpd_data_restrictions é uma configuração aplicada após o corpo da mensagem, informando que o servidor SMTP deve rejeitar as mensagens de erro de entrega (bounces) que têm mais de um destinatário. Já o parâmetro smtpd_sender_restrictions aplica restrições ao endereço do remetente, ou seja, quando o cliente vai enviar um email. Abaixo seguem as restrições usadas:
- Permite requisições quando o IP do remetente está em
mynetworks(parâmetropermit_mynetworks); - Permite emails de remetentes que tenham se autenticado com sucesso (parâmetro
permit_sasl_authenticated); - Rejeita o endereço do remetente se não for um endereço de email válido (parâmetro
reject_non_fqdn_sender); - Rejeita a solicitação quando o Postfix não é o destino final para o endereço do remetente e o domínio do remetente não possui registros DNS válidos (parâmetro
reject_unknown_sender_domain). Além de evitar que o servidor se torne um Open Relay rejeitando solicitações em que ele não é o destino final para o endereço do remetente estamos reforçando a segurança ao rejeitar emails onde o domínio do remetente não possui registros DNS válidos;
Ainda no quarto bloco é implementado uma política de restrição para o recipiente (smtpd_recipient_restrictions), que é o endereço do destinatário, as opções usadas são:
- Permite requisições quando o IP do remetente está em
mynetworks(parâmetropermit_mynetworks); - Permite emails de remetentes que tenham se autenticado com sucesso (parâmetro
permit_sasl_authenticated); - Rejeita e-mails enviados para destinatários cujo endereço de e-mail não esteja em um formato de domínio totalmente qualificado (parâmetro
reject_non_fqdn_recipient); - Rejeita e-mails enviados para destinatários cujo domínio não pode ser resolvido via DNS (parâmetro
reject_unknown_recipient_domain); - Rejeita emails para domínios que não estão listados em
mydestination,relay_domains, evirtual_alias_domains(parâmetroreject_unauth_destination); - Rejeita e-mails enviados para destinatários em que não foi possível confirmar se o endereço de e-mail do destinatário existe no sistema final (parâmetro
reject_unverified_recipient); - Verifica uma política externa para determinar se uma mensagem deve ser aceita ou rejeitada, nesse caso é a verificação de SPF (parâmetro
check_policy_service unix:private/policy-spf).
Ainda no quarto bloco é implementado uma política de restrição para o relay (smtpd_relay_restrictions), que é usado para definir as condições sob as quais o Postfix permitirá ou recusará a retransmissão (relay) de emails, ou seja, aceitar uma mensagem de um cliente e enviá-la para um servidor de email externo. As opções usadas são:
- Permite requisições quando o IP do remetente está em
mynetworks(parâmetropermit_mynetworks); - Permite emails de remetentes que tenham se autenticado com sucesso (parâmetro
permit_sasl_authenticated); - Rejeite as mesmas solicitações que reject_unauth_destination, com um código de erro não permanente (parâmetro
defer_unauth_destination);
No quinto bloco estamos desativando a autenticação anonima e em texto simples (`smtpd_sasl_security_options`) para autenticações que ocorrem sem TLS. Também estamos desativando a autenticação anonima (`smtpd_sasl_tls_security_options`) para clientes que estão autenticando com TLS, basicamente estamos deixando a autenticação somente com uso do TLS. Por fim o parâmetro `smtpd_tls_auth_only` faz com que o Postfix só anuncie e aceite autenticação SASL se a conexão estiver protegida por TLS.
Agora vamos configurar os parâmetros de autenticação do SMTPD, fazendo com que clientes possam se autenticar no nosso servidor SMTP para enviar e receber emails.
#########################
### Autenticação SASL ###
#########################
smtpd_sasl_type = dovecot
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
broken_sasl_auth_clients = yes
Explicação
Primeiro começamos habilitando a autenticação no Postifx (smtpd_sasl_auth_enable), que também força o cliente a se autenticar antes de enviar emails. Para o método de autenticação vamos usar o Dovecot (smtpd_sasl_type), depois temos que passar para o plugin SASL a forma que ele vai usar para se comunicar com o método de autenticação (smtpd_sasl_path), esse caminho deve ser configurado no Dovecot, faremos isso mais para frente. Por fim estamos habilitando a interoperabilidade com clientes SMTP remotos que implementam uma versão obsoleta do comando AUTH, como MicroSoft Outlook Express versão 4 e o MicroSoft Exchange versão 5.
Agora vamos configurar o comportamento do Postfix quando ele for atuar como cliente SMTP, isso ocorre ao enviar emails para outros servidores. Também vamos configurar o TLS na comunicações onde nosso servidor envia email para outros servidores.
########################################################
### SMTP TLS configuration for outcoming connections ###
########################################################
smtp_tls_CApath=/etc/ssl/certs
smtp_tls_loglevel = 1
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_note_starttls_offer = yes
smtp_tls_protocols = >=TLSv1.2, <=TLSv1.3
smtp_tls_mandatory_protocols = >=TLSv1.2, <=TLSv1.3
smtp_tls_ciphers = high
smtp_tls_mandatory_ciphers = high
smtp_tls_exclude_ciphers = aNULL,eNULL,EXPORT,DES,RC4,MD5,PSK,aECDH,EDH-DSS-DES-CBC3-SHA,EDH-RSA-DES-CBC3-SHA,KRB5-DES,CBC3-SHA,DES-CBC3-SHA,AES128-SHA,AES256-SHA,AES128-SHA256,AES128-GCM-SHA256,AES256-SHA256,DHE-RSA-DES-CBC3-SHA,AES256-GCM-SHA384,ECDHE-ECDSA-DES-CBC3-SHA,ECDHE-RSA-DES-CBC3-SHA,CAMELLIA256-SHA256,CAMELLIA256-SHA,CAMELLIA128-SHA256,CAMELLIA128-SHA
smtp_tls_security_level = dane
smtp_dns_support_level = dnssec
Explicação
Primeiro comecemos configurando o diretório onde ficam as CAs do sistema operacional (smtp_tls_CApath). Essa configuração permite que o nosso servidor SMTP valide certificados TLS de outros servidores, utilizando as CAs conhecidas e confiáveis. Depois configuramos os níveis de logg para transações TLS de saída, ou seja, quando o Postfix atua como cliente SMTP ao enviar emails para outros servidores (smtp_tls_loglevel), depois vamos melhora a geração de Chaves de Sessão ao habilitar um cache compartilhado para chaves TLS de saída, ou seja, quando o Postfix atua como cliente SMTP ao enviar emails para outros servidores (smtp_tls_session_cache_database).
Vamos ativar uma monitoração que informa se os servidores de destino (MTAs) oferecem suporte ao STARTTLS, isso vai indicar se eles estão preparados para criptografar as conexões de email ou não (smtp_tls_note_starttls_offer). Os parâmetros smtp_tls_protocols e smtp_tls_mandatory_protocols informam que o servidor SMTP somente vai aceitar o TLS na versão 1.2 e 1.3 nas conexões onde Postfix atua como cliente SMTP ao enviar emails para outros servidores.
No segundo bloco estou configurando o nível de segurança das cifras que serão aceitas smtp_tls_mandatory_ciphers (onde o TLS é obrigatório) e smtp_tls_ciphers (onde o TLS é opcional) e excluindo cifras que não são consideradas seguras (smtp_tls_exclude_ciphers). Apesar de trabalhar com TLS obrigatório e opcional, verá que nossa configuração obriga o cliente a usar TLS. Essas configurações tem validade quando o Postfix atua como cliente SMTP ao enviar emails para outros servidores.
O parâmetro smtp_tls_security_level define o nível de segurança para conexões de saída onde o Postfix atua como cliente SMTP ao enviar emails. Quando configurado como dane, ele exige que as políticas de TLS especificadas por registros TLSA no DNS sejam aplicadas, e que esses registros sejam validados por DNSSEC. Já smtp_dns_support_level vai controlar o nível de suporte ao DNS no cliente SMTP do Postfix, ativando as consultas DNS com suporte ao DNSSEC.
Agora vamos configurar alguns parâmetros para melhorar a segurança no nosso servidor SMTP.
###############################
### Other TLS Configuration ###
###############################
tls_high_cipherlist = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256
tls_random_source = /dev/random
tls_preempt_cipherlist = yes
tls_ssl_options = NO_TICKET, NO_COMPRESSION, NO_RENEGOTIATION, NO_SESSION_RESUMPTION_ON_RENEGOTIATION
Explicação
O parâmetro tls_high_cipherlist define quais cifras são usadas para conexões TLS, estamos configurando para usar algoritmos de criptografia considerados muito seguros. O parâmetro tls_preempt_cipherlist controla a ordem de preferência dos cifradores em uma negociação TLS, isso significa que o servidor SMTP usa sua própria ordem de preferência de cifradores para escolher o cifrador mais adequado. O tls_random_source assegura que o sistema tenha uma fonte confiável de aleatoriedade, que é fundamental para outras operações além da troca de chaves DH.
Por fim vamos configurar o parâmetro tls_ssl_options, ele permite configurar opções específicas do OpenSSL para ajustar o comportamento da criptografia TLS. As opções usadas são:
NO_TICKET
Desativa a retomada de sessão TLS usando tickets.NO_COMPRESSION
Desativa a compressão SSL, mesmo que suportada pela biblioteca OpenSSL. A compressão pode ser intensiva em CPU e não melhora a segurança, pois a compressão antes da criptografia pode ser vulnerável a ataques.NO_RENEGOTIATION
Impede renegociações TLS, que podem ser exploradas para ataques de exaustão de CPU.NO_SESSION_RESUMPTION_ON_RENEGOTIATION
Desativa a retomada de sessão se houver renegociação. Ajuda a prevenir alguns tipos de ataques relacionados a sessões TLS.
Agora vamos configurar o comportamento do Postfix em sí e como ele deve lidar com o mapeamento de usuários. Lembre-se que por usarmos LDAP temos que configurar usuários virtuais. Também por esse motivo, o nome do servidor não pode ser apenas o domínio que vai receber emails, isso causaria conflito e o Postfix entenderia que os usuários desse servidor são locais ao tentar entregar um email na mailbox deles, resultando em usuários desconhecidos.
#############################
### Postfix configuration ###
#############################
myhostname = mail.hermodr.com.br
alias_maps = hash:/etc/aliases, hash:/etc/postfix/aliases-dovecot
alias_database = hash:/etc/aliases, hash:/etc/postfix/aliases-dovecot
myorigin = mail.hermodr.com.br
mydestination = $myhostname, localhost.$mydomain, localhost
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
message_size_limit = 28871600
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all
dovecot_destination_recipient_limit = 1
virtual_transport = dovecot
virtual_mailbox_domains = hermodr.com.br
virtual_alias_maps = hash:/etc/postfix/virtual-dovecot
address_verify_map = proxy:btree:$data_directory/verify_cache
proxy_write_maps = $smtp_sasl_auth_cache_name $lmtp_sasl_auth_cache_name $address_verify_map
disable_vrfy_command = yes
postscreen_greet_action = enforce
show_user_unknown_table_name = no
policyd-spf_time_limit = 3600s
Explicação
Primeiro comecemos configurando o nome do servidor de email (myhostname) em seu formato FQDN. Depois vamos configurar onde estão os mapas de aliases (alias_maps). Esses mapas são usados para mapear endereços de e-mail pela parte do nome do usuário (sem o domínio) para outros endereços de e-mail. Esses aliases se aplicam apenas a destinatários locais, não virtuais ou remotos. A função principal é permitir redirecionamentos e aliasing de e-mails. Embora os aliases possam redirecionar e-mails para endereços externos, a parte local do endereço para o qual o alias aponta deve ser um usuário local.
Se você criar um alias do tipo postmaster: root. O usuário local postmaster não precisa ser um usuário real, é um alias apenas, mas root deve existir como usuário local, ou seja, ele deve ter uma mailbox local, para o que local possa enviar os emails para a mailbox do root. Não é necessário usar domínios aqui, também podemos usar comando para redirecionar a entrega dos emails.
O alias_database é usado especificamente para mapear e-mails locais, esses são os e-mails que são entregues diretamente no sistema, sem passar por um servidor externo. Normalmente ele recebe os mesmos mapas de alias_maps, tornando as alias ali para entregas locais. O próximo parâmetro é o myorigin, ele especifica o domínio que aparece no endereço de remetente para e-mails enviados localmente e também o domínio para o qual os e-mails locais são entregues. Quando um e-mail é enviado de um usuário local, o endereço de remetente será formatado como user@myorigin. Se myorigin estiver definido como $myhostname, o e-mail enviado será exibido como user@mail.hermodr.com.br. Como influencia apenas para usuários locais, não teremos a influencia dele, já que vamos estar usando clientes virtuais via LDAP.
O parâmetro mydestination já foi explicado com muitos detalhes aqui. Um breve resumo, estamos configurando ele para ter o FQDN do servidor de email, dessa forma emails enviados para user@hermodr.com.br não serão reconhecidos como locais, porque hermodr.com.br é diferente de mail.hermodr.com.br, esse comportamento deve ser assim porque vamos usar endereços virtuais. Sendo assim, qualquer email para user@hermodr.com.br nao sera reconhecido como local e o Postfix usará o método de entrega configurado para clientes virtuais (virtual_transport), deixando que o Dovecot tome conta de entregar os emails.
O relayhost deve ficar em branco para desativar o relay, impedindo que nosso servidor entregue emails para um servidor de gateway, que iria fazer a entrega por nós. O parâmetro mynetworks define quais endereços IP ou redes são considerados "confiáveis" pelo servidor de email, os endereços IP aqui podem usar nosso servidor para fazer Relay. O parâmetro mailbox_size_limit especifica o tamanho máximo de uma caixa de correio (mailbox), limitando a quantidade total de dados que uma caixa de correio pode conter, ajudando a prevenir que usuários consumam espaço em disco excessivo, nesse caso, estamos desativando esse limite, já que ele trabalha com o local e vamos usar o virtual porque usamos o Dovecot.
Já o parâmetro message_size_limit define o tamanho máximo total de uma mensagem, incluindo o corpo da mensagem, todos os anexos e cabeçalhos. O valor definido é em bytes. O parâmetro recipient_delimiter foi explicado aqui. O parâmetro inet_interfaces identifica a interface de rede pela qual o servidor vai receber os emails e inet_protocols informa se funcionará em IPv4, IPv6 ou ambos (no nosso caso é ambos).
O parâmetro dovecot_destination_recipient_limit é exclusivo para uso com Dovecot, devemos usar ele quando estamos usando o Dovecot para entregar mensagens e também temos o Sieve ativado para filtragem. A necessidade dessa configuração tem a ver com a forma como o Postfix e o Dovecot lidam com a entrega de e-mails e a manipulação de cabeçalhos. Quando o Dovecot é configurado como um transporte para entrega de e-mails, e você usa o pipe para entregar e-mails para o Dovecot, o Postfix precisa garantir que um único e-mail seja entregue a um único destinatário por vez. Isso é necessário porque o Dovecot pode precisar adicionar cabeçalhos específicos (como Delivered-To) para gerenciar a entrega dos e-mails, e isso não é possível se um único e-mail estiver sendo entregue a múltiplos destinatários ao mesmo tempo.
O parâmetro virtual_mailbox_domains configura o domínio dos usuário desse servidor SMTP devem receber email, como os usuários são virtuais, o domínio virtual deve ser específicado aqui, para um servidor SMTP com múltiplos domínios, podemos colocar todos aqui. o parâmetro virtual_alias_maps é utilizado para mapear endereços de e-mail virtuais para outros endereços, muito parecido com o uso de alias_maps e alias_database, mas funcionando apenas para endereços virtuais.
Como estamos trabalhando com LDAP, é no arquivo definido aqui que vamos configurar os alias para os usuários do nosso servidor de email. As regras são bem parecidas com alias_maps, só que aqui como não é local, além de ter que especificar o nome do usuário/alias, temos que colocar o domínio também. Exemplo, se você criar um alias do tipo diretoria@hermodr.com.br user1@hermodr.com.br,user2@hermodr.com.br, sempre que um email for enviado para diretoria@hermodr.com.br, ele será entregue para user1@hermodr.com.br e user2@hermodr.com.br.
Se você criar um alias e o destinatário desse alias não tiver o domínio, o Postfix entenderá que aponta para um alias local e usará o alias_maps para saber para quem deve entregar, exemplo:
# Em virtual-dovecot:
diretoria@hermodr.com.br copy-diretoria
# Em aliases-dovecot ou etc/alias:
copy-diretoria: "|/usr/sbin/sendmail -oi -f postmaster@mail.hermodr.com.br user1@hermodr.com.br user2@hermodr.com.br"
Quando o servidor SMTP receber um email para diretoria@hermodr.com.br, ele saberá que é um alias mas copy-diretoria por não ter domínio deve ser um outro alias, mas um alias local então ele usará os mapas alias_maps e alias_database, e lá ele verá que copy-diretoria é um alias que deve entregar o email usando o comando do sendmail. Vale ressaltar que poderíamos configurar o LDAP para aliases, mas daria mais trabalho do que usar um simples arquivo.
O parâmetro address_verify_map especifica a tabela de consulta usada para armazenar de forma persistente o status de verificação de endereços de email. A principal função dessa tabela é lembrar o resultado das verificações de endereço para evitar a necessidade de verificar repetidamente os mesmos endereços, o que pode economizar tempo e recursos. Esses endereços de email correspondem a endereços de destinatários externos que estão sendo verificados pelo servidor SMTP antes de aceitar ou rejeitar emails destinados a eles.
O parâmetro proxy_write_maps define quais tabelas de busca o servidor proxymap(8) está autorizado a acessar para serviços de leitura e escrita no Postfix. É relevante quando você utiliza o proxymap para consultar mapas externos ou internos. As referências de tabela que não começam com proxy: são ignoradas, o que significa que apenas tabelas configuradas com o prefixo proxy: são consideradas para acesso de leitura e escrita.
O parâmetro disable_vrfy_command controla se o comando SMTP VRFY deve ser desabilitado ou não, nesse nosso caso deve ser sim, ou seja, o comando VRFY é desabilitado. Quando um remetente remoto tenta usar o comando, o servidor não responde com a confirmação da validade do endereço de email. Desabilitar o comando VRFY ajuda a proteger seu servidor contra a coleta automatizada de endereços de email, dificultando a vida dos spammers.
O parâmetro postscreen_greet_action define a ação que o serviço postscreen(8) deve tomar quando um cliente SMTP remoto fala antes de sua vez, ou seja, antes do tempo especificado no parâmetro postscreen_greet_wait. Nesse nosso caso, permite uma série de testes sejam realizados, mas rejeita tentativas de entrega de email com uma resposta SMTP 550 (indica falha permanente), além de registrar informações como helo/sender/recipient. Esta opção é adequada quando você deseja começar a aplicar restrições, mas ainda quer que todos os testes sejam executados antes de rejeitar o correio. Essa situação ocorre quando o cliente envia dados antes de receber uma saudação do servidor, o que pode indicar comportamento suspeito ou malicioso, como o de alguns bots de spam.
O parâmetro show_user_unknown_table_name controla se o nome da tabela de destinatários será exibido nas respostas de erro quando um endereço de email não for encontrado, para nosso caso, não vamos exibir o nome da tabela. A configuração policyd-spf_time_limit = 3600s define o tempo máximo, em segundos, que o servidor de email esperará por uma resposta dos servidores DNS durante a verificação SPF (quando estamos usando o postfix-policyd-spf-python).
Agora vamos configurar o Milter para comunicação com o Rspamd. Os Milters (Mail Filters) são módulos externos que se integram ao Postfix para realizar processamento adicional nas mensagens de email.
##############################
### Rspamd configuration ###
##############################
milter_protocol = 6
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
milter_default_action = accept
smtpd_milters = inet:127.0.0.1:11332
non_smtpd_milters = $smtpd_milters
internal_mail_filter_classes = bounce
Explicação
O parâmetro milter_protocol define a versão do protocolo de filtro de email (Milter) usada para comunicação entre o Postfix e uma aplicação Milter. O parâmetro milter_mail_macros define quais macros são enviadas para as aplicações Milter após o comando SMTP MAIL FROM. Essas macros fornecem informações adicionais sobre a mensagem de email que pode ser usada pelas aplicações Milter para filtragem e processamento. O parâmetro milter_default_action define o comportamento do servidor quando o Milter não responde, nesse caso o e-mail é processado como se o Milter não estivesse presente, isso significa que em caso de falha do Milter, não vai afetar o processamento do e-mail.
O parâmetro smtpd_milters define quais aplicações Milter serão usadas para processar e-mails que chegam através do servidor SMTP smtpd. Nesse nosso caso um filtro Milter está acessível via IP 127.0.0.1 (inet) na porta 11332. O parâmetro non_smtpd_milters define quais aplicações Milter serão usadas para processar e-mails que não chegam diretamente através do servidor SMTP smtpd. Isso inclui e-mails enviados por meio de submissão local, o serviço qmqpd (Postfix queue manager protocol), e-mails re-injetados na fila com o comando postsuper -r, entre outros. Ao apontar non_smtpd_milters para $smtpd_milters, garante que os mesmos filtros sejam aplicados a todos os e-mails, independentemente de como foram recebidos ou processados.
O parâmetro internal_mail_filter_classes define quais categorias de e-mails gerados pelo Postfix são sujeitos a inspeção de conteúdo antes de serem processados por filtros Milter, header_checks e body_checks. Essa configuração é importante para garantir que apenas e-mails apropriados sejam inspecionados e processados, evitando problemas de desempenho e segurança. Estamos configurando para ativar a inspeção do conteúdo das notificações de falha de entrega (delivery status notifications).
Agora configure o Postfix:
# Faça um backup da configuração original do Postfix:
╼ $ cp /etc/postfix/main.cf /etc/postfix/main.cf-bkp
# Aplique a configuração do Postfix:
╼ $ cat << 'EOF' > /etc/postfix/main.cf
smtpd_banner = $myhostname ESMTP $mail_name
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 3.6 on
# fresh installs.
compatibility_level = 3.6
# appending .domain is the MUA's job.
append_dot_mydomain = no
########################################################
### SMTPD TLS configuration for incoming connections ###
########################################################
smtpd_tls_cert_file=${config_directory}/certs/fullchain.pem
smtpd_tls_key_file=${config_directory}/certs/privkey.pem
smtpd_tls_security_level = may
smtpd_tls_loglevel = 1
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_protocols = >=TLSv1.2, <=TLSv1.3
smtpd_tls_mandatory_protocols = >=TLSv1.2, <=TLSv1.3
smtpd_tls_mandatory_ciphers = high
smtpd_tls_ciphers = high
smtpd_tls_exclude_ciphers = aNULL,eNULL,EXPORT,DES,RC4,MD5,PSK,aECDH,EDH-DSS-DES-CBC3-SHA,EDH-RSA-DES-CBC3-SHA,KRB5-DES,CBC3-SHA,DES-CBC3-SHA,AES128-SHA,AES256-SHA,AES128-SHA256,AES128-GCM-SHA256,AES256-SHA256,DHE-RSA-DES-CBC3-SHA,AES256-GCM-SHA384,ECDHE-ECDSA-DES-CBC3-SHA,ECDHE-RSA-DES-CBC3-SHA,CAMELLIA256-SHA256,CAMELLIA256-SHA,CAMELLIA128-SHA256,CAMELLIA128-SHA
smtpd_tls_dh1024_param_file = /etc/postfix/certs/ffdhe4096.pem
smtpd_helo_required = yes
smtpd_data_restrictions = reject_multi_recipient_bounce
smtpd_sender_restrictions = permit_mynetworks permit_sasl_authenticated reject_non_fqdn_sender reject_unknown_sender_domain
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_non_fqdn_recipient reject_unknown_recipient_domain reject_unauth_destination reject_unverified_recipient check_policy_service unix:private/policy-spf
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous
smtpd_tls_auth_only = yes
#########################
### Autenticação SASL ###
#########################
smtpd_sasl_type = dovecot
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
broken_sasl_auth_clients = yes
########################################################
### SMTP TLS configuration for outcoming connections ###
########################################################
smtp_tls_CApath=/etc/ssl/certs
smtp_tls_loglevel = 1
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_note_starttls_offer = yes
smtp_tls_protocols = >=TLSv1.2, <=TLSv1.3
smtp_tls_mandatory_protocols = >=TLSv1.2, <=TLSv1.3
smtp_tls_ciphers = high
smtp_tls_mandatory_ciphers = high
smtp_tls_exclude_ciphers = aNULL,eNULL,EXPORT,DES,RC4,MD5,PSK,aECDH,EDH-DSS-DES-CBC3-SHA,EDH-RSA-DES-CBC3-SHA,KRB5-DES,CBC3-SHA,DES-CBC3-SHA,AES128-SHA,AES256-SHA,AES128-SHA256,AES128-GCM-SHA256,AES256-SHA256,DHE-RSA-DES-CBC3-SHA,AES256-GCM-SHA384,ECDHE-ECDSA-DES-CBC3-SHA,ECDHE-RSA-DES-CBC3-SHA,CAMELLIA256-SHA256,CAMELLIA256-SHA,CAMELLIA128-SHA256,CAMELLIA128-SHA
smtp_tls_security_level = dane
smtp_dns_support_level = dnssec
###############################
### Other TLS Configuration ###
###############################
tls_high_cipherlist = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256
tls_random_source = /dev/random
tls_preempt_cipherlist = yes
tls_ssl_options = NO_TICKET, NO_COMPRESSION, NO_RENEGOTIATION, NO_SESSION_RESUMPTION_ON_RENEGOTIATION
#############################
### Postfix configuration ###
#############################
myhostname = mail.hermodr.com.br
alias_maps = hash:/etc/aliases, hash:/etc/postfix/aliases-dovecot
alias_database = hash:/etc/aliases, hash:/etc/postfix/aliases-dovecot
myorigin = mail.hermodr.com.br
mydestination = $myhostname, localhost.$mydomain, localhost
relayhost =
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
message_size_limit = 28871600
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all
dovecot_destination_recipient_limit = 1
virtual_transport = dovecot
virtual_mailbox_domains = hermodr.com.br
virtual_alias_maps = hash:/etc/postfix/virtual-dovecot
address_verify_map = proxy:btree:$data_directory/verify_cache
proxy_write_maps = $smtp_sasl_auth_cache_name $lmtp_sasl_auth_cache_name $address_verify_map
disable_vrfy_command = yes
postscreen_greet_action = enforce
show_user_unknown_table_name = no
policyd-spf_time_limit = 3600s
##############################
### Rspamd configuration ###
##############################
milter_protocol = 6
milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen}
milter_default_action = accept
smtpd_milters = inet:127.0.0.1:11332
non_smtpd_milters = $smtpd_milters
internal_mail_filter_classes = bounce
EOF
# Agora crie o diretório para armazenarmos os certificados e o algoritmo Diffie Hellman:
╼ $ mkdir /etc/postfix/certs
# Copie os certificados que geramos usando a lets encrypt:
╼ $ cp /etc/letsencrypt/live/mail.hermodr.com.br/{cert.pem,chain.pem,fullchain.pem,privkey.pem} /etc/postfix/certs/
# Agora obtenha o algoritmo Diffie Hellman de 4096 bits:
╼ $ wget -P /etc/postfix/certs/ https://raw.githubusercontent.com/internetstandards/dhe_groups/master/ffdhe4096.pem
Agora vamos configurar o arquivo master.cf para configurar o submission, dessa forma os clientes vão conseguir se autenticar na porta 587 e configurar o policy-spf para que o Postfix consiga se comunicar com ele para validar SPF e a comunicação com o Dovecot, para que o Postfix saiba como se comunicar com o Dovecot. Vale ressaltar que a comunicação com o Dovecot pode ser configurada usando LMTP, que é um método até que padrão de configuração.
Como essa configuração já está descrita na documentação do Dovecot e é até que simples (só precisa instalar o módulo de LMTP para o Dovecot), vou ensinar a como configurar o Postfix para usar o pipe para se comunicar com o Dovecot. Na configuração com LMTP não é necessário colocar nenhuma configuração do Dovecot em master.cf.
# Para o submission configure assim:
submission inet n - - - - smtpd
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o tls_preempt_cipherlist=yes
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
-o milter_macro_daemon_name=ORIGINATING
# Para o policy-spf configure assim:
policy-spf unix - n n - - spawn
user=nobody argv=/usr/bin/policyd-spf
# Configurando para o Postfix se comunicar com o dovecot.
# O 'dovecot' na linha de baixo tem que ser o mesmo nome que está em 'virtual_transport':
dovecot unix - n n - - pipe
flags=ODRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -e -f ${sender} -d ${recipient}
Explicação
O submission indica o nome do serviço, que indica que esta configuração é para o serviço de submissão de emails (porta 587). O inet indica que o serviço é de rede e utiliza o protocolo TCP/IP. O n indica que o serviço é público e pode ser acessado por outros serviços e redes. Os - não aplicam nenhuma configuração. O smtpd indica o comando e seus argumentos que serão executados para este serviço, nesse caso smtpd é o comando e os argumentos vem logo abaixo.
O -o smtpd_tls_security_level=encrypt exige que todas as comunicações SMTP que estejam entrando para este serviço sejam criptografadas com TLS. Isso garante que as mensagens enviadas para o servidor estejam protegidas. O -o smtpd_sasl_auth_enable=yes habilita a autenticação SASL para o serviço SMTP. Isso significa que os clientes devem se autenticar antes de poderem enviar e-mails, ajudando a prevenir o uso não autorizado do servidor de email.
O -o tls_preempt_cipherlist=yes faz com que o Postfix use uma lista de cifras TLS predefinida, em vez de aceitar as cifras preferidas pelo cliente. Isso ajuda a garantir que o servidor utilize apenas cifras seguras e recomendadas, aumentando a segurança das comunicações TLS. O -o smtpd_relay_restrictions=permit_sasl_authenticated,reject define as restrições de retransmissão para o serviço SMTP. Apenas usuários autenticados via SASL (indicado por permit_sasl_authenticated) são autorizados a enviar e-mails através do servidor. Todos os outros usuários são rejeitados (indicado por reject). Isso ajuda a evitar que o servidor seja usado para envio de spam ou abuso.
O -o milter_macro_daemon_name=ORIGINATING define um macro Milter para a conexão. Neste caso, o macro ORIGINATING é usado, o que pode ser útil para filtros de e-mail que precisam saber o nome do daemon de envio para aplicar regras específicas. Isso pode influenciar o comportamento de filtros e políticas de segurança.
Para o Dovecot nós temos:
O dovecot é o nome do serviço. O serviço é do tipo unix, ou seja, usa soquetes Unix para comunicação, em vez de uma conexão de rede TCP/IP. O primeiro n indica que o serviço é executado com privilégios, ou seja, pode usar privilégios elevados. O segundo n indica que o serviço não é executado dentro de um chroot jail, então ele tem acesso total ao sistema de arquivos. Já o pipe indica que o serviço usa o tipo de processo pipe, que permite que o Postfix envie mensagens para o comando especificado usando um pipe. O comando e seus argumentos são especificados na linha de configuração.
A flag flags=ODRhu indica algumas coisas, segue abaixo:
- O: O serviço pode lidar com mensagens grandes.
- D: O serviço pode verificar o retorno de chamada da entrega.
- R: O serviço pode reexecutar se o destinatário não for encontrado.
- h: O serviço pode manipular cabeçalhos de mensagens.
- u: O serviço pode usar o mesmo usuário para o qual o Postfix foi executado.
Já user=vmail:vmail indica que o comando será executado com o usuário e o grupo vmail. Isso especifica o contexto de segurança para a execução do comando deliver. E argv=/usr/lib/dovecot/deliver -e -f ${sender} -d ${recipient} possuem outros significados, sendo:
- argv: Define o comando e os argumentos que serão usados para processar a mensagem.
- /usr/lib/dovecot/deliver: O comando principal para entregar a mensagem no Dovecot.
- -e: Força a entrega do email, mesmo que o destino tenha problemas.
- -f ${sender}: Define o remetente da mensagem.
- -d ${recipient}: Define o destinatário da mensagem.
Agora reinicie o Postfix. Ainda precisamos liberar as portas no Firewall, mas vou deixar para fazer isso depois de ter configurado o Rspamd e Dovecot. Além de reiniciar o Postfix temos que gerar os mapas que configuramos em virtual_alias_domains, alias_maps e alias_database.
# Agora reinicie o postfix:
╼ $ systemctl restart postfix
# Agora vamos criar os arquivos dos mapas, com exceção de '/etc/aliases' que já existe.
╼ $ touch /etc/postfix/aliases-dovecot
╼ $ touch /etc/postfix/virtual-dovecot
# Agora configura o abuse e postmaster para entrega local:
╼ $ cat << EOF >> /etc/aliases
abuse: postmaster
EOF
# Agora compile os arquivos:
╼ $ postalias /etc/postfix/aliases-dovecot
╼ $ newaliases
╼ $ postmap /etc/postfix/virtual-dovecot
Instalando o OpenLDAP
Não vou explicar cada elemnto do LDAP, isso cabe numa documentação a parte, para um entendimento básico de como funciona recomendo a leitura desse material. Mas vou explicar o que vamos fazer em cada passo, primeiro vamos instalar o OpenLDAP (slapd). Também vamos fazer a instalação de ferramentas (ldap-utils) que vamos usar para configurar o LDAP como ldapsearch, ldappasswd, ldapmodify entre outras. Uma grande adição que vamos usar é o ldapvi que é uma ferramenta onde podemos atualizar entradas do LDAP sem precisar criar arquivos de modificação, facilitando a administração.
Esse LDAP não vai fornecer uma autenticação centralizada, para isso recomendo um outro servidor operando o LDAP ou Kerberos como o FreeIPA. Nós apenas iremos armazenar os dados que os usuário vão usar para fazer autenticação, quem fará a validação dos dados é o Dovecot.
╼ $ apt install -y slapd ldap-utils ldapvi
No momento da configuração é necessário fornecer uma senha de administrador.
Configurando o LDAP
Vamos configurar o LDAP para operar com o Schemas necessários para armazenar dados de emails. Agora vamos criar criar um arquivo chamado schema.conf que inclui vários schemas do LDAP, os schemas definem os tipos de objetos e atributos que podem ser usados no LDAP. No momento não temos os schemas necessários para operar nosso LDAP provendo os dados necessários para autenticarmos nossos usuários no email, então temos que carregar mais schemas no nosso LDAP.
O diretório LDAP inclui inumeros atributos para trabalhar com servidor de email, como o misc.schema, com ele podemos usar os atributos mailRoutingAddress que especifica o endereço para onde o e-mail deve ser roteado, pode ser usado para redirecionar ou encaminhar e-mails para outro endereço e mailLocalAddress que define o endereço de e-mail local, ou seja, o endereço onde as mensagens serão entregues dentro do servidor de e-mail. Ambos atributos fazem parte do ObjectClasses chamado inetLocalMailRecipient que fica dentro do misc.schema.
Também é possível usar o `authldap.schema` no seu servidor LDAP, dependendo das suas necessidades. O `authldap.schema` é um schema que pode ser adicionado ao LDAP para estender as funcionalidades de autenticação e autorizações, como armazenamento de informações adicionais sobre contas de usuário, permissões, e métodos de autenticação. Primeiro de tudo vamos ver quais schemas temos carregados no servidor LDAP:
╼ $ ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=schema,cn=config dn
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}nis,cn=schema,cn=config
dn: cn={3}inetorgperson,cn=schema,cn=config
Eu vou usar o misc.schema por ser mais fácil de trabalhar.
# Entre no diretório abaixo:
╼ $ cd /usr/local/src
# Crie o diretório abaixo:
╼ $ mkdir ldapbase
# Execute o comando para criação do arquivo contendo os schemas:
╼ $ cat << EOF > schema.conf
include /etc/ldap/schema/misc.schema
EOF
# Agora converta os Schemas para Formato LDIF.
# Os arquivos LDIF gerados são armazenados no diretório 'ldapbase'.
╼ $ slaptest -f schema.conf -F ldapbase
config file testing succeeded
# Edite o schema 'misc.ldif' e faça algumas modificações.
##
## Deixe o DN assim: 'dn: cn=misc,cn=schema,cn=config'
## Deixe o objectClass assim: 'objectClass: olcSchemaConfig'
## Deixe o CN assim: 'cn: misc'
##
## Remova o atributo 'SINGLE-VALUE' do objeto 'mailRoutingAddress';
## Isso permite que o atributo aceite múltiplos valores.
##
## Remova os seguinte atributos: 'structuralObjectClass', 'entryUUID', 'creatorsName',
## 'createTimestamp', 'entryCSN', 'modifiersName' e 'modifyTimestamp'
##
## A remoção desses atributos é necessária para permitir a reimportação do arquivo modificado.
##
╼ $ vim "ldapbase/cn=config/cn=schema/cn={0}misc.ldif"
# Agora vamos adicionar o 'misc.schema' modificados ao LDAP:
╼ $ ldapadd -Y EXTERNAL -H ldapi:/// -f ldapbase/cn=config/cn=schema/cn={0}misc.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "cn=misc,cn=schema,cn=config"
# Vamos verificar novamente os schemas que temos carregados no servidor LDAP:
╼ $ ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=schema,cn=config dn
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}nis,cn=schema,cn=config
dn: cn={3}inetorgperson,cn=schema,cn=config
dn: cn={4}misc,cn=schema,cn=config
# Apague os arquivos que não serão mais necessários:
╼ $ rm -rf ldapbase schema.conf
Agora vamos adicionar uma unidade organizacional (OU) chamada accounts, ela será usada para organizar as contas de e-mail. Para criar ela, normalmente teríamos que criar um arquivo .ldif contendo os dados necessários e carregar ele no LDAP, mas vamos usar o ldapvi que é mais fácil. O ldapvi é um editor de interface de linha de comando para edição de diretórios LDAP, permitindo a adição, modificação ou remoção de entradas.
# Edite o diretório LDAP:
╼ $ ldapvi --discover --user cn=admin,dc=hermodr,dc=com,dc=br
# Adicione os dados abaixo ao final do arquivo, depois salve e saia.
add ou=accounts,dc=hermodr,dc=com,dc=br
objectClass: top
objectClass: organizationalUnit
ou: accounts
Agora vamos adicionar uma conta de e-mail chamada test@hermodr.com.br na unidade organizacional accounts. As classes inetLocalMailRecipient e person são usadas para definir os atributos relacionados à conta de e-mail.
# Edite o diretório LDAP:
╼ $ ldapvi --discover --user cn=admin,dc=hermodr,dc=com,dc=br
# Adicione os dados abaixo ao final do arquivo, depois salve e saia.
add cn=test,ou=accounts,dc=hermodr,dc=com,dc=br
cn: test
objectClass: inetLocalMailRecipient
objectClass: person
mailLocalAddress: test@hermodr.com.br
mailRoutingAddress: test@hermodr.com.br
sn: Testando
Agora vamos definir uma senha para a conta de e-mail test@hermodr.com.br. O -W pede a senha do usuário admin, e o -D especifica a DN do usuário administrador.
# Crie uma senha para o usuário 'teste':
╼ $ ldappasswd -W -D "cn=admin,dc=hermodr,dc=com,dc=br" -s 'abc123' "cn=test,ou=accounts,dc=hermodr,dc=com,dc=br"
# Verifique se adicionou a senha:
╼ $ ldapsearch -x -D "cn=admin,dc=hermodr,dc=com,dc=br" -W -b dc=hermodr,dc=com,dc=br
dn: cn=test,ou=accounts,dc=hermodr,dc=com,dc=br
cn: test
objectClass: inetLocalMailRecipient
objectClass: person
mailLocalAddress: test@hermodr.com.br
mailRoutingAddress: test@hermodr.com.br
sn: Testando
userPassword:: e1NTSEF9UU94QWJGMWgyTnFiV0FGRk9RWFdkK2FVUTN1eHMrMDI=
Esses são os passos para configurar um esquema LDAP customizado e adicionam uma conta de e-mail ao diretório, além de realizar testes para garantir que tudo esteja funcionando corretamente.
Instalando o Dovecot
Agora vamos instalar o Dovecot (dovecot-core), também precisamos instalar os módulos do Dovecot para operar como um servidor IMAP (dovecot-imapd), ele também provê o arquivo de configuração padrão do Dovecot para configurar o IMAP. Vamos instalar o módulo do Dovecot para operar com o LDAP e assim conseguir obter os dados dos usuários via LDAP (dovecot-ldap) e por fim vamos instalar um pacote para que o Dovecot consiga trabalhar com Sieve (dovecot-managesieved). O Sieve é uma linguagem de programação que pode ser usada para filtragem de e-mail, ou seja, é um filtro que podemos fazer em cima das mensagens de email através de MDAs.
O Sieve foi projetado para ser implementado tanto em um cliente de e-mail quanto diretamente no servidor de e-mail. As implementações do Sieve devem ocorrer no momento da entrega final do email; quando a mensagem é movida para a caixa de entradado usuário.
╼ $ apt install -y dovecot-core dovecot-imapd dovecot-ldap dovecot-managesieved
Configurando o Dovecot
Primeiro vamos começar criando o usuário e grupo vmail que será usado para gerenciar as mailboxes. Depois vamos começar a configurar o comportamento do Dovecot.
# Crie o grupo 'vmail':
╼ $ addgroup --system vmail --gid 5000
# Agora crie o usuário 'vmail' como uma sysaccount:
╼ $ adduser --system --home /srv/vmail --uid 5000 --gid 5000 --disabled-password --disabled-login vmail
# Agora crie o diretório para armazenar as mailboxes:
╼ $ mkdir /var/vmail
# Corrija as permissões:
╼ $ chown vmail.vmail /var/vmail && chmod 770 /var/vmail
# Execute o comando abaixo para que o Dovecot envie aos clientes uma mensagem personalizada,
# Sempre que eles se conectam ao servidor:
╼ $ sed -i 's/^#login_greeting.*/login_greeting = Dovecot ready./' /etc/dovecot/dovecot.conf
# Execute o comando abaixo para que o Dovecot limite o número de conexões simultâneas que um único
# usuário pode ter de um mesmo endereço IP.
╼ $ sed -i 's/^ #mail_max_userip_connections.*$/ mail_max_userip_connections = 3/' /etc/dovecot/conf.d/20-imap.conf
Agora vamos trabalhar com as configurações do arquivo 10-master.conf, abaixo seguem as configurações que devemos adicionar nesse arquivo:
default_client_limit = 700
service imap-login {
inet_listener imap {
#port = 143
port = 0
}
inet_listener imaps {
port = 993
ssl = yes
}
service auth {
# Este socket Unix é utilizado para autenticação SASL quando o Dovecot é configurado como backend de autenticação para o Postfix.
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
}
# Este socket Unix é usado em comunicações do Dovecot para operações relacionadas ao banco de dados de usuários,
# como autenticação e recuperação de informações sobre usuários.
unix_listener auth-userdb {
mode = 0600
user = vmail
group = vmail
}
Explicação
Configurar o parâmetro default_client_limit no Dovecot define o número máximo de conexões simultâneas que cada processo de serviço pode gerenciar. Quando esse limite é atingido, o Dovecot cria um novo processo para lidar com conexões adicionais. Quando o Dovecot é usado como proxy para outros backends IMAP, cada conexão do cliente pode ser gerenciada por um processo ou thread separado. Isso tem implicações importantes para o gerenciamento de processos e recursos do sistema.
Se o limite de conexões por processo (`default_client_limit`) é muito alto, o Dovecot pode acabar criando um grande número de processos para gerenciar as conexões. Cada processo pode consumir uma quantidade significativa de memória e recursos de CPU. Com um limite menor, cada processo gerencia menos conexões, o que pode reduzir a contagem total de processos em execução. Isso pode ajudar a manter o consumo de memória e CPU em níveis mais controláveis.
Os blocos unix_listener no Dovecot são usados para configurar pontos de escuta para conexões Unix Domain Socket (UDS). Essas configurações são importantes para a comunicação entre o Dovecot e outros serviços ou aplicativos, como o Postfix para autenticação de e-mail. Os próximos dois blocos que vou comentar devem ficar dentro do bloco service auth, indicando que são serviços de autenticação.
O bloco unix_listener /var/spool/postfix/private/auth configura um ponto de escuta Unix Domain Socket em /var/spool/postfix/private/auth. Este socket é usado pelo Postfix para enviar informações de autenticação para o Dovecot. Temos que configurar com o usuário e grupo postfix para que o Postfix consiga interagir com esse socket assim como o Dovecot, possibilitando que ambos se comuniquem para efetuar a autenticação do usuário.
O bloco unix_listener auth-userdb { configura um ponto de escuta para autenticação, usado pelo Dovecot para interagir com o banco de dados de usuários, especialmente quando o Dovecot está configurado para usar um banco de dados externo para autenticação, como o LDAP.
Basicamente o Postfix vai entrar em contato com o Dovecot pelo socket /var/spool/postfix/private/auth quando for autenticar algum usuário, o Dovecot por sua vez vai usar o socket unix_listener auth-userdb para se conectar no LDAP e validar as credencias do usuário. Depois o Dovecot volta a se comunicar com o Postfix pelo socket /var/spool/postfix/private/auth.
Agora vamos trabalhar com as configurações em 10-auth.conf.
auth_mechanisms = plain login
disable_plaintext_auth = yes
auth_username_format = %n@%d
!include auth-ldap.conf.ext
## Comente a opção abaixo:
!include auth-system.conf.ext
Explicação
O parâmetro auth_mechanisms define quais mecanismos de autenticação o Dovecot irá aceitar. Eles foram explicados aqui. O parâmetro disable_plaintext_auth define se a autenticação em texto simples é permitida, nesse caso estamos desativando a autenticação em texto simples.
Já o parâmetro auth_username_format define o formato do nome de usuário que o Dovecot usará para autenticação, nesse caso ele deve fornecer o nome e o domínio como em user@hermodr.com.br, se tentar se logar apenas com o nome de usuário não vai dar certo. O !include auth-ldap.conf.ext inclui uma configuração adicional de autenticação LDAP a partir do arquivo auth-ldap.conf.ext.
Agora vamos trabalhar com as configurações em 10-mail.conf.
mail_location = mdbox:/var/vmail/%d/%n/mdbox
namespace inbox {
separator = .
Explicação
Em mail_location estamos definindo o local e o formato onde as caixas de correio dos usuários serão armazenadas. O mdbox refere-se ao formato de armazenamento MDBOX, que é um formato de armazenamento de caixa de correio que agrupa mensagens em caixas de correio individuais em arquivos de banco de dados. Ele é projetado para melhorar a eficiência e o desempenho do armazenamento e acesso às mensagens.
Já /var/vmail/%d/%n/mdbox especifica o caminho para onde as caixas de correio serão armazenadas. A estrutura de diretórios é baseada em dois parâmetros:
- %d: Substituído pelo domínio do endereço de e-mail do usuário (por exemplo, example.com).
- %n: Substituído pelo nome de usuário (por exemplo, john).
O separator define o separador de subpastas dentro das caixas de correio. No caso, o separador é o ponto (.), o que significa que se você tiver pastas como inbox.Sent, inbox.Drafts, etc., elas serão separadas por um ponto.
Agora vamos trabalhar com as configurações em auth-ldap.conf.ext.
passdb {
driver = ldap
# Path for LDAP configuration file, see example-config/dovecot-ldap.conf.ext
args = /etc/dovecot/dovecot-ldap.conf.ext
}
userdb {
driver = ldap
args = /etc/dovecot/dovecot-ldap.conf.ext
}
Explicação
O passdb define o método de autenticação de senhas. O driver = ldap indica que o Dovecot usará o LDAP para autenticação de senhas. O args = /etc/dovecot/dovecot-ldap.conf.ext especifica o caminho para o arquivo de configuração LDAP do Dovecot, que contém as informações necessárias para conectar-se ao servidor LDAP e autenticar usuários.
O userdb define como o Dovecot obtém informações sobre os usuários. O driver = ldap indica que o Dovecot usará o LDAP para obter informações sobre os usuários. O args = /etc/dovecot/dovecot-ldap.conf.ext especifica o caminho para o mesmo arquivo de configuração LDAP usado para autenticação de senhas. Esse arquivo também contém configurações para buscar detalhes dos usuários no LDAP.
Agora vamos trabalhar com as configurações em local.conf.
cat << 'EOF' > /etc/dovecot/local.conf
mail_uid = vmail
mail_gid = vmail
mail_privileged_group = vmail
EOF
Explicação
A opção mail_uid define o ID do usuário que será usado pelo Dovecot para acessar arquivos de e-mail. Já a opção mail_gid define o ID do grupo que será usado pelo Dovecot para acessar arquivos de e-mail. E mail_privileged_group define que o grupo vmail terá permissões especiais para realizar operações que exigem privilégios elevados no sistema de arquivos, como criar ou modificar arquivos de e-mail. Isso é útil para garantir que apenas processos e usuários autorizados possam realizar essas operações sensíveis.
Essas configurações ajudam a gerenciar e controlar como o Dovecot lida com as caixas de correio dos usuários e como ele interage com o sistema de arquivos para operações de e-mail. Quando um e-mail é enviado para um usuário, o servidor de e-mail (como o Postfix) deposita o e-mail na caixa de correio do usuário. O Dovecot, configurado com o caminho mail_location, é responsável por armazenar o e-mail no diretório correto e garantir que o e-mail fique acessível para o usuário.
Quando um usuário exclui um e-mail, o Dovecot remove o e-mail da caixa de correio. Isso requer que o Dovecot tenha permissões adequadas para acessar e modificar os arquivos de e-mail no sistema de arquivos.
Agora vamos trabalhar com as configurações em 15-lda.conf.
postmaster_address = postmaster@hermodr.com.br
protocol lda {
mail_plugins = $mail_plugins sieve
}
Explicação
A opção postmaster_address define o e-mail que será usado como o endereço do postmaster, o qual é frequentemente utilizado para receber relatórios de erro e mensagens relacionadas ao gerenciamento do servidor de e-mail.
O bloco protocol lda configura o comportamento do protocolo LDA do Dovecot. Nesse caso, mail_plugins define quais plugins devem ser carregados para o protocolo LDA. O $mail_plugins é uma variável que inclui quaisquer plugins configurados globalmente para o Dovecot e o sieve adiciona o plugin Sieve ao conjunto de plugins carregados.
Agora vamos trabalhar com as configurações em 15-mailboxes.conf. Aplique nesse arquivo apenas as configurações abaixo, nada mais.
namespace inbox {
# These mailboxes are widely used and could perhaps be created automatically:
mailbox Drafts {
special_use = \Drafts
auto = subscribe
}
mailbox Trash {
special_use = \Trash
auto = subscribe
}
mailbox Spam {
special_use = \Junk
auto = subscribe
}
# For \Sent mailboxes there are two widely used names. We'll mark both of
# them as \Sent. User typically deletes one of them if duplicates are created.
mailbox Sent {
special_use = \Sent
#auto = subscribe
}
mailbox "Sent Messages" {
special_use = \Sent
}
}
Explicação
O mailbox Drafts define uma pasta chamada "Drafts" (Rascunhos), para salvar emails que foram escritos mas não enviados. A opção special_use = \Drafts marca a pasta como uma pasta especial para rascunhos. Isso é importante para que os clientes de e-mail reconheçam essa pasta como a pasta para armazenar rascunhos de e-mail. Já a opção auto = subscribe faz com que o usuário se inscreva automaticamente na pasta "Drafts" quando a conta é criada ou configurada.
A opção mailbox Trash configura uma pasta chamada "Trash" (Lixeira), para guardar os emails "excluidos". A opção special_use = \Trash marca a pasta como uma pasta especial para itens excluídos. Já a opção auto = subscribe faz com que o usuário se inscreva automaticamente na pasta "Trash".
A opção mailbox Spam define uma pasta chamada "Spam" (Spam) para guardar os emails que foram marcados mas que podem não ser spam. A opção special_use = \Junk marca a pasta como uma pasta especial para lixo eletrônico, nesse caso é a mesma coisa. Já a opção auto = subscribe faz com que o usuário se inscreva automaticamente na pasta "Spam".
A opção mailbox Sent define uma pasta chamada "Sent" (Enviados) para armazenar todos os emails que já foram enviados. A opção special_use = \Sent marca a pasta como uma pasta especial para e-mails enviados. A opção mailbox "Sent Messages" define uma pasta alternativa chamada "Sent Messages". A opção special_use = \Sent marca a pasta como uma pasta especial para e-mails enviados.
A configuração inclui duas pastas para "Sent" (Sent e Sent Messages), isso é padrão do Dovecot para acomodar diferentes clientes de e-mail que podem usar diferentes nomes para a pasta de itens enviados. O usuário pode remover uma das pastas se houver duplicidade.
Agora vamos trabalhar com as configurações em 90-sieve.conf. Aplique nesse arquivo apenas as configurações abaixo, nada mais.
plugin {
sieve_dir = /var/vmail/%d/%n/sieve/scripts
sieve = /var/vmail/%d/%n/sieve/active-script.sieve
sieve_extensions = +notify +imap4flags
Explicação
Essa configuração no Dovecot define o comportamento do plugin Sieve, que é utilizado para filtrar e manipular e-mails de acordo com regras definidas pelos usuários. A opção sieve_dir = /var/vmail/%d/%n/sieve/scripts define o diretório onde os scripts Sieve dos usuários são armazenados. A opção sieve = /var/vmail/%d/%n/sieve/active-script.sieve especifica o caminho do script Sieve ativo para cada usuário. A opção sieve_extensions = +notify +imap4flags lista as extensões Sieve que estão habilitadas.
A extenao +notify habilita a extensão notify, que permite que o script envie notificações sobre a chegada de e-mails. Já a extensão +imap4flags habilita a extensão imap4flags, que permite que o script modifique os flags IMAP das mensagens (por exemplo, definir mensagens como lidas ou importantes).
Agora vamos trabalhar com as configurações em 10-ssl.conf, onde vamos configurar o uso de TLS no Dovecot. Aplique nesse arquivo apenas as configurações abaixo, nada mais.
ssl = required
ssl_cert = </etc/postfix/certs/fullchain.pem
ssl_key = </etc/postfix/certs/privkey.pem
ssl_client_ca_dir = /etc/ssl/certs
ssl_dh = </etc/postfix/certs/ffdhe4096.pem
ssl_min_protocol = TLSv1.2
ssl_cipher_list = ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256
ssl_curve_list = prime256v1:secp384r1
ssl_prefer_server_ciphers = yes
Explicação
O ssl = required exige o uso de SSL/TLS nas conexões. Já ssl_cert e ssl_key configurando caminho do certificado e chave privada que o Dovecot vai usar nas conexões com TLS (estou deixando tudo no diretório do Postfix). O ssl_client_ca_dir define o diretório onde estão armazenados os certificados das autoridades certificadoras confiáveis para validação de clientes.
O ssl_dh define o arquivo com parâmetros Diffie-Hellman para negociações de chave seguras. A opção ssl_min_protocol configura o protocolo mínimo de TLS a ser utilizado, neste caso, TLS 1.2 ou superior. Já a opção ssl_cipher_list especifica a lista de cifras criptográficas permitidas para conexões SSL/TLS, garantindo um nível adequado de segurança.
A opção ssl_curve_list = prime256v1:secp384r1 define as curvas elípticas usadas para negociações de chaves, contribuindo para a segurança das conexões. A opção ssl_prefer_server_ciphers = yes faz com que o servidor prefira suas próprias cifras criptográficas em vez de aceitar as cifras sugeridas pelos clientes.
Por fim vamos configurar o stats-reader e stats-writer. Eles são blocos de configuração que configuram "listeners" Unix para permitir comunicação com o serviço de estatísticas.
service stats {
unix_listener stats-reader {
user = vmail
group = vmail
mode = 0660
}
unix_listener stats-writer {
user = vmail
group = vmail
mode = 0660
}
}
Agora é só reiniciar o Dovecot e verificar se ele está escutando na porta 993 que usa o IMAP com TLS.
# Reinicie o serviço do Dovecot:
╼ $ systemctl restart dovecot
# Agora podemos verificar as portas assim:
╼ $ lsof -Pni | grep dovecot
dovecot 23270 root 15u IPv4 62712 0t0 TCP *:4190 (LISTEN)
dovecot 23270 root 16u IPv6 62713 0t0 TCP *:4190 (LISTEN)
dovecot 23270 root 36u IPv4 62754 0t0 TCP *:993 (LISTEN)
dovecot 23270 root 37u IPv6 62755 0t0 TCP *:993 (LISTEN)
Configurando o Dovecot para conectar no LDAP
Vamos configurar o Dovecot para que ele consiga obter os dados do LDAP para que assim consiga fazer a autenticação dos usuários.
# Entre no diretório abaixo:
╼ $ cd /etc/dovecot
# Ronomeie o arquivo do ldap original para mantermos um backup:
╼ $ mv dovecot-ldap.conf.ext dovecot-ldap.conf.ext-orig
# Agora crie um novo arquivo com a nossa configuração:
cat << 'EOF' > /etc/dovecot/dovecot-ldap.conf.ext
tls = no
hosts = 127.0.0.1
auth_bind = no
ldap_version = 3
dn = cn=admin,dc=hermodr,dc=com,dc=br
dnpass = SENHA
base = ou=accounts,dc=hermodr,dc=com,dc=br
deref = never
default_pass_scheme = SSHA
pass_filter = (&(objectClass=inetLocalMailRecipient)(mailLocalAddress=%u))
pass_attrs = userPassword=password
user_filter = (&(objectClass=inetLocalMailRecipient)(mailLocalAddress=%u))
user_attrs = cn=home=/var/vmail/%d/%$, uid=5000, gid=5000
EOF
Explicação
tls = no
Desativa a conexão TLS com o servidor LDAP. (Não criptografa a conexão LDAP)hosts = 127.0.0.1
Define o servidor LDAP como127.0.0.1(localhost).auth_bind = no
Desativa a autenticação bind do LDAP, onde o Dovecot usa uma conta específica para se conectar ao LDAP.ldap_version = 3
Usa a versão 3 do protocolo LDAP.dn = cn=admin,dc=hermodr,dc=com,dc=br
Define o DN (Distinguished Name) da conta administrativa do LDAP.dnpass = SENHA
Define a senha para a conta administrativa LDAP.base = ou=accounts,dc=hermodr,dc=com,dc=br
Define a base DN para procurar os usuários LDAP.deref = never
Não segue referências (pointers) em resultados LDAP.default_pass_scheme = SSHA
Define o esquema de senha padrão como SSHA (Salted SHA).pass_filter = (&(objectClass=inetLocalMailRecipient)(mailLocalAddress=%u))
Filtro LDAP para encontrar o DN do usuário baseado no atributomailLocalAddress.pass_attrs = userPassword=password
Define como recuperar o atributo de senha do LDAP.user_filter = (&(objectClass=inetLocalMailRecipient)(mailLocalAddress=%u))
Filtro LDAP para localizar usuários baseado no atributomailLocalAddress.user_attrs = cn=home=/var/vmail/%d/%$, uid=5000, gid=5000
Define atributos do usuário, como nome comum (cn), diretório home, UID e GID.
Nesse momento o Dovecot está usando o usuário admin do LDAP, isso não é bom e também não está conectando usando TLS, como está tudo no mesmo ambiente não teria problemas em um mundo perfeito, vamos ver como arrumar isso.
ClamAV
O ClamAV é um software antivírus gratuito e de código aberto para sistemas operacionais Unix, incluindo Linux, macOS e FreeBSD. Ele é projetado para detectar malware, incluindo vírus, cavalos de Troia, worms, spyware e outros tipos de ameaças.
Ele é usado principalmente em servidores de e-mail, servidores de arquivos e em outras situações em que a detecção de malware é necessária. Ele usa uma combinação de assinaturas de vírus e mecanismos heurísticos para detectar malware, e é conhecido por sua alta taxa de detecção e baixo número de falsos positivos. Vamos instalar e configurar o Clamav.
# Faça instalação dos pacotes abaixo:
╼ $ apt install -y clamav-daemon clamav
# Pare o processo do freshclam:
╼ $ systemctl stop clamav-freshclam
# Atualize os bancos de dados de vírus do ClamAV:
╼ $ freshclam
# Inicie o processo do freshclam novamente:
╼ $ systemctl start clamav-freshclam
Vamos adicionar algumas assinaturas extras que são mantidas pelo projeto ClamAV Unofficial Signatures (CUS), que é um projeto de código aberto separado que visa fornecer assinaturas de vírus adicionais para o ClamAV. O que vamos fazer em seguida é baixar alguns scripts e configurações necessários para usar as assinaturas de malware extras fornecidas pelo CUS. Quando os scripts são executados, eles baixam as assinaturas mais recentes do CUS e as adicionam ao ClamAV, permitindo que ele detecte uma ampla variedade de ameaças de malware.
# Entre no diretório abaixo:
╼ $ cd /usr/local/src/
# Baixe a assinatura:
╼ $ wget https://raw.githubusercontent.com/extremeshok/clamav-unofficial-sigs/master/clamav-unofficial-sigs.sh
# "Instale" o script no diretório abaixo com a permissão 0755:
╼ $ install -m 0755 clamav-unofficial-sigs.sh /usr/local/sbin/clamav-unofficial-sigs.sh
# Crie o diretório abaixo:
╼ $ mkdir -p /etc/clamav-unofficial-sigs/
# Baixe os arquivos de configurações:
╼ $ wget https://raw.githubusercontent.com/extremeshok/clamav-unofficial-sigs/master/config/master.conf -O /etc/clamav-unofficial-sigs/master.conf
╼ $ wget https://raw.githubusercontent.com/extremeshok/clamav-unofficial-sigs/master/config/user.conf -O /etc/clamav-unofficial-sigs/user.conf
╼ $ wget https://raw.githubusercontent.com/extremeshok/clamav-unofficial-sigs/master/config/os/os.ubuntu.conf -O /etc/clamav-unofficial-sigs/os.conf
# Force a atualização das assinaturas de malware fornecidas pelo CUS:
╼ $ /usr/local/sbin/clamav-unofficial-sigs.sh --force
# Instale o arquivo de configuração do logrotate:
╼ $ /usr/local/sbin/clamav-unofficial-sigs.sh --install-logrotate
# Instale o arquivo de configuração do man:
╼ $ /usr/local/sbin/clamav-unofficial-sigs.sh --install-man
# Entre no diretório abaixo:
╼ $ cd /etc/systemd/system/
# Baixe o '.service' e o '.timer' do CUS:
╼ $ wget https://raw.githubusercontent.com/extremeshok/clamav-unofficial-sigs/master/systemd/clamav-unofficial-sigs.service -O clamav-unofficial-sigs.service
╼ $ wget https://raw.githubusercontent.com/extremeshok/clamav-unofficial-sigs/master/systemd/clamav-unofficial-sigs.timer -O clamav-unofficial-sigs.timer
# Habilite o '.service' e o '.timer' que acabamos de baixar para iniciar no Boot:
╼ $ systemctl enable clamav-unofficial-sigs.service
╼ $ systemctl enable clamav-unofficial-sigs.timer
# Inicie o '.timer':
╼ $ systemctl start clamav-unofficial-sigs.timer
# Verifique se as assinaturas de malware estão carregadas corretamente:
╼ $ clamscan --debug 2>&1 /dev/null | grep "loaded"
Instalando e Configurando o Rspamd
O Rspamd é um sistema de filtragem e análise de email de código aberto. Ele é projetado para ser executado em servidores de email e é usado para identificar e bloquear spam, vírus e outras ameaças de segurança. O Rspamd é capaz de processar grandes volumes de email e é altamente escalável. Vamos instalar e configurar o RSpamD para atuar em conjunto com o Clamav.
# Instale o rspamd e o Redis:
╼ $ apt install -y rspamd redis-server
# Vamos gerar uma senha criptografada que pode ser usada em arquivos de configuração do Rspamd, para autenticação ou outras finalidades de segurança:
╼ $ rspamadm pw --encrypt
Agora, com a senha gerada vamos colocar ela na variável password, deve ficar dentro do arquivo worker-controller.inc. A variável password define uma senha para autenticar conexões ao worker-controller. Ela autentica os clientes que desejam se conectar e controlar o worker-controller, como o utilitário "rspamadm".
password = "xxxxxx";
Agora vamos criar o worker-proxy, ele é um worker do Rspamd que permite que outros servidores de email enviem e-mails para o Rspamd para processamento. A configuração abaixo permite que o worker-proxy do Rspamd receba conexões de servidores de correio usando o protocolo Milter.
bind_socket = "127.0.0.1:11332";
milter = yes;
timeout = 120s;
upstream "local" {
default = yes;
self_scan = yes;
}
Explicação
bind_socket = "127.0.0.1:11332";
Define o endereço IP (localhost) e a porta (11332) onde oworker-proxyescuta conexões.milter = yes;
Ativa o protocolo Milter para permitir que o Rspamd interaja com servidores de email, como Postfix, durante o processamento de emails.timeout = 120s;
Define um tempo limite de 120 segundos para as conexões do Milter.upstream "local"
Configura um grupo de servidores "upstream" para processamento.default = yes;
Marca este servidor como o padrão para processamento.self_scan = yes;
Indica que o próprio servidor local deve ser usado para escanear emails.
Agora vamos configurar o módulo de verificação de vírus do Rspamd. Essa é a forma como configuramos o módulo de verificação de vírus para usar o ClamAV como um scanner de vírus.
clamav {
scan_mime_parts = false;
symbol = "CLAM_VIRUS";
type = "clamav";
action = "reject";
servers = "/var/run/clamav/clamd.ctl";
}
Explicação
scan_mime_parts = false;
Não escanear partes MIME separadamente.symbol = "CLAM_VIRUS";
O símbolo "CLAM_VIRUS" será adicionado se um vírus for detectado.type = "clamav";
Especifica que o tipo de scanner é.action = "reject";
Emails com vírus serão rejeitados.servers = "/var/run/clamav/clamd.ctl";
Define o caminho do socket do ClamAV para comunicação.
Agora vamos configurar o módulo de classificação Bayesiana do Rspamd. A Cassificação Bayesiana é um método de classificação estatística para análise de spam. O trecho de código abaixo configura o módulo de classificação Bayesiana para usar o Redis como o backend para armazenamento de dados, portanto, precisa instalar o redis como já fizemos (sudo apt-get install redis-server).
backend = "redis";
autolearn = true;
server = "localhost";
Explicação
backend = "redis";
Esta linha especifica que o Rspamd deve usar o Redis como backend para armazenamento de dados da classificação Bayesiana. O Redis é um banco de dados em memória, rápido e eficiente, adequado para armazenar e recuperar dados usados na análise Bayesiana.autolearn = true;
Ativa o recurso de autolearn (autoaprendizagem). Isso significa que o Rspamd ajustará automaticamente seu modelo Bayesiano com base nos emails que processa, aprendendo a identificar padrões de spam e ham (não-spam) de forma dinâmica e contínua.server = "localhost";
Especifica que o Redis está sendo executado nolocalhost, ou seja, na mesma máquina onde o Rspamd está rodando. Se o Redis estivesse em um servidor remoto, você precisaria substituirlocalhostpelo endereço IP ou hostname do servidor Redis.
Agora crie o arquivo para que o Rspamd possa adicionar cabeçalhos de e-mail personalizados.
authenticated_headers = ["authentication-results"];
extended_spam_headers = true;
skip_local = false;
skip_authenticated = false;
Explicação
authenticated_headers = ["authentication-results"];
Quais cabeçalhos devem ser adicionados para mensagens autenticadas.extended_spam_headers = true;
Adiciona cabeçalhos adicionais às mensagens de spam detectadas pelo Rspamd como: score de spam, o número de regras correspondentes e muito mais.skip_local = false;
O Rspamd deve ou não analisar e adicionar cabeçalhos para mensagens que são enviadas localmente (deve analisar sim).skip_authenticated = false;
O Rspamd deve ou não analisar e adicionar cabeçalhos para mensagens autenticadas (deve analisar sim).
Configure o Rspamd para que ele possa verificar a validade do registro MX do domínio de um remetente de e-mail.
enabled = true;
server = "127.0.0.1";
Explicação
server é o servidor DNS que deve ser usado para resolver o registro MX. No caso vamos usar o servidor DNS local.
Agora vamos configurar os endereços IP locais para nosso server. Isso informa ao Rspamd quais endereços IP são considerados locais ou internos na sua rede. Isso ajuda a diferenciar entre emails enviados internamente e aqueles recebidos de fontes externas, o que influencia como ele aplica regras de filtragem, detecção de spam, e outras políticas.
local_addrs = "127.0.0.0/8, ::ffff:127.0.0.0/104, ::1/128, 75.119.143.187/32, 2a02:c206:2120:1140::1/128";
Configure a conexão do Rspamd com o servidor Redis.
write_servers = "127.0.0.1";
read_servers = "127.0.0.1";
# Define os servidores Redis para gravação e leitura, respectivamente.
Agora vamos configurar o módulo DKIM no Rspamd, para que ele assine digitalmente as mensagens de email, ajudando a garantir que o conteúdo da mensagem não foi adulterado durante o trânsito e melhorando a aceitação dos emails para não serem marcadas como spam.
domain {
hermodr.com.br {
selector = "dkim";
path = "/var/lib/rspamd/dkim/hermodr.com.br.private";
}
}
allow_hdrfrom_mismatch = true;
allow_hdrfrom_mismatch_sign_networks = true;
allow_username_mismatch = true;
use_domain = "header";
auth_only = true;
use_esld = true;
Explicação
domain { hermodr.com.br { ... } }
Configura as opções DKIM para o domíniohermodr.com.br. Que é o domínio do servidor de email.selector = "dkim";
Define o seletor comodkim.path = "/var/lib/rspamd/dkim/hermodr.com.br.private";
Especifica o caminho do arquivo de chave privada DKIM.
allow_hdrfrom_mismatch = true;
Permite assinar emails mesmo que o campo "From" no cabeçalho não corresponda ao domínio.allow_hdrfrom_mismatch_sign_networks = true;
Permite o uso deallow_hdrfrom_mismatchpara redes configuradas.allow_username_mismatch = true;
Permite assinar emails mesmo se o nome de usuário não coincidir com o domínio.use_domain = "header";
Utiliza o domínio do cabeçalho "From" para a assinatura DKIM.auth_only = true;
Só assina emails de usuários autenticados.use_esld = true;
Utiliza o domínio de nível superior efetivo (ESLD) para validação. O ESLD é o domínio efetivo de segundo nível, que basicamente é o domínio principal mais comum. Por exemplo, emmail.example.com, o ESLD seriaexample.com.
Agora vamos configurar a chave DKIM que o Rspamd vai usar para assinar os emails.
# Entre no diretório abaixo:
╼ $ cd /etc/rspamd/local.d/
# Crie o link abaixo. O ARC (Authenticated Received Chain) usa a mesma
# configuração que o DKIM (DomainKeys Identified Mail) no Rspamd.
╼ $ ln -s dkim_signing.conf arc.conf
# Agora reinicie o rspamd:
╼ $ systemctl restart rspamd
Desbloquenado as portas no Firewall
Agora vamos desbloquear as portas para que nosso servidor passe a aceitar conexões na porta 25 para envio e recebimento e emails, 587 para autenticação dos clientes de email com TLS, 993 para o protocolo IMAP com TLS e 4190 para o Sieve. Primeiro de tudo adicione as linhas em destaque nos arquivos abaixo.
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A INPUT -m udp -p udp -m multiport --dports 33434:33690 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 64248 -j ACCEPT
-A INPUT -p tcp -m multiport --dports 25,587,993,4190 -m tcp -j ACCEPT
-A INPUT -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[iptables denied]: "
COMMIT
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m rt --rt-type 0 -j DROP
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 1 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 2 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 3 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 4 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 129 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 135 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 136 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 141 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 142 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 148 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -p ipv6-icmp -m icmp6 --icmpv6-type 149 -m hl --hl-eq 255 -j ACCEPT
-A INPUT -p udp -m udp -m multiport --dports 33433:33690 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 64248 -j ACCEPT
-A INPUT -p tcp -m tcp -m multiport --dports 25,587,993,4190 -j ACCEPT
COMMIT
Agora vamos aplicar as regras novas para as portas serem liberadas.
# Entre no diretório abaixo:
╼ $ iptables-restore /etc/iptables/rules.v4
╼ $ ip6tables-restore /etc/iptables/rules.v6
Fazendo as modificações no DNS
Vamos confgurar a parte do DNS do nosso servidor, já expliquei como funciona e como depende do serviço de DNS que está usando, vou descrever apenas o que precisa fazer.
Configurando TLSA
Vamos configurar o TLSA para fornecer informações de autenticação e validação de certificados TLS, permitindo os clientes validem os certificados de um servidor contendo TLS.
# Obtenha o hash para o TLSA usando o certificado:
╼ $ openssl x509 -noout -pubkey -in /etc/letsencrypt/live/mail.hermodr.com.br/fullchain.pem | openssl rsa -pubin -outform DER 2>/dev/null | sha256sum
4bf1e30a81106954ca46ceed0ddad015801c072b9f88f9345d5410aa8117de8a -
Agora no servidor DNS adicione as seguintes entradas:
_25._tcp.mail.hermodr.com.br. IN TLSA (3 1 1 9880da323e4ee6f6929f8150903f8046ae94fb03d8884700279b7139f760dfa9)
Podemos testar o TLSA com o seguinte comando:
$ dig +dnssec +multi _25._tcp.mail.hermodr.com.br. TLSA
Configurando DKIM
Como já fizemos a configuração do DKIM no Rspamd, precisamos gerar a chave que ele vai usar.
# Crie o diretório abaixo:
╼ $ mkdir /var/lib/rspamd/dkim
# Gere as chaves:
╼ $ rspamadm dkim_keygen -s 'dkim' -b 4096 -d hermodr.com.br -k /var/lib/rspamd/dkim/hermodr.com.br.private > /var/lib/rspamd/dkim/hermodr.com.br.txt
# Corrija as permissões:
╼ $ chown _rspamd. -R /var/lib/rspamd/dkim
# Veja o conetúdo do registro DNS:
╼ $ cat /var/lib/rspamd/dkim/hermodr.com.br.txt
dkim._domainkey IN TXT ( "v=DKIM1; k=rsa; "
"p=MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAphrjt2AAdgpQUPvWTmAoM048JGqdIl8EosI7EhtDgi5o4bgDKOhCTvdlEGX6MkGq2gDbEs5ILiUh5kOWZvCX6EzqWbTCj6bk0yRCmYUNjYYQirOj9Is5qXorO53A4gbN/322DCcagBgKamxP5yj8E1OgEb5zSvuSdXhVCj8TZBtX+1Op2aMfxacLmuG92y4l0FScFKAfj4XVRt3Tx"
"uIVm9ZLkMpsBe4N3ziQBop3pKadFngcSzqc7y+7vlw/8G/uKPotxr9ncHsVWTyj5AluyCOv9nw+dLE8d9YYDhUPYDIoFS3IfsYdaKppFeakcyCxc0jpQ6BokKTpFQXzO4YeFJoJcMoP73y36jfeK2aAyCijtTXSmTGra8U69WBQwfyAavoLZwZX9eUxnMlhae5c2hnbjkuvrG8Qug9L84Wo9dDSLxvegSGkbje65qpCpZxVa8OM5ez+wiK+MVua"
"/k7CRd7OPuSzhuT7298+hK0Gd8z/KPrDccjSYUKrceTi0wYWj8Qyt3u/76m71o4Vd+zWOOHXarmf5GmAoeYWW0mhAHoaDqVeqEuQFoeGvb72mlUGuro2pthCtgG/9Ctf0WE/tji+OFJxyNnQ7rzgl3t01ipXbzellLxXuG3kMBE1yoOhwwHWVl0bZVj8rDgIQMXCBuPC5hjceSa3Kv3LgFEnJgUCAwEAAQ=="
) ;
Caso você vá usar o site registro.br para configurar o DNS, você deve colocar tudo numa única linha e não coloque aspas ", exemplo:
dkim._domainkey IN TXT v=DKIM1; k=rsa; p=MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAphrjt2AAdgpQUPvWTmAoM048JGqdIl8EosI7EhtDgi5o4bgDKOhCTvdlEGX6MkGq2gDbEs5ILiUh5kOWZvCX6EzqWbTCj6bk0yRCmYUNjYYQirOj9Is5qXorO53A4gbN/322DCcagBgKamxP5yj8E1OgEb5zSvuSdXhVCj8TZBtX+1Op2aMfxacLmuG92y4l0FScFKAfj4XVRt3TxuIVm9ZLkMpsBe4N3ziQBop3pKadFngcSzqc7y+7vlw/8G/uKPotxr9ncHsVWTyj5AluyCOv9nw+dLE8d9YYDhUPYDIoFS3IfsYdaKppFeakcyCxc0jpQ6BokKTpFQXzO4YeFJoJcMoP73y36jfeK2aAyCijtTXSmTGra8U69WBQwfyAavoLZwZX9eUxnMlhae5c2hnbjkuvrG8Qug9L84Wo9dDSLxvegSGkbje65qpCpZxVa8OM5ez+wiK+MVua/k7CRd7OPuSzhuT7298+hK0Gd8z/KPrDccjSYUKrceTi0wYWj8Qyt3u/76m71o4Vd+zWOOHXarmf5GmAoeYWW0mhAHoaDqVeqEuQFoeGvb72mlUGuro2pthCtgG/9Ctf0WE/tji+OFJxyNnQ7rzgl3t01ipXbzellLxXuG3kMBE1yoOhwwHWVl0bZVj8rDgIQMXCBuPC5hjceSa3Kv3LgFEnJgUCAwEAAQ==
Podemos testar o DKIM com este site.
Pode usar este outro site para ver se o registro do DKIM está correto!
O comando abaixo retorna o valor do DKIM configurado no DNS:
$ dig TXT 20230217._domainkey.hermodr.com.br
Um outro teste que podemos fazer é enviar um email para check-auth@verifier.port25.com e ele irá nos retornar um resultado, com isso testamos a assinatura do DKIM:
$ echo "test dkim" | mail -aFrom:postmaster@hermodr.com.br -s "Test from hermodr" check-auth@verifier.port25.com
O DKIM ainda não está funcional, para isso vamos fazer a parte que falta no tópico de instalação e configuração do Rspamd !
Configurando DMARC
Vamos configurar o DMARC. Você precisa adicionar a seguinte entrada no DNS:
_dmarc.hermodr.com.br IN TXT "v=DMARC1; p=reject; rua=mailto:postmaster@hermodr.com.br"
A política p especifica a ação a ser tomada com os emails que não passam na autenticação. A opção none é recomendada para começar, permitindo que os emails passem mesmo que não sejam autenticados.
O campo rua especifica um endereço de email para o qual relatórios de falhas DMARC serão enviados.
Podemos testar o DMARC com este site! ou usando o comando abaixo:
$ dig TXT _dmarc.hermodr.com.br
Configurando o SPF
Vamos configurar o DMARC. Você precisa adicionar a seguinte entrada no DNS:
IN TXT "v=spf1 mx -all"
Podemos testar o SPF com o comando abaixo:
$ dig TXT hermodr.com.br +short
Conectando no Thunderbird
Vamos conectar no nosso servidor de email usando o Thunderbird como cliente de email (MUA).
- Clique em Settings;
- Account Settings;
- Em 'Account Actions' clique em 'Add Mail Account...', preenche os campos abaixo:
Your full name: Test tests
Email Address: test@hermodr.com.br
Password: abc123
Após colocar essas opções, uma opção vai aparecer para nós, escrito Configure manually, clique nela. Agora configure como abaixo e depois clique em Done.
# Incoming Server
Protocol: IMAP
Hostname: mail.hermodr.com.br
Port: 993
Connection Security: SSL/TLS
Authentication method: Normal password
Username: test@hermodr.com.br
# Outgoing Server
Hostname: mail.hermodr.com.br
Port: 587
Connection Security: STARTTLS
Authentication method: Normal password
Username: test@hermodr.com.br
Após autenticar com sucesso será possível ver essa opção nos logs:
# Estou mudando o meu verdadeiro IP para outro:
Aug 25 11:43:10 mail dovecot: imap-login: Login: user=<test@hermodr.com.br>, method=PLAIN, rip=160.132.28.10, lip=75.119.143.187, mpid=27694, TLS, session=<0pH3BoMg8qq/oiZz>
Entendendo emails durante o envio
Após enviar um email pelo nosso usuátio test conectado no Thunderbird podemos ver nos logs esse envio de emai, vamos analisar os processos.
1. Aug 25 12:07:56 mail postfix/smtpd[31366]: connect from unknown[160.132.28.10]
2. Aug 25 12:07:57 mail postfix/smtpd[31366]: Anonymous TLS connection established from unknown[160.132.28.10]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
3. Aug 25 12:07:58 mail postfix/smtpd[31366]: 12B5A940B6C: client=unknown[160.132.28.10], sasl_method=PLAIN, sasl_username=test@hermodr.com.br
4. Aug 25 12:07:58 mail postfix/cleanup[31373]: 12B5A940B6C: message-id=<f3bd1400-fb81-4303-b3a3-f38481222447@hermodr.com.br>
5. Aug 25 12:07:58 mail postfix/qmgr[31170]: 12B5A940B6C: from=<test@hermodr.com.br>, size=664, nrcpt=1 (queue active)
6. Aug 25 12:07:58 mail postfix/smtp[31375]: Trusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:400c:c0c::1a]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256
7. Aug 25 12:07:59 mail postfix/smtp[31375]: 12B5A940B6C: to=<test@gmail.com>, relay=gmail-smtp-in.l.google.com[2a00:1450:400c:c0c::1a]:25, delay=1.8, delays=0.78/0.01/0.22/0.78, dsn=2.0.0, status=sent (250 2.0.0 OK 1724598479 ffacd0b85a97d-37308273d77si3111289f8f.818 - gsmtp)
8. Aug 25 12:07:59 mail postfix/qmgr[31170]: 12B5A940B6C: removed
9. Aug 25 12:08:03 mail postfix/smtpd[31366]: disconnect from unknown[160.132.28.10] ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 data=1 quit=1 commands=8
Como podemos ver acima para enviar um email alguns passos são seguidos:
- O cliente se conecta no servidor de email.
- É estabelecido o TLS.
- O cliente se autentica antes de enviar o email.
- Processamento do email.
- Envio para a fila.
- Conexão com o servidor de destino.
- Envio bem-sucedido.
- Remoção do email da fila.
- Desconexão do cliente.
Primeiro o Postfix recebe uma conexão de um cliente com o IP 160.132.28.10. A conexão TLS é estabelecida anonimamente, garantindo criptografia para a comunicação entre o cliente e o servidor, nesse ponto podemos ver que é usado TLSv1.3 com o uso da cifra TLS_AES_256_GCM_SHA384. Depois disso o cliente se autentica usando o método SASL PLAIN com o nome de usuário test@hermodr.com.br, não tem problema ser PLAIN porque temos o TLS (já falamos sobre as desvantagens).
O Postfix processa o email e gera um ID de mensagem único que é 12B5A940B6C. O email é colocado na fila do Postfix para envio queue active. O email tem como o remente o test@hermodr.com.br (from=<test@hermodr.com.br>) um tamanho de 664 bytes (size=664) e é destinado a um único destinatário (nrcpt=1). O Postfix então estabelece uma conexão TLS segura com o servidor de destino do Gmail usando o endereço IPv6 2a00:1450:400c:c0c::1a (passo 6).
O email é enviado com sucesso para o destinatário test@gmail.com. O status é sent, e o código de resposta do servidor de destino é 250 2.0.0 OK (passo 7). O email é removido da fila após ser enviado com sucesso e o cliente se desconecta após a conclusão do envio do email.
Entendendo o email após recebido
Após receber um email normalmente só no importamos com o Assunto, o Remetente e o Corpo do email, mas como administradores temos que entender o Envelope e o Header para conseguir identificar possíveis problemas na entrega de um email. Olhe a mensagem abaixo:
Delivered-To: test@gmail.com
Received: by 2002:a05:6a10:1693:b0:586:bd68:c25d with SMTP id gp19csp1392111pxb;
Sun, 25 Aug 2024 08:07:59 -0700 (PDT)
X-Google-Smtp-Source: AGHT+IEhVVE40Fni1ek5dbEy7bhrO8IdOXNfetFSqr4GI9loNfx19UnoUNYWmwlDipREQkVgPY6V
X-Received: by 2002:a5d:674f:0:b0:36b:c126:fe5e with SMTP id ffacd0b85a97d-37311865dc2mr4826658f8f.30.1724598479469;
Sun, 25 Aug 2024 08:07:59 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1724598479; cv=pass;
d=google.com; s=arc-20160816;
b=aBeDdoPcLQBkZWv5/ireYoxVoWZclBWSSWx631qEj0Ngrp6Et0O8aEN+qK3gTxAnnz
hRZbAgYftAn2m5kVQ3OqVeGH4xQJCLNrtO9xrwotqXLb5fpWWrLR+W3qTLpX6Nd0mcsz
erSwG7l0K+1mz014u1AWaMZWsapAlWUnXINfaHeSr0jYcxCogP+eJ1H2IKP6l0vK5pzJ
UNpp2S2zmUCxZxDybUSzkAFJo5wZ2POMTpzAqyJU37i50l3CI3SkNEO7ePt1ABdOz12C
Q35h3kvhRGO5qTjz55dXTuboqSSJ8CEfQJHFAUsHpLVfTUDjnZ93zJ3zkNxCa4sEtF3f
b+yQ==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=content-transfer-encoding:subject:from:to:content-language
:user-agent:mime-version:date:message-id:dkim-signature;
bh=yvPyQ/Kq6T8/9Pt6usuVDxM8La+nNy+ORUdD1enPQYM=;
fh=FuPj5+C6214zDl/CtlLxBco0nnXIImKUsdUoL5JT2m0=;
b=UAlPze5Z2xjY8CdutoQfkpk6JICpgjGFeThOXr+Ir1s1BPwQ3o/CtzGyFDbfrZtfnP
uhkRWNBtcIs/al4ucKpHi/ZVz0joEC5MJPFeSGzbEFN36bFaAQfZqoc8JZ7l5/6lkARU
BMgG8lVY3VlLI49UH95N1UvnA68fc6ybtuDyhHur6ZpXXJ8QzV5sEHfQvOAaIwpF2Wnu
/Zo+Get4MyJqF+RnAXbBOxrlhQdSrMEvYhQ/MOXjnkqZz9rrKuNklKu0UFdRw36SgvK5
xIsDfrtZwcuS0SLv+lj2/rTIC4jtly2moQwNGWNqPXAKMbo17zYFhtF7x9xv/OnDA0rd
mb2g==;
dara=google.com
ARC-Authentication-Results: i=2; mx.google.com;
dkim=pass header.i=@hermodr.com.br header.s=dkim header.b=Zl142UFa;
arc=pass (i=1);
spf=pass (google.com: domain of test@hermodr.com.br designates 2a02:c206:2120:1140::1 as permitted sender) smtp.mailfrom=test@hermodr.com.br;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=hermodr.com.br
Return-Path: <test@hermodr.com.br>
Received: from mail.hermodr.com.br (hermodr.com.br. [2a02:c206:2120:1140::1])
by mx.google.com with ESMTPS id ffacd0b85a97d-37308273d77si3111289f8f.818.2024.08.25.08.07.58
for <test@gmail.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sun, 25 Aug 2024 08:07:59 -0700 (PDT)
Received-SPF: pass (google.com: domain of test@hermodr.com.br designates 2a02:c206:2120:1140::1 as permitted sender) client-ip=2a02:c206:2120:1140::1;
Authentication-Results: mx.google.com;
dkim=pass header.i=@hermodr.com.br header.s=dkim header.b=Zl142UFa;
arc=pass (i=1);
spf=pass (google.com: domain of test@hermodr.com.br designates 2a02:c206:2120:1140::1 as permitted sender) smtp.mailfrom=test@hermodr.com.br;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=hermodr.com.br
Received: from [192.168.1.3] (unknown [160.132.28.10]) by mail.hermodr.com.br (Postfix) with ESMTPSA id 12B5A940B6C for <test@gmail.com>; Sun, 25 Aug 2024 12:07:57 -0300 (-03)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hermodr.com.br; s=dkim; t=1724598478; h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding; bh=yvPyQ/Kq6T8/9Pt6usuVDxM8La+nNy+ORUdD1enPQYM=; b=Zl142UFa67aOvVDt+a403DpVvaDUODCSlbdyqmZlbfHyc2MORhw7rCgr8CPh9wE66VDQpM udiOd9eSzKcRzZTYhj8Cl1dvQXC0mxYQLudpJoxaMLWmDIjMWAh12rU/2o6BtTeThMaTUj WHb2o2XqrDdziL8D/t7yCi1E4D4tqmomr4r9nAGr2YO6PkWMfKohlX5Qkxw1/yiKBX6Yz1 v4QQqe/+3UJY9GY5Ag9ygyzLdHf1/oQYz4U7loJB3+OMPbLNKcEfaDBsU0IT1dAzR+onDs Th1BZBFXm9hwdE/rPDiKe+zRgKVKDanTq5+LpC/S/M/c9W3jnJpVdar5ZizKALTGrfGEsy HiqPqyTl+iAfQlkUhdZIsaAFDtOjkbJt9XbebU2Y4AtT1PEvLnMkPnhEhsva6ol4Q5dUgU vWqk7DndvwuLxbuIJEsiLaSf5Vx5BNZj9hu1oH5r46vRCIeV7CfB+Kmk/HRfF2VT6PQiuL SmPXG4RhgNp9Sm1vhmji2IF1ZIPYsqlWX4ArZbvcWIuv4GkYTIDnMb2kFG7rTlClxuTAlj XzpkBD5y5+b7/O6dQdEbD3PytJZ0N6mPeY5mNfNPdCJNXmoja1Wx2tpoBe5mrU7dgenbzt UWH+iqpzLh2M3pebWTbPXCwYyuPQGGdgOnJ6lQ0ddQiy8paUof2m8=
Message-ID: <f3bd1400-fb81-4303-b3a3-f38481222447@hermodr.com.br>
Date: Sun, 25 Aug 2024 12:07:55 -0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: test <test@gmail.com>
From: Test tests <test@hermodr.com.br>
Subject: Documentação
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hermodr.com.br; s=dkim; t=1724598478; h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding; bh=yvPyQ/Kq6T8/9Pt6usuVDxM8La+nNy+ORUdD1enPQYM=; b=Ti3OyKl2SKB43GrFwQ8BaPETZtV9reMBZltQp1p7ecLPM6d7TnjJ7tQ05GQyXTQFcHwphj SDL5UpIFYOs/ZOXXMqg/Kj+QKG3RVX564JAZGBE/gllFUErPynK4X2x7NjTCKEGy3kFm4a UXvrrkDvlpO7gJOqisP62cqhmFV/jvJEzbqSvqkGCom2xhdP4md9bet77Y+O88jbArdG/X +ovrjsJjFY40WsiXzruKoPY8zdgMMlnERf5zF6lAIaIDk/S7BXo/xSDEYR8LploQ45DDrS VHq9nNpcZ5M1QmKaHGO1uLSsrF97ASioysR3OFgv0fvOM52gS4E6u3uDWUOPY7g622EHw6 zpfSt3qxDAQ4UrXwvw6lTyOMClrCtqeU+GzWq6dAKkh5s3gXyQ5/oYcgHQOys5ZbGEeejt emO6zfAhZZa9saN+ppYHVsTFNascPCtUGi+Wf/NgtsO8oxVX/ap/67dIbpE8oiYgu36BKz G31yxbgQHKm5AMCZUFWl0bJJUFytGgDn1FII+gcGz7pCF9XxXwxRb5KwkeXrMsKpygilTY Gdkh9GhsZlbRRydeHbhQfrdb55B6qelvJq6gk1hIRiw/ix6nln02Zt1kPeLlwVrTGMf5nF Dc5SuAMwZfhwzrS5j6HlOup7aRLRF//y5lLHkjsD1CJ5ppWjb9nG8=
ARC-Seal: i=1; s=dkim; d=hermodr.com.br; t=1724598478; a=rsa-sha256; cv=none; b=JLo3ABrUmK1Nz3LzNpX7uM6gDOSIOktjFk7z4eEXP4ZhwwEn2KSQoO9mm7JRuiHRDcjMrA QoLMBTAJSs1ioOfhIs7mEuhYnLGpZLz+Pu9gD49cxFGAS9CMvD5Ux18m3nOeXixX7yD9sX lRf9HTMHV6HydvEBBwfQga+SPDqba0aq48roWJ7w3Ihm0kIqHU4AQOEGpJ+7XUsoeMlq2F a5YIxBBoPN+y4mbvBjf9fh/LIE6NC4yngSQJ7vDrNVY06x4tDRj2aOxdizlYy9NvfGd9eo X7SpkqcDtPEOhTngQtM51a37XG9qnEmHDcAIQ6HzHNCSGQNIYNxD2wb3D5fS8rF9ozXmFe R0JXe3EEkWJ83XsuXKN5nDbk2enGgYJPvytI+r5/ptlt97lKFgzB1KBbYvLjzCpDMDpVZz 8EaizOruf9VRyGvfINPGj5A5isUVQvdrIJzw9kbDG0NUradUBUN5nPwyLJMCoEeBzSeUsy 06rJ577vBRA8Cd2kog67kay5ZBUK4qnfRAml0kqMyqX42ngZIpwdVw26vybyYRfhtYSxv4 IClDhJSyuCXszxGEopFvxLjTz3x8RqxQnXI/WPkDDgv1JshLkI1ENbKtQ8dHNNVkwxoQlM EMt5/NMSHwBGbfWlQJdGhkSHWZNaNhENmw9TuzjCRKqAJThEZOmZM=
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=test@hermodr.com.br smtp.mailfrom=test@hermodr.com.br
X-Rspamd-Queue-Id: 12B5A940B6C
X-Spamd-Result: default: False [0.91 / 15.00];
ARC_NA(0.00)[];
XM_UA_NO_VERSION(0.01)[];
FROM_HAS_DN(0.00)[];
TO_MATCH_ENVRCPT_ALL(0.00)[];
FREEMAIL_ENVRCPT(0.00)[gmail.com];
MIME_GOOD(-0.10)[text/plain];
ARC_SIGNED(0.00)[hermodr.com.br:s=dkim:i=1];
RCPT_COUNT_ONE(0.00)[1];
DKIM_SIGNED(0.00)[hermodr.com.br:s=dkim];
TO_DN_ALL(0.00)[];
FREEMAIL_TO(0.00)[gmail.com];
RCVD_COUNT_ZERO(0.00)[0];
FROM_EQ_ENVFROM(0.00)[];
MIME_TRACE(0.00)[0:+];
R_MIXED_CHARSET(1.00)[];
ASN(0.00)[asn:26615, ipnet:191.162.32.0/19, country:BR];
MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Server: mail.hermodr.com.br
A documentação está quase pronta.
Vamos separar em partes para entender toda essa bagunça de informações. Começaremos vendo quando o email foi recebido. Cada servidor de email que processa a mensagem adiciona uma nova entrada Received ao cabeçalho, indicando o servidor que processou o email e a data/hora do processamento.
Received: by 2002:a05:6a10:1693:b0:586:bd68:c25d with SMTP id gp19csp1392111pxb;
Sun, 25 Aug 2024 08:07:59 -0700 (PDT)
X-Received: by 2002:a5d:674f:0:b0:36b:c126:fe5e with SMTP id ffacd0b85a97d-37311865dc2mr4826658f8f.30.1724598479469;
Sun, 25 Aug 2024 08:07:59 -0700 (PDT)
Received: from mail.hermodr.com.br (hermodr.com.br. [2a02:c206:2120:1140::1])
by mx.google.com with ESMTPS id ffacd0b85a97d-37308273d77si3111289f8f.818.2024.08.25.08.07.58
for <test@gmail.com>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sun, 25 Aug 2024 08:07:59 -0700 (PDT)
O
X-Receivedé um cabeçalho personalizado que pode ser adicionado por servidores de e-mail específicos, especialmente servidores de e-mail do Google, como Gmail.
Vamos agora ver os cabeçalhos do sistema de autenticação de e-mail ARC (Authenticated Received Chain), projetado para ajudar a manter a integridade e a autenticidade das mensagens de e-mail em cenários complexos de roteamento.
ARC-Seal: i=2; a=rsa-sha256; t=1724598479; cv=pass;
d=google.com; s=arc-20160816;
b=aBeDdoPcLQBkZWv5/ireYoxVoWZclBWSSWx631qEj0Ngrp6Et0O8aEN+qK3gTxAnnz
hRZbAgYftAn2m5kVQ3OqVeGH4xQJCLNrtO9xrwotqXLb5fpWWrLR+W3qTLpX6Nd0mcsz
erSwG7l0K+1mz014u1AWaMZWsapAlWUnXINfaHeSr0jYcxCogP+eJ1H2IKP6l0vK5pzJ
UNpp2S2zmUCxZxDybUSzkAFJo5wZ2POMTpzAqyJU37i50l3CI3SkNEO7ePt1ABdOz12C
Q35h3kvhRGO5qTjz55dXTuboqSSJ8CEfQJHFAUsHpLVfTUDjnZ93zJ3zkNxCa4sEtF3f
b+yQ==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
h=content-transfer-encoding:subject:from:to:content-language
:user-agent:mime-version:date:message-id:dkim-signature;
bh=yvPyQ/Kq6T8/9Pt6usuVDxM8La+nNy+ORUdD1enPQYM=;
fh=FuPj5+C6214zDl/CtlLxBco0nnXIImKUsdUoL5JT2m0=;
b=UAlPze5Z2xjY8CdutoQfkpk6JICpgjGFeThOXr+Ir1s1BPwQ3o/CtzGyFDbfrZtfnP
uhkRWNBtcIs/al4ucKpHi/ZVz0joEC5MJPFeSGzbEFN36bFaAQfZqoc8JZ7l5/6lkARU
BMgG8lVY3VlLI49UH95N1UvnA68fc6ybtuDyhHur6ZpXXJ8QzV5sEHfQvOAaIwpF2Wnu
/Zo+Get4MyJqF+RnAXbBOxrlhQdSrMEvYhQ/MOXjnkqZz9rrKuNklKu0UFdRw36SgvK5
xIsDfrtZwcuS0SLv+lj2/rTIC4jtly2moQwNGWNqPXAKMbo17zYFhtF7x9xv/OnDA0rd
mb2g==;
dara=google.com
ARC-Authentication-Results: i=2; mx.google.com;
dkim=pass header.i=@hermodr.com.br header.s=dkim header.b=Zl142UFa;
arc=pass (i=1);
spf=pass (google.com: domain of test@hermodr.com.br designates 2a02:c206:2120:1140::1 as permitted sender) smtp.mailfrom=test@hermodr.com.br;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=hermodr.com.br
Explicação
O ARC-Seal é usado para assinar e proteger a cadeia de autenticação ARC inteira. Ele ajuda a garantir que a autenticação ARC não foi modificada durante o transporte. Nós configuramos ele com a mesma configuração do DKIM, outros parâmetros do ARC mantemos os defaults.
- As opções apresentadas são:
i=2: Índice do registro ARC, indicando a ordem do cabeçalho ARC na cadeia.a=rsa-sha256: Algoritmo de assinatura usado (RSA com SHA-256).t=1724598479: Timestamp Unix que indica quando o cabeçalho foi assinado.cv=pass: Indica que a verificação da cadeia de autenticação foi bem-sucedida.d=google.com: Domínio que criou a assinatura.s=arc-20160816: Selector de assinatura ARC usado.b=...: Valor da assinatura digital.
O ARC-Message-Signature é uma assinatura digital que autentica o conteúdo da mensagem e garante que ele não foi alterado desde que foi assinado.
- As opções apresentadas são:
i=2: Índice da assinatura na cadeia ARC.a=rsa-sha256: Algoritmo de assinatura usado.c=relaxed/relaxed: Canonicalização usada para criar a assinatura (relaxed para headers e corpo).d=google.com: Domínio que criou a assinatura.s=arc-20160816: Selector de assinatura ARC.h=...: Cabeçalhos incluídos na assinatura.bh=...: Hash do corpo da mensagem.fh=...: Hash dos cabeçalhos.b=...: Valor da assinatura digital.
O ARC-Authentication-Results fornece o resultado das verificações de autenticação realizadas pelo servidor de e-mail que adicionou o cabeçalho ARC.
- As opções apresentadas são:
i=2: Índice dos resultados ARC na cadeia.mx.google.com: Servidor que produziu os resultados.dkim=pass header.i=@hermodr.com.br header.s=dkim header.b=...: Resultado da verificação DKIM, indicando que a assinatura DKIM é válida.arc=pass (i=1): Resultado da verificação ARC anterior na cadeia.spf=pass: Resultado da verificação SPF, indicando que o IP do remetente está autorizado pelo domínio.dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=hermodr.com.br: Resultado da verificação DMARC, indicando que a mensagem passou na política DMARC definida pelo domínio.
Esse foi para o recebimento no servidor SMTP do Google, mas também temos para saída no nosso servidor.
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hermodr.com.br; s=dkim; t=1724598478; h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding; bh=yvPyQ/Kq6T8/9Pt6usuVDxM8La+nNy+ORUdD1enPQYM=; b=Ti3OyKl2SKB43GrFwQ8BaPETZtV9reMBZltQp1p7ecLPM6d7TnjJ7tQ05GQyXTQFcHwphj SDL5UpIFYOs/ZOXXMqg/Kj+QKG3RVX564JAZGBE/gllFUErPynK4X2x7NjTCKEGy3kFm4a UXvrrkDvlpO7gJOqisP62cqhmFV/jvJEzbqSvqkGCom2xhdP4md9bet77Y+O88jbArdG/X +ovrjsJjFY40WsiXzruKoPY8zdgMMlnERf5zF6lAIaIDk/S7BXo/xSDEYR8LploQ45DDrS VHq9nNpcZ5M1QmKaHGO1uLSsrF97ASioysR3OFgv0fvOM52gS4E6u3uDWUOPY7g622EHw6 zpfSt3qxDAQ4UrXwvw6lTyOMClrCtqeU+GzWq6dAKkh5s3gXyQ5/oYcgHQOys5ZbGEeejt emO6zfAhZZa9saN+ppYHVsTFNascPCtUGi+Wf/NgtsO8oxVX/ap/67dIbpE8oiYgu36BKz G31yxbgQHKm5AMCZUFWl0bJJUFytGgDn1FII+gcGz7pCF9XxXwxRb5KwkeXrMsKpygilTY Gdkh9GhsZlbRRydeHbhQfrdb55B6qelvJq6gk1hIRiw/ix6nln02Zt1kPeLlwVrTGMf5nF Dc5SuAMwZfhwzrS5j6HlOup7aRLRF//y5lLHkjsD1CJ5ppWjb9nG8=
ARC-Seal: i=1; s=dkim; d=hermodr.com.br; t=1724598478; a=rsa-sha256; cv=none; b=JLo3ABrUmK1Nz3LzNpX7uM6gDOSIOktjFk7z4eEXP4ZhwwEn2KSQoO9mm7JRuiHRDcjMrA QoLMBTAJSs1ioOfhIs7mEuhYnLGpZLz+Pu9gD49cxFGAS9CMvD5Ux18m3nOeXixX7yD9sX lRf9HTMHV6HydvEBBwfQga+SPDqba0aq48roWJ7w3Ihm0kIqHU4AQOEGpJ+7XUsoeMlq2F a5YIxBBoPN+y4mbvBjf9fh/LIE6NC4yngSQJ7vDrNVY06x4tDRj2aOxdizlYy9NvfGd9eo X7SpkqcDtPEOhTngQtM51a37XG9qnEmHDcAIQ6HzHNCSGQNIYNxD2wb3D5fS8rF9ozXmFe R0JXe3EEkWJ83XsuXKN5nDbk2enGgYJPvytI+r5/ptlt97lKFgzB1KBbYvLjzCpDMDpVZz 8EaizOruf9VRyGvfINPGj5A5isUVQvdrIJzw9kbDG0NUradUBUN5nPwyLJMCoEeBzSeUsy 06rJ577vBRA8Cd2kog67kay5ZBUK4qnfRAml0kqMyqX42ngZIpwdVw26vybyYRfhtYSxv4 IClDhJSyuCXszxGEopFvxLjTz3x8RqxQnXI/WPkDDgv1JshLkI1ENbKtQ8dHNNVkwxoQlM EMt5/NMSHwBGbfWlQJdGhkSHWZNaNhENmw9TuzjCRKqAJThEZOmZM=
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=test@hermodr.com.br smtp.mailfrom=test@hermodr.com.br
Explicação
Para o ARC-Message-Signature nós temos:
- i=1: Indica a instância do ARC. Para cada estágio na cadeia ARC, um novo
ié gerado. - a=rsa-sha256: Algoritmo de assinatura, neste caso, RSA com SHA-256.
- c=relaxed/relaxed: Algoritmo de canonicalização, onde o conteúdo e os cabeçalhos são normalizados antes da assinatura.
- d=hermodr.com.br: Domínio que está assinando a mensagem.
- s=dkim: Seletor usado para encontrar a chave pública de assinatura.
- t=1724598478: Timestamp da assinatura.
- h=...: Cabeçalhos usados na assinatura.
- bh=...: Hash do corpo da mensagem.
- b=...: Assinatura propriamente dita.
Para o **ARC-Seal** nós temos:
- i=1: Indica a instância do ARC Seal.
- s=dkim: Seletor para encontrar a chave pública de assinatura.
- d=hermodr.com.br: Domínio que assinou a mensagem.
- t=1724598478: Timestamp do ARC Seal.
- a=rsa-sha256: Algoritmo de assinatura, neste caso, RSA com SHA-256.
- cv=none: Resultado da verificação da assinatura.
nonesignifica que a verificação não foi realizada ou não foi possível. - b=...: Assinatura propriamente dita.
Por fim o **ARC-Authentication-Results**:
- i=1: Instância da ARC Authentication Results.
- ORIGINATING: Indica que a verificação dos resultados da autenticação é feita na origem do e-mail.
- auth=pass: O resultado da autenticação SMTP passou.
- smtp.auth=test@hermodr.com.br: Autenticador SMTP que foi usado.
- smtp.mailfrom=test@hermodr.com.br: Endereço de e-mail usado para autenticação.
Logo após as mensagens acima, podemos ver uma verificação de autenticação de e-mails em um servidor do Google.
Received-SPF: pass (google.com: domain of test@hermodr.com.br designates 2a02:c206:2120:1140::1 as permitted sender) client-ip=2a02:c206:2120:1140::1;
Explicação
A primeira linha mostra que o validou o SPF para nosso domínio e ele passou nessa validação.
- Received-SPF: Indica o resultado da verificação SPF para o e-mail.
- pass: O e-mail passou na verificação SPF.
- google.com: O servidor do Google está verificando o e-mail.
- domain of test@hermodr.com.br designates 2a02:c206:2120:1140::1 as permitted sender: O domínio
hermodr.com.brdesigna o endereço IP2a02:c206:2120:1140::1como um remetente autorizado, conforme definido no registro SPF do domínio. - client-ip=2a02:c206:2120:1140::1: O IP do SMTP que enviou o e-mail para o MTA do Google.
A próxima linha vamos analisar algo importante, é um Received mas que contém algumas informações cruciais para rastrear o caminho do e-mail e verificar a origem e o servidor que processou o e-mail.
Received: from [192.168.1.3] (unknown [160.132.28.10]) by mail.hermodr.com.br (Postfix) with ESMTPSA id 12B5A940B6C for <test@gmail.com>; Sun, 25 Aug 2024 12:07:57 -0300 (-03)
Explicação
- from [192.168.1.3] (unknown [160.132.28.10])
O [192.168.1.3] é o IP local do cliente que enviou o e-mail, ou seja, é o meu endereço IP na minha rede local. O unknown [160.132.28.10] é o IP público do cliente, ou seja, é o meu endereço IP público, que é usado para se comunicar com servidores na Internet. O "unknown" pode indicar que o servidor de recebimento não conseguiu resolver um nome de host para o IP público.
O by mail.hermodr.com.br (Postfix) indica o servidor que recebeu o e-mail, nesse caso, é o servidor mail.hermodr.com.br e o (Postfix) é o software que está sendo usado no servidor de e-mail.
O with ESMTPSA id 12B5A940B6C indica que a comunicação foi feita usando SMTP com STARTTLS (encriptação) e autenticação e o ID desse email é id 12B5A940B6C.
O for test@gmail.com indica o destinatário final do e-mail. Também podemos ver a data e hora em que o email foi recebido pelo servidor mail.hermodr.com.br Sun, 25 Aug 2024 12:07:57 -0300 (-03).
Agora vamos analisar informações que temos um contato maior sobre quem enviou o email, para onde e alguns outros cabeçalhos.
Message-ID: <f3bd1400-fb81-4303-b3a3-f38481222447@hermodr.com.br>
Date: Sun, 25 Aug 2024 12:07:55 -0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Test <test@gmail.com>
From: Test tests <test@hermodr.com.br>
Subject: Documentação
Content-Type: text/plain; charset=UTF-8; format=flowed
Explicação
Message-ID indica o identificador único para a mensagem. Este ID é gerado pelo servidor de e-mail do remetente e deve ser único para cada e-mail enviado. É útil para rastreamento e referência.
Date indica a data e hora em que o e-mail foi enviado. O horário é no fuso horário GMT-3, que corresponde ao horário de Brasília. Essa informação ajuda a entender o tempo de envio do e-mail.
MIME-Version indica a versão do protocolo MIME usada para formatar o e-mail. O MIME é essencial para a codificação de e-mails que contêm texto e anexos.
User-Agent mostra o cliente de e-mail usado para enviar a mensagem. Isso pode ajudar a identificar o software ou aplicativo usado pelo remetente.
Content-Language indica o idioma do conteúdo do e-mail. Neste caso, é o inglês (Estados Unidos). Isso pode ser usado para determinar o idioma em que o e-mail está escrito e ajustar a exibição ou tratamento do conteúdo conforme necessário.
To indica o destinatário do e-mail. Inclui o nome e o endereço de e-mail.
From indica o remetente do e-mail. Inclui o nome e o endereço de e-mail do remetente.
Subject indica o assunto do e-mail. Este é o título que aparece na caixa de entrada do destinatário e ajuda a identificar o conteúdo do e-mail.
O Content-Type especifica o tipo de conteúdo do email. O text/plain indica que é do tipo texto simples. Já charset=UTF-8 indica que o conjunto de caracteres usado, que é UTF-8. Isso é importante para garantir que caracteres especiais e diferentes idiomas sejam exibidos corretamente. O format=flowed indica que o texto pode ser formatado de maneira fluida, permitindo a quebra automática de linhas em leitores de e-mail que suportam esse formato.
Logo em seguida vamos ver informações adicionadas pelo Rspamd para validação de spam.
X-Rspamd-Queue-Id: 12B5A940B6C
X-Spamd-Result: default: False [0.91 / 15.00];
ARC_NA(0.00)[];
XM_UA_NO_VERSION(0.01)[];
FROM_HAS_DN(0.00)[];
TO_MATCH_ENVRCPT_ALL(0.00)[];
FREEMAIL_ENVRCPT(0.00)[gmail.com];
MIME_GOOD(-0.10)[text/plain];
ARC_SIGNED(0.00)[hermodr.com.br:s=dkim:i=1];
RCPT_COUNT_ONE(0.00)[1];
DKIM_SIGNED(0.00)[hermodr.com.br:s=dkim];
TO_DN_ALL(0.00)[];
FREEMAIL_TO(0.00)[gmail.com];
RCVD_COUNT_ZERO(0.00)[0];
FROM_EQ_ENVFROM(0.00)[];
MIME_TRACE(0.00)[0:+];
R_MIXED_CHARSET(1.00)[];
ASN(0.00)[asn:00000, ipnet:160.132.28.0/19, country:BR];
MID_RHS_MATCH_FROM(0.00)[]
X-Rspamd-Server: mail.hermodr.com.br
Explicação
Antes de começar a explicar, saiba que os parâmetros asn:00000 e ipnet:160.132.28.0/19 foram modificados para omitir seus valores reais. Os cabeçalhos X-Rspamd-Queue-Id e X-Spamd-Result fornecem informações valiosas sobre como o Rspamd, o filtro de spam que estamos utilizando, avaliou a mensagem.
Em X-Rspamd-Queue-Id temos o valor de 12B5A940B6C, ele é um identificador único para a mensagem na fila do Rspamd. Ele é útil para rastreamento e diagnósticos no sistema de filtragem de spam, permitindo que seja consultado ou investigado a mensagem específica no log do Rspamd.
O X-Spamd-Result é um cabeçalho que mostra o resultado da análise de spam realizada pelo Rspamd, incluindo uma pontuação e uma lista de testes com suas respectivas pontuações, isso é muito importante quando um email é bloqueado por ter algum spam ou virus.
Analisemos a linha: default: False [0.91 / 15.00]. O default: False indica que o e-mail não foi classificado como spam com base na configuração padrão, já o [0.91 / 15.00] mostra a pontuação total do e-mail foi 0.91, enquanto o limiar para considerar uma mensagem como spam é 15.00. Portanto, a mensagem está bem abaixo do limite e não é considerada spam.
- ARC_NA(0.00)[]: O teste ARC (Authenticated Received Chain) não se aplica a esta mensagem, ou o resultado é neutro.
- XM_UA_NO_VERSION(0.01)[]: O cliente de e-mail (User Agent) não especificou uma versão. A pontuação é muito baixa e não impacta a classificação geral.
- FROM_HAS_DN(0.00)[]: O endereço do remetente contém um nome. Isso é neutro e não afeta a pontuação.
- TO_MATCH_ENVRCPT_ALL(0.00)[]: Todos os destinatários no cabeçalho
Tocorrespondem aos destinatários noRCPT TOdo e-mail. Isso é um resultado esperado e não afeta a pontuação. - FREEMAIL_ENVRCPT(0.00)[gmail.com]: O e-mail foi enviado para um domínio de e-mail gratuito (gmail.com). Embora usar domínio gratuito possa ser uma característica de spam, nesse caso não é.
- MIME_GOOD(-0.10)[text/plain]: O tipo MIME é
text/plain, que é considerado bom e reduz a pontuação de spam. - ARC_SIGNED(0.00)[hermodr.com.br:s=dkim:i=1]: A mensagem foi assinada com ARC, o que é positivo. A assinatura ARC é verificada com o domínio
hermodr.com.bre a chavedkim. - RCPT_COUNT_ONE(0.00)[1]: Há apenas um destinatário, o que é esperado e não afeta a pontuação.
- DKIM_SIGNED(0.00)[hermodr.com.br:s=dkim]: A mensagem foi assinada com DKIM, o que é positivo para a autenticidade e reduz a pontuação de spam.
- TO_DN_ALL(0.00)[]: Todos os endereços
Totêm um nome de domínio correspondente. Isso é neutro. - FREEMAIL_TO(0.00)[gmail.com]: O endereço
Toé um domínio de e-mail gratuito. Similar aoFREEMAIL_ENVRCPT, essa característica é neutra aqui. - RCVD_COUNT_ZERO(0.00)[0]: O e-mail não foi recebido por outros servidores intermediários (na verificação local), o que é neutro e esperado.
- FROM_EQ_ENVFROM(0.00)[]: O endereço do remetente (
From) corresponde ao endereço no cabeçalhoEnvelope From, o que é esperado e neutro. - MIME_TRACE(0.00)[0:+]: Não há problemas no rastreamento MIME. A pontuação é neutra.
- R_MIXED_CHARSET(1.00)[]: O e-mail contém caracteres de diferentes conjuntos de caracteres. Esse fator pode levantar uma bandeira vermelha para spam, mas ainda é uma única característica em uma lista de verificações.
- ASN(0.00)[asn:00000, ipnet:160.132.28.0/19, country:BR]: O endereço IP do remetente está associado a um ASN e um país específico. Isso é neutro e não afeta a pontuação.
- MID_RHS_MATCH_FROM(0.00)[]: A parte direita do
Message-IDcorresponde ao domínio do remetente, o que é esperado e neutro.
Email recusado
Abaixo vamos analisar uma mensagem bloqueada pelo Gmail no envio de um anexo. É sempre bom solicitar o email completo para que possamos analisar o Header.
This is the mail system at host mail.hermodr.com.br.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<test@gmail.com>: host gmail-smtp-in.l.google.com[108.177.15.27] said:
552-5.7.0 This message was blocked because its content presents a potential
552-5.7.0 security issue. To review our message content and attachment
content 552-5.7.0 guidelines, go to 552 5.7.0
https://support.google.com/mail/?p=BlockedMessage
ffacd0b85a97d-37308201042si3218084f8f.497 - gsmtp (in reply to end of DATA
command)
Reporting-MTA: dns; mail.hermodr.com.br
X-Postfix-Queue-ID: C5BE2940B92
X-Postfix-Sender: rfc822; test@hermodr.com.br
Arrival-Date: Sun, 25 Aug 2024 14:36:27 -0300 (-03)
Final-Recipient: rfc822; test@gmail.com
Original-Recipient: rfc822;test@gmail.com
Action: failed
Status: 5.7.0
Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 552-5.7.0 This message was blocked because its content
presents a potential 552-5.7.0 security issue. To review our message
content and attachment content 552-5.7.0 guidelines, go to 552 5.7.0
https://support.google.com/mail/?p=BlockedMessage
ffacd0b85a97d-37308201042si3218084f8f.497 - gsmtp
Vamos analisar o email acima.
# O email foi bloqueado porque um conteúdo presente é um risco em potencial,
# mas ainda não sabemos o que é:
<test@gmail.com>: host gmail-smtp-in.l.google.com[108.177.15.27] said:
552-5.7.0 This message was blocked because its content presents a potential
552-5.7.0 security issue. To review our message content and attachment
content 552-5.7.0 guidelines, go to 552 5.7.0
https://support.google.com/mail/?p=BlockedMessage
ffacd0b85a97d-37308201042si3218084f8f.497 - gsmtp (in reply to end of DATA
command)
# Temos o ID do email:
X-Postfix-Queue-ID: C5BE2940B92
# Quem enviou:
X-Postfix-Sender: rfc822; test@hermodr.com.br
# Quem iria receber:
Final-Recipient: rfc822; test@gmail.com
Vamos tentar descobrir que anexo a pessoa enviou.
# Primeiro vamos pesquisar o ID do email:
╼ $ grep C5BE2940B92 /var/log/mail.log
Aug 25 14:36:28 mail postfix/cleanup[36462]: C5BE2940B92: message-id=<2b868db7-01cd-4687-93cd-5a54e21bcd6a@hermodr.com.br>
Aug 25 14:36:29 mail postfix/bounce[36466]: C5BE2940B92: sender non-delivery notification: 091E5940BA4
Sabemos qual é o ID da mensagem de retorno, após receber o erro (091E5940BA4) na entrega do email, isso é útil para ver onde o email e retorno foi salvo e também sabemos qual é o ID da mensagem que foi enviada (2b868db7-01cd-4687-93cd-5a54e21bcd6a@hermodr.com.br). Agora vamos ver no Rspamd.
# Ver onde foi salvo a mensagem do erro:
╼ $ grep 091E5940BA4 /var/log/mail.log
Aug 25 14:36:29 mail dovecot: lda(test@hermodr.com.br)<36468><+C7VC51ry2Z0jgAAJicUuw>: msgid=<20240825173629.091E5940BA4@mail.hermodr.com.br>: saved mail to INBOX
## Outro método para ver onde foi salvo a mensagem do erro:
╼ $ doveadm search -u test@hermodr.com.br HEADER Message-ID 091E5940BA4
cdd33b33fe42cb662e6c0000262714bb 4
### Agora traduza a informação de cima:
╼ $ doveadm fetch -u test@hermodr.com.br "mailbox" mailbox-guid cdd33b33fe42cb662e6c0000262714bb uid 4
mailbox: INBOX
# Primeiro vamos pesquisar o ID do email:
╼ $ grep C5BE2940B92 /var/log/rspamd/rspamd.log
2024-08-25 14:36:28 #36001(rspamd_proxy) <82e1e0>; proxy; rspamd_task_write_log: id: <2b868db7-01cd-4687-93cd-5a54e21bcd6a@hermodr.com.br>, qid: <C5BE2940B92>, ip: 160.132.28.10, user: test@hermodr.com.br, from: <test@hermodr.com.br>, (default: F (no action): [4.01/15.00] [MIME_BAD_EXTENSION(4.00){bat;},MIME_GOOD(-0.10){multipart/mixed;text/plain;},MIME_UNKNOWN(0.10){application/x-msdos-program;},XM_UA_NO_VERSION(0.01){},ARC_NA(0.00){},ARC_SIGNED(0.00){hermodr.com.br:s=dkim:i=1;},ASN(0.00){asn:26615, ipnet:191.162.32.0/19, country:BR;},DKIM_SIGNED(0.00){hermodr.com.br:s=dkim;},FREEMAIL_ENVRCPT(0.00){gmail.com;},FREEMAIL_TO(0.00){gmail.com;},FROM_EQ_ENVFROM(0.00){},FROM_HAS_DN(0.00){},HAS_ATTACHMENT(0.00){},MID_RHS_MATCH_FROM(0.00){},MIME_TRACE(0.00){0:+;1:+;2:-;2:~;},RCPT_COUNT_ONE(0.00){1;},RCVD_COUNT_ZERO(0.00){0;},TO_DN_ALL(0.00){},TO_MATCH_ENVRCPT_ALL(0.00){}]), len: 808, time: 69.436ms, dns req: 1, digest: <99b5f2dd2688d4e24b364299fe1a8e3d>, rcpts: <test@gmail.com>, mime_rcpts: <test@gmail.com>
Podemos ver que o Rspamd classificou com 4.01 de 15.00. O filtro que mais recebeu pontuação foi o MIME_BAD_EXTENSION com pontuação de 4.00 e bat é o tipo do arquivo anexado, indicando ser um .bat, um tipo de anexo que o Google bloqueia por segurança. Para reforçar isso podemos ver em MIME_UNKNOWN, ele diz que o tipo do MIME para o anexo é do tipo application/x-msdos-program.
Já sabemos onde foi salvo a mensagem do erro, mas e como ver o conteúdo dela? Não é legal fazer isso sem a permissão do usuário, vou deixar os comandos apenas para vermos os pontos importantes.
# Ver o ID da mensagem '2b868db7-01cd-4687-93cd-5a54e21bcd6a@hermodr.com.br', para acessarmos especificamente ela:
╼ $ search -u test@hermodr.com.br HEADER Message-ID 2b868db7-01cd-4687-93cd-5a54e21bcd6a@hermodr.com.br
20d25b02fa45cb662e6c0000262714bb 9
# Ver onde foi salvo a mensagem:
╼ $ doveadm fetch -u test@hermodr.com.br "mailbox" mailbox-guid 20d25b02fa45cb662e6c0000262714bb uid 9
mailbox: Sent
## Nesse caso vamos ver os detalhes do email de envio!
# Ler todo o email:
╼ $ doveadm fetch -u test@hermodr.com.br "text" mailbox-guid 20d25b02fa45cb662e6c0000262714bb uid 9
# Aqui podemos ver o Subject, From, To:
╼ $ doveadm fetch -u test@hermodr.com.br "hdr" mailbox-guid 20d25b02fa45cb662e6c0000262714bb uid 9
# Ver o nome do anexo:
╼ $ doveadm fetch -u test@hermodr.com.br "body" mailbox-guid 20d25b02fa45cb662e6c0000262714bb uid 9 | grep -E "filename="
Content-Disposition: attachment; filename="exe.bat"
Email com virus
Agora vamos fazer um teste enviando um email com virus, estou usando um arquivo txt para não ter problemas, o conteúdo do arquivo é considerado malicioso. Se você quiser testar também estou usando esse site https://secure.eicar.org/eicar.com.txt.
Ao enviar o email com o arquivo em anexo tanto pelo Gmail quanto pelo Thunderbird eu tive uma surpresa boa, nenhum dos dois me deixa enviar o email, o Gmail informa que identificou um virus e o Thunderbird me retorna a mensagem abaixo:
# Mensagem mostrada no Thunderbird:
Sending of the message failed.
An error occurred while sending mail. The mail server responded: clamav: virus found: "{HEX}EICAR.TEST.3.UNOFFICIAL". Please check the message and try again.
# Logs do postfix:
Aug 25 15:47:40 mail postfix/cleanup[37439]: 3B72C940B92: milter-reject: END-OF-MESSAGE from unknown[160.132.28.10]: 5.7.1 clamav: virus found: "{HEX}EICAR.TEST.3.UNOFFICIAL"; from=<test@hermodr.com.br> to=<test@gmail.com> proto=ESMTP helo=<[192.168.1.3]>
# Logs do Rspamd:
2024-08-25 15:47:40 #36001(rspamd_proxy) <5a8d5d>; proxy; rspamd_add_passthrough_result: <87067cc9-40a1-41e3-a962-91f18bc11de3@hermodr.com.br>: set pre-result to 'reject' (no score): 'clamav: virus found: "{HEX}EICAR.TEST.3.UNOFFICIAL"' from clamav(1)
2024-08-25 15:47:40 #36001(rspamd_proxy) <5a8d5d>; proxy; rspamd_task_write_log: id: <87067cc9-40a1-41e3-a962-91f18bc11de3@hermodr.com.br>, qid: <3B72C940B92>, ip: 160.132.28.10, user: test@hermodr.com.br, from: <test@hermodr.com.br>, (default: T (reject): [8.01/15.00] [MIME_DOUBLE_BAD_EXTENSION(6.00){.com.txt;},CTYPE_MIXED_BOGUS(1.00){},MIME_BASE64_TEXT_BOGUS(1.00){},MIME_BASE64_TEXT(0.10){},MIME_GOOD(-0.10){multipart/mixed;text/plain;},XM_UA_NO_VERSION(0.01){},ARC_NA(0.00){},ARC_SIGNED(0.00){hermodr.com.br:s=dkim:i=1;},ASN(0.00){asn:26615, ipnet:191.162.32.0/19, country:BR;},CLAM_VIRUS(0.00){{HEX}EICAR.TEST.3.UNOFFICIAL;},DKIM_SIGNED(0.00){hermodr.com.br:s=dkim;},FROM_EQ_ENVFROM(0.00){},FROM_HAS_DN(0.00){},HAS_ATTACHMENT(0.00){},MID_RHS_MATCH_FROM(0.00){},MIME_TRACE(0.00){0:+;1:+;2:-;2:+;},RCPT_COUNT_ONE(0.00){1;},RCVD_COUNT_ZERO(0.00){0;},TO_DN_NONE(0.00){},TO_MATCH_ENVRCPT_ALL(0.00){}]), len: 886, time: 50.203ms, dns req: 1, digest: <d30ea47854c79b34d00688ac8b894c9d>, rcpts: <test@gmail.com>, mime_rcpts: <test@gmail.com>, forced: reject "clamav: virus found: "{HEX}EICAR.TEST.3.UNOFFICIAL""; score=nan (set by clamav)
Para que o envio funcione eu enviei ele de outro servidor usando o terminal, para isso foi necessário desativar o rspamd. Nesse cenário vamos pensar que recebemos uma mensagem de alguém informando que ao enviar email para alguém da nossa empresa ele está dando erro. Nós solicitamos então que a pessoa copie toda a mensagem de erro para nos enviar; ela precisa copiar e colar e não encaminhar a mensagem, se encaminhar vai dar erro de novo.
A pessoa então nos enviou abaixo a mensagem de erro:
This is the mail system at host mail.wlf.eti.br.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<test@hermodr.com.br>: host mail.hermodr.com.br[2a02:c206:2120:1140::1] said:
554 5.7.1 clamav: virus found: "{HEX}EICAR.TEST.3.UNOFFICIAL" (in reply to
end of DATA command)
[-- Attachment #2: Delivery report --]
[-- Type: message/delivery-status, Encoding: 7bit, Size: 0.4K --]
Reporting-MTA: dns; mail.wlf.eti.br
X-Postfix-Queue-ID: A5249240537
X-Postfix-Sender: rfc822; root@mail.wlf.eti.br
Arrival-Date: Sun, 25 Aug 2024 16:02:05 -0300 (-03)
Final-Recipient: rfc822; test@hermodr.com.br
Original-Recipient: rfc822;test@hermodr.com.br
Action: failed
Status: 5.7.1
Remote-MTA: dns; mail.hermodr.com.br
Diagnostic-Code: smtp; 554 5.7.1 clamav: virus found:
"{HEX}EICAR.TEST.3.UNOFFICIAL"
[-- Attachment #3: Undelivered Message --]
[-- Type: message/rfc822, Encoding: 8bit, Size: 0.7K --]
Date: Sun, 25 Aug 2024 16:02:05 -0300
From: root <root@wlf.eti.br>
To: test@hermodr.com.br
Subject: Teste de virus
[-- Attachment #1 --]
[-- Type: text/plain, Encoding: 7bit, Size: 0.1K --]
Virus
[-- Attachment #2: eicar.com.txt --]
[-- Type: text/plain, Encoding: 7bit, Size: 0.1K --]
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
Claro, está tudo na cara que tem um virus nesse email, mas é proposital, no dia a dia, talvez não esteja tão visivel assim. Vamos analisar o email acima.
# ID da mensagem enviada:
X-Postfix-Queue-ID: A5249240537
# Quem enviou, user e domain:
X-Postfix-Sender: rfc822; root@mail.example.com.br
# Quem iria receber:
Final-Recipient: rfc822; test@hermodr.com.br
# Mensagem do motivo de não te enviado:
<test@hermodr.com.br>: host mail.hermodr.com.br[2a02:c206:2120:1140::1] said:
554 5.7.1 clamav: virus found: "{HEX}EICAR.TEST.3.UNOFFICIAL" (in reply to
end of DATA command)
# Podemos ver também o Subject, o Body, nome do arquivo anexado e o conteúdo dele.
Mas vamos supor que você não ficou contente e quer ver as informações do lado do nosso servidor de email, então vamos lá.
# Pesquise as mensagens do remetente:
╼ $ grep root@mail.exemplo.com.br /var/log/mail.log
Aug 25 16:02:09 mail policyd-spf[37469]: prepend Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=XXXX:XXXX:XXXX:XXXX::1; helo=mail.exemplo.com.br; envelope-from=root@mail.exemplo.com.br; receiver=<UNKNOWN>
Aug 25 16:02:10 mail postfix/cleanup[37470]: C1335940B93: milter-reject: END-OF-MESSAGE from exemplo.com.br[XXXX:XXXX:XXXX:XXXX::1]: 5.7.1 clamav: virus found: "{HEX}EICAR.TEST.3.UNOFFICIAL"; from=<root@mail.exemplo.com.br> to=<test@hermodr.com.br> proto=ESMTP helo=<mail.exemplo.com.br>
# Pesquise o ID da mensagem no rspamd:
╼ $ grep C1335940B93 /var/log/rspamd/rspamd.log
2024-08-25 16:02:09 #36001(rspamd_proxy) <c73e2a>; proxy; rspamd_message_parse: loaded message; id: <Zst/rWtPBrE/mux8@wlf.eti.br>; queue-id: <C1335940B93>; size: 867; checksum: <faad35a58757afa05dd3c066e3729b73>
2024-08-25 16:02:10 #36001(rspamd_proxy) <c73e2a>; proxy; rspamd_task_write_log: id: <Zst/rWtPBrE/mux8@exemplo.com.br>, qid: <C1335940B93>, ip: XXXX:XXXX:XXXX:XXXX::1, from: <root@mail.exemplo.com.br>, (default: T (reject): [6.49/15.00] [MIME_DOUBLE_BAD_EXTENSION(6.00){.com.txt;},CTYPE_MIXED_BOGUS(1.00){},DMARC_POLICY_ALLOW(-0.50){exemplo.com.br;reject;},FORGED_SENDER(0.30){root@exemplo.com.br;root@mail.exemplo.com.br;},R_SPF_ALLOW(-0.20){+mx:c;},MIME_GOOD(-0.10){multipart/mixed;text/plain;},MX_GOOD(-0.01){},ARC_NA(0.00){},ASN(0.00){asn:40021, ipnet:xxxx:xxxx::/32, country:US;},CLAM_VIRUS(0.00){{HEX}EICAR.TEST.3.UNOFFICIAL;},FROM_HAS_DN(0.00){},FROM_NEQ_ENVFROM(0.00){root@exemplo.com.br;root@mail.exemplo.com.br;},HAS_ATTACHMENT(0.00){},MID_RHS_MATCH_FROM(0.00){},MIME_TRACE(0.00){0:+;1:+;2:-;2:+;},RCPT_COUNT_ONE(0.00){1;},RCVD_COUNT_TWO(0.00){2;},RCVD_TLS_ALL(0.00){},R_DKIM_NA(0.00){},TO_DN_NONE(0.00){},TO_MATCH_ENVRCPT_ALL(0.00){}]), len: 867, time: 213.651ms, dns req: 7, digest: <faad35a58757afa05dd3c066e3729b73>, rcpts: <test@hermodr.com.br>, mime_rcpts: <test@hermodr.com.br>, forced: reject "clamav: virus found: "{HEX}EICAR.TEST.3.UNOFFICIAL""; score=nan (set by clamav)
# Se pesquisarmos pelo ID do prox 'c73e2a' também vamos ver um pouco do que tem acima:
╼ $ grep c73e2a /var/log/rspamd/rspamd.log
2024-08-25 16:02:09 #36001(rspamd_proxy) <c73e2a>; lua; common.lua:108: clamav: result - virusfound: "{HEX}EICAR.TEST.3.UNOFFICIAL - score: 1"
2024-08-25 16:02:09 #36001(rspamd_proxy) <c73e2a>; proxy; rspamd_add_passthrough_result: <Zst/rWtPBrE/mux8@wlf.eti.br>: set pre-result to 'reject' (no score): 'clamav: virus found: "{HEX}EICAR.TEST.3.UNOFFICIAL"' from clamav(1)
Aqui podemos ver o IP ip: XXXX:XXXX:XXXX:XXXX::1, a ação que foi realizada default: T (reject), quem enviou from: <root@mail.exemplo.com.br>, a pontuação para detectar se é spam 6.49/15.00 e a ação que ocorreu forced: reject "clamav: virus found: "{HEX}EICAR.TEST.3.UNOFFICIAL""; score=nan (set by clamav).
Verificando conformidade do servidor com os padrões técnicos da Internet
Vamos usar o site top.nic.br e internet.nl (ambos são iguais) para testar a conformidade do nosso servidor de email com as normas e boas práticas da internet, como IPv6, DNSSEC, HTTPS, STARTTLS, entre outras. Fiz o teste para servidor de email e recebi o resultado abaixo:
Teste TOP - E-mail: hermodr.com.br
Resultado: 100%
Parabéns, seu domínio será adicionado em breve ao Quem é TOP!
Isso indica que estamos no caminho correto e nosso servidor possui uma boa configuração.
Outras configurações para o Postfix
Caso você queira configurar um servidor que não receba email, só faça o envio para outro servidor, mude as duas opções abaixo na configuração do Postfix.
# Remova todas as opções de 'mydestination' para que ele não entregue nada localmente.
mydestination =
# Coloque o IP ou nome do servidor de email que será usado para enviar emails, os emails serão enviados através de outro servidor.
relayhost = XXX.XXX.XXX.XXX
# Mude a interfaces para receber emails somente via loopback (não aceita email vindos da rede):
inet_interfaces = loopback-only
Fontes
https://www.postfix.org/BASIC_CONFIGURATION_README.html
https://www.antispam.br/admin/porta25/definicao/
https://www.postfix.org/postconf.5.html
https://www.postfix.org/OVERVIEW.html
https://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall
https://www.postfix.org/VIRTUAL_README.html
https://www.postfix.org/SASL_README.html
https://www.postfix.org/postconf.5.html#smtpd_sasl_security_options
https://www.postfix.org/SASL_README.html#server_cyrus
https://www.postfix.org/SASL_README.html#server_dovecot
https://www.postfix.org/TLS_README.html
https://access.redhat.com/articles/1468593
https://bettercrypto.org/#_postfix
https://think.unblog.ch/en/how-to-use-sender-policy-framework-on-debian-server/
https://www.postfix.org/LOCAL_RECIPIENT_README.html