termo · protocolo de e-mail SMTP

O que é o protocolo de e-mail SMTP e como ele afeta o e-mail da aplicação?

O SMTP, ou Simple Mail Transfer Protocol, é o protocolo padronizado que os sistemas de e-mail usam para submeter, retransmitir e repassar e-mails de saída. Normalmente, uma aplicação entrega uma mensagem pronta a um serviço de submissão autenticado; os servidores de e-mail então usam comandos SMTP e roteamento DNS para levá-la até cada destinatário. As respostas SMTP revelam se um salto específico aceitou ou rejeitou um destinatário, mas aceitação não é o mesmo que chegada à caixa de entrada. As aplicações ainda precisam de filas duráveis, novas tentativas seguras, identificadores de mensagem, autenticação e processamento de bounces.

O SMTP transfere e-mails entre sistemas responsáveis

O SMTP é um protocolo de transferência do tipo store-and-forward. Um cliente abre uma sessão com um servidor, se identifica, apresenta um remetente de envelope, propõe um ou mais destinatários de envelope e transmite o conteúdo da mensagem depois que o servidor concorda em recebê-la. O servidor pode aceitar alguns destinatários e rejeitar outros, então o status pertence a um destinatário e a uma transação, e não apenas à mensagem como um todo. Depois que um servidor assume a responsabilidade, ele pode entregar localmente ou retransmitir a mensagem para outro sistema selecionado pelos registros DNS de Mail Exchanger. Esse desenho salto a salto é o motivo pelo qual uma aplicação não deve reduzir o estado do e-mail a um único booleano de enviado. A aplicação, o serviço de submissão, o relay, o servidor de destino e o sistema de filtragem da caixa postal conhecem, cada um, partes diferentes do resultado. O SMTP move a mensagem entre sistemas, enquanto os registros no nível do produto e os eventos do provedor tornam esse movimento compreensível para usuários e operadores.

Submissão e relay são papéis diferentes no protocolo

A RFC 6409 separa a submissão de mensagens do relay de mensagens. A submissão é o primeiro repasse de um usuário ou aplicação autorizados para um Message Submission Agent, normalmente pela porta 587. O relay é a transferência entre Message Transfer Agents e, por convenção, usa a porta 25. Os serviços de submissão podem exigir autenticação, validar ou completar campos da mensagem e aplicar a política de remetentes, porque sabem quem está introduzindo o novo e-mail. Os servidores públicos de relay precisam interoperar com outros domínios e seguem regras de confiança diferentes. Por isso, o código da aplicação deve se conectar ao endpoint de submissão documentado pelo provedor ou usar a API HTTP dele, e não abrir conexões arbitrárias na porta 25 com os servidores de destino. Essa divisão também esclarece as credenciais: um nome de usuário ou token SMTP autoriza a submissão a um serviço específico; ele não concede autoridade sobre o domínio de destino. Mantenha as credenciais de submissão no servidor, restrinja o escopo delas à carga de envio quando o provedor permitir e faça a rotação sem incorporá-las ao conteúdo das mensagens ou a software cliente.

O envelope SMTP é diferente dos cabeçalhos visíveis da mensagem

Uma transação SMTP carrega um envelope com `MAIL FROM` e um ou mais comandos `RCPT TO`. O conteúdo transferido segue, à parte, o Internet Message Format definido pela RFC 5322, com campos como From, To, Date, Subject e Message-ID, além de um corpo. Os padrões MIME estendem esse conteúdo para HTML, partes alternativas, anexos e dados não ASCII. O remetente do envelope é o endereço usado para falhas de transporte e pode ser diferente do autor visível no From. Os destinatários do envelope também podem ser diferentes dos campos To e Cc visíveis, como acontece com o Bcc. Não construa essas estruturas concatenando strings não confiáveis. Use uma biblioteca de mensagens mantida, valide os endereços, bloqueie a injeção de quebras de linha nos campos de cabeçalho e preserve um Message-ID estável. Ao investigar problemas, inspecione as duas camadas: um campo From visível correto não conserta uma identidade de envelope não autorizada, e um envelope válido não faz um MIME malformado ser exibido corretamente.

Leia a transação como uma máquina de estados

