Parece haver muitos casos estranhos em que e-mails que não deveriam ser rejeitados acabam sendo rejeitados mesmo assim. Isso significa que, às vezes, os usuários enviam e-mails de suporte que nunca recebemos.
Por exemplo, e-mails enviados para nosso endereço de suporte a partir de endereços mac.com são frequentemente rejeitados por não terem corpo (Email::Receiver::NoBodyDetectedError). Esses e-mails, na verdade, costumam ter texto no corpo, então pode haver um problema de análise.
Mas, além de corrigir o que está causando essas rejeições indevidas, ficaria feliz se pudéssemos receber alertas sempre que houver novas rejeições, para que pudéssemos analisá-las e verificar se a rejeição foi adequada.
Isso poderia ser feito por meio de uma opção para enviar alertas à equipe sobre todas as rejeições, ou de uma opção para simplesmente colocar em cópia (CC) todos os e-mails de rejeição para a equipe.
Caso contrário, se não quisermos perder nenhum e-mail de suporte recebido, teríamos que consultar continuamente a lista de e-mails rejeitados no back-end do Discourse. Isso é tedioso e desnecessário.
Acho que é melhor focar no exemplo específico. Você disse que são “frequentemente” rejeitados; você notou algum padrão aqui no conteúdo do e-mail? Se fosse um problema constante, eu esperaria que todos os e-mails de mac.com falhassem.
Bem… ‘frequentemente’ no sentido de ‘frequentemente o suficiente para ser meio chato’. Nossa principal preocupação é não queremos que as pessoas fiquem irritadas com uma suposta falta de resposta da nossa equipe de suporte.
Procurei padrões nos casos que observei. Originalmente, achei que pudesse haver um problema na forma como o mac.com lidava com e-mails, mas desde então determinei que temos cerca de 30 usuários com endereços mac.com que não apresentam nenhum problema.
Também pensei que, se o mac.com tivesse um cliente de webmail, ele poderia estar lidando com e-mails HTML de forma não padrão. Mas nem tenho certeza se existe um cliente de webmail do mac.com.
Achei que tinha resolvido o problema quando percebi que o incidente mais recente envolvia e-mails que continham apenas linhas citadas no corpo, mas testes subsequentes mostraram que o Discourse processa esses e-mails sem problemas.
Vou revisar os logs para ver com que frequência esse tipo de coisa aconteceu e, claro, procurar por padrões. Estava apenas pensando que, enquanto existir a possibilidade de o Discourse ocasionalmente cometer erros como esse, um e-mail de alerta parece uma medida de segurança simples o suficiente.
Vou publicar aqui os resultados da minha investigação.
Os endereços de e-mail do Mac.com são, na verdade, contas do iCloud.com. A Apple migrou as contas do Mac.com e do me.com para o iCloud há cinco ou seis anos.
Não há um padrão real. Existem 21 casos em que o motivo da rejeição não está muito claro ou parece estar errado.
1 x “Email não pode ser processado: O corpo é muito semelhante ao que você postou recentemente”
8 x “Email não pode ser processado: Email::Receiver::BadDestinationAddress” - estes são um tanto misteriosos; por que os endereços são inválidos?
3 x “Email não pode ser processado: Email::Receiver::NoBodyDetectedError” - dois parecem ter texto de corpo que parece normal; um diz apenas ‘sem corpo’
1 x “Email não pode ser processado: Email::Receiver::TooShortPost”
6 x “Email não pode ser processado”
1 x “Email não pode ser processado: Desculpe, novos usuários podem adicionar apenas uma imagem em uma postagem.”
1 x “Erro não capturado: Erro de sintaxe, expressão não reconhecida: #xxxxxx-email:product at company dot com”
Vários desses casos envolviam tentativas legítimas de comunicação por parte de clientes. Se o e-mail de rejeição enviado pelo Discourse foi para a pasta de spam do remetente ou simplesmente foi ignorado permanece incerto.
Eles enviaram para um endereço que você não está gerenciando, como o suporte.
Para mim, apenas o “no body”, onde você diz que há um corpo, parece algo que pode ser um bug. Uma possibilidade é que tenha a ver com eles estarem usando algum cliente de e-mail antigo e com defeito.
Verifiquei alguns desses (Email::Receiver::BadDestinationAddress), e muitos parecem ser respostas legítimas de clientes, com o destinatário no formato: replies+longidentifier@discourse.site.com. O e-mail de alerta que o Discourse envia ao remetente sugere que o e-mail foi enviado de um endereço diferente daquele associado ao tópico referenciado, o que provavelmente é a explicação, mas, em um caso como este, eu ainda gostaria que a equipe fosse alertada.
Parece mesmo um bug, mas, embora eu gostaria que isso fosse corrigido, sinto que sempre haverá casos como este, de modo que, além de investigar possíveis bugs na análise de e-mails, um e-mail de alerta para a equipe nos permitiria oferecer suporte oportuno no intervalo.
Foi exatamente isso que pensei. Da próxima vez que eu vir isso, vou perguntar ao cliente qual cliente de e-mail eles estão usando.
O ponto que estou tentando fazer é que, quando e-mails são rejeitados, às vezes são apenas pessoas tentando obter suporte, sem qualquer intenção maliciosa.
Claro, algumas vezes, os e-mails que o Discourse rejeita realmente precisam ser rejeitados, mas não queremos correr o risco de perder nenhum e-mail de suporte, então ficamos presos à verificação periódica da lista de rejeitados.
Enquanto isso, remetentes confusos são forçados a encontrar outras formas de nos contatar, como o formulário de contato em nosso site.
Para sites maiores, alertas de rejeição de e-mail podem ser numerosos demais para lidar, mas, para nós, seria muito mais fácil lidar com eles do que lidar com clientes irritados.
Além disso, embora o Discourse envie e-mails de rejeição ao remetente com informações potencialmente úteis, acredito que esses e-mails às vezes acabam na pasta de spam, o que confunde ainda mais os clientes afetados.
No entanto, não tenho certeza de como resolver o problema de respostas enviadas da caixa de correio errada. (E, caramba, como eu odeio formulários de contato — independentemente de qual lado deles eu esteja!)
Se um usuário estiver respondendo de um endereço diferente daquele para o qual o e-mail foi enviado, isso é esperado.
Se permitíssemos respostas a esses e-mails de outro endereço, estaríamos abrindo as contas para abuso via e-mail, com outras pessoas se passando por um usuário. Enfrentamos esse problema às vezes em nossas próprias mensagens de suporte aqui no meta.
Se formulários de contato por e-mail estiverem em uso, eles geralmente enviam de um e-mail e definem o cabeçalho Reply-To, o que significa que estamos enfrentando o mesmo problema mencionado acima.
Não tenho certeza de uma ótima solução para isso pessoalmente — talvez alguém mais da equipe tenha uma ideia.
Sim, como eu disse, faz sentido rejeitar esses casos. Mas eu ainda gostaria de ser notificado quando isso acontecer.
Eu mencionei formulários de contato apenas porque, quando os clientes não conseguem nos contatar pelo endereço de e-mail de suporte (que o Discourse processa), eles são forçados a procurar alternativas, o que não é ideal.
Não tenho certeza de como fazer isso exatamente. Você pode acompanhar /admin/email/rejected, mas para receber um alerta real, atualmente precisaria de um plugin.
Eu também não, por isso postei isso como um pedido de recurso.
Sim, entendi. Mas ir até essa página e atualizar a cada poucos minutos parece bastante ineficiente.
Um plugin seria aceitável, mas não entendo por que esse recurso não poderia ser simplesmente adicionado ao Discourse. Para mim, parece uma decisão óbvia. O Discourse já envia vários alertas para administradores e equipe do site. Torne a configuração (alerta sobre rejeição de e-mail) padrão como desativada, o que, imagino, atenderia muitos sites.
Outro exemplo: um cliente enviou um e-mail para o endereço de suporte para relatar um problema que está enfrentando com sua compra. O Discourse rejeitou o e-mail: [Email::Receiver::InactiveUserError].
Entendo que faz todo o sentido que o Discourse rejeite e-mails de usuários inativos, mas se nossa equipe de suporte fosse alertada ao mesmo tempo, poderíamos entrar em contato imediatamente com o cliente, explicando o que aconteceu e o que pode ser feito a respeito.
Em vez disso, a menos que consultemos frequentemente a lista de Rejeitados, o cliente agora enfrenta dois problemas, ambos resultantes de sistemas automatizados, dos quais nossa equipe de suporte permaneceria desconhecida. A intervenção humana nesta etapa é importante, mas podem haver atrasos no tempo de resposta, pois, novamente, estamos dependendo da verificação manual da lista de Rejeitados.
Existe algum motivo técnico pelo qual os administradores não podem ser alertados sobre rejeições de e-mail?
