A viagem de um email

Módulo 1: Como funciona o email · Tempo de leitura: 9 minutos

Objetivo de aprendizagem: Após esta lição, saberá descrever passo a passo como um email chega do remetente ao destinatário, e indicar em cada etapa qual o programa ou servidor que realiza o trabalho.

Conceitos-chave: programa de correio eletrónico (MUA), servidor de envio (MSA, submission), servidor de correio (MTA), registo MX, fila de espera, entrega (MDA), caixa de correio, obtenção (IMAP/POP3), envelope, cabeçalhos

O correio eletrónico é correspondência, não uma mensagem de chat

Quando envia uma mensagem de chat, esta passa por uma única empresa: a aplicação do remetente e a aplicação do destinatário falam com os mesmos servidores. O email funciona de forma diferente. O remetente e o destinatário podem estar em fornecedores diferentes: um numa empresa de alojamento, outro no Gmail, um terceiro no Microsoft 365 ou no seu próprio servidor empresarial. Ainda assim, o email chega ao destino. Isto é possível porque todos os servidores de correio do mundo seguem as mesmas regras.

Pode comparar o email com o correio tradicional. Escreve uma carta (a mensagem), coloca-a num envelope com um endereço (o envelope), leva-a até à caixa do correio (o servidor de envio), a empresa postal descobre onde fica o endereço (a pesquisa de MX), transporta a carta até ao centro de distribuição correto (o servidor de correio recetor) e este coloca-a na caixa de correio do destinatário (a caixa de correio). O destinatário vai lá buscá-la quando lhe for conveniente.

As etapas, uma a uma

Imagine que a Ana envia um email a partir de anna@example.com para jan@example.net. Isto é o que acontece:

Em fornecedores pequenos, o MSA, o MTA e o MDA costumam ser o mesmo programa num único servidor. Em fornecedores grandes, são conjuntos de servidores separados (clusters). Para si, isso faz pouca diferença: são funções, não aparelhos.

Repare na diferença entre a etapa 1 e a etapa 4. Ambas usam SMTP, o Simple Mail Transfer Protocol (RFC 5321). Mas na etapa 1 autentica-se e utiliza a porta 587 ou 465; a isto chama-se submission (RFC 6409). Na etapa 4, dois servidores comunicam entre si na porta 25, sem autenticação: o servidor recetor aceita correio para os seus próprios domínios vindo de qualquer remetente. Na lição 1.4 verá por que razão existe esta separação.

A etapa 3 em detalhe: a pesquisa de MX

O servidor de envio não sabe por si só onde example.net recebe o seu correio. Pergunta ao DNS:

example.net.   3600  IN  MX  10 mx1.mailprovider.example.
example.net.   3600  IN  MX  20 mx2.mailprovider.example.

O número mais baixo tem prioridade. O servidor tenta primeiro mx1 e, se este não responder, tenta mx2. Depois, consulta o endereço IP desse nome (registo A ou AAAA) e estabelece a ligação.

Há dois casos especiais que encontrará na prática:

• Ausência de registo MX. Nesse caso, o remetente tenta o registo A ou AAAA do próprio domínio (o "MX implícito" da RFC 5321, secção 5.1). Trata-se de um resquício do passado que não funciona de forma fiável; todo o domínio que recebe correio deve ter um registo MX.
• Um null MX: 0 . Isto significa: "este domínio nunca recebe correio" (RFC 7505). O domínio example.com tem um registo deste tipo. O remetente desiste de imediato e devolve uma mensagem de erro, em vez de continuar a tentar durante dias.

Pode ler em detalhe como funcionam os registos MX e as prioridades na lição 4.1 do curso de DNS.

A fila de espera: o email pode demorar um pouco

Um email nem sempre chega ao destino em menos de um segundo. Se o servidor recetor não responder, ou disser "tente mais tarde" (um código que começa por 4), o email permanece na fila de espera do servidor de envio. Este volta a tentar mais tarde, aumentando progressivamente o intervalo entre tentativas. A RFC 5321 (secção 4.5.4.1) recomenda um intervalo mínimo de 30 minutos entre tentativas e só desistir ao fim de 4 a 5 dias. Muitos servidores enviam, ao fim de algumas horas, um aviso prévio ("delayed", ainda não entregue) e, ao fim de alguns dias, a mensagem de erro definitiva.

Este é um ponto forte do email: se um servidor de correio estiver avariado durante uma hora, não se perde nenhum email. É também a razão pela qual, por vezes, um email só chega horas mais tarde. No módulo 6 verá como reconhecer esse tipo de atraso.

