Protocolo de transferência de correio simples - Simple Mail Transfer Protocol

"SMTP" redireciona aqui. Para a empresa de entrega de e-mail, consulte SMTP (empresa) . Para o protocolo de transferência de mensagens curtas, consulte GSM 03.40 .

Suíte de protocolo de Internet
Camada de aplicação
Camada de transporte
Camada de Internet
Camada de link

O Simple Mail Transfer Protocol ( SMTP ) é um protocolo de comunicação padrão da Internet para transmissão de correio eletrônico . Os servidores de correio e outros agentes de transferência de mensagens usam SMTP para enviar e receber mensagens de correio. Os clientes de e - mail em nível de usuário normalmente usam SMTP apenas para enviar mensagens a um servidor de e-mail para retransmissão e, normalmente, enviam e-mail de saída para o servidor de e-mail na porta 587 ou 465 por RFC 8314 . Para recuperar mensagens, o IMAP (que substituiu o POP3 mais antigo ) é o padrão, mas os servidores proprietários também costumam implementar protocolos proprietários, por exemplo, Exchange ActiveSync .  

Desde a introdução do SMTP em 1981, ele foi atualizado, modificado e estendido várias vezes. A versão do protocolo em uso comum hoje tem estrutura extensível com várias extensões para autenticação , criptografia , transferência de dados binários e endereços de e-mail internacionalizados . Os servidores SMTP normalmente usam o Transmission Control Protocol na porta número 25 (para texto simples) e 587 (para comunicações criptografadas).

História

Predecessores para SMTP

Várias formas de mensagens eletrônicas um para um foram usadas na década de 1960. Os usuários se comunicavam por meio de sistemas desenvolvidos para computadores mainframe específicos . À medida que mais computadores foram interconectados, especialmente na ARPANET do governo dos EUA , foram desenvolvidos padrões para permitir a troca de mensagens entre diferentes sistemas operacionais. O SMTP cresceu a partir desses padrões desenvolvidos durante os anos 1970.

O SMTP tem suas raízes em duas implementações descritas em 1971: o Mail Box Protocol, cuja implementação foi contestada, mas é discutida na RFC  196 e outras RFCs, e o programa SNDMSG, que, de acordo com a RFC  2235 , Ray Tomlinson da BBN inventou para Computadores TENEX para enviar mensagens de correio através da ARPANET. Menos de 50 hosts foram conectados à ARPANET neste momento.

Outras implementações incluem FTP Mail e Mail Protocol, ambos de 1973. O trabalho de desenvolvimento continuou ao longo da década de 1970, até que a ARPANET fez a transição para a Internet moderna por volta de 1980.

SMTP Original

Em 1980, Jon Postel publicou o RFC  772 que propôs o Mail Transfer Protocol como uma substituição do uso do File Transfer Protocol (FTP) para o correio. A RFC  780 de maio de 1981 removeu todas as referências ao FTP e alocou a porta 57 para TCP e UDP , uma alocação que já foi removida pela IANA . Em novembro de 1981, Postel publicou o RFC  788 "Simple Mail Transfer Protocol".

O padrão SMTP foi desenvolvido na mesma época que a Usenet , uma rede de comunicação um-para-muitos com algumas semelhanças.

O SMTP tornou-se amplamente utilizado no início dos anos 1980. Na época, era um complemento do Unix to Unix Copy Program (UUCP), que era mais adequado para lidar com transferências de e-mail entre máquinas que estavam conectadas de forma intermitente. O SMTP, por outro lado, funciona melhor quando as máquinas de envio e recebimento estão conectadas à rede o tempo todo. Ambos usaram um mecanismo de armazenamento e encaminhamento e são exemplos de tecnologia push . Embora os grupos de notícias da Usenet ainda fossem propagados com o UUCP entre os servidores, o UUCP como um transporte de correio virtualmente desapareceu junto com os " caminhos de explosão " que ele usava como cabeçalhos de roteamento de mensagens.

Sendmail , lançado com 4.1cBSD em 1982, logo após a publicação da RFC  788 em novembro de 1981, foi um dos primeiros agentes de transferência de correio a implementar o SMTP. Com o tempo, conforme o BSD Unix se tornou o sistema operacional mais popular na Internet, o Sendmail se tornou o MTA (agente de transferência de correio) mais comum .

O protocolo SMTP original suportava apenas comunicações de texto ASCII de 7 bits não autenticadas e não criptografadas, suscetíveis a ataques man-in-the-middle triviais , spoofing e spam , e exigindo que todos os dados binários fossem codificados em texto legível antes da transmissão. Devido à ausência de um mecanismo de autenticação adequado, por design, cada servidor SMTP era uma retransmissão de email aberta . O Internet Mail Consortium (IMC) relatou que 55% dos servidores de e-mail eram open relays em 1998, mas menos de 1% em 2002. Devido às preocupações com spam, a maioria dos provedores de e-mail bloqueia os open relays, tornando o SMTP original essencialmente impraticável para uso geral na Internet .

SMTP moderno

