Pagina inicial » como » Por que um Servidor SMTP Intermediário é Necessário para Enviar Correio?

    Por que um Servidor SMTP Intermediário é Necessário para Enviar Correio?

    Como uma pessoa aprende mais sobre como os clientes de e-mail, os servidores SMTP e todo o sistema de e-mail on-line funciona, eles podem estar curiosos para saber por que um servidor SMTP intermediário é necessário. Com isso em mente, o post de perguntas e respostas do SuperUser de hoje tem as respostas para as perguntas de um curioso leitor.

    A sessão de perguntas e respostas de hoje nos é oferecida por cortesia do SuperUser - uma subdivisão do Stack Exchange, um agrupamento de sites de perguntas e respostas conduzido pela comunidade..

    Foto cedida por David Schroeder (Flickr).

    A questão

    Leitor de superusuário Tobia quer saber por que um servidor SMTP intermediário é necessário para enviar mensagens:

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

    Por exemplo, se eu tiver que enviar e-mail para [email protected] com minha conta do Gmail, eu a envio para o smtp.gmail.com servidor; então este servidor envia minha mensagem para o servidor MX de example.com.

    Por que um servidor SMTP intermediário é necessário para enviar mensagens?

    A resposta

    O colaborador do SuperUser davidgo tem a resposta para nós:

    É tecnicamente possível enviar mensagens 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, portanto, você tem um servidor SMTP. Da mesma forma, antigamente, nem todos os servidores de e-mail estavam conectados o tempo todo (os links de longa distância eram caros), portanto, os e-mails seriam enfileirados e enviados quando um link fosse estabelecido.

    Passando para onde os serviços da Internet são baratos, ainda é útil ter mecanismos para repetir o envio de mensagens se um servidor não estiver disponível. Não é ideal que esta 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 pior - spammers. A maioria dos e-mails (mais de 80%) é spam. Os provedores de correio fazem o que podem para reduzir esse problema e um grande número de técnicas faz suposições sobre o modo como o correio é entregue. A seguir, considerações 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 esperar que eles tentem uma segunda vez. Frequentemente, os spammers não tentam novamente enquanto um servidor SMTP deve sempre fazer isso. Isso reduz o volume de spam em cerca de 80%, mas é uma droga ter que fazer isso.

    2. Reputação: É muito mais provável que alguém enviando mensagens por meio de um servidor SMTP conhecido e confiável seja legítimo se comparado a um servidor fly-by-night. Para sentir a reputação, os provedores fazem várias coisas:

    • Bloquear endereços dinâmicos / clientes (não 100%, mas grandes blocos da Internet foram mapeados).
    • Verifique se o DNS reverso corresponde ao DNS encaminhado. Não é muito difícil de fazer, mas mostra algum nível de responsabilidade e conhecimento das melhores práticas (algo que muitos blocos de endereços de clientes não têm).
    • Verifique a reputação. Ao se comunicar com outros servidores SMTP, muitos provedores controlam a quantidade de spam e volume de mensagens enviadas. Eles podem reduzir a quantidade de spam limitando as conexões e observando esses parâmetros. Há muitas maneiras de fazer isso, nem todas óbvias, mas que exigem um remetente conhecido..
    • SPF e DKIM. Esses mecanismos vinculam os recursos DNS ao nome de domínio para dificultar o trabalho de falsificação de mensagens e seria difícil, mas não necessariamente impossível de implantar, se o programa de email (MUA) for responsável pelo email de saída.

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


    Tem algo a acrescentar à explicação? Som desligado nos comentários. Quer ler mais respostas de outros usuários do Stack Exchange com experiência em tecnologia? Confira o tópico de discussão completo aqui.