Estou tentando descobrir como fazer o Discourse limpar listas de e-mail, especificamente e-mails devolvidos. O site está usando um servidor SMTP privado para enviar e-mails, mas a resposta está configurada para retornar a um endereço do Gmail para acesso POP pelo Discourse.
Então, vejo e-mails devolvidos no painel de E-mails Recebidos.
O Discourse usa a reply_key para associar rejeições a e-mails enviados. Quando o Discourse envia e-mails, ele usa o valor de reply_by_email_address como remetente do envelope SMTP.
Você precisa garantir que seu reply_by_email_address inclua uma {reply_key} para que sua instância possa associar as rejeições ao e-mail enviado correto.
Por exemplo, aqui no meta, está configurado como incoming+%{reply_key}@meta.discoursemail.com e qualquer coisa enviada para esse endereço é entregue a esta instância.
Obrigado pela resposta. Infelizmente, tive que desativar a reply_key da resposta para o e-mail porque nosso servidor de retransmissão de e-mail não reconhece o endereçamento +. Existe alguma outra opção?
Seu servidor de retransmissão de e-mail não deveria importar, apenas o servidor final onde a caixa de correio está. As partes locais do e-mail são opacas para quaisquer servidores intermediários.
Não é gmail, conforme:
Não tenho certeza se temos outro mecanismo para detectar com confiabilidade os bounces.
Para esclarecer, o servidor de domínio SMTP de destino que recebe o e-mail retornado não reconhece o endereçamento com +, portanto, ele encaminha e-mails apenas com base no campo To para o endereço do Gmail, que é captado pelo Discourse via POP. Isso significa que, se o campo To incluir a reply_key, ele não encaminhará esse e-mail para a conta do Gmail usada pelo Discourse.
Portanto, não posso colocar a reply_key no endereço de e-mail, pode colocá-la em outro lugar? No campo do assunto ou no corpo ou em algum lugar onde o Discourse possa analisá-la?
O e-mail enviado pelo Discourse sai de discourse@xxx.com via um servidor SMTP de domínio dedicado configurado para o Discourse (usando o endereço de domínio do Discourse).
Quaisquer respostas ou quando um e-mail retorna como falha, o servidor SMTP de domínio encaminha o e-mail para discourse.xxxx@gmail.com. Este servidor SMTP de domínio não consegue reconhecer o endereçamento +, então se eu incluir a reply_key no endereço de e-mail de resposta, ela será descartada pelo servidor SMTP de domínio. Só consigo definir regras para encaminhar endereços de e-mail de entrada discretos/únicos.
O fórum Discourse então usa POP via GMail para acessar essas respostas/e-mails devolvidos encaminhados e analisá-los.
Entendo o que você está dizendo. Infelizmente, devido a uma limitação nas regras do servidor SMTP, não posso configurar o encaminhamento para subdomínios, apenas posso configurá-lo para encaminhar IDs de e-mail To exclusivos.
No entanto, tenho um esclarecimento aqui - mais como uma discrepância na forma como o Discourse parece estar funcionando:
Quando um usuário responde a uma postagem por e-mail, ela chega corretamente - as respostas parecem funcionar perfeitamente mesmo sem nenhuma {reply_key} explicitamente configurada em qualquer lugar (veja as capturas de tela acima).
No entanto, quando um e-mail é devolvido, o Discourse o categoriza como Recebido em vez de Devolvido.
Os logs de erro mostram que algo no Discourse reconhece que é um e-mail devolvido (veja o log de erro da minha primeira postagem). Portanto, se algo no Discourse está reconhecendo que é um e-mail devolvido, por que ele não aparece em Devolvido em vez de Recebido?
Então, por que quando um usuário responde a uma postagem ela é processada corretamente pelo Discourse, mas um e-mail devolvido não (e também parece haver uma desconexão entre os logs de erro e o painel para e-mails devolvidos). Estou perdendo alguma coisa na configuração?
Também tentei configurar as opções de endereço de e-mail para resposta no Discourse para discourse.xxx+%{reply_to}@gmail.com, mas quando o e-mail é entregue, o Gmail parece pensar que o domínio yyy.com (domínio SMTP do Discourse) está tentando falsificar o domínio do Gmail e acaba marcando-o como spam. Parece que definir um domínio de resposta diferente do domínio do remetente está acionando uma falha no DMARC e SPF.
ARC-Authentication-Results: i=1; mx.google.com;
spf=softfail (google.com: domain of transitioning discussion.xxx+verp-b9c40db917ca04993dd3433cc9748518@gmail.com does not designate y.y.y.y as permitted sender) smtp.mailfrom=discussion.xxx+verp-b9c40db917ca04993dd3433cc9748518@gmail.com;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yyy.com
Return-Path: <discussion.xxx+verp-b9c40db917ca04993dd3433cc9748518@gmail.com>
Você desativou find related posts with key (espero que você tenha lido o aviso), portanto o Discourse está usando o cabeçalho de e-mail in-reply-to para determinar a qual tópico/postagem a resposta deve se referir.
Ele não pode fazer isso para devoluções - o Discourse precisa saber a mensagem específica que foi devolvida e essa informação só é garantida em um local - o endereço To: (que vem do endereço envelope-from da mensagem original).
Para que isso funcione, quando o Discourse envia uma mensagem, ele precisa receber a resposta do endereço de onde ela veio. O Discourse procura no cabeçalho To: por isso (não no envelope-to).
está falsificando o domínio do gmail
Se você quiser enviar e-mails de um endereço do gmail, você precisa enviá-los através dos servidores deles. Mas eles não gostam disso.
Não parece que você configurou o DKIM para yyy.com; você deveria fazer isso. Se você acertar isso, o DMARC deve passar.
Sim, está configurado e o e-mail “enviado” pelo Discourse através do servidor SMTP yyy.com passa pelos testes SPF, DKIM e DMARC sem problemas (pelo menos a partir da página “Enviar e-mail de teste” no console de administração).
Este problema ocorre se eu definir um endereço do Gmail como reply_by_email_address para um endereço gmail.com em vez do endereço yyy.com. Há algo que eu possa fazer para esta configuração para que o DMARC não falhe quando definido como reply_by_email_address para um endereço do Gmail, mantendo o servidor de saída como yyy.com?
Não pode analisar o restante do conteúdo/anexos no e-mail devolvido para extrair essa informação se não conseguir o que precisa no local “óbvio” (ou pelo menos fornecer uma opção nas configurações para fazer isso com os avisos necessários sobre personificação)?
O alinhamento DMARC falha, pois o reply_by_email_address é usado como endereço envelope-from nesta situação.
Praticamente a única coisa que é garantido que permaneça intacta em um bounce é o endereço.
Talvez o assunto, mas não seria prático colocar essa informação lá.
Vejo que alguns sistemas incluem a mensagem original como um anexo… é teoricamente possível que possamos verificar bounces em busca de um anexo para obter mais informações, se existirem.
Se entendi corretamente, o reply_by_email_address deve ser definido no campo reply-to do envelope enviado pelo Discourse (de yyy.com). Assim, quando o usuário responder, ele responderá para o e-mail reply-to (gmail.com) em vez do endereço original (yyy.com). Portanto, no envelope da resposta do e-mail, o endereço from deve ser o endereço de e-mail do usuário e o to é o endereço gmail.com.
Por que o reply_by_email_address seria usado como o endereço from?
o reply_by_email_address não é usado como o endereço de remetente, mas sim o envelope-from, especificamente para que os bounces funcionem
Aqui está uma imagem que demonstra como cada endereço é usado. Os endereços em si são específicos para nossa hospedagem, mas devem ser suficientes como exemplo.
Então, basicamente, o reply_by_email_address é usado no cabeçalho from para que ele retorne para esse endereço de e-mail se houver um bounce. E o mesmo endereço de e-mail também é definido no cabeçalho reply-to se as respostas por e-mail estiverem habilitadas.
Portanto, se meu entendimento acima estiver correto, então se o Discourse puder ter uma configuração separada (reply_to_email) para o cabeçalho reply-to, isso resolveria o problema para a falha do DMARC. Ao usar o domínio yyy.com (obtido de reply_by_email_address) para from ao enviar e o gmail.com para o reply-to (obtido de uma nova configuração reply_to_email). Se o e-mail der bounce, ele ainda será retornado para o reply_by_email_address, mas se o usuário responder, ele irá para o reply_to_email.
Para passar no DMARC, o SPF (que valida o envelope-from em combinação com o IP de envio) ou o DKIM (que valida o From e os campos de checksum da mensagem) precisam se alinhar.
Parece que o objetivo de todo esse exercício é ter um endereço de reply-to “bonito”, para o qual os usuários respondem?
Você quer algo assim?
envelope-from: outgoing+12309847801923840923502389423@yyy.com
…
From: notifications@yyy.com
To: user@contoso.com
Reply-to: my_sweet_forum+12309847801923840923502389423@gmail.com
Você deve ter esse envelope-from assim, ou os erros não funcionarão.
Sim, está correto. A ideia é ter o envelope-from diferente do reply-to.
Como o domínio envelope-from e o IP de envio correspondem, o SPF deve passar, mas ao mesmo tempo a resposta pode ir para o GMail para processar as respostas e, se o e-mail falhar, ele voltará para o servidor de domínio original, que poderá então encaminhar o bounce de volta para a caixa de entrada do GMail também.
Na verdade, ficaria assim:
envelope-from: outgoing@yyy.com
…
From: notifications@yyy.com
To: user@contoso.com
Reply-to: my_sweet_forum+12309847801923840923502389423@gmail.com
Na minha configuração, o outgoing não terá um VERP porque meu SMTP de entrada não suporta VERP (ou seja, o bounce não terá um endereço VERP), é por isso que o reply-to está sendo enviado para o GMail porque ele suporta VERP. Isso não deve causar uma falha no DMARC como está acontecendo agora.