Em novembro de 1995, a RFC  1869 definiu o protocolo ESMTP (Extended Simple Mail Transfer Protocol), que estabeleceu uma estrutura geral para todas as extensões existentes e futuras com o objetivo de adicionar os recursos ausentes no SMTP original. ESMTP define meios consistentes e gerenciáveis ​​pelos quais clientes e servidores ESMTP podem ser identificados e os servidores podem indicar extensões suportadas.

O envio de mensagens ( RFC  2476 ) e o SMTP-AUTH ( RFC  2554 ) foram introduzidos em 1998 e 1999, ambos descrevendo novas tendências na entrega de e-mail. Originalmente, os servidores SMTP eram normalmente internos a uma organização, recebendo e-mails para a organização de fora e retransmitindo mensagens da organização para o exterior . Mas com o passar do tempo, os servidores SMTP (agentes de transferência de correio), na prática, expandiram suas funções para se tornarem agentes de envio de mensagens para agentes de usuário de correio , alguns dos quais agora retransmitiam correio de fora de uma organização. (por exemplo, um executivo de uma empresa deseja enviar e-mail durante uma viagem usando o servidor SMTP corporativo.) Esse problema, uma consequência da rápida expansão e popularidade da World Wide Web , fez com que o SMTP tivesse que incluir regras e métodos específicos para retransmissão de e-mail e autenticar usuários para evitar abusos, como retransmissão de e-mail não solicitado ( spam ). O trabalho no envio de mensagens ( RFC  2476 ) foi iniciado originalmente porque os servidores de e-mail populares frequentemente reescreviam as mensagens na tentativa de corrigir problemas, por exemplo, adicionando um nome de domínio a um endereço não qualificado. Esse comportamento é útil quando a mensagem que está sendo corrigida é um envio inicial, mas é perigoso e prejudicial quando a mensagem se originou em outro lugar e está sendo retransmitida. Separar claramente a correspondência em envio e retransmissão foi visto como uma forma de permitir e encorajar a reescrita de envios, ao mesmo tempo que proíbe a reescrita de retransmissão. À medida que o spam se tornou mais comum, ele também foi visto como uma forma de fornecer autorização para o envio de e-mails de uma organização, bem como rastreabilidade. Essa separação de retransmissão e envio rapidamente se tornou a base para as práticas modernas de segurança de e-mail.

Como este protocolo começou puramente baseado em texto ASCII , ele não lidou bem com arquivos binários ou caracteres em muitos idiomas diferentes do inglês. Padrões como Multipurpose Internet Mail Extensions ( MIME ) foram desenvolvidos para codificar arquivos binários para transferência por meio de SMTP. Os agentes de transferência de correio (MTAs) desenvolvidos após o Sendmail também tendiam a ser implementados com 8 bits limpos , de modo que a estratégia alternativa "apenas enviar oito" pudesse ser usada para transmitir dados de texto arbitrários (em qualquer codificação de caracteres semelhante ao ASCII de 8 bits) via SMTP. Mojibake ainda era um problema devido aos diferentes mapeamentos de conjuntos de caracteres entre os fornecedores, embora os próprios endereços de e-mail ainda permitissem apenas ASCII . MTAs limpos de 8 bits hoje tendem a suportar a extensão 8BITMIME, permitindo que alguns arquivos binários sejam transmitidos quase tão facilmente quanto texto simples (limites no comprimento da linha e valores de octeto permitidos ainda se aplicam, de modo que a codificação MIME é necessária para a maioria dos não-texto dados e alguns formatos de texto). Em 2012, a SMTPUTF8extensão foi criada para suportar texto UTF-8 , permitindo conteúdo e endereços internacionais em scripts não latinos, como cirílico ou chinês .

Muitas pessoas contribuíram com as especificações centrais do SMTP, entre elas Jon Postel , Eric Allman , Dave Crocker, Ned Freed , Randall Gellens, John Klensin e Keith Moore .

Modelo de processamento de correio

Setas azuis representam a implementação de variações SMTP

O e-mail é enviado por um cliente de correio ( agente de usuário de correio , MUA) a um servidor de correio ( agente de envio de correio , MSA) usando SMTP na porta TCP 587. A maioria dos provedores de caixa de correio ainda permite o envio na porta 25 tradicional. agente de transferência de correio (agente de transferência de correio , MTA). Freqüentemente, esses dois agentes são instâncias do mesmo software iniciado com opções diferentes na mesma máquina. O processamento local pode ser feito em uma única máquina ou dividido entre várias máquinas; os processos do agente de correio em uma máquina podem compartilhar arquivos, mas se o processamento for em várias máquinas, eles transferem mensagens entre si usando SMTP, onde cada máquina é configurada para usar a próxima máquina como um host inteligente . Cada processo é um MTA (um servidor SMTP) em seu próprio direito.

O MTA de limite usa DNS para pesquisar o registro MX (mail Exchanger) para o domínio do destinatário (a parte do endereço de e-mail à direita de @). O registro MX contém o nome do MTA de destino. Com base no host de destino e em outros fatores, o MTA de envio seleciona um servidor destinatário e se conecta a ele para concluir a troca de mensagens.

