Sobre esse Material

Este material foi desenvolvido para ensinar os conhecimentos básicos necessários para o funcionamento eficiente de um servidor de email, sem o uso de ferramentas que facilitem a administração ou gerenciamento do servidor. Em outras palavras, todo o processo será realizado via linha de comando (CLI), sem o auxílio de ferramentas para criação de usuários, troca de senhas, e outras funções administrativas.

A leitura deste documento não substitui a consulta à documentação oficial, que é essencial. O objetivo aqui é tornar o aprendizado mais acessível, de modo que, ao se deparar com a documentação oficial, você possa compreendê-la e assimilar os conhecimentos de maneira mais eficaz.

Iniciaremos com o Postfix, abordando seu funcionamento teórico e prático. Em seguida, exploraremos o Dovecot para entender seu papel e operação. Nesse ponto, já estaremos aptos a configurar um servidor de email básico. No entanto, para uma solução mais completa, também veremos como integrar o RSpamD para filtragem de spam, além do ClamAV para análise de vírus em emails. Algumas configurações específicas serão necessárias, e abordaremos também um pouco de LDAP para gerenciamento centralizado.

É imprescindível possuir um bom entendimento sobre DNS, especialmente em relação a registros como: TLSA, TXT, MX, SPF, DKIM, DMARC, DANE e ADSP. Esses tópicos serão abordados com o intuito de transformar este material em uma referência sobre servidores de email. No entanto, esteja ciente de que o conteúdo aqui apresentado exige dedicação tanto para compreensão teórica quanto para sua aplicação prática, já que não utilizaremos ferramentas que simplifiquem a configuração dos componentes envolvidos. Tentarei reservar uma seção para demonstrar algumas ferramentas que podem facilitar a configuração, mas sem aprofundamento.

Durante os procedimentos descritos, vou usar o Ubuntu 22.04 como sistema operacional no servidor. Quando um procedimento em outro sistema for descrito, deixarei explícito.

Explicando a Convenção de Símbolos no Terminal

Para quem está começando a se aventurar no mundo do terminal, a variedade de símbolos e comandos pode parecer um pouco intimidante. Vamos simplificar isso!

Quando estamos trabalhando no terminal, usamos símbolos para representar diferentes coisas. Um dos mais comuns é o $. Esse símbolo, geralmente, indica que você está logado como um usuário comum, e não como o superusuário (root). O $ ajuda a visualizar rapidamente se você está com privilégios de administrador ou não. É uma convenção amplamente utilizada em tutoriais e documentações para representar a linha de comando.

Normalmente, quando você está logado como root, o símbolo que aparece antes dos comandos é o #. O root possui permissões mais elevadas e pode realizar alterações em qualquer parte do sistema. Para facilitar a visualização e a compreensão dos comandos, eu vou adotar uma pequena convenção:

╼ $: Indicará que estamos executando um comando como root.
#: Será utilizado para adicionar comentários ou explicações sobre os comandos no dentro do terminal do Linux.

Essa é apenas uma convenção adotada aqui. Na prática, o símbolo que aparece antes dos comandos pode variar dependendo da distribuição Linux que você está usando e das configurações do seu terminal. Exemplo:

Terminal

# Criando um novo usuário (como root):
╼ $ useradd novo_usuario

# Alterando a senha do novo usuário comum, nesse caso preciso usar o sudo para ter privilégios administrativos:
$ sudo passwd novo_usuario

Antes de prosseguir

Antes de prosseguir com instalação e começar a configurar um servidor de email, vamos entender os tipos de configurações e como elas funcionam. Primeiramente, isso ajuda a evitar erros e problemas que podem ocorrer devido a configurações inadequadas. Compreender as opções de configuração e suas interações permite que você configure o servidor corretamente, evitando falhas que poderiam impactar a entrega de emails e a operação do sistema.

Entender o funcionamento interno do servidor e o impacto das configurações no fluxo de trabalho é essencial. Isso permite prever como as alterações afetarão o sistema e facilita a identificação e resolução de problemas rapidamente. Portanto, inicialmente veremos como o Postfix trabalha para então começar a configurar ele.

Introdução

Postfix é um Agente de Transporte de Mensagens (MTA - Message Transport Agent) de código aberto, amplamente utilizado para o envio e roteamento de emails. Sua função principal é transportar mensagens de um servidor de email para outro, garantindo a entrega.

Além de transportar mensagens, um MTA como o Postfix também pode atuar como um Relay, ou seja, repassa emails de um servidor para outro. Nesse papel, o Postfix recebe mensagens de outros servidores (que não são MTA) e as encaminha para o destino final, que na maioria das vezes é um servidor MTA. O Postfix foi criado por Wietse Venema, um engenheiro de segurança da computação e pesquisador conhecido por suas contribuições à segurança de sistemas. Wietse desenvolveu o Postfix enquanto trabalhava no laboratório de pesquisa da IBM, como uma alternativa segura e eficiente ao Sendmail, que era o MTA mais comum na época.

O Postfix é uma ferramenta essencial para a construção de um servidor de email, mas, por si só, não é suficiente para oferecer um serviço completo e seguro. Para atingir esse objetivo, é necessário combiná-lo com outras ferramentas e softwares que cuidem de tarefas como filtragem de spam, detecção de vírus e fornecimento de uma interface para os usuários.

Embora o Postfix possa realizar muitas dessas funções de forma isolada, e seja possível implementar um sistema de filtragem de spam sem o uso de um software específico, isso exigiria mais esforço por parte dos administradores e, ainda assim, seria viável. Agora, vamos explorar os componentes necessários para o funcionamento de um servidor de email e os protocolos envolvidos. Faremos uma análise inicial para entender quem são esses componentes e qual é o papel de cada um na entrega de um email, sem nos aprofundar nos detalhes técnicos neste momento.

Mail User Agent (MUA)

O Mail User Agent (MUA) é o cliente de email que o usuário utiliza para enviar, receber e gerenciar seus emails. Alguns exemplos comuns de MUA incluem Thunderbird, Outlook, Gmail, entre outros.

O MUA é responsável por compor e enviar a mensagem, que é então transmitida ao Agente de Transporte de Mensagens (MTA). O MTA, por sua vez, cuida da tarefa de encaminhar a mensagem ao servidor de email correto, garantindo que ela chegue ao seu destino final.

O MUA se comunica com o servidor de email (MTA) utilizando os seguintes protocolos e portas:

POP3 (Porta 110 ou 995 para conexões seguras)
IMAP (Porta 143 ou 993 para conexões seguras)
SMTP (Porta 587 ou 465 para envio de emails)

Mail Transport Agent (MTA)

O Mail Transport Agent (MTA) é o servidor de email responsável por enviar, receber e encaminhar mensagens entre servidores, garantindo que elas sejam entregues corretamente. O MTA opera usando o protocolo SMTP (Simple Mail Transfer Protocol) na porta 25 para realizar a comunicação entre servidores durante o processo de envio e recebimento de emails.

Exemplos de MTA incluem Postfix, Sendmail, Qmail, Exim, Microsoft Exchange, entre outros.

Mail Delivery Agent (MDA)

Após o MTA do remetente enviar o email para o servidor correto, o MTA do destinatário encaminha essa mensagem para um Mail Delivery Agent (MDA). O MDA é responsável por diversas tarefas críticas, como verificar se o email é spam ou contém vírus, aplicar políticas de segurança (como bloqueio de anexos com extensão .iso), e gerenciar encaminhamentos para outros emails, por exemplo, quando há aliases configurados.

O MDA apenas entra em jogo quando o email é entregue no servidor de destino (MTA). Ele processa o email e o disponibiliza para leitura pelo MUA através de protocolos como IMAP ou POP, que usam as portas 143/993 (IMAP) ou 110/995 (POP).

O MDA normalmente se comunica com o MTA e o MUA usando arquivos de sockets locais (como UNIX sockets) ou diretamente através de processos internos no servidor de email.

Comunicação MDA com MTA:
O MDA pode receber mensagens do MTA por meio de arquivos de sockets ou diretórios de fila de emails (spool directories). Por exemplo, o MDA pode ler as mensagens armazenadas em diretórios específicos pelo MTA e processá-las.

Comunicação MDA com MUA:
O MDA se comunica com o MUA usando protocolos como POP, IMAP ou LMTP para entregar o email ao cliente de email. Esses protocolos sim, utilizam portas de rede para a comunicação (como mencionado anteriormente).

Em resumo, enquanto o MDA usa portas para comunicar-se com o MUA através de protocolos como IMAP ou POP, sua comunicação com o MTA é geralmente feita por meio de sockets locais ou outros mecanismos internos, não dependendo diretamente de portas de rede.

Exemplos de MDA incluem Procmail, Fetchmail, Courier, Dovecot, Maildrop, Postdrop, entre outros.

Simple Mail Transfer Protocol (SMTP)

O Simple Mail Transfer Protocol (SMTP) é o protocolo utilizado para a comunicação entre Mail Transport Agents (MTAs), ou seja, servidores de email. É através do SMTP que os servidores de email enviam e encaminham mensagens entre si.

A porta padrão para SMTP é a 25, mas ela não oferece criptografia, o que significa que as mensagens são enviadas em texto claro. Para garantir a segurança dos emails durante a transmissão, devem ser utilizadas as portas 465 (para SMTP sobre SSL) ou 587 (para SMTP com STARTTLS), que oferecem criptografia através de SSL ou TLS, respectivamente.

O uso da porta 465 foi inicialmente designada para SMTP sobre SSL (SMTPS), proporcionando uma conexão criptografada desde o início. No entanto, sua utilização não foi oficialmente padronizada e foi posteriormente desencorajada em favor do STARTTLS. Já a porta 587 é a porta padrão para SMTP com STARTTLS, que é um método para atualizar uma conexão SMTP não criptografada para uma criptografada usando TLS. É a porta recomendada para envio de emails, especialmente quando a criptografia é necessária.

A conexão começa como uma conexão não criptografada e, se o servidor e cliente suportarem, pode ser atualizada para criptografada usando o STARTTLS. Isso permite que a conexão seja segura sem exigir que ela seja criptografada desde o início.

A porta 587 é a porta oficialmente recomendada para envio de emails usando SMTP com criptografia. Ela é amplamente suportada e preferida para comunicação segura.

Durante a configuração do servidor de email veremos bastante o termo SMTPD. O SMTPD (SMTP Daemon) é o componente do servidor de email que escuta e processa as requisições recebidas do SMTP (muito visto como incoming mail). O termo "daemon" refere-se a um processo que opera em segundo plano e lida com solicitações de rede.

O SMTPD é responsável por receber emails de outros servidores ou clientes, processar essas mensagens, e encaminhá-las para o Mail Delivery Agent (MDA) para entrega final. Ele atua como o servidor que aceita conexões SMTP e executa as operações necessárias para a entrega de emails.

