Por que preciso de um servidor SMTP?

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 [email protected]minha conta do Gmail, eu o envio ao smtp.gmail.comservidor; e esse servidor enviará minha mensagem ao servidor MX de example.com.

É 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.

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.

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.

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.

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.

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