SMTP: a conversa entre servidores de correio

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

Objetivo de aprendizagem: Após esta lição, saberá ler uma conversa SMTP, explicar o que fazem EHLO, MAIL FROM, RCPT TO e DATA, e reconhecer, através de um código de resposta, se um erro é temporário ou definitivo.

Conceitos-chave: SMTP (RFC 5321), sessão, EHLO/HELO, MAIL FROM, RCPT TO, DATA, QUIT, código de resposta (2xx, 3xx, 4xx, 5xx), código de estado alargado, extensões (STARTTLS, AUTH, SIZE), null MX

Uma conversa em texto simples

O SMTP é um protocolo muito antigo (a primeira versão é de 1982) e, por isso, muito legível. Dois servidores trocam linhas de texto entre si. O remetente (o cliente) envia um comando, o destinatário (o servidor) responde com um número de três algarismos e uma breve explicação. Pode ler literalmente uma destas conversas numa mensagem de erro ou num registo (log), e é exatamente por isso que vale a pena compreendê-la.

Segue-se uma conversa completa. S: é o servidor recetor, C: o servidor remetente. A mensagem vai de anna@example.com para jan@example.net.

S: 220 mx1.mailprovider.example ESMTP ready
C: EHLO out.hosting.example
S: 250-mx1.mailprovider.example Hello out.hosting.example [192.0.2.25]
S: 250-SIZE 52428800
S: 250-8BITMIME
S: 250-STARTTLS
S: 250 SMTPUTF8
C: STARTTLS
S: 220 2.0.0 Ready to start TLS
   (a partir daqui, a ligação está cifrada; o cliente envia novamente EHLO)
C: EHLO out.hosting.example
S: 250 ...
C: MAIL FROM:<anna@example.com> SIZE=24310
S: 250 2.1.0 Ok
C: RCPT TO:<jan@example.net>
S: 250 2.1.5 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: Anna <anna@example.com>
C: To: Jan <jan@example.net>
C: Subject: Orçamento
C: Date: Sun, 8 Nov 2026 10:15:00 +0100
C: Message-ID: <a1b2c3@example.com>
C:
C: Olá Jan, envio em anexo o orçamento.
C: .
S: 250 2.0.0 Ok: queued as 4F2A1B
C: QUIT
S: 221 2.0.0 Bye

Os comandos, um a um

A conclusão mais importante: tudo o que vem antes de DATA é o envelope, tudo o que vem depois é o conteúdo. O que consta em MAIL FROM e o que consta no cabeçalho From: são fornecidos separadamente e não têm de ser iguais. O servidor entrega com base em RCPT TO; a linha To: no conteúdo não desempenha qualquer papel na entrega.

Os códigos de resposta

O primeiro algarismo do código é o mais importante:

A seguir aos três algarismos, os servidores modernos apresentam um código de estado alargado na forma class.subject.detail (RFC 3463), por exemplo 5.1.1. O primeiro algarismo é novamente 2, 4 ou 5. O segundo algarismo indica o tema: 1 = endereço, 2 = caixa de correio, 3 = sistema de correio, 4 = rede e encaminhamento, 5 = protocolo, 6 = conteúdo, 7 = segurança e política. Alguns exemplos frequentes:

550 5.1.1  The email account that you tried to reach does not exist
452 4.2.2  Mailbox full (temporário)
552 5.3.4  Message size exceeds fixed limit
451 4.7.1  Greylisted, please try again later
550 5.7.1  Message rejected (política: spam, lista de bloqueio, DMARC)

No módulo 6, aprenderá a ler um bounce completo e encontrará uma tabela com os códigos mais frequentes.

Porque é tão importante distinguir temporário de definitivo

Um servidor em dúvida responde frequentemente com um 4xx. Um exemplo conhecido é o greylisting: um servidor que ainda não conhece um remetente diz, da primeira vez, "tente mais tarde". Um servidor de correio genuíno volta a tentar ao fim de alguns minutos; muitos programas de spam não o fazem. Também os grandes destinatários utilizam o 4xx para reduzir o ritmo quando ainda não confiam num endereço IP. Para si, como remetente, isto significa: atraso, mas não perda. O sistema resolve-o normalmente por si próprio.