Programas de servidor que implementam SMTPD incluem Postfix, Sendmail e Exim.

Só para fixar na mente. O *SMTPD* é o daemon para recebimento de emails e o *SMTP* é o daemon para o envio de email.

Open Relay

Um Open Relay ocorre quando um servidor SMTP (servidor de email) é configurado para permitir que qualquer usuário da Internet o utilize para enviar emails, sem restrições. Isso significa que o servidor aceita e encaminha mensagens de email de qualquer remetente para qualquer destinatário, independentemente da origem.

Um servidores configurados como open relay são altamente suscetíveis a usos maliciosos, como envio de spam e phishing. Essa configuração pode resultar em uma quantidade significativa de tráfego de email indesejado e prejudicial, além de potencialmente prejudicar a reputação do servidor e sua capacidade de entrega de emails legítimos.

Processo para enviar um email

A imagem abaixo descreve o processo para enviar um email, passando por todos os pontos mencionados acima, ela não descreve em detalhes todo o processo real, é apenas uma ilustração para demonstrar onde ficam os pontos esclarecidos acima.

Email_process

Abaixo segue uma descrição detalhada do fluxo mostrado na imagem acima.

1. Envio de Email de who@outlook.com para someone@gmail.com

MUA (Outlook - From who@outlook.com): O usuário que envia o email utiliza o cliente de email Outlook para compor e enviar a mensagem.
MTA (MX Outlook): O cliente de email Outlook se conecta ao servidor de email (MTA) da Microsoft (MX Outlook) para entregar a mensagem. O MTA da Microsoft é responsável por processar e encaminhar o email.
MTA (MX Gmail): O MTA do servidor de email do destinatário (MX Gmail) recebe o email do MTA da Microsoft. O servidor Gmail processa a mensagem e a armazena.
MDA: O MDA no servidor Gmail lida com a entrega final do email, colocando-o na caixa de entrada do destinatário (someone@gmail.com).
MUA (To someone@gmail.com): O cliente de email do destinatário, no caso alguém usando Gmail, recebe e visualiza a mensagem na sua caixa de entrada.

2. Resposta de someone@gmail.com para who@outlook.com

MUA (To someone@gmail.com): O destinatário (someone@gmail.com) utiliza o cliente de email (Gmail) para responder ao email.
MTA (MX Gmail): O cliente de email se conecta ao servidor de email do Gmail (MTA) para enviar a resposta. O MTA do Gmail processa e encaminha a resposta.
MTA (MX Outlook): O MTA do servidor de email da Microsoft (MX Outlook) recebe a resposta do MTA do Gmail. Ele processa a mensagem e a entrega ao servidor de email associado ao endereço who@outlook.com.
MUA (Outlook - From who@outlook.com): O cliente de email do remetente original (Outlook) recebe a resposta e a exibe na caixa de entrada de who@outlook.com.

Protocolos envolvidos no serviço de Email

Vários protocolos e serviços trabalham em conjunto para garantir que o servidor de email opere da forma mais eficiente possível. Vamos explorar alguns dos principais protocolos envolvidos nesse processo.

SMTP

O protocolo SMTP (Simple Mail Transfer Protocol) é utilizado para o envio de emails (envia email entre servidores de email, apenas de MTA para MTA), enquanto o POP3 (Post Office Protocol versão 3) e o IMAP (Internet Message Access Protocol) são usados para o recebimento de emails (envia o email do MTA para o MUA e do MUA para o MTA).

Vamos entender como funcionam as portas do SMTP:

Terminal

$ grep -Ei "[[:space:]]25/|465/|587/" /etc/services 
smtp        25/tcp      mail
submissions 465/tcp     ssmtp smtps urd # Submission over TLS [RFC8314]
submission  587/tcp             # Submission [RFC4409]

A porta descrita acima como Submission é usada para a comunicação entre o cliente de email (MUA) e o servidor de email (MTA) para enviar emails. É a porta padrão para o envio de emails com autenticação e suporte a criptografia via STARTTLS. Deve ser a porta principal utilizada para envio de emails a partir do cliente de email.

Já a porta descrita como mail (porta 25) é utilizada para a troca de emails entre servidores de email (MTA). É o protocolo padrão para a comunicação entre servidores para enviar e receber mensagens. Os servidores MTA só podem enviar e receber emails usando essa porta.

Tendo isso em mente vamos separar as portas do SMTP que são usadas para cada caso:

Submission
465 - Suporta TLS
587 - Porta padrão, você deve usar essa primeiramente.
Relay
25

Basicamente então nós temos uma porta para que o cliente de email possa enviar o email até o nosso servidor de email (porta 587), temos uma porta para que os servidores de email possam trocar emails entre sí (porta 25) e por fim temos uma porta para baixar ou sincronizar nosso cliente de email com o servidor de email (IMAP: 993 e/ou POP: 995).

Vale lembrar que, atualmente, a porta 25 é frequentemente bloqueada por padrão pela maioria dos ISPs. Isso se deve a razões de segurança e prevenção de spam. Para entender melhor o motivo desse bloqueio, você pode consultar os seguintes links: antispam.br e gerencial.galafassi.com.br.

Esse bloqueio pode tornar mais difícil a configuração de um servidor de email, já que muitos ISPs não permitem o tráfego na porta 25 para clientes residenciais. Se você precisar usar a porta 25, uma alternativa é procurar um provedor que a libere ou solicitar ao seu ISP que a desbloqueie, embora muitos ISPs não estejam dispostos a fazer isso.

Uma solução prática para esse problema é configurar um relayhost no servidor SMTP do seu ISP. O relayhost atuará como intermediário, retransmitindo seus emails através da porta 25. Embora haja controles sobre essa retransmissão, a solução geralmente não afeta a maioria dos usuários.

Outra alternativa mais avançada é se tornar um ASN (Autonomous System Number), o que lhe daria controle total sobre a sua rede e a configuração das portas, incluindo a porta 25.

O comando abaixo foi executado num servidor que possui a porta 25 aberta, é um servidor de email válido, veja como ele consegue se conectar na porta 25 do servidor de email do Google:

Terminal

# Identifique os servidores de email do Google:
$ dig mx gmail.com +short
40 alt4.gmail-smtp-in.l.google.com.
20 alt2.gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.
5 gmail-smtp-in.l.google.com.
30 alt3.gmail-smtp-in.l.google.com.

## O menor número tem maior prioridade de uso!


# Verifique se é possível se conectar na porta 25 da MX do Google:
$ nc -zv gmail-smtp-in.l.google.com 25
Connection to gmail-smtp-in.l.google.com 25 port [tcp/smtp] succeeded!

# Agora veja o mesmo comando sendo executado da minha máquina, onde o meu ISP
# faz o bloqueio da porta 25:
$ nc -zv gmail-smtp-in.l.google.com 25
nc: connect to gmail-smtp-in.l.google.com port 25 (tcp) failed: Connection timed out
nc: connect to gmail-smtp-in.l.google.com port 25 (tcp) failed: Network is unreachable

Submission

O termo Submission refere-se à porta 587, que é usada para a comunicação entre o MUA e o MTA. A porta 587 é especificamente utilizada quando um MUA, como o aplicativo de email em um smartphone, se comunica remotamente com um MTA para enviar um email. Por exemplo, quando um usuário com um aplicativo do Gmail no smartphone envia um email, o aplicativo se conecta à porta 587 do servidor MTA do Gmail para submeter a mensagem. Essa porta garante que o envio de emails seja feito de maneira segura, com autenticação e criptografia apropriadas entre o cliente e o servidor.

Quando um MTA não está configurado para usar a porta 587 (Submission), ele frequentemente atua como um servidor de relay, mas essa não é a única possibilidade. Em algumas configurações, clientes e/ou usuários podem se conectar diretamente ao servidor MTA através de SSH por exemplo e utilizar ferramentas como o mutt (que é um MUA). Nesse cenário, a comunicação ocorre de forma diferente, pois o MUA e o MTA estão localizados no mesmo servidor.

Isso elimina a necessidade de um MUA se conectar externamente no MTA, nesse caso, o MUA está no mesmo local do MTA, no mesmo servidor. Assim, as mensagens enviadas pelo cliente são processadas diretamente pelo MTA e enviadas pela porta 25, e o email é encaminhado diretamente para o MTA de destino na mesma porta, sem a necessidade de usar a porta 587 para submissão.

Essa abordagem pode ser adequada em ambientes controlados e seguros, mas é importante garantir que as configurações e políticas de segurança estejam corretamente implementadas para proteger o sistema contra possíveis abusos e garantir a integridade das comunicações. Esta porta é usada para a submissão do email, permitindo que o cliente de email autentique o usuário e envie a mensagem de forma segura, utilizando criptografia STARTTLS.

POP3

O POP3 (Post Office Protocol 3) é um protocolo utilizado para baixar emails do servidor para o dispositivo do usuário. Quando configurado para usar POP3, o cliente de email se conecta ao servidor, baixa as mensagens e, em seguida, remove esses emails do servidor, armazenando-os localmente no dispositivo do cliente.

Essa abordagem é ideal para situações em que não se deseja manter uma cópia dos emails no servidor. No entanto, é importante garantir que backups regulares sejam feitos no dispositivo para evitar a perda de mensagens importantes. O POP3 utiliza as portas 110 e 995. Recomenda-se sempre usar a porta 995, pois ela suporta criptografia SSL/TLS, oferecendo uma camada adicional de segurança para a transmissão dos emails.

IMAP

O IMAP (Internet Message Access Protocol) é um protocolo que permite a sincronização de emails mantendo-os no servidor. Ao contrário do POP3, que baixa e remove os emails do servidor, o IMAP mantém todas as mensagens no servidor e sincroniza o conteúdo entre o servidor e todos os dispositivos usados para acessar o email. Isso significa que, independentemente do dispositivo utilizado terá acesso às mesmas mensagens e pastas.

Devido a essa abordagem, o backup dos emails deve ser realizado no servidor para garantir a integridade e a disponibilidade das mensagens. O IMAP utiliza as portas 143 e 993. Recomenda-se sempre usar a porta 993, pois ela suporta criptografia SSL/TLS, proporcionando uma comunicação mais segura entre o cliente de email e o servidor.

LMTP

O Local Mail Transfer Protocol (LMTP) é um protocolo de entrega de emails que funciona de maneira semelhante ao SMTP, mas é projetado para um uso mais específico e restrito. Como o nome sugere, o "Local" indica que o LMTP é frequentemente utilizado para transferir emails dentro da mesma rede ou sistema.

O LMTP é comumente usado para entregar emails de um MTA (Mail Transfer Agent) para outros componentes de email, como um MDA (Mail Delivery Agent). Isso facilita a comunicação interna dentro de uma rede ou entre servidores de email em uma arquitetura de sistema.

