Por que preciso de um servidor SMTP?


92

Por que preciso de um servidor SMTP intermediário para enviar email? Por que meu cliente (Outlook, Thunderbird) não pode enviar mensagens diretamente para o domínio SMTP do destinatário?

Por exemplo, se eu tiver que enviar um email para address@example.comminha conta do Gmail, eu o envio ao smtp.gmail.comservidor; e esse servidor enviará minha mensagem ao servidor MX de example.com.


Respostas:


114

É tecnicamente possível enviar um email diretamente para o servidor SMTP do destinatário do seu computador.

Olhando para ele de uma base histórica, se o servidor SMTP remoto estiver inativo, você deseja que um sistema o manipule automaticamente e continue tentando novamente; portanto, você tem um servidor SMTP. Da mesma forma, antigamente, nem todos os servidores de email estavam conectados o tempo todo - os links de longa distância eram caros; portanto, os emails eram enfileirados e enviados quando um link era estabelecido.

Passando para onde a Internet é barata, ainda é útil ter mecanismos para tentar enviar novamente o email se um servidor não estiver disponível, e não é ideal que essa funcionalidade seja gravada no MUA (programa de email do agente de usuário / usuário final). Essas funções se encaixam em um MTA (servidor de email / servidor SMTP).

Mas fica pior - spammers . A maioria dos emails (mais de 80%) é spam. Portanto, os provedores de correio fazem o possível para reduzir esse problema - e um grande número de técnicas faz suposições sobre a maneira como o email é entregue - as seguintes considerações importantes:

  1. Lista de espera: alguns provedores eliminam automaticamente uma conexão de e-mail se o remetente e o destinatário não tiverem se comunicado antes e esperam que eles tentem uma segunda vez - porque os remetentes de spam geralmente não o fazem, enquanto um servidor SMTP sempre deveria. Isso reduz os volumes de spam em cerca de 80%. É péssimo ter que fazer isso.

  2. Reputação: É muito mais provável que alguém enviando email por um servidor SMTP conhecido e respeitável seja legítimo que um servidor noturno. Para ter uma idéia da reputação, os provedores fazem várias coisas:

    1. Bloquear endereços dinâmicos / de cliente (não 100%, mas grandes partes da Internet foram mapeadas).

    2. Observe que o DNS reverso corresponde ao DNS avançado: não é muito difícil de fazer, mas mostra algum nível de responsabilidade e conhecimento das melhores práticas - e algo que muitos blocos de endereços de clientes não possuem.

    3. Reputação: Ao se comunicar com outros servidores SMTP, muitos provedores controlam a quantidade de spam e os volumes de email enviados e podem reduzir a quantidade de spam limitando as conexões e vigiando esses parâmetros. (Existem várias maneiras de fazer isso, nem todas óbvias, mas que exigem um remetente conhecido).

    4. SPF e DKIM: esses mecanismos vinculam os recursos DNS ao nome de domínio para dificultar a falsificação de mensagens e seriam difíceis (mas não necessariamente impossíveis de implantar se o programa de email (MUA) for responsável pelas mensagens enviadas). completo, pois já foi aceito. O crédito deve ser enviado para os pôsteres abaixo, pois isso me passou pela cabeça, mas é, no entanto, muito válido)

Provavelmente existem outras preocupações menores, mas essas seriam as principais.


19
Não se esqueça de coisas não exatamente menores, como SPF (lista de permissões de hosts autorizados a enviar correio para um domínio) e DKIM (assinatura digital de mensagens no nível do domínio) - especialmente o último só é possível com uma retransmissão dedicada.
grawity

Definitivamente vale a pena mencionar, mas por que o DKIM não é "possível" sem um relé dedicado? Os seletores DKIM não estão vinculados ao aplicativo ou endereço IP de envio. Se o seu cliente de email puder assinar a mensagem com uma chave publicada, é tão válido quanto qualquer outro signatário.
Mathias R. Jessen

2
@ManuH: De acordo com as métricas da resposta correta, o correio normal compromete 1/5 do volume do correio. De acordo com as métricas do meu servidor, o correio normal compromete 1/20 do volume de correio. É um ótimo trade off.
dotancohen