Envelope e cabeçalhos: dois endereços

Tal como no correio tradicional, um email tem dois tipos de endereços:

• O envelope. São os endereços que os servidores utilizam entre si na conversa SMTP: MAIL FROM (o remetente para mensagens de erro, visível mais tarde como Return-Path) e RCPT TO (o destinatário). Os servidores entregam o correio com base no envelope.
• Os cabeçalhos (headers). É o que consta na própria carta: From:, To:, Cc:, Subject:, Date:. O seu programa de correio eletrónico mostra estes campos.

Na maioria dos casos coincidem, mas nem sempre. Um destinatário em BCC consta do envelope, mas não dos cabeçalhos; por isso, os outros destinatários não o veem. Um serviço de newsletter coloca o seu próprio endereço como remetente do envelope, de modo que as mensagens de erro cheguem ao serviço, enquanto no campo From: consta o seu endereço. E um burlão pode colocar o que quiser no campo From:.

Porque é que isto importa: o SPF verifica o remetente do envelope, o utilizador vê o campo From:. É por isso que existe o DMARC, que liga estes dois elementos entre si (módulo 4).

Onde algo pode correr mal

Com este esquema, pode perguntar-se, perante qualquer problema: em que etapa é que algo correu mal?

• O envio falha (mensagem de erro imediata no seu programa): etapa 1 ou 2. Quase sempre uma questão de configurações: porta, autenticação, palavra-passe (módulo 2).
• Recebe um bounce: etapa 4 ou 5. O servidor recetor recusou o email, ou o endereço não existe (módulo 6).
• O email chega, mas vai para a pasta de spam: etapa 5. O destinatário não confia no email (módulos 4 e 5).
• O destinatário não vê nada e o senhor não recebe nenhuma mensagem de erro: o email talvez ainda esteja numa fila de espera, ou tenha sido filtrado silenciosamente pelo destinatário. Aqui, os registos (logs) do servidor de envio são úteis (módulo 6).
• O correio não chega de todo para o seu domínio: etapa 3. Os registos MX não estão corretos, por exemplo após uma mudança (módulo 8).

Na prática: assim funciona num pacote de alojamento

Num pacote de alojamento da WebOké, um único servidor por pacote desempenha todas as funções: o seu programa de correio eletrónico entrega o email nesse servidor (etapas 1 e 2), o servidor envia-o para o exterior (etapas 3 e 4) e recebe correio para o seu domínio (etapa 5). No DirectAdmin, pode utilizar o Rastreamento de e-mails para verificar, mensagem a mensagem, se foi entregue. Noutros fornecedores, o funcionamento é semelhante; lá, essa funcionalidade pode chamar-se, por exemplo, "rastreamento de mensagens" ou "mail log".

Resumo

• Um email vai do seu programa de correio eletrónico (MUA), através do servidor de envio (MSA/MTA), até ao servidor recetor (MTA/MDA) e deste até ao programa de correio eletrónico do destinatário.
• Enviar a partir do seu programa é SMTP-submission com autenticação (587/465); os servidores comunicam entre si por SMTP na porta 25; a obtenção faz-se por IMAP ou POP3.
• O servidor de envio consulta os registos MX do domínio a seguir ao @. Um null MX (0 .) significa: este domínio não recebe correio.
• Um email que não pode ser entregue de imediato permanece na fila de espera e é tentado novamente durante vários dias.
• O envelope (Return-Path) e os cabeçalhos (From) são dois remetentes diferentes. O SPF verifica o primeiro, o utilizador vê o segundo.

Quiz

Exercício

Exercício Z1.1: Encontrar o primeiro servidor de correio. Consulte os registos MX de gmail.com (ou do seu próprio domínio). Indique que servidor é tentado em primeiro lugar, com o respetivo número de prioridade, e um endereço IP (IPv4 ou IPv6) desse servidor. O programa consulta os mesmos dados em tempo real e verifica a sua resposta.

Para saber mais

Os passos descritos nestes artigos aplicam-se aos painéis da WebOké; noutros fornecedores, o funcionamento é semelhante.

• Como funciona o envio de e-mails / SMTP
• Manual DirectAdmin 8.7: IMAP ou POP3: qual é a diferença?
• Curso gratuito de DNS 4.1: Registos MX e prioridade
• RFC 5321 (SMTP), secção 5.1 (MX e MX implícito) e 4.5.4.1 (nova tentativa); RFC 7505 (null MX)