Além disso, o LMTP é útil para cenários em que se deseja minimizar a exposição de servidores. Ele permite que apenas um servidor seja exposto externamente, enquanto outros servidores de email internos utilizam o LMTP para a entrega e o processamento de mensagens de forma segura e eficiente.

Como o Postfix Funciona?

O Postfix é um sistema de e-mail sofisticado que opera por meio de vários programas que trabalham em conjunto para garantir o envio e a entrega eficaz das mensagens. O processo central que coordena todos os outros é o MASTER. Esse processo principal gerencia os subprocessos em segundo plano, assegurando que o sistema de e-mail funcione de maneira sincronizada. O MASTER inicia, controla e termina esses subprocessos, garantindo que todas as tarefas relacionadas ao e-mail sejam realizadas corretamente.

Entre os subprocessos controlados pelo MASTER, destaca-se o PICKUP. Esse subprocesso é responsável por coletar as mensagens que chegam ao servidor e encaminhá-las para a fila principal do Postfix. O PICKUP atua como o ponto inicial onde as mensagens entram no sistema, preparando-as para o processamento subsequente.

Após a coleta das mensagens pelo PICKUP, entra em cena o QMGR, ou "Queue Manager". O QMGR gerencia e organiza a fila de e-mails, determinando o destino e o tratamento adequado para cada mensagem. Ele otimiza o fluxo das mensagens e garante que sejam processadas de forma eficiente e encaminhadas para a fila de saída quando estiverem prontas para entrega.

O QMGR também é responsável por enviar uma notificação de falha ao remetente quando um e-mail não pode ser entregue, o que é conhecido como "bounce". O termo "bounce" refere-se a uma situação em que o sistema de e-mail não consegue entregar uma mensagem e devolve uma notificação de falha ao remetente. Essa falha pode ocorrer por diversos motivos, como um endereço de e-mail inválido, uma caixa de entrada cheia ou problemas de configuração no servidor de destino. O Postfix cria uma mensagem de retorno, chamada de "bounce message", que inclui detalhes sobre o motivo da falha.

Além disso, o QMGR pode adiar temporariamente a entrega de uma mensagem, um processo conhecido como "defer". Quando uma mensagem é "deferred", ela não é entregue imediatamente, mas o sistema tentará novamente mais tarde. Isso pode ocorrer devido a problemas temporários, como dificuldades na rede, problemas no servidor de destino ou limitações de recursos no servidor de envio. Durante o adiamento, a mensagem é colocada em uma fila de espera, e o Postfix continuará tentando entregá-la em intervalos regulares até que a entrega seja bem-sucedida ou a mensagem seja removida após várias tentativas falhadas. O Postfix também registra informações sobre o motivo do adiamento para ajudar na resolução de problemas.

Vejamos mais alguns Daemons que trabalham com o Postfix parao gerenciamento de emails:

Daemon	Descrição
`error`	Gerencia o fluxo de mensagens que falham ao serem entregues, incluindo mensagens de erro e falhas.
`trivial-rewrite`	Realiza reescritas simples de endereços de e-mail, como alterar endereços de remetentes e destinatários.
`showq`	Exibe o conteúdo da fila de e-mails do Postfix, permitindo a visualização de mensagens pendentes e seu status.
`flush`	Força o processamento imediato da fila de e-mails, normalmente usado para forçar a entrega de mensagens pendentes.
`local`	Lida com a entrega de e-mails para usuários locais, processando mensagens endereçadas para o mesmo sistema.
`virtual`	Gerencia a entrega de e-mails para domínios virtuais configurados no Postfix, lidando com endereços que não são locais.
`pipe`	Executa comandos externos para processar e-mails, redirecionando mensagens para scripts ou programas especificados.
`cleanup`	Prepara e organiza mensagens para processamento, incluindo a verificação e formatação antes de enviar para a fila.
`qmqpd`	Gerencia as conexões para o acesso à fila de e-mails, utilizado em configurações distribuídas do Postfix.
`anvil`	Fornece informações de limite e controle de conexões, ajudando a gerenciar e controlar a quantidade de conexões que o servidor aceita.

Logs para o Postfix

Os logs do postfix ficam em /var/log/mail.log, normalmente é mail.log, mail.err, mail.info, mail.warn etc. Para o padrão RedHat é um pouco diferente, o padrão é /var/log/mailog.

Postfix Maps

No Postfix, as tabelas de pesquisa são conhecidas como "mapas", ou seja, são tabelas de mapeamento usadas para realizar consultas e tomar decisões baseadas em diferentes tipos de informações. Essas tabelas são fundamentais para diversas operações dentro do servidor de email, como roteamento de emails, controle de acesso, verificação de usuários, entre outras.

Os maps no Postfix podem ser armazenados em vários formatos, como arquivos de texto simples, bancos de dados Berkeley DB, ou bancos de dados SQL, e são referenciados por diretivas específicas no arquivo de configuração main.cf.

Aqui estão alguns exemplos comuns de maps no Postfix:

alias_maps
Usado para mapear endereços de email para outros endereços de email ou listas de distribuição. Normalmente esse mapa é configurado da seguinte forma: alias_maps = hash:/etc/aliases.
virtual_alias_maps e virtual_mailbox_maps
Usado para mapear endereços de email virtuais para caixas de correio locais ou para endereços de email externos. Isso é comum em configurações onde você hospeda emails para vários domínios.
transport_maps
Usado para definir regras de roteamento personalizadas, especificando como e para onde os emails devem ser entregues com base no domínio do destinatário.
smtpd_access_maps
Usado para controlar o acesso ao servidor de email, permitindo ou bloqueando emails de determinados endereços IP, domínios ou endereços de email.
smtpd_sender_restrictions e smtpd_recipient_restrictions
Usado para aplicar restrições específicas a remetentes e destinatários com base em maps.

Index Maps

Index maps é a um tipo de estrutura de dados que o Postfix utiliza para armazenar e recuperar informações de forma eficiente. Maps em geral são tabelas de consulta que o Postfix usa para procurar valores associados a chaves específicas. Index maps são arquivos que o Postfix utiliza para armazenar pares de chave-valor, onde cada chave está associada a um valor correspondente. Esses mapas são frequentemente armazenados em formatos otimizados, como hash ou btree, que permitem buscas rápidas e eficientes. Esses binários são criados usando os comandos newaliases, postalias e postmap.

Quando o Postfix precisa consultar um valor associado a uma chave (por exemplo, determinar para onde redirecionar um email baseado no endereço do destinatário), ele procura essa chave no map apropriado. Se o map for armazenado em um formato de index otimizado, como hash ou btree, a consulta pode ser feita rapidamente, mesmo em mapas muito grandes. Após a edição é preciso recarregar os arquivos para que o Postfix note a mudança, algo como postfix reload deve resolver.

Databases

O Postfix trata Databases ou Banco de dados como um Index Maps, a diferença nesse caso é que não é necessário fazer o Postfix reconhecer as mudanças quando usamos Banco de dados. Os bancos que Postfix pode trabalhar são: MySQL, PostgreSQL e LDAP).

Entrega de email para usuários locais

Quando o Postfix recebe um email destinado a um usuário local, ele segue uma série de etapas para entregar essa mensagem ao destinatário correto. Quando o Postfix recebe um email, seja por conexão SMTP de outro servidor ou de um cliente de email (MUA), a mensagem é colocada na fila de entrada (incoming queue). O Postfix então passa a verificar se o destinatário do email (por exemplo, user@exemplo.com) pertence ao próprio servidor, para saber se pertence, o domínio do destinatário é comparado com as configurações em mydestination, inet_interfaces, e proxy_interfaces. Se o domínio do destinatário corresponder a um desses valores, o Postfix considera o destinatário como local.

O Postfix verifica o arquivo de aliases (/etc/aliases ou outro definido por alias_maps) para ver se o destinatário tem um alias configurado. Se encontrar um alias, ele expande o endereço para o endereço real do destinatário. Se o destinatário tiver um alias configurado, o Postfix reescreve o endereço do email para o endereço real antes de proceder.

Se o email for para um usuário local (por exemplo, user@exemplo.com), o Postfix usa o agente de entrega local (chamado local) para processar a mensagem. O local é responsável por colocar a mensagem na caixa de correio do usuário. Se o email for para um domínio virtual (geralmente configurado em virtual_alias_domains), o Postfix usa o agente virtual para entregar o email.

O local coloca a mensagem na caixa de correio do usuário, que pode estar em um diretório como /var/mail/user ou outro local especificado na configuração do Postfix. O formato da caixa de correio pode ser mbox (um único arquivo para todas as mensagens) ou Maildir (uma estrutura de diretórios onde cada mensagem é um arquivo separado).

Vejamos um exemplo prático. Suponhamos que o Postfix receba um email para user@exemplo.com. O Postfix verifica se exemplo.com está listado em mydestination. Se estiver, o Postfix considera user como um usuário local. Se houver um alias configurado como user: admin@exemplo.com, o email é redirecionado para admin@exemplo.com. Finalmente, o Postfix usa o agente local (local) para entregar o email na caixa de correio de admin.

Entrega para um Comando

Quando um alias no Postfix é configurado para executar um comando em vez de redirecionar para outro endereço de email, o fluxo de processamento do email é um pouco diferente.

O Postfix recebe o email e o coloca na fila de entrada (incoming queue), como de costume. O Postfix verifica se o destinatário do email pertence ao domínio do servidor, conforme configurado em mydestination, inet_interfaces, ou proxy_interfaces. O Postfix consulta o arquivo de aliases (/etc/aliases ou outro definido por alias_maps) para ver se o destinatário é um alias configurado. Se o destinatário for um alias que aponta para um comando, o Postfix identificará isso e procederá para a próxima etapa.

Quando um alias é configurado para um comando, o Postfix executa esse comando em vez de entregar o email diretamente em uma caixa de correio. O comando é executado com a mensagem de email fornecida como entrada padrão (stdin), permitindo que o comando processe o email conforme necessário.

CUIDADO

No Postfix, os comandos especificados em aliases são processados apenas para usuários locais. Quando um alias é configurado para um comando, o Postfix executa esse comando em vez de entregar o email a uma caixa de correio. Isso é possível porque o comando pode ser configurado no arquivo de aliases (/etc/aliases ou conforme definido por alias_maps).

O Postfix usa o conceito de destinatários locais para determinar se deve executar um comando para um alias. Um destinatário é considerado local se o domínio do destinatário estiver listado em mydestination, inet_interfaces, ou proxy_interfaces. Se um alias para um comando for configurado para um endereço que não seja local, o Postfix não executará o comando e pode tratar o email como um erro ou encaminhá-lo para outro destino, conforme configurado. Em servidores com Dovecot, esse email será encaminhado para o Dovecot e o mesmo dará erro de usuário desconhecido, já que é um alias ele tentará descobrir se o usuário existe para efetuar a entrega local na mailbox do usuário.