11
@manuh: a lista cinza funciona fechando a conexão antes que o email seja enviado - ele escuta apenas até receber o remetente e o destinatário - que estão no cabeçalho. Além disso, alguns sistemas greylist serão omitidamente. aceite todos os emails de um servidor smtp com histórico de novas tentativas de entrega. Infelizmente, é muito eficaz.
Davidgo 27/11/2015

4
Pode-se acrescentar que, nos "bons e velhos tempos", os emails eram frequentemente enviados de um servidor SMTP para outro, depois para outro e para outro antes de chegar ao destino. Isso geralmente funcionava bem, mas, por exemplo, durante o ataque do rtm-worm, um dos computadores inoperantes era um dos relés de e-mail essenciais; portanto, e-mails com aviso, soluções e correções no worm podiam levar até 48 horas para chegar seus destinatários.
Baard Kopperud

32

Por que preciso de um servidor SMTP intermediário para enviar email? Por que meu cliente (Outlook, Thunderbird) não pode enviar mensagens diretamente para o domínio SMTP do destinatário?

Em 1991 - e na maior parte do início dos anos 90 e até mais cedo - você pode fazer o que descreve. Mas a realidade em 2015 é que, embora se possa enviar tecnicamente um email para qualquer pessoa de qualquer máquina que tenha um serviço de email instalado, o mundo do SPAM tornou esse método efetivamente inútil.

Quando você usa um serviço SMTP "real", as coisas são definidas como registros PTR, SPF e até DomainKeys, todos estabelecidos para uma finalidade e apenas uma finalidade: garantir que o SMTP que está enviando a mensagem é legítimo. E se não for? Filtre a mensagem em uma pasta SPAM ou no "grande abismo" da exclusão. Aqui está um detalhamento do que são cada um desses itens:

  • PTR (Registro de ponteiro / Registro DNS reverso): verificação no nível do servidor. Conforme explicado aqui , um registro PTR é usado para mapear uma interface de rede (IP) para um nome de host. Ou seja, se você tiver um endereço 123.456.789.0no servidor SMTP enviando e-mails para smtp.example.comum registro PTR apropriado, seria smtp.example.com. Parece muito simples, mas funciona, já que o único que realmente pode definir um registro PTR é o proprietário do endereço IP e só pode ser definido em seu hardware. Portanto, ele atua como um ponto de verificação para quem possui / executa / gerencia esse endereço IP.

  • SPF (Sender Policy Framework): verificação de nível de entrada DNS do nome do host. Um registro SPF - como explicado aqui - é basicamente um registro DNS definido pelo detentor do nome de domínio que fornece uma lista de endereços IP e nomes de host de servidores com permissão para enviar e-mails para esse nome de domínio. Essa é outra etapa de verificação que garante que apenas o verdadeiro proprietário do nome de domínio de um servidor SMTP possa enviar e-mails. Então, digamos que um servidor com o endereço IP de 123.456.789.9está enviando e-mails para example.com. Nós já sabemos que smtp.example.comutiliza 123.456.789.0, mas uma entrada registro SPF para example.comEstado pode “, Hey! 123.456.789.9é um bom servidor! Ele é legítimo! Respeite os e-mails dele!

  • DKIM (DomainKeys Identified Mail): verificação no nível da mensagem de email. Conforme explicado aqui e na Wikipedia , “DKIM é um sistema de validação de email projetado para detectar a falsificação de email, fornecendo um mecanismo para permitir que os trocadores de email verifiquem se as mensagens recebidas de um domínio são autorizadas pelos administradores desse domínio e se o email (incluindo anexos) não foi modificado durante o transporte. ”Ao usar hashes criptográficos, o DKIM verifica se o correio em si não foi filtrado ou violado durante o transporte. Isso também serve como mais um ponto de verificação na cadeia "Você é legítimo ou é spam?".

Portanto, no final, um servidor SMTP voltado para o público que vale qualquer coisa terá pelo menos dois desses itens (PTR e SPF) configurados para verificar se o servidor SMTP e o email relacionado são legítimos. Nem todo mundo usa DKIM, mas é outra camada de validação que está se tornando cada vez mais popular hoje em dia, à medida que os SPAMmers se tornam mais tenazes em seus esforços para enviar SPAM.