Uma sessão básica de Extended SMTP começa com a saudação do servidor e, em seguida, `EHLO`, para que o servidor anuncie suas extensões. Na submissão, o cliente pode negociar TLS e autenticação. Uma transação de e-mail usa então `MAIL FROM`, um `RCPT TO` por destino, `DATA`, a mensagem completa terminada de acordo com o enquadramento do SMTP e `QUIT`. Não trate o exemplo como motivo para implementar o protocolo manualmente; bibliotecas SMTP maduras lidam com quebras de linha, transparência de pontos, negociação de capacidades, autenticação e estado do TLS de forma mais segura. Instrumente a biblioteca no nível de categoria de comando e de código de resposta, sem registrar credenciais nem corpos completos de mensagens. Registre qual destinatário falhou em qual etapa e se o servidor já tinha assumido a responsabilidade depois dos dados da mensagem. Essa fronteira determina se uma nova tentativa é adequada, se uma duplicata é possível e se a falha virá em uma notificação de status de entrega posterior, e não em uma resposta imediata.

Classifique os códigos de resposta antes de decidir tentar novamente

As classes de resposta do SMTP indicam uma ação. Uma resposta 2xx indica que aquele comando foi concluído com sucesso. Uma resposta 4xx é uma conclusão negativa transitória, então um remetente com fila pode tentar novamente após um intervalo. Uma resposta 5xx é uma conclusão negativa permanente para o comando tentado e normalmente exige correção, supressão ou investigação humana, em vez de novas tentativas repetidas. Os códigos de status estendidos acrescentam um diagnóstico estruturado `X.Y.Z` para condições de endereço, caixa postal, sistema, roteamento, protocolo, conteúdo ou segurança e política. Preserve tanto o código numérico quanto o texto do servidor, porque ambos podem agregar valor ao diagnóstico, mas não exponha amplamente respostas brutas que contenham dados de destinatários. Aplique backoff exponencial com jitter e um tempo de vida máximo na fila às falhas transitórias. Nunca faça novas tentativas de forma tão agressiva que um problema temporário no destino se transforme em tráfego abusivo. Em falhas permanentes de endereço, interrompa os envios automáticos para aquele destino e atualize o estado de supressão. Em falhas de política ou de autenticação, corrija a identidade, o DNS, as credenciais ou o conteúdo antes de outra tentativa.

Use submissão criptografada e autenticada

O SMTP nasceu como um protocolo de transporte entre redes com premissas de confiança diferentes, então a submissão segura depende de extensões e da política de implantação. O STARTTLS eleva uma conexão SMTP para TLS; depois disso, o cliente deve descartar as capacidades aprendidas antes do handshake e enviar `EHLO` novamente. A RFC 8314 atualiza as orientações de submissão, tratando o acesso e a submissão em texto claro como obsoletos e descrevendo o TLS implícito para submissão. O SMTP AUTH, padronizado na RFC 4954, permite que um servidor de submissão autentique um cliente por meio dos mecanismos anunciados. Use o hostname, a porta, o modo de TLS e as instruções de autenticação atuais do provedor, em vez de adivinhar uma combinação. Valide o certificado do servidor e não volte silenciosamente para texto claro quando a carga de trabalho exigir submissão protegida. Mantenha senhas ou tokens em um gerenciador de segredos, use credenciais separadas por ambiente e desabilite mecanismos de autenticação obsoletos. O TLS protege um salto da conexão; ele não autentica o autor da mensagem para todos os destinatários posteriores nem substitui o alinhamento de identidade de SPF, DKIM e DMARC.

Diagnostique uma falha de e-mail da aplicação salto a salto

Comece pelo registro de saída durável da aplicação: o evento do produto foi autorizado, e apenas um job da fila o assumiu? Em seguida, inspecione a submissão: resolução DNS, conexão TCP, negociação TLS, validação do certificado, autenticação, autorização do remetente do envelope, respostas por destinatário e resposta final ao DATA. Se o serviço de submissão aceitou a mensagem, pare de repetir a requisição às cegas e acompanhe o identificador da mensagem e o fluxo de eventos dela. Diferencie um estado processado pelo provedor da aceitação pelo servidor de destino. Um bounce posterior ainda pode informar uma falha permanente após a aceitação inicial. Se o servidor de destino aceitou a mensagem, investigue os resultados de autenticação, a reputação, a política do destinatário, o conteúdo e a classificação na caixa postal, em vez de chamar isso de falha de transporte SMTP. Verifique as identidades do envelope e do cabeçalho e guarde timestamps, códigos de resposta, número de tentativas na fila e identificadores do provedor. Use destinatários controlados nos testes. Nunca cole credenciais SMTP de produção nem mensagens completas de clientes em tickets, prompts, histórico do terminal ou ferramentas públicas de diagnóstico.