Outro ponto para se manter a atenção é com os parâmetros myhostname e myorigin. Eles podem impactar a forma como o Postfix lida com o roteamento de emails e aliases, especialmente quando se trata de comandos. O myhostname define o nome do host do servidor de email. Este é o nome usado pelo Postfix em várias mensagens de log e na comunicação com outros servidores, a configuração correta é definir o FQDN do servidor de email aqui, ou seja, se o domínio é exemplo.com e o nome do host é mail, o FQDN será mail.exemplo.com. Já myorigin define o domínio de origem que será anexado aos endereços locais não qualificados, ou seja, quando o Postfix precisa formar um endereço completo a partir de um endereço local, ele usa o valor de myorigin. Para um servidor único de email deve apontar para myhostname.

Quando myhostname e myorigin são configurados de maneira diferente, isso pode afetar a entrega local e o processamento de aliases para comandos. Se myhostname é mail.exemplo.com.br e myorigin é exemplo.com.br, isso pode causar confusão na forma como o Postfix trata endereços de email e aliases. Por exemplo, um endereço como cto@exemplo.com.br pode ser interpretado de forma diferente dependendo de como o Postfix resolve myhostname e myorigin.

O impacto será maior quando se usa comandos para entrega dos emails. Vejamos o seguinte cenário:

$ cat virtual-dovecot
cto@exemplo.com.br  copy-cto

$ cat aliases-dovecot
copy-cto: "|/usr/sbin/sendmail -oi -f postmaster@mail.exemplo.com.br fulano@domain.com.br"

O comportamento esperado para a configuração acima é:

O Postfix recebe um email para cto@exemplo.com.br;
O endereço deve permanecer inalterado, já que estamos usando FQDN no alias cto@exemplo.com.br apontando para copy-cto;
O Postfix procura no virtual_alias_maps (é onde devemos colocar o arquivo virtual-dovecot) e encontra o mapeamento para copy-cto.
O copy-cto é resolvido via alias_maps (é onde colocarmos o arquivo aliases-dovecot) e executa o comando especificado.
O email é entregue corretamente através do comando.

Agora vamos ver o que acontece se myhostname e myorigin não apontarem para o mesmo domínio. Se o Postfix não reconhecer cto@exemplo.com.br como local devido a diferenças em myhostname e myorigin, ele pode tentar entregar o email para um destino que não existe, resultando em um erro indicando que copy-cto@exemplo.com.br não existe. Isso acontece porque nesse caso um banco de dados de alias deve ser configurado e atribuir a cada usuário o alias.

PS.: É só configurar ambos para o mesmo FQDN se executar um servidor de email único.

Local vs Virtual

Um usuário local é uma conta de usuário que existe no próprio sistema operacional onde o Postfix está rodando. Esses usuários têm suas caixas de correio armazenadas localmente no servidor, geralmente em diretórios como /var/mail/ ou /home/usuário/Maildir/. O Postfix reconhece um usuário local se o domínio do destinatário fizer parte do valor definido em mydestination, e o nome do usuário existir no sistema. Aliases para usuários locais são definidos em arquivos como /etc/aliases. Se um alias local aponta para um comando ou outro endereço, o Postfix executa isso dentro do contexto do servidor.

Um usuário virtual não tem uma conta de usuário correspondente no sistema operacional. Em vez disso, os usuários virtuais são definidos em tabelas externas, como arquivos de mapeamento, bancos de dados SQL, ou LDAP. Sempre que usar LDAP, SQL ou outro tipo de mapeamento para usuários que não existem fisicamente no servidor, estamos falando de usuários virtuais. Os usuários virtuais são utilizados quando você deseja gerenciar múltiplos domínios de email em um único servidor sem criar uma conta no sistema para cada usuário.

Os usuários virtuais são gerenciados pelo Postfix usando virtual_mailbox_maps e virtual_alias_maps. Esses mapas associam endereços de email a locais de armazenamento ou a outros endereços, sem a necessidade de uma conta de sistema correspondente. O Postfix trata os usuários virtuais como destinatários que não precisam de uma conta de sistema para existir, mas sim uma entrada válida nas tabelas de mapeamento configuradas.

Quando o Postfix recebe um email para um usuário virtual, ele consulta os mapas configurados para determinar onde entregar o email ou como redirecioná-lo. Exemplo: Se o Postfix recebe um email para maria@seudominio.com, onde seudominio.com é gerenciado como um domínio virtual, o Postfix verifica virtual_mailbox_maps para encontrar o caminho onde armazenar o email de Maria.

Aliases para usuários virtuais são configurados em virtual_alias_maps. Diferente dos aliases locais, que podem apontar para comandos, os aliases virtuais geralmente redirecionam emails para outros endereços ou para caixas de correio virtuais.

Postfix Queues

Todas as mensagens que o Postfix manipula ficam armazenadas em determinados diretórios até serem entregues (As filas internas do Postfix ficam em /var/spool/postfix/, já as mensagens dos usuários podem ficar em /var/spool/mail/ ou /var/mail/). Você pode determinar o status de uma mensagem pela sua fila: incoming (recebida), maildrop, deferred (adiada), active (ativa), hold (retida) ou corrupt (corrompida).

Todas as novas mensagens que entram no sistema de filas do Postfix são enviadas para a fila de incoming pelo serviço de cleanup (limpeza). Novos arquivos de fila são criados com o usuário postfix como dono e modo de acesso 0600. Assim que um arquivo de fila está pronto para processamento posterior, o serviço de cleanup (limpeza) muda o modo do arquivo de fila para 0700 e notifica o gerenciador de filas (qmgr) que novas mensagens chegaram. O gerenciador de filas (qmgr) ignora arquivos de fila incompletos cujo modo é 0600.

O gerenciador de filas (qmgr) verifica a fila incoming ao mover novas mensagens para a fila active e garante que os limites de recursos da fila active não sejam excedidos. Por padrão, a fila active tem um máximo de 20.000 mensagens. Uma vez que o limite de mensagens da fila ativa é alcançado, o gerenciador de filas para de verificar as filas incoming e deferred.

O limite de 20.000 mensagens na fila active pode ser ajustado alterando o valor do parâmetro qmgr_message_active_limit. No entanto, antes de alterar esse valor, é importante entender as implicações de aumentar esse limite. Quando o limite da fila active é alcançado, o gerenciador de filas (qmgr) para de mover novas mensagens da fila incoming para a fila active. Nesse ponto, as mensagens na fila incoming permanecerão lá até que haja espaço na fila active para processá-las.

Aumentar o limite da fila active pode exigir mais recursos do servidor, como memória e CPU, especialmente se o volume de emails for significativamente alto. Um limite muito alto pode causar sobrecarga no servidor, resultando em atrasos ou falhas na entrega de emails. É importante balancear a capacidade do servidor com o volume de emails esperado.

Aqui estão algumas ações que você pode tomar caso isso aconteça. Verifique se há mensagens problemáticas na fila active que estão causando atrasos. Mensagens que não podem ser entregues imediatamente são movidas para a fila deferred. Ao resolver esses problemas (por exemplo, corrigindo erros de configuração, aumentando os recursos do servidor, ou resolvendo problemas de rede), você pode reduzir o tamanho da fila active.

Se possível, você pode configurar políticas que priorizem a entrega de certos tipos de mensagens ou mensagens para determinados domínios, ajudando a limpar a fila active mais rapidamente. Implemente um sistema de monitoramento que alerte quando a fila active estiver se aproximando do limite, para que você possa tomar medidas preventivas antes que o limite seja atingido.

Fluxo do email

Vamos seguir o caminho que um email percorre no Postfix desde o momento em que ele é recebido até que seja encaminhado para o próximo Mail Transfer Agent (MTA).

Quando um email chega ao servidor Postfix, ele é recebido por um dos serviços de entrada, como o SMTP daemon (smtpd), que aceita a conexão de entrada. O SMTP daemon realiza verificações iniciais, como checar as restrições de remetente e destinatário, autenticação, e aplicar políticas anti-spam ou anti-relay se configuradas.
Após o email ser aceito pelo SMTP daemon, ele é colocado na fila incoming. A fila incoming serve como área temporária onde as mensagens aguardam para serem processadas pelo Postfix.
O serviço cleanup processa o email na fila incoming, aplicando verificações adicionais, como substituição de aliases e verificação de regras de reescrita. O email então é formalmente preparado para ser enfileirado e entregue. Depois disso, o queue manager (qmgr) assume a responsabilidade de gerenciar as mensagens. Ele verifica a fila incoming e decide para onde mover as mensagens.
Se a fila active tem espaço (menos que 20.000 mensagens, por padrão), o queue manager move as mensagens da fila incoming para a fila active.
Se a fila active está cheia, as mensagens permanecem na fila incoming até que haja espaço disponível.

Uma vez na fila active, as mensagens estão prontas para serem entregues. A fila active é onde as mensagens aguardam por uma tentativa de entrega imediata. O Postfix processa as mensagens na fila active da seguinte forma:
O Postfix determina o próximo destino do email, seja outro MTA (por exemplo, o MTA de destino do email) ou uma caixa de correio local.
Se a entrega é para um MTA remoto, o Postfix estabelece uma conexão SMTP com o MTA de destino e tenta entregar a mensagem.

Se a entrega for bem-sucedida, a mensagem é removida da fila active. Se a entrega falha temporariamente (por exemplo, devido a problemas de rede ou servidor do destinatário indisponível), a mensagem é movida para a fila deferred. O Postfix tentará reentregar a mensagem em intervalos regulares.
Se a entrega falha permanentemente (por exemplo, o endereço de email não existe), a mensagem pode ser retornada ao remetente com uma notificação de falha.
As mensagens na fila deferred são reprocessadas pelo queue manager em intervalos definidos, na esperança de que a condição temporária tenha sido resolvida. Essas mensagens são movidas de volta para a fila active para uma nova tentativa de entrega.

A fila hold no Postfix é uma fila especial onde as mensagens são colocadas em espera indefinida até que o administrador do sistema decida intervir. Isso significa que, ao contrário das outras filas (como active ou deferred), as mensagens na fila hold não têm tentativas automáticas de entrega e permanecem lá até que sejam manualmente movidas para outra fila ou descartadas.

DNSBL

O DNSBL, ou Domain Name System-based Blackhole List, é uma ferramenta utilizada por servidores de email para identificar e bloquear mensagens indesejadas, como spam, que vêm de endereços IP ou domínios suspeitos. Ele combina a funcionalidade do DNS (Domain Name System) com listas negras que contêm informações sobre endereços reconhecidamente envolvidos em atividades maliciosas, como o envio de spam, phishing, ou a propagação de malware.