A transferência de mensagens pode ocorrer em uma única conexão entre dois MTAs ou em uma série de saltos por meio de sistemas intermediários. Um servidor SMTP de recebimento pode ser o destino final, uma "retransmissão" intermediária (ou seja, ele armazena e encaminha a mensagem) ou um "gateway" (ou seja, pode encaminhar a mensagem usando algum protocolo diferente de SMTP). De acordo com a RFC  5321 seção 2.1, cada salto é uma transferência formal de responsabilidade pela mensagem, por meio da qual o servidor receptor deve entregar a mensagem ou relatar adequadamente a falha em fazê-lo.

Assim que o salto final aceita a mensagem recebida, ele a entrega a um agente de entrega de correio (MDA) para entrega local. Um MDA salva mensagens no formato de caixa de correio relevante . Tal como acontece com o envio, esta recepção pode ser feita através de um ou vários computadores, mas no diagrama acima o MDA é representado como uma caixa perto da caixa de correio. Um MDA pode entregar mensagens diretamente para o armazenamento ou encaminhá- las por uma rede usando SMTP ou outro protocolo como o Local Mail Transfer Protocol (LMTP), um derivado do SMTP desenvolvido para esse fim.

Depois de entregue ao servidor de e-mail local, o e-mail é armazenado para recuperação em lote por clientes de e-mail autenticados (MUAs). O correio é recuperado por aplicativos do usuário final, chamados de clientes de e-mail, usando Internet Message Access Protocol (IMAP), um protocolo que facilita o acesso ao correio e gerencia o correio armazenado, ou o Post Office Protocol (POP) que normalmente usa o correio mbox tradicional formato de arquivo ou um sistema proprietário, como Microsoft Exchange / Outlook ou Lotus Notes / Domino . Os clientes de webmail podem usar qualquer um dos métodos, mas o protocolo de recuperação geralmente não é um padrão formal.

O SMTP define o transporte da mensagem , não o conteúdo da mensagem . Assim, ele define o envelope de correio e seus parâmetros, como o remetente do envelope , mas não o cabeçalho (exceto as informações de rastreamento ) nem o próprio corpo da mensagem. O STD 10 e o RFC  5321 definem o SMTP (o envelope), enquanto o STD 11 e o RFC  5322 definem a mensagem (cabeçalho e corpo), formalmente denominado Formato de Mensagem da Internet .

Visão geral do protocolo

SMTP é um protocolo baseado em texto , orientado por conexão , no qual um remetente de email se comunica com um receptor de email emitindo strings de comando e fornecendo os dados necessários por meio de um canal de fluxo de dados ordenado confiável, normalmente uma conexão TCP ( Transmission Control Protocol ). Uma sessão SMTP consiste em comandos originados por um cliente SMTP (o agente iniciador , remetente ou transmissor) e respostas correspondentes do servidor SMTP (o agente de escuta ou receptor) para que a sessão seja aberta e os parâmetros da sessão sejam trocados. Uma sessão pode incluir zero ou mais transações SMTP. Uma transação SMTP consiste em três sequências de comando / resposta:

  1. Comando MAIL , para estabelecer o endereço de retorno, também chamado de caminho de retorno, caminho reverso, endereço de devolução , mfrom ou remetente de envelope.
  2. Comando RCPT , para estabelecer um destinatário da mensagem. Este comando pode ser emitido várias vezes, uma para cada destinatário. Esses endereços também fazem parte do envelope.
  3. DATA para sinalizar o início do texto da mensagem ; o conteúdo da mensagem, em oposição ao seu envelope. Ele consiste em um cabeçalho de mensagem e um corpo de mensagem separado por uma linha em branco. DATA é na verdade um grupo de comandos, e o servidor responde duas vezes: uma vez para o próprio comando DATA , para reconhecer que está pronto para receber o texto, e a segunda vez após a sequência de fim de dados, para aceitar ou rejeitar toda a mensagem.

Além da resposta intermediária para DATA, a resposta de cada servidor pode ser positiva (códigos de resposta 2xx) ou negativa. As respostas negativas podem ser permanentes (códigos 5xx) ou temporárias (códigos 4xx). Uma rejeição é uma falha permanente e o cliente deve enviar uma mensagem devolvida ao servidor de onde a recebeu. Uma queda é uma resposta positiva seguida pelo descarte da mensagem em vez da entrega.

O host inicial, o cliente SMTP, pode ser um cliente de e-mail do usuário final , identificado funcionalmente como um agente de usuário de e-mail (MUA), ou um agente de transferência de e-mail (MTA) do servidor de retransmissão , que é um servidor SMTP agindo como um cliente SMTP , na sessão relevante, para retransmitir correio. Os servidores SMTP com capacidade total mantêm filas de mensagens para repetir as transmissões de mensagens que resultaram em falhas temporárias.

Um MUA conhece o servidor SMTP de correio de saída a partir de sua configuração. Um servidor de retransmissão normalmente determina a qual servidor se conectar, pesquisando o registro de recurso DNS MX (Mail eXchange) para o nome de domínio de cada destinatário . Se nenhum registro MX é encontrado, um servidor de retransmissão conformant (nem todos são) em vez olha para o registro A . Os servidores de retransmissão também podem ser configurados para usar um host inteligente . Um servidor de retransmissão inicia uma conexão TCP com o servidor na " porta conhecida " para SMTP: porta 25, ou para conexão a um MSA, porta 587. A principal diferença entre um MTA e um MSA é que a conexão com um MSA requer Autenticação SMTP .