15

A maioria dos ISPs residenciais bloqueia a porta TCP 25 (SMTP) para impedir a participação em uma rede de spam. Se o seu PC for infectado, ele poderá começar a espalhar spam a pedido de outra pessoa.


Você escreve "A maioria dos ISPs residenciais bloqueia a porta TCP 25 (SMTP)" <- você pode explicar o que isso significa. Você quer dizer que eles não permitem que você faça uma conexão de saída com um servidor SMTP na porta 25? Ou você quer dizer que eles não permitem que você receba uma conexão na porta 25?
barlop

2
@barlop o primeiro - eles bloqueiam conexões de saída em 25 de links residenciais para máquinas que não sejam seus próprios servidores de correio (ou mesmo para qualquer lugar, porque eles podem usar 587 ou 465 para seus próprios servidores). No entanto, é um exagero dizer que a maioria dos ISPs o faz.
Hbbs #

2
@ Hobbs - Minha experiência (e é uma parte justa do meu trabalho) é diferente. Embora muitos ISPs bloqueiem o tráfego deixando sua rede com um destino da porta 25 (o que força o tráfego da porta 25 através de seus servidores de correio), o mesmo geralmente não é verdadeiro para as portas 587 ou 465 - e, de fato, isso faz sentido. As portas 587 e 465 geralmente EXIGEM autenticação e bloqueio, e são especificamente MUA para MTA, e não MTA-MTA - o bloqueio dessas portas geraria uma enorme RESPOSTA, conforme exigido por muitas empresas, permitindo roaming, responsabilidade e não quebra do SPF.
Davidgo 28/11/2015

3
@ Hobbs, eu nunca escrevi que a maioria dos ISPs faz isso; o que escrevi é que a maioria dos ISPs residenciais faz isso. Por exemplo, AT&T, Comcast, TWC, Verizon etc. fazem isso para seus clientes residenciais, mas não fazem isso para seus clientes corporativos.
precisa

6

As outras respostas são excelentes, e o spam tem muito a ver com isso.

Mas na verdade há uma resposta mais simples e genérica: recursos. O envio de email por SMTP é, na verdade, uma tarefa muito complexa. Mesmo sem spam, você não gostaria de implementar todo o conjunto de recursos do protocolo SMTP em todos os clientes de email; você está melhor com um software dedicado (sendmail, postfix etc., são os grandes do mundo * nix, Exchange no mundo do Windows).

Por exemplo, mesmo no mais básico, um servidor SMTP "real" precisa pelo menos ser capaz de resolver registros MX. Depois, é necessário negociar recursos (principalmente TLS, mas também existem outros recursos). Ele precisa gerenciar filas para tentar novamente, gerar relatórios de falha na entrega etc.

E essa é apenas a funcionalidade básica, indispensável, sem a qual o servidor nem funcionaria. Ele nem sequer inclui coisas como reescrever endereços, endereçáveis. Sem mencionar a dúzia de outros protocolos compatíveis com o sendmail e outros, como o UUCP.

A implementação de SMTP no Outlook, Thunderbird etc. é muito mínima - na melhor das hipóteses, aproximadamente o equivalente ao uso de um host inteligente no sendmail, se for o caso.

Problema relacionado, mas separado: o email é um tópico muito sensível à segurança, e você gostaria de ter um ou muito poucos servidores gerenciados centralmente, em vez de potencialmente centenas ou milhares de servidores individuais em cada área de trabalho.


Este é um bom argumento. Não se trata apenas dos recursos reais para filas e assim por diante: a disponibilidade do servidor faz a diferença para alguns desses recursos. Se houver um problema e você desligar o laptop, ele não poderá tentar novamente até a próxima inicialização - o servidor de email provavelmente estará disponível 24 horas por dia, sete dias por semana, por isso está em uma posição muito melhor para gerenciar uma fila de mensagens. Depois de enviar sua mensagem ao servidor por SMTP, seu cliente de email não precisa ficar online para garantir a entrega.
precisa