Imagine que um servidor de email recebe uma tentativa de entrega de mensagem. Antes de permitir que o email chegue à caixa de entrada do destinatário, o servidor consulta uma lista negra, que é mantida por um serviço especializado em identificar fontes de spam e outras atividades maliciosas. Essa consulta é feita usando o sistema DNS, que é o mesmo sistema que traduz nomes de domínio em endereços IP na internet.

Se o endereço IP ou domínio do remetente estiver listado na DNSBL, isso significa que ele já foi identificado como uma fonte potencial de spam ou de outro tipo de ameaça. Nesse caso, o servidor de email pode bloquear a mensagem, marcá-la como spam, ou tomar outra ação definida pelo administrador do sistema. Se o endereço não estiver na lista negra, o email é processado normalmente.

O uso de uma DNSBL não substitui a necessidade de um sistema de antispam completo, como o Rspamd. Enquanto a DNSBL é uma ferramenta útil para bloquear emails provenientes de endereços IP ou domínios conhecidos por enviar spam ou se envolver em atividades maliciosas, ela faz parte de uma abordagem mais ampla para a proteção contra spam e outras ameaças.

Mailists

Um Mailing List ou Lista de Distribuição é um serviço que permite enviar emails para um grupo de pessoas ao mesmo tempo. Os membros se inscrevem em uma lista com um endereço de email específico (por exemplo, promocoes@exemplo.com). Quando alguém envia um email para esse endereço, o servidor de mailing list reenvia automaticamente a mensagem para todos os inscritos na lista. Os Mailing lists são usados para discussões em grupo, newsletters, e distribuição de informações para um grande número de pessoas sem precisar enviar emails individuais.

Software como Mailman, Listserv e Google Groups são usados para gerenciar mailing lists, permitindo adicionar ou remover membros, moderar mensagens e configurar opções de entrega. Essencialmente, uma mailing list facilita a comunicação em massa por email. Tenho um tutorial de como instalar e fazer as configurações para um servidor que deverá operar com o Mailman aqui, nesse tutorial a configuração é simples porque o Postfix não tem a necessidade de entregar emails locamente, apenas para a lista.

Em um servidor de email onde deve-se entregar emails localmente e ainda trabalhar com um servidor de lista como o Mailman, temos que levar algumas coisas em consideração quanto ao que conhecemos do funcionamento do servidor de emails. Isso seria um tópico mais avançado, mas como acho que pode acabar ajudando algúem, vou descrever alguns desses conceitos.

Para que um servidor de email consiga entregar emails corretamente, é necessário que ele tenha usuários configurados. Tradicionalmente, usamos usuários locais, registrados no sistema (em arquivos como /etc/passwd e /etc/shadow), e a entrega de emails para esses usuários é realizada pelo agente de entrega local. No entanto, em cenários mais complexos e profissionais, é altamente recomendado utilizar uma configuração mais avançada. Em vez de depender das contas locais do sistema, podemos armazenar as informações dos usuários em bancos de dados externos, como LDAP ou SQL. Isso oferece maior flexibilidade e segurança na gestão de contas de email.

Quando optamos por essa abordagem, os usuários são considerados usuários virtuais. Como as informações desses usuários não estão disponíveis nos arquivos locais do sistema, o agente de entrega local não consegue acessá-las. Nesse contexto, é necessário configurar o servidor de email para trabalhar com usuários virtuais, garantindo que os emails sejam entregues corretamente, mesmo que as informações dos usuários estejam armazenadas fora do sistema local.

Outro aspecto crucial a ser considerado é o nome do servidor de email e como ele interage com o Mailman. Quando um email é enviado para um servidor que utiliza o Mailman para gerenciamento de listas de distribuição, o fluxo de mensagens segue um processo específico. O Postfix, o servidor de email, recebe a mensagem inicialmente, um arquivo de rotas é usado para encaminhar o email para o Mailman. Cada endereço de email utilizado pelo Mailman é configurado com uma rota específica, direcionando a mensagem para o serviço LMTP (Essas rotas são criadas pelo Mailman ao criar uma nova lista).

Vamos considerar um cenário em que o servidor de email precisa entregar emails para usuários locais utilizando LDAP e também gerenciar listas de distribuição. Para este exemplo, o domínio configurado é exemplo.com.br e o nome do servidor é mail, resultando no FQDN do servidor como mail.exemplo.com.br. Normalmente o parâmetro mydestination é configurado assim mydestination = $myhostname, localhost.$mydomain, localhost, isso significa que Postix pega o domínio de $myhostname, agora vamos supor que o myhostname esteja configurado assim myhostname = exemplo.com.br.

Nesse cenário quando o Postfix receber um email, se o destinatário estiver no mapa de rotas, será entregue para o Mailman, mas e se não estiver, qual será o caminho nesse caso? Se o destinatário não estiver no mapa de rotas, o Postfix verificará se o domínio do destinatário (a parte após o @) está listado na configuração mydestination. Se o domínio estiver em mydestination o Postfix tratará o email como destinado a um usuário local e entregará a mensagem usando os métodos configurados para entrega local, como o agente de entrega local ou qualquer outro agente configurado para usuários locais.

Vamos nos atentar ao fato de que o agente de entrega local não consegue acessar os dados de usuários virtuais. Isso significa que, se você tentar entregar um email para um usuário virtual usando o agente local, ele não conseguirá encontrar o usuário e retornará um erro de "usuário desconhecido". Para endereços virtuais, é necessário configurar o parâmetro virtual_transport, apontando para o Dovecot, que será responsável por gerenciar esses endereços a partir desse ponto.

Outro detalhe importante é que o nome do host (do servidor Postfix) pode ser o mesmo para o qual as pessoas enviam emails. Por exemplo, se myhostname estiver configurado como exemplo.com.br e você enviar um email para bob@exemplo.com.br, o Postfix tentará entregar o email localmente porque o domínio do destinatário é o mesmo que o configurado em mydestination. O email enviado para bob@exemplo.com.br será devolvido ao remetente com o erro "usuário desconhecido" porque o Postfix, ao ver que o domínio do destinatário (exemplo.com.br) coincide com o configurado em myhostname, assume que o destinatário é local. No entanto, como o usuário é virtual, o agente de entrega local não consegue verificar a existência desse usuário, resultando no erro.

Se o domínio configurado em mydestination for diferente do domínio do destinatário, o Postfix não tratará o email como local. Nesse caso, ele continuará o processamento normal de entrega, encaminhando a mensagem de acordo com as configurações definidas. Como você configurou o virtual_transport para apontar para o Dovecot, o Postfix redirecionará a mensagem para o Dovecot, que então cuidará da entrega para o usuário virtual correspondente.

A solução é configurar o myhostname como myhostname = mail.exemplo.com.br. Dessa forma, o domínio estará sempre diferente do destinatário, e o Postfix não tratará o email como local. Lembre-se de que utilizar o FQDN tanto em myhostname quanto em myorigin é a forma correta de configurar esses parâmetros. Uma dica importante é que, em cenários complexos onde você se depara com erros de "usuário desconhecido", é fundamental entender o fluxo de processamento do email para identificar onde está o problema. Isso também afeta aliases que se expandem para comandos, pois esses comandos só podem ser executados quando o email é tratado pelo agente de entrega local. Se o email for interpretado como virtual devido a uma configuração incorreta, o comando não será executado.

Gerenciando o Postfix pela CLI - Command Line Interface

O Postfix é um dos servidores de email mais populares e confiáveis, e sua administração pode ser feita em grande parte através da linha de comando (CLI). Aqui estão alguns dos principais utilitários de gerenciamento do Postfix e suas funções:

postfix

O comando postfix é o utilitário principal para gerenciar o serviço Postfix, com ele podemos iniciar, parar, reiniciar, recarregar ou verificar o estado do serviço Postfix.

Terminal

╼ $ postfix start  # Inicia o serviço Postfix.
╼ $ postfix stop   # Para o serviço Postfix.
╼ $ postfix reload # Recarrega a configuração do Postfix sem parar o serviço.
╼ $ postfix status # Exibe o status atual do serviço Postfix.

postalias

O postalias é usado para compilar o arquivo de aliases em um formato de banco de dados que o Postfix pode consultar rapidamente.

Terminal

╼ $ postalias /etc/aliases # Atualiza o banco de dados de aliases a partir do arquivo /etc/aliases.

postcat

O postcat é usado para permitir que os administradores inspecionem o conteúdo das mensagens que estão na fila sem precisar processá-las.

Terminal

# Obtenha o ID:
╼ $ mailq

# Inspecione:
╼ $ postcat -q QUEUE_ID # Exibe o conteúdo da mensagem identificada pelo QUEUE_ID.

postmap

O postmap é similar ao postalias, mas enquanto o postalias é usado apenas para trabalhar com o arquivo /etc/alias, o postmap é utilizado para compilar arquivos de mapa, como os de alias, transportes, ou restrições de acesso, em um formato otimizado para consulta rápida. O postmap ainda pode ser usado para testar diversos tipos de mapas, não se limitando apenas a mapas de aliases. Aqui estão alguns exemplos de como você pode usar o postmap para trabalhar com diferentes mapas:

Terminal

# Atualiza o banco de dados de transporte que define como os emails devem ser roteados para diferentes domínios.
╼ $ postmap /etc/postfix/transport

# Atualiza o banco de dados de mapas virtuais que define o redirecionamento de emails para domínios virtuais.
╼ $ postmap /etc/postfix/virtual

# Atualiza o banco de dados de acesso que define quais endereços IP ou domínios têm permissão para se conectar ao servidor de email.
╼ $ postmap /etc/postfix/access

# Testar as regras que estão no mapa do ldap:
╼ $ postmap -q sender@example.com.br ldap:/etc/postfix/ldap.cf

# Outras formas: 
╼ $ postmap -q sender@example.com.br hash:/etc/postfix/FILE

postdrop

O postdrop é usado para adicionar mensagens às filas do Postfix de forma segura, geralmente usado em scripts e automações.

Terminal

╼ $ postdrop -d # Adiciona um email à fila de entrega.

postkick

O postkick é utilizado para fazer com que o qmgr processe as filas mais rapidamente, útil quando há mensagens que precisam ser tratadas imediatamente.

Terminal

╼ $ postkick # Sinaliza o gerenciador de filas para processamento.

postlock

O postlock é usado para proteger arquivos e recursos para evitar problemas de concorrência durante a manipulação de mensagens e configurações.

Terminal

╼ $ postlock /var/mail/root from

postlog

O postlog é utilizado para gerenciar logs do Postfix. Embora menos utilizado diretamente, é fundamental para a administração e monitoramento dos logs do sistema de email.