SMTP vs recuperação de e-mail

SMTP é apenas um protocolo de entrega. Em uso normal, o e-mail é "enviado" para um servidor de e-mail de destino (ou servidor de e-mail de próximo salto) assim que chega. O correio é roteado com base no servidor de destino, não nos usuários individuais aos quais é endereçado. Outros protocolos, como o Post Office Protocol (POP) e o Internet Message Access Protocol (IMAP), são projetados especificamente para uso por usuários individuais que recuperam mensagens e gerenciam caixas de correio . Para permitir que um servidor de e-mail conectado de forma intermitente extraia mensagens de um servidor remoto sob demanda, o SMTP tem um recurso para iniciar o processamento da fila de mensagens em um servidor remoto (consulte Iniciando a fila de mensagens remota abaixo). POP e IMAP são protocolos inadequados para retransmissão de e-mail por máquinas conectadas de forma intermitente; eles são projetados para operar após a entrega final, quando as informações essenciais para o funcionamento correto da retransmissão de correspondência (o "envelope de correspondência") forem removidas.

Início da fila de mensagens remotas

O início remoto da fila de mensagens permite que um host remoto inicie o processamento da fila de mensagens em um servidor para que possa receber mensagens destinadas a ele enviando um comando correspondente. O TURNcomando original foi considerado inseguro e foi estendido na RFC  1985 com o ETRNcomando que opera com mais segurança usando um método de autenticação baseado em informações do Sistema de Nomes de Domínio .

Servidor SMTP de saída de correio

Um cliente de e - mail precisa saber o endereço IP de seu servidor SMTP inicial e isso deve ser fornecido como parte de sua configuração (geralmente fornecido como um nome DNS ). Este servidor entregará mensagens de saída em nome do usuário.

Restrições de acesso ao servidor de saída de e-mail

Os administradores de servidor precisam impor algum controle sobre quais clientes podem usar o servidor. Isso permite que eles lidem com o abuso, por exemplo, spam . Duas soluções têm sido de uso comum:

  • No passado, muitos sistemas impunham restrições de uso pela localização do cliente, permitindo o uso apenas por clientes cujo endereço IP é aquele controlado pelos administradores do servidor. O uso de qualquer outro endereço IP de cliente não é permitido.
  • Os servidores SMTP modernos geralmente oferecem um sistema alternativo que requer autenticação de clientes por credenciais antes de permitir o acesso.

Restringindo o acesso por localização

Nesse sistema, o servidor SMTP de um ISP não permitirá o acesso de usuários que estejam fora da rede do ISP. Mais precisamente, o servidor só pode permitir o acesso a usuários com um endereço IP fornecido pelo ISP, o que equivale a exigir que eles estejam conectados à Internet usando esse mesmo ISP. Um usuário móvel pode frequentemente estar em uma rede diferente da de seu ISP normal e, então, descobrirá que o envio de e-mail falha porque a escolha do servidor SMTP configurado não está mais acessível.

Este sistema possui diversas variações. Por exemplo, o servidor SMTP de uma organização só pode fornecer serviço a usuários na mesma rede, reforçando isso por meio de firewall para bloquear o acesso de usuários na Internet mais ampla. Ou o servidor pode realizar verificações de alcance no endereço IP do cliente. Esses métodos eram normalmente usados ​​por empresas e instituições, como universidades, que forneciam um servidor SMTP para correio de saída apenas para uso interno na organização. No entanto, a maioria desses órgãos agora usa métodos de autenticação de cliente, conforme descrito a seguir.

Quando um usuário é móvel e pode usar diferentes ISPs para se conectar à Internet, esse tipo de restrição de uso é oneroso e alterar o endereço do servidor SMTP de e-mail de saída configurado é impraticável. É altamente desejável poder usar as informações de configuração do cliente de e-mail que não precisam ser alteradas.

Autenticação de cliente

Os servidores SMTP modernos normalmente exigem autenticação de clientes por credenciais antes de permitir o acesso, em vez de restringir o acesso por local, conforme descrito anteriormente. Este sistema mais flexível é amigável para usuários móveis e permite que eles tenham uma escolha fixa de servidor SMTP de saída configurado. A autenticação SMTP , frequentemente abreviada como SMTP AUTH, é uma extensão do SMTP para fazer login usando um mecanismo de autenticação.

Ports

A comunicação entre servidores de e-mail geralmente usa a porta 25 TCP padrão designada para SMTP.

Os clientes de email , entretanto, geralmente não usam isso, em vez de portas de "envio" específicas. Os serviços de correio geralmente aceitam o envio de e-mail de clientes em um dos seguintes:

  • 587 (Envio), conforme formalizado no RFC  6409 (anteriormente RFC  2476 )
  • 465 Esta porta foi descontinuada após o RFC  2487 , até a emissão do RFC  8314 .

A porta 2525 e outras podem ser usadas por alguns provedores individuais, mas nunca foram oficialmente suportadas.

