Skip to main content

211.1 Utilizando servidores de E-mail


Este tópico introduz os serviços que compõe o serviço de email, mostrando como todos se interagem para fornecer a funcionalidade de um email.



Introdução​

Vamos começar revisando a parte básica de um servidor de email como as nomeclaturas, que são importante para o entendimento básico do funcionamento de email e os agentes que atuam para que tudo funcione.



Mail User Agent - MUA​​

O Mail User Agent (MUA) é o cliente utilizado pelo usuário para escrever, enviar, receber, organizar e ler mensagens de e-mail.


Exemplos de MUA:

  • Mozilla Thunderbird;
  • Microsoft Outlook;
  • Apple Mail;
  • interfaces web como Gmail e Outlook.com.

Ao enviar uma mensagem, o MUA normalmente a encaminha para um servidor de submissão de e-mails, chamado Mail Submission Agent (MSA), utilizando o protocolo SMTP.

Em configurações mais simples, as funções de MSA e MTA podem ser executadas pelo mesmo software, como o Postfix ou o Exim.



Mail Submission Agent — MSA​

O Mail Submission Agent (MSA) recebe mensagens enviadas por um cliente de e-mail, também chamado de Mail User Agent (MUA), e as encaminha ao Mail Transfer Agent (MTA) responsável pelo transporte da mensagem até o servidor de destino.


O MSA é responsável especificamente pela submissão de mensagens. Ele normalmente exige autenticação para confirmar que o usuário está autorizado a enviar e-mails pelo servidor, embora também possa permitir o envio a partir de redes previamente autorizadas.


Durante a submissão, o MSA pode aplicar políticas de envio, validar os endereços utilizados, limitar remetentes autorizados, corrigir ou adicionar cabeçalhos e rejeitar mensagens que não atendam às regras configuradas. Após essas verificações, a mensagem é encaminhada ao MTA.


O acesso às mensagens armazenadas na caixa postal não é função do MSA. Essa tarefa é realizada por protocolos como IMAP e POP3, ou por uma aplicação de webmail.


As portas normalmente utilizadas para submissão são:

PortaUtilização
587/TCPSMTP Submission, normalmente com STARTTLS
465/TCPSMTP Submission com TLS implícito

A porta 587/TCP é normalmente utilizada para a submissão autenticada com STARTTLS, enquanto a porta 465/TCP estabelece a conexão TLS desde o início.



Mail Transport Agent - MTA​​

O Mail Transport Agent (MTA) é responsável por transportar mensagens entre servidores de e-mail.


Quando precisa entregar uma mensagem para outro domínio, o MTA consulta os registros MX do DNS para identificar qual servidor recebe mensagens em nome daquele domínio. A comunicação entre MTAs normalmente utiliza o protocolo SMTP pela porta 25/TCP.


Exemplos de MTA:

  • Postfix;
  • Sendmail;
  • Exim;
  • qmail;
  • Microsoft Exchange.

Caso a mensagem não possa ser entregue imediatamente, o MTA normalmente a mantém em uma fila e realiza novas tentativas. Dependendo do erro e da configuração, ele pode gerar uma mensagem de falha de entrega, conhecida como bounce.



Mail Delivery Agent - MDA​

O Mail Delivery Agent (MDA) é responsável pela entrega final da mensagem na caixa postal do destinatário.


Exemplos de MDA:

  • Procmail;
  • Maildrop;
  • Dovecot LDA;
  • Dovecot LMTP;
  • Cyrus LMTP.

O MTA pode executar o MDA diretamente ou encaminhar a mensagem para ele utilizando o protocolo LMTP.

Nem todo filtro antispam ou antivírus é necessariamente parte do MDA. Ferramentas como SpamAssassin, Rspamd e ClamAV podem ser integradas em diferentes etapas do fluxo de e-mail.



Local Mail Transfer Protocol - LMTP​

O Local Mail Transfer Protocol (LMTP) é semelhante ao SMTP, mas foi desenvolvido principalmente para a entrega local de mensagens entre o MTA e o sistema responsável pelas caixas postais.


Diferentemente do SMTP, o LMTP pode informar individualmente o resultado da entrega para cada destinatário da mensagem.

O LMTP não é utilizado pelo usuário para acessar ou ler sua caixa postal.



Simple Mail Tranfer Protocol - SMTP​​

O Simple Mail Transfer Protocol (SMTP) é o protocolo utilizado para transmitir mensagens de e-mail, normalmente entre servidores MTA.


