Pergunta

Ao criar um usuário para o meu aplicativo da Web, um email SMTP (usando o SMTPClient do ASP.NET) é enviado ao usuário com a senha gerada automaticamente.Porém, às vezes o que percebo é que o tempo expira e o novo usuário simplesmente não recebe o e-mail com a senha.

Tudo bem, exibirei uma mensagem indicando que o e-mail não foi enviado, mas o usuário foi criado.

Portanto, o administrador do sistema tem 2 opções até agora:

  1. Redefina a senha do usuário e espere que outro e-mail SMTP seja enviado com a senha gerada automaticamente.
  2. Exclua e recrie o usuário.

Eu poderia reverter a criação do usuário se o smtp não fosse enviado, mas qual é a melhor prática para resolver esse problema?

Estou pensando em tentar enviar o e-mail novamente 3 vezes com um tempo limite de 5 segundos cada.Portanto, 15 segundos seria o pior cenário.

É este o caminho a percorrer?

Foi útil?

Solução

Bem, dependendo da sua plataforma, se você puder simplesmente entregar seu e-mail para um MTA local, ele deverá lidar com as novas tentativas e coisas assim.Seu programa pode simplesmente colocar o e-mail na fila e seguir em frente, sem se preocupar em lidar com tempos limite e listas cinza, etc.

Se a mensagem ainda não puder ser entregue, você pode tentar reenviá-la (por meio de um recurso de redefinição de senha).Se isso também falhar, provavelmente houve um erro no endereço de e-mail e eu sugeriria excluir a conta, fazendo com que o usuário se registrasse novamente.

É claro que isso pode não ser possível em alguns sistemas, dependendo do que pode ser feito com um usuário não confirmado - isso realmente depende do que você permite que as pessoas façam antes que seus e-mails sejam validados.

Outras dicas

Parece que seu aplicativo da web está falando SMTP diretamente com o servidor de e-mail do usuário.Seu aplicativo da web é um MUA (agente do usuário do Mail) conversando com o MTA do usuário (agente de transferência de correio).] Nada diz que o MTA do usuário deve estar acessível ou trabalhar no momento.Você precisa executar seu próprio MTA para garantir que alguém esteja fornecendo enfileiramento, novas tentativas, etc.

Se você realmente quiser retroceder, poderá fazer o que está fazendo (apenas uma tentativa), voltar a colocar a mensagem na fila e continuar a tentar novamente em uma programação mais lenta por pelo menos 24 horas e expor esse estado inacabado ao do utilizador.

A resposta oficial sobre como seu aplicativo deve se comportar pode ser encontrada em RFC1123 (Requisitos para Hosts de Internet – Aplicação e Suporte):

5.3.1.1 Estratégia de Envio

O modelo geral de um remetente-SMTP é um ou mais processos que tentam periodicamente transmitir emails de saída.Em um sistema típico, o programa que compõe uma mensagem possui algum método para solicitar atenção imediata para uma nova peça de emails, enquanto o email que não pode ser transmitido imediatamente deve ser filmado e realizado periodicamente pelo remetente.Uma entrada na fila de correio incluirá não apenas a mensagem em si, mas também as informações do envelope.

O remetente deve atrasar a tentativa de um destino específico após a falha de uma tentativa.Em geral, o intervalo de tentativa deve ser de pelo menos 30 minutos;No entanto, estratégias mais sofisticadas e variáveis ​​serão benéficas quando o remetente-SMTP puder determinar o motivo da não entrega.

As tentativas continuam até que a mensagem seja transmitida ou o remetente desista;O tempo de desistência geralmente precisa ser de pelo menos 4-5 dias.Os parâmetros do algoritmo de tentativa devem ser configuráveis.

Se você estiver usando ASP.NET e as classes System.Net.Mail, provavelmente estará enviando o e-mail por meio da instância do IIS na máquina do servidor web (não tenho certeza, pois você não especificou).Não há uma boa maneira de saber o que está acontecendo com o seu agente de transferência de correio (IIS SMTP).Ele possui sua própria lógica de repetição e, por padrão, pode levar muito tempo para que a mensagem seja entregue.

Como você está detectando que a correspondência não foi entregue?De onde vem o "tempo limite"?

Você deve ter um processo em segundo plano que lide com o envio de mensagens.Se a entrega ao MTA for bem-sucedida, você deverá presumir que está tudo bem.A menos que você esteja na lista negra de SPAM, a maioria dos MTAs continuará tentando até conseguir.Se você realmente receber um erro ao enviar a mensagem com seu MTA, tente novamente ou descubra o que está causando a falha e corrija o bug.Honestamente, esta parte nunca deve falhar.

Você pode querer monitorar o endereço de retorno das mensagens NDR para poder tomar algum tipo de ação quando tiver certeza de quando o e-mail não foi entregue.Mas se o usuário ainda não consegue fazer login no sistema, não há uma boa maneira de informá-lo sobre o que aconteceu.Talvez você possa definir um cookie com um valor associado ao e-mail e colocar algo na página de login/registro se não conseguir entregar o e-mail.

IMHO você deve notificar o usuário, solicitando que ele verifique o e-mail, sem novas tentativas.

Se o usuário não verificar o e-mail e sair da página, é melhor reverter a conta, pois o usuário não poderá acessá-la de qualquer maneira.

A maioria dos casos de tempo limite seria causada por contas de e-mail inválidas.Os usuários cometeram um erro ou forneceram um endereço de e-mail inexistente para evitar spam.

Se possível, não peça os e-mails dos seus usuários.A regra número um de programação deve ser:NÃO incomode o usuário.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top