Muitos provedores de serviços de Internet agora bloqueiam todo o tráfego de saída da porta 25 de seus clientes. Principalmente como uma medida anti-spam, mas também para curar o custo mais alto que eles têm ao deixá-lo aberto, talvez cobrando mais dos poucos clientes que exigem sua abertura.

Exemplo de transporte SMTP

Um exemplo típico de envio de uma mensagem via SMTP para duas caixas de correio ( alice e theboss ) localizadas no mesmo domínio de correio ( example.com ) é reproduzido na troca de sessão a seguir. (Neste exemplo, as partes da conversa são prefixadas com S: e C:, para servidor e cliente , respectivamente; esses rótulos não fazem parte da troca.)

Após o remetente da mensagem (cliente SMTP) estabelecer um canal de comunicação confiável com o receptor da mensagem (servidor SMTP), a sessão é aberta com uma saudação pelo servidor, geralmente contendo seu nome de domínio totalmente qualificado (FQDN), neste caso smtp.exemplo .com . O cliente inicia seu diálogo respondendo com um HELOcomando identificando-se no parâmetro do comando com seu FQDN (ou um literal de endereço se nenhum estiver disponível). 

S: 220 smtp.example.com ESMTP Postfix
C: HELO relay.example.org
S: 250 Hello relay.example.org, I am glad to meet you
C: MAIL FROM:<bob@example.org>
S: 250 Ok
C: RCPT TO:<alice@example.com>
S: 250 Ok
C: RCPT TO:<theboss@example.com>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: "Bob Example" <bob@example.org>
C: To: "Alice Example" <alice@example.com>
C: Cc: theboss@example.com
C: Date: Tue, 15 Jan 2008 16:02:43 -0500
C: Subject: Test message
C:
C: Hello Alice.
C: This is a test message with 5 header fields and 4 lines in the message body.
C: Your friend,
C: Bob
C: .
S: 250 Ok: queued as 12345
C: QUIT
S: 221 Bye
{The server closes the connection}

O cliente notifica o destinatário do endereço de e-mail de origem da mensagem em um MAIL FROMcomando. Este também é o endereço de devolução ou devolução , caso a mensagem não possa ser entregue. Neste exemplo, a mensagem de e-mail é enviada para duas caixas de correio no mesmo servidor SMTP: uma para cada destinatário listado nos campos de cabeçalho To:e Cc:. O comando SMTP correspondente é RCPT TO. Cada recepção e execução bem-sucedida de um comando é confirmada pelo servidor com um código de resultado e mensagem de resposta (por exemplo, 250 Ok).

A transmissão do corpo da mensagem de correio é iniciada com um DATAcomando, após o qual é transmitida literalmente linha por linha e é encerrada com uma seqüência de fim de dados. Esta sequência consiste em uma nova linha ( <CR><LF>), um único ponto final ( .), seguido por outra nova linha ( <CR><LF>). Uma vez que o corpo de uma mensagem pode conter uma linha com apenas um ponto como parte do texto, o cliente envia dois pontos sempre que uma linha começa com um ponto; correspondentemente, o servidor substitui cada sequência de dois pontos no início de uma linha por um único. Esse método de escape é denominado dot-stuffing .

A resposta positiva do servidor ao fim dos dados, conforme exemplificado, implica que o servidor assumiu a responsabilidade de entregar a mensagem. Uma mensagem pode ser duplicada se houver uma falha de comunicação neste momento, por exemplo, devido a uma queda de energia: Até que o remetente receba a 250 Okresposta, ele deve assumir que a mensagem não foi entregue. Por outro lado, após o receptor decidir aceitar a mensagem, ele deve assumir que a mensagem foi entregue a ele. Portanto, durante esse intervalo de tempo, os dois agentes têm cópias ativas da mensagem que tentarão entregar. A probabilidade de que uma falha de comunicação ocorra exatamente nesta etapa é diretamente proporcional à quantidade de filtragem que o servidor executa no corpo da mensagem, na maioria das vezes para fins anti-spam. O tempo limite limite é especificado como 10 minutos.

O QUITcomando termina a sessão. Se o e-mail tiver outros destinatários localizados em outro lugar, o cliente se QUITconectará a um servidor SMTP apropriado para os destinatários subsequentes após o (s) destino (s) atual (is) ter sido colocado (s) na fila. As informações que o cliente envia nos comandos HELOe MAIL FROMsão adicionadas (não vistas no código de exemplo) como campos de cabeçalho adicionais à mensagem pelo servidor de recebimento. Ele adiciona um campo de cabeçalho Receivede Return-Path, respectivamente.

Alguns clientes são implementados para fechar a conexão após a mensagem ser aceita ( 250 Ok: queued as 12345), portanto, as duas últimas linhas podem ser omitidas. Isso causa um erro no servidor ao tentar enviar a 221 Byeresposta.

Extensões SMTP

Mecanismo de descoberta de extensão

Os clientes aprendem as opções suportadas de um servidor usando a EHLOsaudação, conforme exemplificado abaixo, em vez da original HELO. Os clientes recorrerão HELOapenas se o servidor não suportar EHLOsaudação.