postqueue

O postqueue é utilizado para visualizar e gerenciar as mensagens na fila do Postfix. Permite a visualização do conteúdo das filas e a execução de operações de gerenciamento, como a limpeza ou reprocessamento de mensagens.

Terminal

╼ $ postqueue -p # Exibe as email que estão na fila.
╼ $ postqueue -f # Força o envio dos emails que estão na fila.

postconf

O postconf é usado para exibir e modificar parâmetros de configuração.

# Exibe todas as configurações não padrão, ou seja, aquelas que foram modificadas ou definidas explicitamente no `main.cf`.
postconf -n

# Exibir um parâmetro específico:
postconf <parametro>

# Exibir todas as configurações (padrão e não padrão):
postconf -d

# Modificar um parâmetro temporariamente:
postconf <parametro>=<valor>

# Modificar permanentemente:
postconf -e <parametro>=<valor>

# Validar Configurações (Se tiver erro vai exibir):
postconf -c /caminho/para/configuracao

postsuper

O postsuper é usado para gerenciar e manipular mensagens na fila do Postfix. Permite ações como o bloqueio, desbloqueio, e exclusão de mensagens na fila. Também pode ser usado para mover mensagens entre filas.

Terminal

╼ $ postsuper -d QUEUE_ID # Remove uma email específica da fila.
╼ $ postsuper -r QUEUE_ID # Reenfileira uma email na fila.
╼ $ postsuper -h QUEUE_ID # Coloca um email em hold.
╼ $ postsuper -H QUEUE_ID # Libera um email que está em hold.
╼ $ postsuper -s # Reenfileira uma email na fila.

qshape

Uma outra ferramenta muito útil para analisar a fila de e-mails é o qshape. Com esse comando ele nos retorna as mensagens que estão ficando presas na fila, qual a origem/destinos e etc. Para conseguir usar essa ferramenta precisamos instalar o pacote postfix-perl-scripts.

Processamento de Emails

Quando lidamos com emails alguns termos como Messenger, Envelope, Header, Body e Attachment aparecerão com certa frequência. Vamos entender o que cada um significa.

Messenger

O termo messenger pode ser usado de várias maneiras, mas no ambiente de email, é o cliente.

Envelope

O envelope de um email refere-se às informações de controle que envolvem a mensagem e ajudam a determinar o caminho que ela deve seguir para chegar ao destinatário. Diferente do corpo do email (Body), o envelope não é visível para o destinatário final; é usado pelos servidores de email para gerenciar o fluxo de mensagens.

Componentes do Envelope:

Envelope Sender: O endereço do remetente, usado para o retorno ou respostas.
Envelope Recipient: O endereço do destinatário para o qual a mensagem está sendo enviada.

Envelope Sender Vazios

Bloquear envelopes de remetente vazios pode parecer uma boa prática para proteger seu servidor de email, mas existem algumas razões pelas quais pode não ser a melhor abordagem. Alguns servidores de relés podem enviar emails sem um envelope sender definido, especialmente em cenários de encaminhamento interno ou quando a informação não é relevante para o destino final. Bloquear todos os envelope senders vazios pode levar ao bloqueio de emails legítimos, causando inconvenientes para os usuários.

O header (cabeçalho) de um email contém metadados sobre a mensagem. Esses metadados incluem informações sobre o remetente, destinatário, assunto, data, e outros detalhes que ajudam a gerenciar e processar a mensagem.

Componentes Comuns do Header:

From: O endereço de e-mail do remetente.
To: O endereço de e-mail do destinatário.
Cc: O campo Cc (Carbon Copy) coloca em cópia outros destinatários.
Reply-To: Especifica o endereço de email para o qual as respostas ao email devem ser enviadas.
Content-Type: Especifica o tipo de conteúdo do email, pode ser text/plain (texto simples), text/html (html), multipart/mixed (texto e anexo) etc.
MIME-Version: Indica a versão do protocolo MIME (Multipurpose Internet Mail Extensions). Este campo é usado para garantir que o cliente de email possa interpretar corretamente a estrutura do email, incluindo qualquer formatação especial ou anexos.
Received: 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.
Return-Path: É o endereço para o qual as mensagens de erro e rejeição são enviadas.
X-Originating-IP: Opcional. Esse campo pode mostrar o IP do cliente que enviou o email.
Subject: O assunto da mensagem.
Date: A data e hora em que a mensagem foi enviada.
Message-ID: Um identificador único para a mensagem.

tip

O Envelope Sender e Envelope Recipient não é a mesma coisa que o sender e recipint que é fornecido aqui no Header. O Envelope Sender e o Envelope Recipient são usados internamente pelos servidores de email e não são visíveis para os usuários finais. Já o Header Sender e o Header Recipient são visíveis e mostrados para os usuários finais.

O Envelope Sender e o Envelope Recipient são usados para o roteamento e gerenciamento da entrega de emails, enquanto que o Header Sender e o Header Recipient fornecem informações sobre o remetente e destinatário da perspectiva do usuário.

Body

O corpo (body) do email é a parte principal da mensagem onde o conteúdo real é escrito. É a seção visível para o destinatário e pode conter texto, imagens, e formatação.

Componentes do Corpo:

Texto: O conteúdo principal da mensagem.
Formato: Pode ser texto simples ou HTML, permitindo formatação rica.

MIME encoding

MIME encoding é o processo de transformar dados binários ou texto em uma forma que possa ser incluída em um email sem corromper ou alterar os dados durante a transmissão. Isso é necessário porque o protocolo SMTP, que é usado para enviar emails, lida apenas com texto ASCII, e qualquer dado não textual deve ser convertido para um formato que possa ser transmitido sem problemas.

O MUA é quem realiza a tarefa de codificar o anexo binário e também cria automaticamente a estrutura MIME necessária para incorporar o texto do e-mail e os anexos codificados em um formato compreendido por outros MUAs com capacidade MIME. Abaixo vemos os dois tipos de MIME Enconding para arquivos binários.

Base64
Converte dados binários em uma representação de texto ASCII usando um conjunto de 64 caracteres imprimíveis. É o método mais comum de codificação para anexos e conteúdo não textual. É utilizado para codificar arquivos binários, como imagens, documentos, e outros tipos de mídia. Base64 aumenta o tamanho dos dados em aproximadamente 33%. No Header é representado como Content-Transfer-Encoding.
Quoted-Printable
Codifica o texto que pode conter caracteres não ASCII, preservando a legibilidade. Caracteres que não podem ser representados diretamente são codificados em uma forma de escape, usando um sinal de igual (=) seguido por dois dígitos hexadecimais. Adequado para textos que contêm caracteres especiais e que precisam ser representados em uma forma legível.

Normalmente textos serão codificados com Quoted-Printable e anexos em Base64.

Attachment

Um anexo (attachment) é um arquivo que é enviado junto com um email. Pode ser qualquer tipo de arquivo, como documentos, imagens, ou vídeos.

Componentes de Anexos:

Filename: O nome do arquivo anexado.
MIME Type: O tipo de mídia do arquivo (por exemplo, application/pdf para um PDF).
Content-Disposition: Informações sobre como o anexo deve ser tratado pelo cliente de email (por exemplo, se deve ser exibido inline ou como um anexo separado).

Controle do SMTP

Os parâmetros smtpd_*_restrictions no Postfix são usados para definir restrições e políticas de controle sobre como o servidor SMTP deve lidar com conexões, comandos e dados durante o processo de recebimento de emails. Estes parâmetros permitem que o administrador controle aspectos como quais clientes podem se conectar, quem pode enviar emails, e se um email deve ser aceito ou rejeitado com base em vários critérios.

As restrições definidas pelos parâmetros smtpd_*_restrictions no Postfix são aplicadas com base nas informações do envelope do email, e não nos headers. Essas restrições são aplicadas em uma ordem específica, e a ordem de aplicação pode afetar como os e-mails são processados e aceitos ou rejeitados. Normalmente colocarmos os permit_* primeiro, depois colocamos os check_* caso seja de permissão e por fim os reject_*. Algumas das opções são:

smtpd_data_restrictions

Define restrições aplicadas após o comando DATA, que precede o envio do corpo da mensagem.

Opções para se usar com smtpd_data_restrictions:

reject_multi_recipient_bounce
Rejeita mensagens de erro de entrega (bounces) que têm mais de um destinatário. Esse parâmetro é útil para prevenir abusos, como ataques de backscatter, onde um grande número de mensagens de erro é enviado a partir de servidores mal configurados ou comprometidos.
check_policy_service
Verifica uma política externa que pode aplicar regras adicionais antes de aceitar os dados.

smtpd_sender_restrictions

Aplica restrições ao endereço do remetente especificado no comando MAIL FROM.

Opções para se usar com smtpd_sender_restrictions:

reject_unknown_sender_domain
Rejeita a solicitação quando o Postfix não é o destino final para o endereço do remetente e o domínio do remetente (MAIL FROM) não possui registros DNS válidos, como registros MX ou A.DNS, ou um domínio do remetente tem um registro MX malformado, como um registro com um nome de host MX de comprimento zero.
reject_non_fqdn_sender
Rejeita se o endereço do remetente não for um endereço de email válido (por exemplo, sem @ ou domínio).
reject_unlisted_sender
Controla se o servidor deve aceitar ou rejeitar emails baseados no endereço do remetente fornecido no envelope (comando MAIL FROM) em comparação com a lista de endereços válidos configurados no servidor. Quando o Postfix recebe um email, ele verifica se o endereço do remetente (MAIL FROM) está listado como um remetente válido no servidor. Se o endereço do remetente não estiver listado, o Postfix rejeita a mensagem com um erro.
reject_authenticated_sender_login_mismatch
Rejeita a solicitação quando o cliente está autenticado com SASL, mas o endereço MAIL FROM não está listado em $smtpd_sender_login_maps ou o nome de login SASL não é proprietário desse endereço. Isso impede que um cliente autenticado use um endereço MAIL FROM que não seja explicitamente de sua propriedade. Portanto, se um usuário autenticado tentar alterar o campo From para um endereço que não esteja autorizado a usar, o Postfix rejeitará a mensagem com base nessa restrição.
reject_known_sender_login_mismatch
Quando o cliente está autenticado com SASL, rejeita a solicitação quando o endereço MAIL FROM está listado em $smtpd_sender_login_maps, mas o nome de login SASL não é proprietário desse endereço. Quando o cliente não está autenticado com SASL, rejeita a solicitação quando o SASL está habilitado e o endereço MAIL FROM está listado em $smtpd_sender_login_maps. Isso protege qualquer endereço MAIL FROM listado em $smtpd_sender_login_maps, permitindo ainda que um cliente use qualquer endereço MAIL FROM não listado.