4

Por que preciso de um servidor SMTP intermediário para enviar email? Por que meu cliente (Outlook, Thunderbird) não pode enviar mensagens diretamente para o domínio SMTP do destinatário?

Você pode criar um programa de email que tenha feito isso, e não tenho dúvida de que outros já o fizeram (ou tentaram) antes.

Essencialmente, você escreveria uma ferramenta que é um MUA (agente de usuário de email) e MTA (agente de transferência de email) em um.

A razão pela qual isso é tradicionalmente separado em ferramentas diferentes, com o MTA residindo no "lado do servidor", é que um MTA que envia email pela Internet aberta é consideravelmente mais complexo para escrever e configurar e também se beneficia de residir em um servidor "sempre ativo" confiável.

Um MTA deve:

  • Procure e conecte-se a servidores nos quais não confia, ou que possam se comportar mal, e lide com condições de erro de maneira sensata que não perca correio.

  • Lide com servidores inativos e direcione para servidores alternativos ou enfileire o correio para tentar novamente mais tarde. Isso funciona melhor em um processo do servidor que está "sempre conectado" à Internet. Isso também implica que o agente de transferência de email precisa de suas próprias áreas de armazenamento para emails que estão na fila.

  • Lide com uma variedade de recursos diferentes do servidor, ajustando o comportamento de acordo com os recursos do servidor receptor.

  • Informe ao usuário sobre condições de erro ou quando o e-mail não pode ser entregue, para que o e-mail não seja apenas perdido.

  • Tenha excelentes práticas de segurança e tenha muita segurança.

  • O ideal é residir em um servidor confiável e sempre conectado, com um endereço IP estável e uma entrada DNS reversa, ou seja, uma conexão à Internet adequada para servidores públicos. Isso ajuda outros sistemas a não detectar emails enviados como spam.

Dado esses requisitos, faz sentido alojar o servidor SMTP em um servidor sempre ativo voltado para o público em algum lugar e tentar usar uma ferramenta adequada para realizar esse trabalho específico.


1

Outra coisa a considerar é receber e-mails retornados . No mínimo, todos os emails de saída têm um endereço FROM para o qual uma resposta pode ser enviada (usuário desconhecido, resposta de férias, etc.). Para que o endereço de retorno seja resolvido, é necessário que exista um registro MX que aponte para o local da caixa de entrada de retorno. A menos que você esteja enviando email de um computador com um endereço IP estático sempre ativo, você precisará de um servidor para lidar com essas mensagens de entrada. Isso geralmente é tratado (mas nem sempre) pelo mesmo serviço.

GMail, Outlook 365 e Yahoo Mail são exemplos de serviços de email usados ​​por pessoas que estão enviando email. Para o envio comercial de e-mail, existem serviços como MailChimp, Marketo e Eloqua que são muito bons no envio de e-mail em massa para uma empresa e lidam com coisas como devoluções, otimização e capacidade de entrega.

Veja: https://en.m.wikipedia.org/wiki/Bounce_address


Não entendo por que preciso de um IP estático para obter minha resposta ... A resposta deve ser entregue ao meu servidor MX (por exemplo, Gmail) e não ao meu computador. Estou certo?
Tobia

Sim você está correto. Acho que meu argumento é que geralmente existe uma caixa de entrada em um servidor em algum lugar para que o email de saída seja enviado. Logicamente, faz sentido para esse servidor lidar também com os emails enviados. Caso contrário, você perderia coisas como ter uma pasta de email "enviada".
dana

Mmh é razoável. Mas eu sou livre para enviar uma mensagem com o Gmail com um desconhecido "de" ou "replyto" endereço unsing seu servidor SMTP ...
Tobia

11
Se você usa o GMail, é necessário usar a autenticação smtp. Portanto, o endereço FROM está definido como seu endereço @ gmail.com. Caso contrário, você poderá usar o serviço deles para falsificação.
dana 27/11

2
Hoje em dia, muitos usuários não se importam com as devoluções, mas uma configuração que não aceita devoluções geralmente é considerada uma provável fonte de spam.
precisa saber é o seguinte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.