Os clientes modernos podem usar a palavra SIZE- chave de extensão ESMTP para consultar o servidor sobre o tamanho máximo de mensagem que será aceito. Clientes e servidores mais antigos podem tentar transferir mensagens de tamanho excessivo que serão rejeitadas após consumir recursos da rede, incluindo o tempo de conexão a links de rede que é pago por minuto.

Os usuários podem determinar manualmente com antecedência o tamanho máximo aceito pelos servidores ESMTP. O cliente substitui o HELOcomando pelo EHLOcomando. 

S: 220 smtp2.example.com ESMTP Postfix
C: EHLO bob.example.org
S: 250-smtp2.example.com Hello bob.example.org [192.0.2.201]
S: 250-SIZE 14680064
S: 250-PIPELINING
S: 250 HELP

Assim, smtp2.example.com declara que pode aceitar um tamanho máximo fixo de mensagem não superior a 14.680.064 octetos (bytes de 8 bits).

No caso mais simples, um servidor ESMTP declara um máximo SIZEimediatamente após receber um EHLO. De acordo com a RFC  1870 , no entanto, o parâmetro numérico para a SIZEextensão na EHLOresposta é opcional. Em vez disso, os clientes podem, ao emitir um MAIL FROMcomando, incluir uma estimativa numérica do tamanho da mensagem que estão transferindo, para que o servidor possa recusar o recebimento de mensagens muito grandes.

Transferência de dados binários

O SMTP original suporta apenas um único corpo de texto ASCII, portanto, quaisquer dados binários precisam ser codificados como texto nesse corpo da mensagem antes da transferência e, em seguida, decodificados pelo destinatário. Codificações binário para texto , como uuencode e BinHex eram normalmente usadas.

O comando 8BITMIME foi desenvolvido para resolver isso. Foi padronizado em 1994 como RFC  1652. Ele facilita a troca transparente de mensagens de e-mail contendo octetos fora do conjunto de caracteres ASCII de sete bits , codificando-os como partes de conteúdo MIME , normalmente codificadas com Base64 .

Extensões de mecanismo de entrega de correio

Retransmissão de correio sob demanda

Artigo principal: On-Demand Mail Relay

O On-Demand Mail Relay ( ODMR ) é uma extensão SMTP padronizada no RFC  2645 que permite que um servidor SMTP conectado de forma intermitente receba e-mails enfileirados para ele quando estiver conectado.

Extensão de internacionalização

Artigo principal: Email internacional

O SMTP original oferece suporte a endereços de e-mail compostos apenas de caracteres ASCII , o que é inconveniente para usuários cujo script nativo não é baseado em latim ou que usam sinais diacríticos que não estão no conjunto de caracteres ASCII. Essa limitação foi atenuada por meio de extensões que permitem UTF-8 em nomes de endereço. O RFC  5336 introduziu o UTF8SMTPcomando experimental e mais tarde foi substituído pelo RFC  6531, que introduziu o SMTPUTF8comando. Essas extensões fornecem suporte para caracteres multibyte e não ASCII em endereços de e-mail, como aqueles com sinais diacríticos e outros caracteres de idioma, como grego e chinês .

O suporte atual é limitado, mas há um grande interesse na ampla adoção do RFC  6531 e dos RFCs relacionados em países como a China, que têm uma grande base de usuários onde o latim (ASCII) é uma escrita estrangeira.

Extensões

Como o SMTP, o ESMTP é um protocolo usado para transportar correio da Internet. É usado como protocolo de transporte entre servidores e (com comportamento restrito) como protocolo de envio de mensagens.

O principal recurso de identificação para clientes ESMTP é abrir uma transmissão com o comando EHLO(Extended HELLO), em vez de HELO(Hello, o padrão RFC  821 original ). Um servidor responderá com sucesso (código 250), falha (código 550) ou erro (código 500, 501, 502, 504 ou 421), dependendo de sua configuração. Um servidor ESMTP retorna o código 250 OK em uma resposta multilinha com seu domínio e uma lista de palavras-chave para indicar as extensões suportadas. Um servidor compatível com RFC 821 retorna o código de erro 500, permitindo que os clientes ESMTP tentem HELOou QUIT.

Cada extensão de serviço é definida em um formato aprovado em RFCs subsequentes e registrada na Internet Assigned Numbers Authority (IANA). As primeiras definições foram os serviços opcionais RFC 821: SEND, SOML(Enviar ou Mail), SAML(Enviar e Mail), EXPN, HELP, e TURN. O formato de verbos SMTP adicionais foi definido e para novos parâmetros em MAILe RCPT.

Algumas palavras-chave relativamente comuns (nem todas correspondendo a comandos) usadas hoje são:

O formato ESMTP foi reformulado no RFC  2821 (substituindo o RFC 821) e atualizado para a definição mais recente no RFC  5321 em 2008. O suporte para o EHLOcomando em servidores tornou-se obrigatório e HELOdesignado como um fallback obrigatório.

Extensões de serviço não padronizadas e não registradas podem ser usadas por acordo bilateral, esses serviços são indicados por uma EHLOpalavra-chave de mensagem começando com "X" e com quaisquer parâmetros adicionais ou verbos marcados de forma semelhante.