smtpd_recipient_restrictions

Aplica restrições ao endereço do destinatário especificado no comando RCPT TO. Durante uma sessão SMTP, depois que o servidor recebe o comando MAIL FROM (que especifica o remetente do e-mail), o cliente SMTP envia um ou mais comandos RCPT TO para identificar os destinatários do e-mail. Cada comando RCPT TO indica um endereço de e-mail para o qual a mensagem deve ser entregue.

O servidor SMTP valida o endereço de destino. Isso pode incluir verificar se o domínio do destinatário é válido, se o endereço de e-mail existe, e se o servidor está autorizado a entregar e-mails para aquele destinatário. Se o endereço for aceito, o servidor responde com um código de status 250 (OK). Se houver algum problema, o servidor pode responder com códigos de erro, como 550 (Mailbox unavailable) ou 451 (Requested action aborted).

Resumindo, aplica restrições que ajudam a filtrar e bloquear e-mails indesejados ou potencialmente maliciosos, impedindo que spam chegue ao servidor. Ao rejeitar e-mails inválidos ou suspeitos o mais cedo possível durante a transação SMTP, o servidor economiza recursos e melhora a eficiência geral.

Opções para se usar com smtpd_recipient_restrictions:

reject_unauth_destination
Rejeita emails para destinos que não são autorizados (ou seja, destinos fora dos domínios locais ou dos domínios tratados pelo servidor). Para que funcione corretamente, você deve configurar os seguintes parâmetros: mydestination, relay_domains e virtual_alias_domains. Rejeita emails para domínios que não estão listados em mydestination, relay_domains, e virtual_alias_domains.
check_recipient_access
Verifica um mapa de acesso personalizado para permitir ou rejeitar destinatários específicos.
reject_non_fqdn_recipient
Rejeita e-mails enviados para destinatários cujo endereço de e-mail não esteja em um formato de domínio totalmente qualificado (FQDN). Este parâmetro ajuda a garantir que os e-mails sejam enviados para domínios corretamente formatados, reduzindo o risco de problemas de entrega ou configuração incorreta.
reject_unknown_recipient_domain
Rejeita e-mails enviados para destinatários cujo domínio não pode ser resolvido via DNS. Esse parâmetro é útil para evitar a aceitação de e-mails destinados a domínios inválidos ou inexistentes, o que pode ajudar a reduzir o volume de spam e e-mails indesejados.
reject_unverified_recipient
Rejeita e-mails enviados para destinatários que não puderam ser verificados durante a recepção do e-mail. A verificação normalmente envolve um teste de entrega simulado para confirmar se o endereço de e-mail do destinatário existe no sistema final.

smtpd_relay_restrictions

É usado para definir as condições sob as quais o Postfix permitirá ou recusará a retransmissão (relay) de emails. Retransmitir um email significa aceitar uma mensagem de um cliente e enviá-la para um servidor de email externo. Este é um ponto crítico de segurança, pois se o servidor de email for configurado para permitir retransmissão indiscriminada, ele pode ser usado por spammers para enviar emails de forma massiva.

smtpd_client_restrictions

Define restrições baseadas no cliente que está tentando se conectar ao servidor SMTP. Esta verificação é feita no início da conexão SMTP.

Opções para se usar com smtpd_client_restrictions:

permit_mynetworks
Permite conexões de hosts definidos na lista mynetworks.
reject_unknown_client_hostname
Rejeita conexões de clientes cujo hostname não pode ser resolvido via DNS. Requer não apenas a existência dos mapeamentos de endereço para nome e nome para endereço, mas também que os dois mapeamentos reproduzam o endereço IP do cliente.
check_client_access
Verifica um mapa de acesso personalizado para permitir ou rejeitar clientes.
permit_sasl_authenticated
Permite a aceitação de emails de clientes que tenham se autenticado com sucesso via RFC 4954 (AUTH). Quando configurado, qualquer cliente que se autenticar corretamente pode passar pelas outras restrições de envio. É útil para permitir que usuários legítimos enviem emails, mesmo que outros controles rígidos estejam em vigor.
reject_unknown_reverse_client_hostname
Rejeita emails de clientes cujo nome de host inverso (PTR) não pode ser resolvido para um nome de domínio, ou cujo nome de domínio não corresponde ao endereço IP do cliente. Isso ajuda a prevenir emails de servidores mal configurados ou falsificados.
reject_unauth_pipelining
Rejeita emails de clientes que tentam usar o comando SMTP pipelining sem estar autenticados. Pipelining é uma técnica que permite ao cliente enviar múltiplos comandos SMTP em sequência sem esperar por uma resposta para cada um. Este parâmetro impede que clientes não autenticados usem essa técnica. Pipelining não autenticado pode ser usado para ataques de spam ou abuso do servidor. Ao rejeitar pipelining de clientes não autenticados, o Postfix melhora a segurança do servidor.

smtpd_helo_restrictions

Controla as restrições baseadas no comando HELO/EHLO, que é o primeiro comando que um cliente SMTP envia ao servidor para se identificar.

Opções para se usar com smtpd_helo_restrictions:

reject_invalid_helo_hostname
Rejeita conexões se o hostname fornecido no comando HELO/EHLO não for válido. Deve-se especificar smtpd_helo_required = yes para aplicar totalmente essa restrição (sem smtpd_helo_required = yes, um cliente pode simplesmente ignorar reject_invalid_helo_hostname não enviando HELO ou EHLO).
reject_non_fqdn_helo_hostname
Rejeita se o hostname no comando HELO/EHLO não for um nome de domínio totalmente qualificado (FQDN). Deve-se especificar smtpd_helo_required = yes para aplicar totalmente essa restrição (sem smtpd_helo_required = yes, um cliente pode simplesmente ignorar reject_invalid_helo_hostname não enviando HELO ou EHLO).

tip

É sempre bom forçar o cliente a enviar o HELO/EHLO ao iniciar uma comunicação com o servidor de email.

smtpd_end_of_data_restrictions

Aplica restrições após o recebimento completo de uma mensagem, no final do comando DATA.

Role Account

Uma role account (ou conta de função) é uma conta de usuário que não está associada a uma pessoa específica, mas sim a uma função ou tarefa dentro de uma organização. Essas contas são usadas para serviços ou processos que precisam ser acessados por várias pessoas ou sistemas, em vez de por um indivíduo específico. Existem dois endereços que devemos sempre aceitar mensagens no servidor de email para ficar de acordo com a RFC.

postmaster
Os administradores de sistemas e servidores de e-mail usam o endereço postmaster para receber mensagens sobre problemas técnicos, solicitações de suporte e outras questões relacionadas ao funcionamento do servidor de e-mail. Este é um endereço oficial definido pela RFC 5321 e pela RFC 822 (e suas atualizações).
abuse
O endereço abuse permite que outras organizações ou usuários reportem abusos ou problemas relacionados ao domínio. Ele ajuda a manter a reputação do domínio e a responder rapidamente a qualquer comportamento inadequado.

Para servidor Web e DNS

Opcionalmente devemos aceitar emails para as role accounts abaixo:

webmaster
Caso tenhamos um servidor Web no domínio.
hostmaster
Caso tenhamos servidores DNS no domínio.

Podemos criar um arquivo contendo:

postmaster@   OK
abuse@        OK

E depois aplicar essa configuração: smtpd_recipient_restrictions = ... check_recipient_access hash:/etc/postfix/roleaccount ...

Registro DNS Bogus

Um Bogus DNS Record refere-se a um registro DNS que é incorreto, malformado ou fraudulento, e pode comprometer a integridade e a segurança da resolução de nomes na Internet. Esses registros podem causar diversos problemas, como falhas na resolução de nomes, redirecionamento de tráfego para sites falsos ou não seguros, e impactos na entrega de e-mails.

Para esse tipo de bloqueio podemos criar um arquivo com o seguinte conteúdo:

# Bogus
0.0.0/8       550 Broadcast
0.0.0/8      550 RFC 1918
16.0.0/12   550 RFC 1918
168.0.0/16  550 RFC 1918
0.0.0/8     550 Loopback
0.0.0/8     550 Multicast
X.X.X.X/Y       550 Achado em ...

Agora é só aplicar:

smtpd_recipient_restrictions = 
   ...
   check_sender_mx_access cidr:/etc/postfix/bogus
   ...

Mail Gateways

Um Mail Gateway (ou smarthost como também é conhecido) é um sistema que atua como um intermediário para o tráfego de e-mails entre diferentes redes ou domínios. Ele pode ser usado para várias funções, incluindo filtragem de spam, verificação de vírus, tradução de formatos de e-mail ou até mesmo roteamento de e-mails entre sistemas diferentes que usam protocolos ou formatos incompatíveis.

Empresas e ISPs frequentemente utilizam gateways de e-mail para controlar o tráfego SMTP que entra e sai de suas redes. O mail gateway age como um ponto central através do qual todo o tráfego de e-mail deve passar, permitindo que a organização implemente políticas de segurança, verificação de spam e malware, e outras medidas de controle. O tráfego na porta 25, que é a porta padrão usada pelo SMTP, é geralmente configurado para só alcançar o mail gateway. Isso significa que, dentro da rede, os clientes de e-mail (MUAs) não enviam e-mails diretamente para servidores de e-mail externos, mas sim através do mail gateway. O objetivo é garantir que todas as mensagens sejam verificadas e processadas de acordo com as políticas da organização antes de sair da rede.

O servidor que atua como Mail Gateway está exposto na internet, e o registro MX (Mail Exchanger) no DNS da empresa aponta para ele. Esse é o ponto de entrada para todos os e-mails externos destinados ao domínio da empresa. Apenas o mail gateway tem permissão para se comunicar diretamente com servidores externos na porta 25 (já que ele é o único acessível na Internet), o que ajuda a prevenir abusos e a garantir a segurança. Quando um e-mail é enviado para um endereço dentro do domínio da empresa, ele é entregue primeiro ao Mail Gateway, conforme especificado pelo registro MX.

O Mail Gateway processa o e-mail (por exemplo, verificando spam, malware, etc.) e, em seguida, o redireciona para o MTA que está dentro da rede interna da empresa. Esse MTA interno não é acessível diretamente pela internet, e a comunicação entre o Mail Gateway e o MTA interno ocorre por meio de canais seguros, garantindo que apenas o Mail Gateway possa entregar e-mails a ele. O MTA interno recebe o e-mail do Mail Gateway, processa-o conforme necessário (por exemplo, aplicando regras de roteamento interno, entregando-o à mailbox do destinatário, etc.). Esse MTA pode estar integrado com sistemas de gerenciamento de usuários e caixas de correio, como o Dovecot, que armazenará as mensagens para que os usuários possam acessá-las.

