Questão Por que preciso de um servidor SMTP?


Por que preciso de um servidor SMTP intermediário para enviar e-mails? 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.com com minha conta do Gmail, eu a envio para o smtp.gmail.com servidor; e então este servidor irá enviar minha mensagem para o servidor MX de example.com.


90


origem


Duplicação possível de Por que os clientes de email não usam diretamente o servidor SMTP do destinatário - WoDoSc


Respostas:


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

Analisando-a a partir 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 e-mail estavam conectados o tempo todo - os links interurbanos eram caros, portanto, os e-mails seriam enfileirados e enviados quando um link fosse estabelecido.

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

Mas fica piorspammers. A maioria dos emails (mais de 80%) são spam. Portanto, os provedores de email fazem o que podem para reduzir esse problema - e um grande número de técnicas faz suposições sobre o modo como o email é entregue - as seguintes considerações são importantes:

  1. Greylisting: Alguns provedores abandonarão 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 spammers geralmente não o fazem, enquanto um servidor SMTP deve sempre fazer isso. Isso reduz os volumes de spam em cerca de 80%. É uma droga ter que fazer isso embora.

  2. Reputação: É muito mais provável que alguém que envie e-mails através de um servidor SMTP conhecido e confiável seja legítimo do que um servidor fly-by-night. Para sentir a reputação, os provedores fazem várias coisas:

    1. Bloquear endereços dinâmicos / clientes (Não 100%, mas grandes trechos da Internet foram mapeados).

    2. Veja que as correspondências de DNS reverso encaminham o DNS: Não é muito difícil de fazer, mas mostra algum nível de responsabilidade e conhecimento das práticas recomendadas - e algo que muitos blocos de endereços de clientes não têm.

    3. Reputação: Ao se comunicar com outros servidores SMTP, muitos provedores controlam a quantidade de spam e volumes de e-mails enviados e podem reduzir a quantidade de spam limitando as conexões e mantendo um olho nesses parâmetros. (Há muitas maneiras de fazer isso, nem todas óbvias, mas que exigem um remetente conhecido).

    4. SPF e DKIM: Esses mecanismos vinculam os recursos do DNS ao domínio nome para dificultar o envio de correspondência, e seria difícil (mas não necessariamente impossível implantar se o programa de e-mail (MUA) for responsável pelo correio de saída. (Adicionado para tornar esta resposta mais completa como já foi aceito. Crédito por isso deve ir para cartazes abaixo como escorregou minha mente, mas é, no entanto, muito válido)

Existem provavelmente outras preocupações menores, mas estas seriam as principais.


112



Não se esqueça de não exatamente menor coisas como SPF (whitelisting de hosts autorizados a enviar e-mail para um domínio) e DKIM (assinar digitalmente mensagens no nível do domínio) - especialmente o último só é possível com um relé dedicado. - grawity
@grawity Definitivamente, vale a pena mencionar, mas por que o DKIM não é "possível" sem um revezamento dedicado? Os seletores DKIM não estão vinculados ao aplicativo de envio ou ao endereço IP. Se o seu cliente de e-mail pode assinar a mensagem com uma chave publicada, ela é tão válida quanto qualquer outro signatário. - Mathias R. Jessen
@ManuH: Como por métricas na resposta bem, o correio normal compromete 1/5 do volume de e-mail. De acordo com as métricas meu servidor, o correio normal compromete 1/20 do volume de mensagens. É um excelente negócio. - dotancohen
@manuh: Greylisting funciona fechando a conexão antes do email ser enviado - ele ouve apenas até receber o remetente e o destinatário - que estão no cabeçalho. Além disso, alguns sistemas greylist serão ommediatelly. Aceitar todos os emails de um servidor SMTP que tenha um histórico de entrega de novas tentativas. Infelizmente, é muito eficaz. - davidgo
Poderia acrescentar que em "os bons e velhos dias" o correio era frequentemente enviado de um servidor SMTP para outro, depois outro, depois outro antes de chegar ao seu destino. Isso normalmente funcionava bem, mas, por exemplo, durante o ataque do worm rtm, um dos computadores inativos era um dos e-mails essenciais, portanto, e-mails com avisos, soluções e correções para o worm podiam levar até 48 horas para chegar seus destinatários. - Baard Kopperud


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

Em 1991 - e a maior parte do início dos anos 1990 e até antes - você pode fazer o que descreve. Mas a realidade em 2015 é que, embora seja tecnicamente possível enviar 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, registros SPF e até mesmo DomainKeys que são todos estabelecidos para uma finalidade e um único propósito: garantir que o SMTP que está enviando a mensagem é legítimo. E se não é? Filtrar a mensagem em uma pasta de SPAM ou o "grande abismo" de exclusão. Aqui está um detalhamento do que cada um desses itens é:

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

  • SPF (Sender Policy Framework): Verificação do nível de entrada DNS do nome do host. Um registro SPFcomo explicado aqui- é basicamente um registro DNS definido pelo proprietário do nome de domínio que fornece uma lista de endereços IP e nomes de host dos servidores com permissão para enviar emails para esse nome de domínio. Novamente, 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.9 está enviando e-mails para example.com. Nós já sabemos que smtp.example.com usa 123.456.789.0, mas uma entrada de registro SPF para example.com pode afirmar: “Ei! 123.456.789.9 é um bom servidor! Ele é legal! Respeite seus emails! ”

  • DKIM (DomainKeys Identified Mail): Verificação do nível da mensagem de e-mail. Como explicou aqui e em Wikipedia, “O DKIM é um sistema de validação de email projetado para detectar falsificação de email fornecendo um mecanismo para permitir que os remetentes de email verifiquem se o email recebido de um domínio está autorizado pelos administradores desse domínio e se o email (incluindo anexos) não foi modificado durante o transporte . ”Usando hashes criptográficos, o DKIM verifica se o e-mail em si não foi filtrado ou adulterado durante o trânsito. Isso também serve como mais um ponto de verificação na cadeia “Você é legítimo ou você é SPAM?”.

Assim, no final, um servidor SMTP voltado para o público que valha alguma 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, pois os SPAMmers se tornam mais persistentes em seus esforços para enviar SPAM.


32





A maioria dos ISPs residenciais bloqueia a porta TCP 25 (SMTP) para impedir que você participe de uma rede de spam. Se o seu PC for infectado, o seu PC pode começar a vomitar spam a mando de outra pessoa.


15



Você escreve "A maioria dos ISPs residenciais bloqueia a porta TCP 25 (SMTP)" <- você poderia elaborar o que isso significa. Você quer dizer que eles não vão deixar você fazer uma conexão de saída para um servidor SMTP na porta 25? Ou você quer dizer que eles não vão deixar você receber uma conexão na porta 25? - barlop
@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 pouco exagerado dizer que a maioria dos ISPs faz isso. - hobbs
@hobbs - Minha experiência (e é uma boa parte do meu trabalho) é diferente. Embora muitos ISPs bloqueiem o tráfego deixando sua rede com um alvo da porta 25 (o que força o tráfego da porta 25 através de seus servidores de email), o mesmo geralmente não é verdadeiro para a porta 587 ou 465 - e isso faz sentido. As portas 587 e 465 geralmente requerem autenticação e bloqueio e são especificamente MUA para MTA, em vez de MTA-MTA. O bloqueio dessas portas geraria enorme repercussão, já que muitas empresas precisam disso para permitir roaming, responsabilização e não quebra de SPF. - davidgo
@hobbs, nunca escrevi que a maioria dos ISPs faz isso; o que eu escrevi é que a maioria ISPs residenciais faça isso. Por exemplo, a AT & T, a Comcast, a TWC, a Verizon, etc. fazem isso para seus clientes residenciais, mas não fazem isso para seus clientes corporativos. - Ron Maupin


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

Mas, na verdade, existe uma resposta mais simples e genérica: os recursos. Enviar e-mail através do SMTP é, na verdade, uma tarefa muito complexa. Mesmo sem spam, você não desejaria 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 maiores no mundo * nix, Exchange no mundo Windows).

