Estou trabalhando com um usuário para solucionar o problema de não recebimento de e-mail e encontrei a ação “revogar e-mail” registrada na conta dele. Como posso cancelar ou desfazer essa ação?
Além disso: se o e-mail de um usuário for revogado, isso é refletido nos logs de E-mail Enviado ou E-mail Ignorado? Ou apenas na ação de Revogar E-mail?
Continuando a discussão de O que significa a ação ‘revogar e-mail’ nos Logs?:
A ação de revogar e-mail é acionada quando múltiplos e-mails enviados a um usuário retornam (falham na entrega). Cada vez que um e-mail retorna, a “pontuação de retorno” do usuário é incrementada pelo valor definido nas configurações pontuação de retorno suave ou pontuação de retorno forte do seu site. Assim que a pontuação de retorno do usuário atingir o valor definido na configuração limite de pontuação de retorno do seu site (padrão: 4), a ação de revogar e-mail será acionada.
Você pode desfazer essa ação acessando a página de administração do usuário e clicando no botão “Redefinir” que está na linha “Pontuação de Retorno”, próximo ao topo da página.
Se você não clicar no botão Redefinir, o Discourse limpará automaticamente a pontuação de retorno do usuário após o período definido na configuração redefinir pontuação de retorno após dias. Essa configuração tem como padrão 30 dias. Após esse período, o Discourse tentará enviar e-mails ao usuário novamente.
Se um e-mail não for enviado a um usuário que excedeu o limite de pontuação de retorno do site, uma entrada será adicionada aos registros de Pulado. O Motivo do Pulamento será definido como “Excedeu o limite de pontuação de retorno”.
Obrigado. Então, se eu vir “Exceeded bounce_score_threshold” no log de ignorados para uma mensagem de email recente enviada ao Usuário X, posso assumir que houve uma ação de “revogar email” para esse usuário anteriormente, e vice-versa?
O contexto é que um dos meus usuários não está recebendo emails da nossa instância do Discourse. Ele é bastante competente, então confio em seus relatos de que verificou a pasta de spam, etc. Eu redefini a pontuação de bounce dele há algum tempo, mas só descobri hoje, ao acaso, a ação de Revogar Email no log para ele.
Isso é interessante. Eu assumi que a pontuação de bounce seria redefinida para aqueles cujos e-mails ainda não foram desabilitados (como funciona no Mailman). Acho que o mais próximo seria definir essa configuração para cerca de 10 anos!
Pelo que pude verificar, o Discourse sempre redefine a pontuação de bounce de um usuário e, em seguida, tenta reenviar os e-mails para ele. A única diferença entre como os bounces temporários e permanentes são tratados é que os bounces permanentes incrementam a pontuação de bounce por um valor padrão de 2 (definido pela configuração do site hard bounce score), em vez de um valor padrão de 1 (definido pela configuração do site soft bounce score).
Isso resolveria, mas poderia ter consequências não intencionais. Por exemplo, usuários que ultrapassaram o bounce score threshold devido à recente queda do Gmail teriam que esperar 10 anos para que sua pontuação de bounce fosse redefinida automaticamente.
O Mailman 2 possui configurações e limites padrão mais altos para rejeições (bounces), mas, ao atingi-los, você é removido da lista. Entendo os argumentos de ambos os lados. Edição: Não me lembro dos detalhes, mas acho que, em algum momento, você recebe a oportunidade de responder a um e-mail administrativo, o que reiniciaria sua pontuação de rejeição e o manteria na lista.
Muitas pessoas que fazem hospedagem própria do Discourse provavelmente usam o Mailgun, que mantém o endereço de e-mail em sua lista de supressão após uma única “falha permanente” e, portanto, ignorará a abordagem mais tolerante do Discourse.
Aparentemente, é possível obter essa lista de supressão usando a API do Mailgun, e acho que também pode ser possível sincronizá-la com as configurações do Discourse.
Recebi um e-mail do Google hoje afirmando de forma inequívoca que alguém obteve minha senha — “O Google ficou ciente de que outra pessoa conhece sua senha” — então me pergunto se isso está relacionado à “interrupção”…
Acabei de perceber isso: Configure VERP to handle bouncing e-mails - #166
Trata-se da remoção da configuração bounce_score_threshold_deactivate. Estou me perguntando se isso foi um erro. Se a configuração padrão fosse difícil de alcançar, a resposta seria reduzi-la.
Uma consequência indesejada dessa remoção para um fórum grande parece ser a tentativa de enviar e-mails para um número crescente de endereços inválidos regularmente ao longo de muitos anos. Isso poderia levar a problemas com um serviço externo (como o Mailgun, que suspende um endereço após um único bounce de permanent fail) ou à reputação do IP.
Como está, a menos que eu tenha entendido mal, o Discourse acha que está enviando e-mails que o Mailgun simplesmente se recusa a enviar por causa de sua lista de suspensão — e não é possível sincronizar a abordagem do Discourse com a do Mailgun.
Eu tinha esquecido disso. Não tenho certeza se a configuração bounce_score_threshold_deactivate estava funcionando para impedir que o Discourse tentasse enviar e-mails para endereços inválidos. O problema é que, assim que um usuário atinge o limiar de pontuação de bounce, o Discourse para de enviar e-mails para ele até que o período definido pela configuração reset bounce score after days tenha passado. Nesse momento, a pontuação de bounce do usuário será redefinida e o processo recomeçará.
Não tenho certeza de qual seria a melhor solução para isso. Se estou entendendo corretamente, parece que, com o tempo, um site do Discourse estará tentando enviar e-mails para um número crescente de endereços inválidos.
Há pelo menos dois lados nisso. Um é qual seria uma boa política para o Discourse, assumindo que o remetente do e-mail (por exemplo, localhost) concordará com isso. O outro é como sincronizar as coisas com um serviço de envio de e-mails que não concordará com isso (por exemplo, Mailgun).
Acho que já existe uma mensagem no Discourse mais ou menos assim: “Por favor, verifique seu endereço de e-mail, pois tivemos problemas ao enviar para ele.” Talvez o Discourse precise de uma abordagem mais agressiva para desativar e-mails com bounce, combinada com um aviso do site não descartável sobre a falta de envio de e-mails.
A sincronização com remetentes externos seria mais difícil. O Mailgun diz que é possível obter sua lista de supressão por meio da API , mas ainda não sei se também é possível remover endereços via API. Se for possível fazer ambos, o Discourse poderia desativar um endereço assim que ele entrar na lista de supressão e removê-lo da lista de supressão quando uma etapa manual for realizada dentro do Discourse pelo administrador ou usuário (por exemplo, respondendo a um e-mail de confirmação). Outro problema ligado a isso é que cada provedor provavelmente tem regras diferentes.
Edição: O texto riscado acima foi adicionado porque é possível remover um endereço de e-mail da lista de supressão do Mailgun usando a API: https://documentation.mailgun.com/en/latest/api-suppressions.html#delete-a-single-bounce