Os usuários se conectam diretamente ao MTA que está dentro da rede interna para acessar seus e-mails, usando protocolos como IMAP ou POP3 para receber e visualizar as mensagens. Eles não se conectam diretamente ao Mail Gateway; a interação deles é exclusivamente com o servidor que gerencia as caixas de correio na rede interna.

Configurando um Mail Gateway

Vamos ver como configurar o Mail Gateway, fornecerei a configuração primeiro e depois explicarei.

/etc/postfix/main.cf
# Nesse caso vamos configurar myorigin, mas onde você tenha mais de um domínio no mesmo servidor de email, tome cuidado.
myorigin = example.com

# Adicione o IP do servidor de email que está na rede interna (ex: 192.168.10.15).
# Dessa forma outros servidores não poderão usar o Mail Gateway para enviar emails.
mynetworks = 127.0.0.0/8 192.168.10.15/32

# Desative a entrega local:
mydestination =
local_recipient_maps =
local_transport = error:local mail delivery is disabled

# Não aceita emails para "user@anything.example.com", apenas emails que são destinados a '@example.com':
parent_domain_matches_subdomains = 
    debug_peer_list smtpd_access_maps

# Aplica regras de retransmissão (relay) de emails:
smtpd_relay_restrictions =
   permit_mynetworks
   permit_sasl_authenticated

# Aplica restrições ao endereço do destinatário especificado no comando RCPT TO. Basicamente regras de bloqueio de spam.
smtpd_recipient_restrictions = 
    permit_mynetworks
    reject_non_fqdn_recipient
    reject_unknown_recipient_domain
    reject_unauth_pipelining
    reject_unverified_recipient


# Configure um arquivo de alias para que o servidor aceite emails de abuse e postmaster:
virtual_alias_maps = hash:/etc/postfix/virtual

# Agora configure os domínios que o Mail Gateway vai ter que retransmitir, ou seja, domínios que não serão entregues localmente:
relay_domains = example.com

# Crie uma lista com os usuários válidos:
relay_recipient_maps = hash:/etc/postfix/relay_recipients

# Vamos criar regras de roteamento personalizadas, especificando como e 
# para onde os emails devem ser entregues com base no domínio do destinatário.
transport_maps = hash:/etc/postfix/transport

A linha local_transport = error:local mail delivery is disabled cria uma mensagem de erro para entregas locais.

Porque usar relay_recipient_maps ?

O relay_recipient_maps evita que a fila de e-mails fique cheia de mensagens MAILER-DAEMON não entregues. Se você não puder manter uma lista de destinatários válidos, deverá especificar relay_recipient_maps = (ou seja, um valor vazio) ou deverá especificar um curinga @example.com x na tabela relay_recipients.

Ou seja, usar relay_recipient_maps significa que muitos e-mails indesejados podem ser rejeitados imediatamente, reduzindo o risco de sobrecarga nos servidores de email, ele faz isso rejeitando e-mails que não são destinados a destinatários válidos ou autorizados, limitando o potencial de abuso. Ao rejeitar e-mails inválidos ou indesejados o mais cedo possível, o Mail Gateway economiza recursos, como CPU, memória e espaço de armazenamento. Isso é essencial para manter o desempenho e a estabilidade do servidor.

Agora que temos o domínio que será retransmitido (em relay_domains) para outro servidor, temos que informar qual o MTA que vai receber as mensagens para esse domínio.

/etc/postfix/transport

example.com   relay:internal-mx.example.com:25

Agora configure os aliases abuse e postmaster para que esses sejam entregues corretamente:

/etc/postfix/virtual

postmaster      postmaster@example.com
abuse           abuse@example.com

Agora vamos configurar os usuários válido:

/etc/postfix/relay_recipients
postmaster@example.com   OK
abuse@example.com        OK

fulano@example.com       OK
bob@@example.com         OK
alice@example.com        OK

Agora vamos desativar o Local Delivery Agent, isso vai prevenir do daemon Master iniciar o agente de entregas locais, como não teremos nenhuma entrega local, não precisamos dele ativo.

/etc/postfix/master.cf

#local     unix  -       n       n       -       -       local

Por fim vamos aplicar tudo para que entre em vigor:

Terminal

# Compile o arquivo de transport:
$ sudo postmap /etc/postfix/transport

# Compile o arquivo de relay_recipients:
$ sudo postmap /etc/postfix/relay_recipients

# Compile o arquivo de virtual:
$ sudo postmap /etc/postfix/virtual

# Agora reinicie o postfix:
$ sudo postfix reload

Multiplos domínios

O Postfix é um servidor de e-mail capaz de gerenciar vários domínios de diferentes maneiras. Para que isso funcione temos alguns métodos distintos e para cada um técnicas diferentes para tipos de domínios, como canônicos, hospedados, domínios de backup MX e domínios de trânsito.

Domínios Canônicos

Na maioria das instalações do Postfix, o servidor é o destino final para um número limitado de domínios, chamados de domínios canônicos. Eles incluem os nomes de host e endereços IP da máquina em que o Postfix é executado e, às vezes, também incluem o domínio pai do nome do host. Esses domínios são normalmente gerenciados pela classe de endereços local do Postfix (local_domain), e o servidor trata todos os e-mails destinados a esses domínios como destinatários finais, processando-os internamente.

Os domínios configurados em mydestination são conhecidos como Domínios Canônicos porque listam todos os domínios do servidor de emails local.

Domínios Hospedados

Além dos domínios canônicos, o Postfix pode ser configurado para ser o destino final para qualquer número de domínios adicionais, que são conhecidos como domínios hospedados. Esses domínios não estão diretamente associados ao nome da máquina, mas o Postfix os gerencia para entrega de e-mails.

Existem dois modos principais de gerenciar domínios hospedados:

virtual_alias_domains
Usado quando o Postfix deve redirecionar e-mails destinados a um domínio hospedado para um ou mais endereços de e-mail reais. Por exemplo, se você receber um e-mail para info@exemplo.com, o Postfix pode redirecionar esse e-mail para admin@exemplo.com. Isso é feito através de alias (apelidos) que mapeiam endereços virtuais para endereços reais.

Resumindo, é usado quando os endereços de e-mail em um domínio não precisam de caixas de correio separadas no servidor. Em vez disso, os e-mails são redirecionados para outros endereços, que podem ser locais ou remotos. É útil em cenários onde múltiplos endereços virtuais precisam ser mapeados para endereços de e-mail reais, facilitando a administração e mantendo a flexibilidade.
virtual_mailbox_domains
Usado quando o Postfix deve armazenar as mensagens em caixas de correio locais para domínios hospedados. Aqui, o servidor Postfix age como um servidor de e-mail completo para esses domínios, armazenando as mensagens em caixas de correio associadas aos usuários do domínio hospedado.

Resumindo, é usado quando o Postfix deve gerenciar as caixas de correio para um domínio hospedado, armazenando as mensagens em caixas de correio locais. Cada usuário do domínio tem sua própria caixa de correio no servidor. É ideal para provedores de e-mail ou organizações que precisam gerenciar múltiplos domínios com usuários distintos, oferecendo uma solução completa de e-mail para esses domínios.

Domínios de Backup MX

Postfix também pode funcionar como um servidor MX de backup para outros domínios. Nessa configuração, o Postfix não é o destino final dos e-mails, mas sim um intermediário que armazena as mensagens enquanto o servidor MX primário está inacessível. Quando o servidor MX primário se torna disponível novamente, o Postfix reencaminha as mensagens para ele. Esta função é implementada por relay_domain.

Domínios de Trânsito

Finalmente, o Postfix pode ser configurado como um servidor de trânsito para o envio de e-mails através da internet. Neste caso, o Postfix não é o destino final das mensagens, mas serve como um relé que encaminha e-mails para outros servidores, geralmente para clientes ou usuários autorizados. Esta função é gerida por default_domain.

como configurar virtual domains ?

Como são muitos métodos, vou deixar o link para a documentação oficial, onde explicam como configurar todos os exemplos mencionados.

Veja aqui.

Explicando a Convenção de Símbolos no Terminal​

Antes de prosseguir​

Introdução​

Mail User Agent (MUA)​

Mail Transport Agent (MTA)​

Mail Delivery Agent (MDA)​

Simple Mail Transfer Protocol (SMTP)​

Open Relay​

Processo para enviar um email​

Protocolos envolvidos no serviço de Email​

SMTP​

Submission​

POP3​

IMAP​

LMTP​

Como o Postfix Funciona?​

Postfix Maps​

Index Maps​

Databases​

Entrega de email para usuários locais​

Entrega para um Comando​

Local vs Virtual​

Postfix Queues​

Fluxo do email​

DNSBL​

Mailists​

Gerenciando o Postfix pela CLI - Command Line Interface​

postfix​

postalias​

postcat​

postmap​

postdrop​

postkick​

postlock​

postlog​

postqueue​

postconf​

postsuper​

qshape​

Processamento de Emails​

Messenger​

Envelope​

Header​

Body​

Attachment​

Controle do SMTP​

smtpd_data_restrictions​

smtpd_sender_restrictions​

smtpd_recipient_restrictions​

smtpd_relay_restrictions​

smtpd_client_restrictions​

smtpd_helo_restrictions​

smtpd_end_of_data_restrictions​

Role Account​

Registro DNS Bogus​

Mail Gateways​

Configurando um Mail Gateway​

Multiplos domínios​

Domínios Canônicos​

Domínios Hospedados​

Domínios de Backup MX​

Domínios de Trânsito​

Explicando a Convenção de Símbolos no Terminal

Antes de prosseguir

Introdução

Mail User Agent (MUA)

Mail Transport Agent (MTA)

Mail Delivery Agent (MDA)

Simple Mail Transfer Protocol (SMTP)

Open Relay

Processo para enviar um email

Protocolos envolvidos no serviço de Email

SMTP

Submission

POP3

IMAP

LMTP

Como o Postfix Funciona?

Postfix Maps

Index Maps

Databases

Entrega de email para usuários locais

Entrega para um Comando

Local vs Virtual

Postfix Queues

Fluxo do email

DNSBL

Mailists

Gerenciando o Postfix pela CLI - Command Line Interface

postfix

postalias

postcat

postmap

postdrop

postkick

postlock

postlog

postqueue

postconf

postsuper

qshape

Processamento de Emails

Messenger

Envelope

Header

Body

Attachment

Controle do SMTP

smtpd_data_restrictions

smtpd_sender_restrictions

smtpd_recipient_restrictions

smtpd_relay_restrictions

smtpd_client_restrictions

smtpd_helo_restrictions

smtpd_end_of_data_restrictions

Role Account

Registro DNS Bogus

Mail Gateways

Configurando um Mail Gateway

Multiplos domínios

Domínios Canônicos

Domínios Hospedados

Domínios de Backup MX

Domínios de Trânsito