Por que os clientes de email não usam diretamente o servidor SMTP do destinatário

Question

Normalmente, em um cliente de e-mail, é necessário configurar um servidor SMTP para enviar e-mails. Quando você envia um email, seu servidor SMTP configurado simplesmente resolve o domínio após o @at no endereço de email do destinatário com uma solicitação de DNS do tipo MX. O DNS responderá com o endereço do servidor SMTP do servidor de e-mail do destinatário, e seu servidor SMTP encaminhará suas mensagens para ele.

Minha pergunta é: por que isso não é feito diretamente pelo cliente de email? Não é nada de especial: é apenas uma requisição de DNS mx e o protocolo que lida diretamente com o mail exchanger do provedor do destinatário é o SMTP de ala.

Se assim fosse, o e-mail poderia ir diretamente para o servidor certo: deveria ser mais rápido e evitar tráfego inútil.

Talvez isso se deva ao fato de talvez o servidor SMTP do destinatário estar inativo por algum motivo ou estar muito ocupado para processar o e-mail quando você o envia e, portanto, a vantagem de usar nosso servidor SMTP pessoal é que toma cuidado para tentar novamente enviar a correspondência em intervalos regulares?

Esta é a única razão pela qual vejo: na verdade, não seria tão prático se isso fosse responsabilidade do cliente de e-mail, já que talvez o usuário o feche ou desligue o computador.

Se este é o único motivo: acontece com tanta frequência que um servidor SMTP não consegue processar um email imediatamente?

    

Answer 1

Um possível motivo é que o remetente pode simplesmente não conseguir acessar diretamente o servidor de e-mails do destinatário.

Nos primeiros dias do e-mail & SMTP, você tinha mais do que apenas Internet - você tinha Bitnet; UUCPnet / Usenet; Berknet; MILNET; DECnet; etc. todos usando protocolos incompatíveis. Um domínio como sri-unix.uucp pode não ter um endereço IP no DNS - apenas um registro MX apontando para um gateway (um servidor SMTP que também tinha links UUCP).

Hoje em dia, uma situação semelhante ocorre com as comunicações entre os hosts somente IPv4 e somente IPv6 (embora estes últimos sejam um pouco raros).

Além disso, as redes não eram exatamente confiáveis (e ainda não são) - você não iria querer olhar para um "servidor de e-mail do destinatário inacessível, por favor aguarde" por meia hora , quando você poderia simplesmente enviar a mensagem para um sendmail executando 24/7 no mesmo computador em que você estava escrevendo a mensagem, e continuar com o trabalho.

Bônus: alguns endereços "From:" muito estranhos que vi no OldUse.Net:

• UCBVAX.@[email protected]@RAND-RELAY

• farber%udel-eecis1.udeecis@[email protected]

• notes@CSvax:Pucc-H:pur-phy.UUCP

• utzoo!linus!security!genrad!decvax!harpo!floyd!whuxlb!pyuxll!abnjh!u1100a!pyuxn!pyuxi!mhuxm!mhuxd!mhuxa!houxm!hocda!spanky!burl!akgua!emory!sb6!sb1!ll1!otuxa!we13!ihnp4!ixn5c!inuxc!pur-ee!uiucdcs!mcewan

Answer 2

drk.com.ar nos comentários tem razão.

Se você tem um IP estático do seu ISP, você pode hospedar seu próprio SMTP localmente, da maneira que quiser e ter esse e-mail de processo, tudo bem. Então, se você abusar dele, o spamhause e o co te colocarão uma lista negra e você será totalmente ignorado.

Com IPs dinâmicos, isso não funciona, eles não podem bloquear seu IP, já que você pode alterá-lo dentro de 60 segundos ou mais. Portanto, neste caso, seu ISP tem a responsabilidade de filtrar seus e-mails enviados. Você encaminha todos os e-mails para o servidor SMTP que os encaminha e, se começar a abusar deles, os registros de aluguel saberão exatamente de quem vieram e poderão reagir de acordo.

Curiosamente, tivemos um problema com isso há alguns meses, quando o Cello da empresa-mãe de ISPs não gerenciava seu servidor SMTP corretamente e alguns dos clusters foram bloqueados como spammers, levando a spamblocks intermitentes na extremidade receptora.

Espero que isso ajude.

    

Answer 3

If this is the only reason: does it happen so often that an SMTP server is unable to process an email immediately?

Isso acontece, especialmente quando o servidor SMTP é mantido por uma organização pequena.

Mas além de ser realmente incapaz de processar o e-mail recebido, às vezes pode, mas não quer. Dois exemplos que vêm à mente:

1. Os servidores que usam Gray Listing rejeitam as primeiras tentativas de remetentes desconhecidos com erros 4xx de forma sistemática , de propósito, como uma técnica contra spammers.

2. Alguns provedores de e-mail usam o afogamento contra seus próprios clientes, respondendo com erros 4xx quando muitos e-mails são enviados por unidade de tempo a partir do mesmo endereço IP ou conta. Isso pode impedir que o cliente faça spam, seja intencionalmente (pequenas empresas enviando seu boletim informativo) ou não (como vítima de uma infecção). Recentemente, eu vi o GMail fazendo isso por nem cem mensagens por dia e de uma conta de pagamento, a mensagem SMTP sendo ... o e-mail enviado do seu endereço IP foi temporariamente limitado à taxa ...

Há também o caso de uma falha de DNS transiente para o MX alvo.

É mais prático ter um primeiro salto SMTP para lidar com tudo isso, em vez de deixá-lo para o cliente de e-mail.

    

Answer 4

O servidor real pode estar inativo. Então você precisa do seu servidor para tentar novamente.

É por isso que às vezes você recebe "Este e-mail não chegou ao destinatário. Repetirá em breve. Não há nada que você precise fazer sobre isso."

E, eventualmente, você recebe "Não alcançou o destinatário. Essa falha é permanente".