Os comandos SMTP não diferenciam maiúsculas de minúsculas. Eles são apresentados aqui em maiúsculas apenas para ênfase. Um servidor SMTP que requer um método específico de capitalização é uma violação do padrão.

8BITMIME

Pelo menos os seguintes servidores anunciam a extensão 8BITMIME:

Os seguintes servidores podem ser configurados para anunciar 8BITMIME, mas não realizam a conversão de dados de 8 bits em 7 bits ao se conectar a retransmissões não 8BITMIME:

  • O Exim e o qmail não traduzem mensagens de oito bits em sete bits ao tentar retransmitir dados de 8 bits para pares não 8BITMIME, conforme exigido pela RFC. Isso não causa problemas na prática, uma vez que virtualmente todas as retransmissões de correio modernas são limpas de 8 bits .
  • O Microsoft Exchange Server 2003 anuncia 8BITMIME por padrão, mas retransmitir para um par não 8BITMIME resulta em uma rejeição. Isso é permitido pela RFC 6152 seção 3 .

SMTP-AUTH

Artigo principal: Autenticação SMTP

A extensão SMTP-AUTH fornece um mecanismo de controle de acesso. Consiste em uma etapa de autenticação por meio da qual o cliente efetua login efetivamente no servidor de e-mail durante o processo de envio de e-mail. Os servidores que oferecem suporte a SMTP-AUTH geralmente podem ser configurados para exigir que os clientes usem essa extensão, garantindo que a verdadeira identidade do remetente seja conhecida. A extensão SMTP-AUTH é definida na RFC  4954 .

O SMTP-AUTH pode ser usado para permitir que usuários legítimos retransmitam emails, enquanto nega o serviço de retransmissão a usuários não autorizados, como spammers . Isso não garante necessariamente a autenticidade do remetente do envelope SMTP ou do cabeçalho RFC  2822 "De:". Por exemplo, spoofing , no qual um remetente se disfarça de outra pessoa, ainda é possível com SMTP-AUTH, a menos que o servidor esteja configurado para limitar os endereços de mensagens aos endereços para os quais esse usuário AUTH está autorizado.

A extensão SMTP-AUTH também permite que um servidor de e-mail indique a outro que o remetente foi autenticado ao retransmitir o e-mail. Em geral, isso exige que o servidor do destinatário confie no servidor de envio, o que significa que esse aspecto do SMTP-AUTH raramente é usado na Internet.

SMTPUTF8

Os servidores de suporte incluem:

Extensões de segurança

A entrega de correio pode ocorrer tanto em texto simples quanto em conexões criptografadas; no entanto, as partes em comunicação podem não saber com antecedência da capacidade da outra parte de usar o canal seguro.

STARTTLS ou "TLS oportunista"

Artigos principais: TLS oportunista e criptografia de e- mail

As extensões STARTTLS permitem que os servidores SMTP de suporte para notificar os clientes conectados que oferecem suporte à comunicação criptografada TLS e oferece a oportunidade para os clientes atualizarem sua conexão enviando o comando STARTTLS. Os servidores que suportam a extensão não ganham inerentemente quaisquer benefícios de segurança de sua implementação por conta própria, pois a atualização para uma sessão criptografada por TLS depende da decisão do cliente conectado em exercer esta opção, daí o termo TLS oportunista .

STARTTLS é eficaz apenas contra ataques de observação passiva, uma vez que a negociação STARTTLS ocorre em texto simples e um atacante ativo pode remover comandos STARTTLS trivialmente. Esse tipo de ataque man-in-the-middle é às vezes conhecido como STRIPTLS , em que as informações de negociação de criptografia enviadas de uma extremidade nunca chegam à outra. Nesse cenário, ambas as partes consideram as respostas inválidas ou inesperadas como indicação de que a outra não oferece suporte adequado para STARTTLS, adotando como padrão a transferência de correio em texto simples tradicional. Observe que STARTTLS também é definido para IMAP e POP3 em outros RFCs, mas esses protocolos têm finalidades diferentes: SMTP é usado para comunicação entre agentes de transferência de mensagens, enquanto IMAP e POP3 são para clientes finais e agentes de transferência de mensagens.

A Electronic Frontier Foundation mantém uma lista "STARTTLS Everywhere" que, de maneira semelhante à lista " HTTPS Everywhere ", permite que as partes confiáveis ​​descubram outras que oferecem suporte à comunicação segura sem comunicação prévia.

A RFC  8314 declarou oficialmente o texto simples obsoleto e recomenda sempre o uso de TLS, adicionando portas com TLS implícito.

SMTP MTA Strict Transport Security

Uma nova RFC  8461 2018 chamada "SMTP MTA Strict Transport Security (MTA-STS)" visa resolver o problema do adversário ativo, definindo um protocolo para servidores de e-mail para declarar sua capacidade de usar canais seguros em arquivos específicos no servidor e DNS específico Registros TXT. A parte confiável verificaria regularmente a existência de tal registro e o armazenaria em cache pelo período de tempo especificado no registro e nunca se comunicaria por canais inseguros até que o registro expirasse. Observe que os registros MTA-STS se aplicam apenas ao tráfego SMTP entre servidores de e-mail, enquanto as comunicações entre o cliente de um usuário e o servidor de e-mail são protegidas pelo Transport Layer Security com SMTP / MSA, IMAP, POP3 ou HTTPS em combinação com uma política organizacional ou técnica. Essencialmente, o MTA-STS é um meio de estender essa política a terceiros.

