Os MTAs sempre enfileiram e-mails quando não conseguem se conectar ao servidor MX de destino?

Question

No nosso (pequeno) escritório, estamos decidindo se o nosso registro MX deve apontar para o nosso servidor Exchange local. Eu estava um pouco preocupado com o tempo de inatividade, então pensei que eu deveria configurar um servidor MX de backup. Em seguida, pesquisei um pouco e encontrei um casal de posts que sugeriu que não valeria necessariamente o esforço , principalmente porque o MTA remetente irá enfileirar os e-mails por alguns dias antes de desistir, o que deve ser um tempo mais que suficiente para colocar seus assuntos em ordem.

Eu estava muito feliz por isso, mas nosso provedor de TI local, que está comprando nosso novo servidor, insiste que os servidores nem sempre enfileiram os e-mails: às vezes, eles simplesmente pulam de imediato. Alguém pode comentar sobre esta posição?

Além disso, estou tentando encontrar o que a norma diz sobre o assunto (embora esteja ciente de que a vida real e os padrões nem sempre estão alinhados). O artigo da Wikipédia sobre os registros MX de backup diz

The SMTP protocol establishes a store-and-forward network, and if a domain's mail servers are all offline, sending servers are required to queue messages destined for that domain to retry later.

Olhando para RFC 821 não consigo encontrar essa parte, mas estou apenas digitalizando. Alguém poderia apontar a parte relevante se ela existir? Eu também estaria interessado em qualquer parte que lide com quanto tempo as mensagens devem ser guardadas antes de serem descartadas.

    

Answer 1

O provedor de TI está certo, alguns se recuperam imediatamente. No entanto, na minha experiência, são apenas burros-anfitriões que saltam imediatamente, os hosts inteligentes fazem fila. Existem alguns padrões de fato disponíveis por quanto tempo um MTA enfileirará o email antes de criar um DSN, com 4 horas sendo o mais comum. Como com todo esse padrão, há muita variabilidade.

Os tipos de e-mails que tendem a ser enviados por meio de hosts estúpidos são os e-mails vindos diretamente de aplicativos da web que contam com um servidor inteligente o suficiente para lidar com exceções. Estes podem ser seus próprios aplicativos para mala-mails em massa por aí na web. Essas mensagens são geralmente de uma classe inferior de e-mail, mas nem sempre.

Se você decidir ir com um MTA de backup, você PRECISARÁ colocar anti-spam nele. Os spammers sabem há mais de uma década que os MTAs de 'backup' são um ótimo local para segmentar, já que geralmente não são tão bem protegidos quanto o primário.

    

Answer 2

Eu não acho que seja necessário, mas é uma boa prática.

Valores bastante padrão para filas e tentativas são "primeiro tentar novamente após 30 minutos, depois a cada 60 minutos até 12 horas, depois disso, a cada seis horas até 72 horas, depois disso, mais algumas tentativas em 12- Se o correio não puder ser entregue em 7 dias, devolva o e-mail e (opcionalmente, nestes dias, já que muitos remetentes falsificados) retornam um "Desculpe, não foi possível entregar".

Isto é, na verdade, principalmente a partir da experiência e um pouco datado, já que eu não tenho um servidor de e-mail para fins de trabalho há cerca de 4 anos.

    

Answer 3

Servidores de correio DEVEM enfileirar, mas nem todos os servidores de correio se comportam bem. Mas como há tantas outras coisas que podem dar errado com o e-mail, a maioria das empresas muito pequenas que eu conheço não se incomoda com um backup, pois não parece ser eficiente em termos de custo.

Se você quiser fazer isso, verifique se o seu provedor de serviços de Internet agirá como uma loja e retransmitirá o servidor de email de backup, o que significa que aceitará o email em seu nome e o enviará aos seus servidores quando ele for acessível. (Não ajuda se o servidor e os servidores de backup ficarem off-line).

Por nossa própria experiência, nosso ISP oferece este serviço, mas é um custo extra que decidimos não aceitar. (Isso não causou nenhum problema em mais de dez anos e, como nossa base de clientes é muito pequena e não técnica, tenho certeza de que eles levantariam o telefone se tivessem problemas para enviar e-mail para nós).