Um 5xx é diferente. Nesse caso, o remetente não volta a tentar. Se receber um 5xx, alguém tem de alterar algo: o endereço, o conteúdo ou as definições do domínio de envio.

Uma armadilha: alguns servidores devolvem um 5xx quando o problema é, na verdade, temporário (por exemplo, numa caixa de correio cheia, 552 5.2.2), e outros devolvem um 4xx para algo que nunca vai funcionar. Leia, por isso, sempre o texto a seguir ao código, não apenas o número.

Quem é responsável?

Após o 250 no ponto final de DATA, a responsabilidade passa para o servidor recetor. Se este, posteriormente, não conseguir colocar a mensagem na caixa de correio, tem de enviar ele próprio uma mensagem de erro. É essa a origem de um fenómeno incómodo: o backscatter. Um servidor que primeiro aceita tudo e só depois verifica que o endereço não existe envia um bounce para o remetente do envelope. Se esse remetente tiver sido forjado por um spammer, um terceiro inocente recebe o bounce. Por isso, os servidores deveriam recusar já em RCPT TO o que não é possível entregar (ver também catch-all na lição 3.3).

Na prática: ver o SMTP no seu próprio ambiente

Um utilizador comum raramente vê a conversa SMTP na íntegra, mas vê-a em fragmentos:

• num bounce encontra a última linha da conversa, por exemplo Remote-MTA: mx1.mailprovider.example e Diagnostic-Code: smtp; 550 5.1.1 ...;
• nos cabeçalhos de uma mensagem recebida, encontra, por cada servidor, uma linha Received: com o nome EHLO e o endereço IP (lição 1.5);
• num painel com registo de correio, como o Rastreamento de e-mails no DirectAdmin da WebOké, pode ver, por cada mensagem, a resposta do servidor recetor. Noutros fornecedores, isto pode chamar-se, por exemplo, rastreamento de mensagens ou mail log, e o conteúdo é semelhante.

Não precisa, portanto, de estabelecer ligação a um servidor de correio para conseguir ler isto. Quem quiser experimentar pode, com openssl s_client -starttls smtp -connect server:25, conduzir a conversa manualmente, mas muitos fornecedores de internet residencial bloqueiam o tráfego de saída na porta 25 (lição 1.4).

Resumo

• O SMTP é uma conversa legível: EHLO, (STARTTLS), MAIL FROM, RCPT TO, DATA, QUIT.
• Tudo antes de DATA é envelope (entrega e mensagens de erro), tudo depois é o conteúdo com os cabeçalhos que vê.
• 2xx = sucesso, 4xx = temporário (nova tentativa mais tarde), 5xx = definitivo (bounce).
• O código alargado X.Y.Z indica o tema em causa; X.1 endereço, X.2 caixa de correio, X.7 política e segurança.
• Leia sempre o texto a seguir ao código; os servidores nem sempre são consistentes.

Quiz

Exercício

Exercício Z1.2: Um domínio que não recebe correio. Procure os registos MX de example.com. Indique o que encontra e escolha o que faz um servidor de envio com correio destinado a info@example.com: (a) entregar ao servidor com prioridade 0, (b) tentar o registo A, (c) desistir imediatamente, ou (d) tentar novamente mais tarde. O programa consulta o registo MX ao vivo e verifica a resposta.

Para saber mais

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

• Explicação do processo de envio de e-mails / SMTP
• Mail delivery failed: como ler a mensagem de erro e o que significam os códigos
• Manual DirectAdmin 9.3: Rastreamento de e-mails: onde ficou o meu e-mail?
• RFC 5321 (SMTP), secção 3 e 4.2 (códigos de resposta); RFC 3463 (códigos de estado alargados); RFC 7505 (null MX)