Em abril de 2019, o Google Mail anunciou o suporte para MTA-STS.

Relatório SMTP TLS

Vários protocolos permitem a entrega segura de mensagens, mas podem falhar devido a configurações incorretas ou interferência ativa deliberada, levando a mensagens não entregues ou entrega por canais não criptografados ou não autenticados. RFC  8460 "SMTP TLS Reporting" descreve um mecanismo de relatório e formato para compartilhar estatísticas e informações específicas sobre possíveis falhas com domínios de destinatários. Os domínios de destinatários podem então usar essas informações para detectar ataques em potencial e diagnosticar configurações incorretas não intencionais.

Em abril de 2019, o Google Mail anunciou o suporte para relatórios TLS SMTP.

Spoofing e spamming

Artigos principais: Técnicas anti-spam e autenticação de e- mail

O design original do SMTP não tinha facilidade para autenticar remetentes ou verificar se os servidores estavam autorizados a enviar em seu nome, o que tornava possível o spoofing de e-mail , comumente usado em spam e phishing de e -mail .

Propostas ocasionais são feitas para modificar extensivamente o SMTP ou substituí-lo completamente. Um exemplo disso é o Internet Mail 2000 , mas nem ele, nem qualquer outro avançou muito em face do efeito de rede da enorme base instalada do SMTP clássico.

Em vez disso, os servidores de e-mail agora usam uma variedade de técnicas, como a aplicação mais rígida de padrões como RFC  5322 , DomainKeys Identified Mail , Sender Policy Framework e DMARC , DNSBLs e greylisting para rejeitar ou colocar em quarentena e-mails suspeitos.

Implementações

Também há implementação de proxy SMTP como, por exemplo, nginx .

Artigos principais: Lista de software de servidor de e- mail e comparação de servidores de e-mail

Pedidos de comentários relacionados

  • RFC  1123 - Requisitos para Hosts da Internet - Aplicativo e Suporte (STD 3)
  • RFC  1870 - Extensão de serviço SMTP para declaração de tamanho de mensagem (оbsoletes: RFC  1653 )
  • RFC  2505 - Recomendações anti-spam para MTAs SMTP (BCP 30)
  • RFC  2821 - Protocolo Simples de Transferência de Correio
  • RFC  2920 - Extensão do Serviço SMTP para Command Pipelining (STD 60)
  • RFC  3030 - Extensões de serviço SMTP para transmissão de mensagens MIME grandes e binárias
  • RFC  3207 - Extensão de Serviço SMTP para SMTP Seguro sobre Segurança da Camada de Transporte ( RFC  2487 obsoleto )
  • RFC  3461 - Extensão de serviço SMTP para notificações de status de entrega (obsoleta RFC  1891 )
  • RFC  3463 - Códigos de status aprimorados para SMTP (obsoleta RFC  1893 , atualizado por RFC  5248 )
  • RFC  3464 - um formato de mensagem extensível para notificações de status de entrega ( RFC  1894 obsoleto )
  • RFC  3798 - Notificação de disposição de mensagem (atualiza RFC  3461 )
  • RFC  3834 - Recomendações para respostas automáticas ao correio eletrônico
  • RFC  3974 - Experiência operacional SMTP em ambientes IPv4 / v6 mistos
  • RFC  4952 - Visão geral e estrutura para e-mail internacionalizado (atualizado por RFC  5336 )
  • RFC  4954 - Extensão do Serviço SMTP para Autenticação ( torna obsoleto o RFC  2554 , atualiza o RFC  3463 , atualizado pelo RFC  5248 )
  • RFC  5068 - Operações de envio de e-mail: Requisitos de acesso e responsabilidade (BCP 134)
  • RFC  5248 - Um registro para códigos de status do sistema de correio aprimorado SMTP (BCP 138) (atualiza RFC  3463 )
  • RFC  5321 - O protocolo de transferência de correio simples ( torna  obsoleto o RFC 821, também conhecido como STD 10, RFC  974 , RFC  1869 , RFC  2821 , atualiza o RFC  1123 )
  • RFC  5322 - Formato de Mensagem da Internet ( torna  obsoleto o RFC 822 também conhecido como STD 11 e RFC  2822 )
  • RFC  5504 - Mecanismo de Downgrade para Internacionalização de Endereços de Email
  • RFC  6409 - Envio de mensagem para correio (STD 72) (obsoleta RFC  4409 , RFC  2476 )
  • RFC  6522 - O tipo de conteúdo multiparte / relatório para o relatório de mensagens administrativas do sistema de correio ( torna obsoleto o RFC  3462 e, por sua vez, o RFC  1892 )
  • RFC  6531 - Extensão SMTP para endereços de e-mail internacionalizados (atualiza RFC  2821 , RFC  2822 , RFC  4952 e RFC  5336 )
  • RFC  8314 - Texto simples considerado obsoleto: uso de Transport Layer Security (TLS) para envio e acesso de e-mail

Veja também

Notas

Referências

links externos