O SMTP pode ser usado em:

  • entre um MUA e um MSA;
  • entre um MSA e um MTA;
  • entre diferentes MTAs (é o mais comum).


Processo para enviar um email​

De forma simplificada, o envio de uma mensagem ocorre da seguinte maneira:

Remetente
   |
   v
MUA
   |
   | SMTP Submission na portas 587 ou 465
   v
MSA / MTA do remetente
   |
   | Consulta DNS/MX
   |
   | SMTP na porta 25
   v
MTA do destinatário
   |
   | LMTP ou execução local
   v
MDA
   |
   v
Caixa postal
   |
   | IMAP ou POP3
   v
MUA do destinatário

A imagem abaixo representa esse processo de forma simplificada. Ela não descreve todos os componentes e verificações que podem existir em uma infraestrutura real de e-mail.

Email_process



Mão na massa​

Vamos começar instalando o postfix.

# Instale o postfix:
$ sudo apt install -y postfix

O Postfix utiliza uma arquitetura modular, composta por diversos processos especializados. Em vez de um único processo executar todas as funções do servidor de e-mail, cada serviço fica responsável por uma etapa específica do processamento das mensagens.


Os processos são iniciados e supervisionados pelo processo master, de acordo com as configurações presentes no arquivo /etc/postfix/master.cf.


Entre os principais processos do Postfix estão:

  • master

    É o processo principal do Postfix. Ele inicia, supervisiona e encerra os demais serviços conforme necessário.

    O processo master lê o arquivo master.cf, no qual estão definidos os serviços disponibilizados pelo Postfix, como SMTP, entrega local, gerenciamento de filas e comunicação com outros componentes.

    A maioria dos processos do Postfix é iniciada sob demanda. Portanto, nem todos os processos estarão permanentemente visíveis na listagem de processos.

  • pickup

    O processo pickup coleta mensagens que foram submetidas localmente no diretório maildrop da fila do Postfix.

    Isso acontece, por exemplo, quando uma aplicação local utiliza o comando sendmail compatível com o Postfix. O comando postdrop grava a mensagem na fila maildrop, e o processo pickup a encaminha para o processo cleanup.

    O processo pickup não recebe mensagens por SMTP. Mensagens enviadas pela rede são normalmente recebidas pelo processo smtpd.

  • cleanup

    O processo cleanup processa mensagens recém-recebidas antes que elas sejam colocadas na fila incoming.

  • qmgr

    O Queue Manager, representado pelo processo qmgr, é responsável pelo gerenciamento das filas de mensagens.

    Ele seleciona mensagens disponíveis para entrega, analisa seus destinatários e agenda a execução do agente de entrega apropriado.

    Dependendo do destino, o qmgr pode encaminhar a mensagem para processos como:

    • smtp, para entrega em outro servidor SMTP;
    • local, para entrega em uma caixa postal local;
    • lmtp, para entrega por LMTP;
    • pipe, para entrega a um comando externo;
    • virtual, para entrega em caixas postais virtuais.

    Caso uma tentativa de entrega falhe temporariamente, a mensagem pode ser colocada na fila deferred para uma nova tentativa posterior.

  • smtpd

    O processo smtpd recebe conexões SMTP de clientes ou de outros servidores de e-mail.

    Depois de receber a mensagem, o smtpd a encaminha para o processo cleanup.

    Não se deve confundir smtpd com smtp. O processo smtpd recebe mensagens, enquanto o processo smtp envia mensagens para outros servidores.

  • smtp

    É o cliente SMTP do Postfix. Ele é utilizado para enviar mensagens para outros servidores de e-mail.

    O qmgr aciona o processo smtp quando identifica que a mensagem precisa ser entregue remotamente.

  • tlsmgr

    O processo tlsmgr gerencia dados relacionados ao TLS, como caches de sessão e geração de números pseudoaleatórios utilizados nas conexões criptografadas.


Podemos ver isso com o comando abaixo:

# Vendo o processo master:
$ ps aux | grep -i "postfix.*master"
root        1291  0.0  0.2  38068  4616 ?        Ss   13:59   0:00 /usr/lib/postfix/sbin/master -w

# Vendo o processo qmgr:
$ ps aux | grep -i "postfix.*qmgr"
postfix     1293  0.0  0.3  38532  6168 ?        S    13:59   0:00 qmgr -l -t unix -u

# Com o pstree:
$ pstree -p 1291
master(1291)─┬─pickup(1292)
             ├─qmgr(1293)
             └─tlsmgr(1301)

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


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



