- Navios
- 5 de agosto de 2026 às 17:10 UTC
- Autor
- Kamo
- Enviar
- b922a98
Uma resposta rápida a uma notificação KamoCRM falhou com `{"error":"Endereços Inválidos"}` verbatim na caixa de resposta. Essa string é o texto de Jakarta Mail de SMTPTransport.rcpt Para; o log do pod mostra o que ele estava escondendo: 550 5.1.1 <NoReply@KamoCRM.com>: Endereço do destinatário rejeitado: Usuário desconhecido na tabela de correio virtual Dois defeitos atrás dele. Respostas foram dirigidas para De incondicionalmente, e nada no caminho lido mesmo carreg Reply-To — assim respondendo a qualquer coisa enviada do NoReply@{org.domain} não encaminhado que NoReplySenderService coloca em cada e-mail transacional foi para uma caixa de correio que não existe. Os envios da campanha foram atingidos da mesma forma, apesar de definir um Reply-To real cabeçalho (CampaignMessageComposer). EmailMessage agora carrega respostaPara, leia do ENVELOPE a listagem já busca assim que uma lista de correio custa nenhum extra ida e volta. Ele colapsa para nulo quando apenas coincide De, porque RFC 3501 §7.4.2 requer um servidor para espelhar De dentro da resposta do envelope até quando o cabeçalho está ausente — um o valor igual não contém qualquer informação. E ambos os terminais de envio responderam falhas com `{"error": e.getMessage()}`, que é como uma exceção Java serializada atingiu a tela de um usuário. SendFailureResponse maps a rejeição a um 422 nomeando os endereços recusados e a razão do próprio servidor receptor — caminha próximoExcepção, onde Jakarta Mail mantém o detalhe SMTP, em vez de causa corrente. Endereços que simplesmente nunca foram tentados são relatados ao lado do rejeitado: a transação aborta como um todo, então eles não receberam a mensagem Nem um nem outro. Também corrige NoReplySenderServiceTest, que ainda afirmava que d1e7191 deliberadamente substituído por preservação de casos, e desde então tinha falhado no main.