Avisos importantes ficaram presos na fila de e-mails

Desta vez o cron estava ativo e as tarefas eram executadas, mesmo assim nenhum aviso chegava aos destinatários, o que mostrou que a fila andava até o momento de conversar com o servidor de e mail e falhava somente na entrega.

Antes de alterar qualquer configuração, conferimos se o endereço usado estava correto, se a conta permanecia ativa, qual método de autenticação estava atribuído, quando havia ocorrido o último acesso bem sucedido e se a falha atingia apenas aquele usuário ou todos que dependiam do mesmo serviço, porque redefinir a senha novamente poderia apenas esconder por alguns minutos uma inconsistência de LDAP, SSO, certificado ou cadastro.

Com esse primeiro recorte pronto, reproduzimos o login em uma sessão limpa e acompanhamos os registros gerados desde o envio do formulário até a resposta do provedor de identidade, comparando a conta afetada com outra do mesmo perfil que ainda conseguia entrar e verificando horário, origem, retorno recebido e mudanças recentes na configuração.

Só então as evidências começaram a apontar para a mesma direção, pois o resumo inicial de que o cron funcionava, porém uma falha de autenticação no servidor SMTP impedia a entrega das mensagens. passou a coincidir com uma diferença concreta encontrada no caminho da autenticação, então a correção foi testada primeiro de forma controlada e depois repetida com perfis distintos para garantir que o acesso havia voltado sem abrir permissões além do necessário.

Fizemos um envio controlado e encontramos a recusa de autenticação no SMTP, a credencial foi corrigida e as mensagens pendentes foram liberadas aos poucos para evitar bloqueio por volume, enquanto novos avisos eram acompanhados até aparecerem nas caixas de entrada.