Por exemplo, mesmo no mais básico, um servidor SMTP "real" precisa pelo menos resolver os registros MX. Em seguida, ele precisa negociar recursos (principalmente o TLS, mas também há outros recursos). Tem que 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 inclui coisas como reescrita de endereço, mailertables. Sem mencionar a dúzia de outros protocolos que o sendmail et al suportam, como o UUCP.

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

Relacionado, mas um problema separado: o email é um tópico muito sensível à segurança, e você gostaria de ter um ou alguns poucos servidores gerenciados centralmente, em vez de potencialmente centenas ou milhares de usuários individuais em cada desktop.


6



Este é um bom ponto. Não é apenas sobre os recursos reais para filas e assim por diante: o disponibilidade do servidor faz uma diferença em alguns desses recursos. Se houver um problema e você desligar seu laptop, ele não poderá tentar novamente até que seja ligado - o servidor de e-mail provavelmente estará disponível 24 horas por dia, 7 dias por semana, de modo que ele estará em uma posição muito melhor para gerenciar uma fila de mensagens. Depois de enviar sua mensagem ao servidor por SMTP, seu cliente de e-mail não precisa ficar on-line para garantir a entrega. - David Spillett


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

Você poderia criar um programa de e-mail que fizesse isso, e não tenho dúvidas de que outros já fizeram (ou tentaram) isso antes.