Arquivos de configuração​

Os principais arquivos de configuração do Postfix são main.cf e master.cf. Normalmente, eles ficam no diretório /etc/postfix/.

  • master.cf

    Define os serviços executados e supervisionados pelo processo master do Postfix.


  • main.cf

    Contém os parâmetros globais de configuração do Postfix.



Principais configurações do Postfix​

Vamos ver as principais opções de configuração do Postfix:

OpçãoDescrição
inet_interface = localhostInterface pela qual o servidor vai receber os emails, o padrão localhost só permite troca de
emails com usuários conectados na mesma máquina.
Podemos deixar como all para que aceite de todas as interfaces.
myhostname = mail.example.teÉ o nome do servidor de email na Internet, deve-se usar o FQDN.
mydomain = $myhostnameDomínio do servidor de email. Ele especifica o domínio pai de $myhostname (somente o domínio mesmo).
O exemplo usado é o padrão a menos que mydomain seja adicionado na configuração.
myorigin = /etc/mailnameDomínio que vai aparecer no remetente, normalmente é usado como valor a variável $mydomain.
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128Especifica qual servidor vai poder fazer Relayhost no servidor de email.
relayhost = IP ou FQDNPermite usar outro servidor para enviar email.
mydestination = $myhostname, mail.example.te, localhost.example.te, localhostO parâmetro mydestination especifica quais domínios esta máquina entregará localmente, em vez de encaminhar para outra máquina.
É interessante adicionar $mydomain aqui.

Vamos enviar uma mensagem usando o telnet através de uma máquina cliente.

Como a conexão ficará meio complicada de ser visualizada por etapas, sempre que uma linha começar com $› significa que fui eu quem digitou!

# Primeiro conecte no servidor smtp:
$ telnet 192.168.121.119 25
Trying 192.168.121.119...
Connected to 192.168.121.119.
Escape character is '^]'.
220 mail.example.te ESMTP Postfix (Ubuntu)

Agora vamos fazer passo a passo as ações que são realizadas pelo protocolo SMTP quando dois hosts estão se comunicando para enviar um email. Primeiro envie um olá para o servidor se identificando:

$› HELO mailtest.example.te
250 mail.example.te

Caso você veja EHLO é o mesmo que HELO mas é usado para ESMTP, mas ambos funcionam igualmente nesse exemplo.


Agora devemos dizer quem está enviando o email:

$› MAIL FROM: fulano@mailtest.example.te
250 2.1.0 Ok

Agora vamos dizer para quem queremos enviar o email:

$› RCPT TO: jhon
250 2.1.5 Ok

E por fim vamos digitar a mensagem:

$› DATA
354 End data with <CR><LF>.<CR><LF>
$› Mensagem de test para jhon.
$› .
250 2.0.0 Ok: queued as AB14C7402E6

A mensagem é enviada quando digitamos o ponto (.).


Por curiosidade vou deixar todo esse processo como foi realizado originalmente abaixo:

$ telnet 192.168.121.119 25
Trying 192.168.121.119...
Connected to 192.168.121.119.
Escape character is '^]'.
220 mail.example.te ESMTP Postfix (Ubuntu)
HELO mailtest.example.te
250 mail.example.te
MAIL FROM: fulano@mailtest.example.te
250 2.1.0 Ok
RCPT TO: jhon
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Mensagem de test para jhon.
.
250 2.0.0 Ok: queued as AB14C7402E6

Com o código na linha final podemos verificar no servidor de email e ver detalhes no log:

$ sudo grep -i AB14C7402E6 /var/log/mail.log
Nov  4 15:42:06 mail postfix/smtpd[2133]: AB14C7402E6: client=_gateway[192.168.121.1]
Nov  4 15:43:28 mail postfix/cleanup[2157]: AB14C7402E6: message-id=<>
Nov  4 15:43:28 mail postfix/qmgr[1431]: AB14C7402E6: from=<fulano@mailtest.example.te>, size=202, nrcpt=1 (queue active)
Nov  4 15:43:28 mail postfix/local[2159]: AB14C7402E6: to=<jhon@mail.example.te>, orig_to=<jhon>, relay=local, delay=195, delays=195/0.02/0/0.01, dsn=2.0.0, status=sent (delivered to mailbox)
Nov  4 15:43:28 mail postfix/qmgr[1431]: AB14C7402E6: removed