Separe aceitação, entrega e chegada à caixa de entrada

A precisão do protocolo importa nas interfaces do produto. Aceitação pela aplicação significa que o sistema local registrou uma requisição. Aceitação na submissão significa que o primeiro serviço de e-mail assumiu a responsabilidade por processá-la. Entrega ao servidor de destino significa que o servidor SMTP de destino retornou sucesso no repasse. A chegada à caixa de entrada é uma decisão posterior de política e classificação dentro do ambiente de destino. Uma mensagem pode passar por um estado e falhar ou ser classificada de outra forma no seguinte. O SMTP fornece evidência direta sobre a transação atual e pode produzir notificações de status de entrega posteriores, mas não expõe a pasta final do destinatário. Armazene esses estados de forma independente, em vez de rotular toda resposta 250 como entrega na caixa de entrada. Um evento do provedor que inclui a resposta SMTP de sucesso do destino pode sustentar um estado de entregue ao servidor. Um bounce sustenta o tratamento de falha ou de supressão. Nenhum dos dois sustenta uma promessa de visibilidade, leitura ou engajamento. Esse modelo mantém o status verdadeiro e evita novas tentativas inseguras depois que a responsabilidade já foi transferida.

Use a API documentada do SendHQ

Uma aplicação pode falar SMTP por uma biblioteca de provedor ou chamar uma API de e-mail HTTP cujo provedor trata o transporte de e-mail da Internet por trás dessa interface. O SendHQ fornece uma API de e-mail com escopo por workspace, com verificações de domínio, recursos de mensagens de saída e de entrada, eventos, supressões, caixas de entrada e limites de recursos por workspace. Sua API HTTP pode fornecer requisições estruturadas, identificadores e eventos junto à submissão SMTP direta. Ela não altera o comportamento do servidor de destino nem estabelece aceitação SMTP, chegada à caixa de entrada ou engajamento do destinatário.

Perguntas frequentes

O que significa SMTP?

SMTP significa Simple Mail Transfer Protocol. Ele define como clientes e servidores de e-mail submetem e transferem mensagens de saída por meio de comandos, respostas, envelopes, dados da mensagem e extensões para recursos como autenticação e TLS.

O SMTP é usado para ler e-mails de uma caixa de entrada?

Não. O SMTP serve principalmente para submeter e transferir e-mails de saída. O acesso à caixa de entrada usa outras interfaces, como IMAP, POP, uma API de caixa postal específica do provedor ou uma API de e-mail para aplicações que expõe as mensagens de entrada armazenadas.

Qual é a diferença entre as portas 25, 587 e 465?

A porta 25 é usada, por convenção, para relay entre servidores. A porta 587 é o serviço padrão de submissão de mensagens e geralmente negocia TLS. A porta 465 é registrada para submissão com TLS implícito. Siga o endpoint e o modo de segurança documentados pelo provedor, em vez de trocar de porta por tentativa e erro.

Um sucesso no SMTP prova que o e-mail chegou à caixa de entrada?

Não. Uma resposta de sucesso prova apenas que o servidor SMTP que respondeu aceitou o comando correspondente ou a responsabilidade pela mensagem. O sistema de destino ainda pode aplicar uma política posterior, gerar uma falha atrasada ou classificar o e-mail aceito fora da caixa de entrada principal.

Uma aplicação deve tentar novamente toda resposta SMTP 4xx?

Um código 4xx indica um resultado negativo transitório, mas as novas tentativas devem usar uma fila durável, backoff exponencial com jitter, um tempo de vida finito e limites de tentativas por destinatário. Investigue falhas temporárias repetidas, em vez de tentar novamente indefinidamente.

Uma API HTTP de e-mail substitui o SMTP?

Ela pode substituir o SMTP no código da aplicação, mas o provedor normalmente continua usando SMTP para se comunicar com os sistemas de e-mail dos destinatários. Uma API acrescenta autenticação estruturada, payloads, escopo de recursos, identificadores e tratamento de eventos acima da camada de transporte.

Fontes

Continue aprendendo

Guia de implementação de API de e-mail para equipes de produtoProjete uma integração segura com uma API de e-mail, com domínios verificados, envios em fila, identificadores estáveis, novas tentativas controladas, eventos de entrega, supressão e isolamento de tenants.