Você essencialmente estaria escrevendo uma ferramenta que é tanto 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 "lado do servidor", é que um MTA que envia e-mails pela Internet aberta é consideravelmente mais complexo para escrever e configurar, e também que se beneficia de residir em um servidor confiável "sempre ligado".

Um MTA tem que:

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

  • Lidar com servidores que estão inativos e rotear para servidores alternativos ou enfileirar o correio para posterior nova tentativa. Isso funciona melhor em um processo de 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 mensagens enfileiradas.

  • Lidar com uma gama de diferentes capacidades de servidor, ajustando o comportamento de acordo com as capacidades do servidor de recebimento.

  • Reporte ao usuário sobre condições de erro ou quando o correio não é 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, sempre conectado, com um endereço IP estável e uma entrada de DNS reverso, ou seja, uma conexão com a Internet adequada para servidores voltados para o público. Isso ajuda outros sistemas a não detectar emails enviados como spam.

Dadas essas exigências, faz sentido abrigar o servidor SMTP em um servidor sempre ativo voltado para o público em algum lugar e tentar usar uma ferramenta adequada para executar esse trabalho específico.


4





Outra coisa a considerar é recebendo e-mail retornado. No mínimo, todo o email de saída tem um endereço FROM, onde uma resposta pode ser enviada (usuário desconhecido, resposta de férias, etc). Para que o endereço de retorno seja resolvido, deve existir um registro MX que aponte para o local de retorno da caixa de entrada. A menos que você esteja enviando e-mail de um computador com um endereço IP estático que esteja sempre ativado, você precisará de um servidor para lidar com essas mensagens de entrada. Isso é normalmente (mas nem sempre) tratado pelo mesmo serviço.

GMail, Outlook 365 e Yahoo Mail são exemplos de serviços de e-mail usados ​​por indivíduos que estão enviando e-mails. Para o envio de e-mail comercial, existem serviços como MailChimp, Marketo e Eloqua, que são muito bons em enviar e-mails em massa para uma empresa e lidar com coisas como rejeições, afogamentos e entregabilidade.

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


1



Eu não entendo porque eu preciso de um IP estático para obter a minha resposta ... A resposta deve ser entregue para o meu servidor MX (ex. Gmail) não para o meu computador. Estou certo? - Tobia
Sim você está correto. Eu acho que meu ponto é que uma caixa de entrada geralmente existe em um servidor em algum lugar para envio de e-mail de saída. Logicamente, faz sentido que o servidor também lide com os emails enviados. Caso contrário, você perderia coisas como ter uma pasta de e-mail "enviada". - dana
Mmh é razoável. Mas estou livre para enviar uma mensagem com o Gmail com um endereço desconhecido "de" ou "responder a" desmarcando seu servidor SMTP ... - Tobia
Se você usa o GMail, você tem que usar a autenticação SMTP. Assim, o endereço DE é definido para o seu endereço @ gmail.com. Caso contrário, você poderá usar o serviço deles para falsificação. - dana
Atualmente, muitos usuários não se importam com os saltos, MAS uma configuração que não aceita rejeições é geralmente considerada uma provável fonte de spam. - rackandboneman