É uma boa ideia reduzir o tempo de desistência da entrega de e-mail?

4

Nós executamos um servidor de e-mail para alguns clientes e recentemente nos deparamos com um problema.

Tivemos um usuário que enviou um e-mail para um endereço de e-mail incorreto. O domínio especificado incorretamente infelizmente existia. Não tinha registros MX e o registro A do domínio foi para um servidor que não falava SMTP. Portanto, o servidor de email tentou entrega e não teve êxito porque nenhum servidor de email estava em execução.

Por esse motivo, nosso servidor de e-mail, totalmente de acordo com o SMTP RFC, tentou reenviar ao longo de cinco dias e finalmente desistiu e enviou um aviso ao remetente após 5 dias de entrega malsucedida. / p>

Seção 4.5.4.1 do RFC5321 (Simple Mail Transfer Protocol) diz:

Retries continue until the message is transmitted or the sender gives up; the give-up time generally needs to be at least 4-5 days.

Portanto, o servidor de email em sua configuração padrão, neste caso, operou de acordo com o RFC, o que significa que um usuário especificando o endereço de email errado neste caso não receberia aviso disso, exceto cinco dias depois. / p>

Neste ponto, meu chefe perguntou se seria possível reduzir o tempo de desistência para algo mais curto, digamos, um dia. Seu raciocínio é que é melhor que o usuário seja notificado antes da não entrega e que o usuário possa tentar a nova entrega em uma data posterior, ou a entrega por meio de um canal alternativo. Parece uma coisa razoável de se fazer, mas em geral tenho receio de realizar qualquer tipo de alteração de configuração que contradiga o que está no RFC.

Existe alguma razão não óbvia para que seja uma má ideia reduzir o tempo de desistência para 24 horas, além de apenas dizer "a RFC diz o contrário"?

Além disso, o que os maiores provedores de e-mail por aí (Googles, Microsoft, AOLs e Yahoos) fazem nesse cenário?

    
por Per von Zweigbergk 10.11.2015 / 16:09

3 respostas

7

Por que você não deveria desistir de entregar e-mails depois de um dia? Uma boa razão é fins de semana .

O e-mail não é agora, e nunca foi, particularmente confiável . Nos primeiros dias da Internet, na década de 1980, era inteiramente possível que o email demorasse alguns dias apenas para chegar ao destino, com alguns links de rede não sendo 24x7, em vez de chamadas telefônicas discadas de longa distância (na época, > custo por minuto para chamar duas cidades de distância, esqueça o custo de uma ligação de Sydney para Los Angeles), ou até mesmo por rádio amador. Como resultado, pode demorar um pouco para entregar e-mail, e os protocolos tiveram que lidar com conexões não confiáveis e de meio período. Eles fazem isso muito bem, mas, mesmo assim, o correio pode ser atrasado ou perdido.

Certamente, hoje, o email tem uma ilusão de confiabilidade, mesmo porque os transportes subjacentes são mais confiáveis, e muitas pessoas desinformadas (como a maioria de nossos usuários) têm uma expectativa de serem confiáveis, mas essa expectativa não corresponde à realidade. Sem uma mudança significativa nos protocolos de entrega de e-mails, o que provavelmente nunca acontecerá, o e-mail, como qualquer coisa construída por humanos, sempre será menos de 100% perfeito.

Às vezes, nós sysadmins aproveitamos isso.

Por exemplo, em um escritório onde todos estão lá apenas de segunda a sexta-feira, posso ter uma interrupção de e-mail que dura todo o final de semana, se necessário. Claro, praticamente nunca é necessário ficar fora por muito tempo, mas eu tive que ter e-mail por mais de 24 horas em casos raros.

Nesse caso, se você desistir após 24 horas, o e-mail enviado na tarde de sexta-feira pode não chegar ao destinatário. O remetente não descobrirá até a manhã de segunda-feira, mas se você tivesse continuado tentando, o destinatário o teria na manhã de segunda-feira.

Além disso, é muito importante definir as expectativas do usuário adequadamente. O fato de que o email da Internet não é e nunca será 100% confiável precisa ser claramente entendido, mesmo quando gostamos de pensar que é.

O RFC diz que você deve continuar tentando, precisamente porque as coisas dão errado, e a intenção é que o e-mail seja entregue eventualmente, mas em algum momento você terá que desistir. Pode ser aceitável reduzir isso para três dias. Eu sempre pensei que cinco dias fosse muito longo para esperar pela entrega da maioria das mensagens em uma Internet 24x7.

Quanto ao seu servidor de e-mail:

O postfix pode notificar os remetentes quando uma mensagem de e-mail é atrasada, mas esse recurso é desativado por padrão. Esse aviso deve ser suficiente para permitir que seus usuários saibam que algo pode ter dado errado, como um endereço de e-mail incorretamente digitado, e chegará muito antes das 24 horas que seu chefe propôs.

Para ativá-lo, defina delayed_warning_time para o valor desejado em main.cf .

delayed_warning_time=4h

A partir da versão 3.0, o Postfix pode também notificar os mesmos remetentes quando as mensagens atrasadas são finalmente entregues. Isso também é desativado por padrão, pois pode resultar em muitas notificações. Mas se você quiser isso, ative confirm_delay_cleared em main.cf .

confirm_delay_cleared=yes
    
por 15.11.2015 / 12:56
1

Vou tomar o outro lado disso do que a maioria das respostas aqui.

O ISP para o qual eu trabalho serve cerca de 3.000 clientes e usa o Qmail como nosso MTA para as caixas de correio desses clientes.

Executamos nosso sistema com uma vida útil de 2 dias em fila por quase dois anos, e não recebemos reclamações nem tivemos problemas com a entrega de e-mails. Ele diminuiu o tamanho da fila, o que tornou muito mais fácil identificar as contas comprometidas (raras, mas ocorrem) e limpá-las.

A vida útil da fila ao longo de um dia é apenas a administração do sistema Cargo Cult e um resquício de quando a Internet estava muito menos "sempre ativa". Os bons administradores seguem as "melhores práticas", mas os melhores compreendem por que foi a melhor prática e mudam a "melhor prática" para uma melhor prática quando a situação difere daquela em que a "melhor prática" anterior foi desenvolvida.

    
por 15.01.2017 / 02:47
0

Eu não recomendo mudar o tempo de desistir. Digamos que o escritório do destinatário (com o e-mail no local) foi eliminado por um tornado | terremoto | fogo \ no fim de semana. Se a empresa usa backups em fita externos para o plano de DR, é melhor acreditar que levará mais de 24 horas para passar do tornado para aceitar o e-mail novamente. 5 dias seriam muito longos neste cenário, mas essa não é a raiz do problema.

Quer sejam 5 dias, 48 horas ou 24 horas, todos esses períodos de tempo são muito longos para serem alertados para o email não enviado, e todos eles são muito curtos para acomodar todos os possíveis motivos de falha do servidor. Se não estiver usando o sendmail, talvez dê uma olhada no sendmail, como MadHatter sugeriu. No mínimo, você deve configurar alguns alertas para si mesmo (e / ou outros) se houver algo na fila por mais de algumas horas.

    
por 15.11.2015 / 12:43