# Olhe na mailbox do jhon para ver se o email foi entregue:
$ sudo cat /var/spool/mail/jhon 
From fulano@mailtest.example.te  Fri Nov  4 15:43:28 2022
Return-Path: <fulano@mailtest.example.te>
X-Original-To: jhon
Delivered-To: jhon@mail.example.te
Received: from mailtest.example.te (_gateway [192.168.121.1])
    by mail.example.te (Postfix) with SMTP id AB14C7402E6
    for <jhon>; Fri,  4 Nov 2022 15:40:13 +0000 (UTC)

Mensagem de test para jhon.


Configurações Adicionais no Postfix​

Vamos introduzir o que chamamos de canonical_maps. Esse recurso permite reescrever endereços de e-mail, substituindo um endereço por outro. Para configurar a reescrita dos endereços dos remetentes, adicionamos a seguinte opção ao arquivo main.cf:

sender_canonical_maps = hash:/etc/postfix/scanonical

O sender_canonical_maps vai aplicar a reescrita aos remetentes. Se você quiser aplicar a reescrita aos destinatários, use recipient_canonical_maps. Para ambos, podemos usar canonical_maps, ele aplica a reescrita aos remetentes e destinatários.


Agora temos que criar o arquivo e adicionar a configuração.

# Crie o arquivo:
$ sudo touch /etc/postfix/scanonical

# Adicione a conf abaixo nele:
$ sudo cat /etc/postfix/scanonical
jhon Jhon.Wick

# Refaça o map:
$ sudo postmap /etc/postfix/scanonical

# Restarte o postfix:
$ sudo systemctl restart postfix

Agora, quando o usuário jhon enviar um e-mail por esse servidor, o endereço do remetente deixará de aparecer como jhon@mail.example.te e passará a aparecer como Jhon.Wick@mail.example.te.


Dependendo da configuração do servidor, pode ser necessário utilizar o seguinte formato no arquivo sender_canonical:

jhon    Jhon.Wick@mail.example.te


Configurações de SMTPS (TLS)​

Veremos como habilitar o TLS no SMTP. O TLS adiciona uma camada de criptografia à comunicação entre o Postfix e os clientes ou outros servidores de e-mail. No SMTP, essa criptografia normalmente é iniciada por meio do comando STARTTLS.


A conexão começa sem criptografia e, quando o servidor informa que suporta STARTTLS, os dois lados iniciam uma conexão protegida antes de transmitir a mensagem. Esse recurso é especialmente importante na porta 25, utilizada na comunicação entre servidores MTA.


Durante a entrega de um e-mail, o MTA remetente se conecta ao MTA destinatário e pode utilizar o STARTTLS para proteger a transmissão da mensagem entre eles. O TLS, por si só, não controla quais usuários podem enviar mensagens. Para exigir usuário e senha, é necessário configurar a autenticação SASL.


Para habilitar o TLS nas conexões recebidas pelo Postfix, devemos modificar o arquivo main.cf:

# Habilitar o TLS de forma opcional:
smtpd_tls_security_level = may

# Informar os arquivos do certificado e da chave privada:
smtpd_tls_cert_file = /etc/postfix/cert.pem
smtpd_tls_key_file = /etc/postfix/key.pem

O valor may anuncia o suporte ao STARTTLS, mas ainda permite conexões sem criptografia. Para tornar o TLS obrigatório, podemos utilizar:

smtpd_tls_security_level = encrypt

Usando may o Postfix oferece suporte ao STARTTLS, mas não exige que a conexão seja criptografada. Se o outro servidor não suportar TLS ou se a negociação não for realizada, a mensagem ainda poderá ser transmitida sem criptografia.


Nesse caso, alguém que consiga capturar o tráfego entre os servidores poderá visualizar informações como: remetente e destinatário, cabeçalhos, assunto, corpo da mensagem, anexos entre outros dados.


Quando o TLS for obrigatório, podemos definir os protocolos e algoritmos aceitos:

smtpd_tls_mandatory_protocols = >=TLSv1.2
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5

A opção smtpd_tls_security_level substitui a configuração antiga smtpd_use_tls, que é considerada obsoleta nas versões atuais do Postfix. Após realizar as alterações, devemos verificar e recarregar o Postfix:

sudo postfix check
sudo systemctl reload postfix

Podemos criar um certificado autoassinado para testes com:

openssl req -nodes -x509 -newkey rsa:2048 \
  -keyout /etc/postfix/key.pem \
  -out /etc/postfix/cert.pem

Em seguida, devemos restringir o acesso à chave privada:

chmod 600 /etc/postfix/key.pem

Os parâmetros iniciados por smtpd_ controlam o Postfix atuando como servidor, ou seja, recebendo conexões SMTP. Os parâmetros iniciados por smtp_ controlam o Postfix atuando como cliente, durante o envio de mensagens para outros servidores.



Principais Comandos​

Vamos ver os principais comandos usados para se gerenciar um servidor de email.

ComandoDescrição
mailqExibe as mensagens presentes na fila. É uma interface mantida pelo Postfix para compatibilidade com o Sendmail.
postqueue -pExibe as mensagens presentes na fila utilizando o comando nativo do Postfix.
sendmail -bpTambém exibe as mensagens presentes na fila por meio da interface compatível com o Sendmail.
postconf -dExibe os valores padrão dos parâmetros do Postfix.
postconf -nExibe os parâmetros que foram explicitamente configurados, omitindo a maioria dos valores padrão.
postfix startInicia o Postfix.
postfix stopEncerra o Postfix.
postfix reloadRecarrega os arquivos de configuração sem interromper completamente o serviço.
postfix statusVerifica se o Postfix está em execução.
postfix checkVerifica arquivos, diretórios, permissões e outros problemas na instalação.
postfix flushSolicita uma nova tentativa de entrega das mensagens presentes na fila.
postqueue -fTambém solicita uma nova tentativa de entrega das mensagens presentes na fila.
postcat -q IDExibe o conteúdo de uma mensagem da fila utilizando seu ID.
postsuper -d IDRemove da fila a mensagem correspondente ao ID informado.
postsuper -d ALLRemove todas as mensagens da fila.

Os comandos mailq, postqueue -p e sendmail -bp apresentam a mesma fila, mas os comandos mailq e sendmail existem como interfaces de compatibilidade com o Sendmail. O comando nativo para controlar a fila do Postfix é o postqueue.




Analisando a fila com qshape​

Outra ferramenta útil para analisar a fila de e-mails é o qshape. Enquanto o postqueue -p apresenta cada mensagem individualmente, o qshape mostra uma visão resumida da fila, agrupando as mensagens pelo domínio e pelo tempo em que estão aguardando entrega.

qshape

Para analisar especificamente as mensagens que tiveram falhas temporárias de entrega:

qshape deferred

A saída possui um formato semelhante ao seguinte:

                     T  5  10  20  40  80  160  320  640  1280  1280+
TOTAL                8  1   2   0   3   0    2    0    0     0      0
example.com          5  1   1   0   2   0    1    0    0     0      0
example.net          3  0   1   0   1   0    1    0    0     0      0

O qshape foi desenvolvido para ajudar a identificar congestionamentos e distribui as mensagens da fila por domínio e idade. Em distribuições da família Red Hat ou Fedora, ele pode ser instalado por meio do pacote:

dnf install postfix-perl-scripts


Testando o SMTP com Swaks​

O Swaks, ou Swiss Army Knife for SMTP, é uma ferramenta externa utilizada para testar servidores SMTP. Ela permite simular o envio de uma mensagem e acompanhar todo o fluxo SMTP.


O Swaks suporta SMTP, ESMTP, LMTP, TLS, autenticação e conexões IPv4 ou IPv6. Para instalar:

# Debian e Ubuntu:
apt install swaks

# Red Hat, Fedora e derivados:
dnf install swaks

Um teste básico pode ser realizado com:

swaks \
  --server mail.example.test \
  --from remetente@example.test \
  --to destinatario@example.test

Para testar a negociação STARTTLS:

swaks \
  --server mail.example.test \
  --port 25 \
  --tls \
  --from remetente@example.test \
  --to destinatario@example.test

Para testar a submissão autenticada pela porta 587:

swaks \
  --server mail.example.test \
  --port 587 \
  --tls \
  --auth \
  --auth-user usuario@example.test \
  --auth-password 'senha' \
  --from usuario@example.test \
  --to destinatario@example.test

Informar a senha diretamente na linha de comando pode deixá-la registrada no histórico do shell ou visível temporariamente na lista de processos. Em ambientes reais, devem ser utilizados métodos mais seguros para fornecer a credencial.


O Swaks é especialmente útil para descobrir em qual etapa ocorre um erro, como:

Connection refused
Relay access denied
Authentication failed
Sender address rejected
Recipient address rejected
STARTTLS not available

Ele realiza uma sessão SMTP por execução e apresenta as respostas enviadas pelo servidor durante a transação.