Abrindo uma nova solicitação de recurso aqui, atualmente o Discourse permite apenas um único endereço de e-mail que é usado tanto para envelope-from quanto para reply-to. Se um site desejar usar seu próprio domínio STMP para enviar e-mails, mas quiser que as respostas de e-mail sejam enviadas para um domínio diferente (por exemplo, gmail), os e-mails enviados falharão no DMARC. Ao separar esses dois campos de cabeçalho, evitará uma falha no DMARC e também não perderá a capacidade de lidar com e-mails devolvidos.
Não vejo como os bounces serão tratados neste cenário. Os bounces vão para o envelope from, não para o endereço em Reply-To. Portanto, se o seu envelope from não for capaz de lidar com e-mails com tags VERP, você ainda estará em apuros.
No tópico que você referencia, você não explica por que a assinatura DKIM contra o domínio no cabeçalho From: não funciona. Isso deve fornecer alinhamento DMARC, mesmo que o SPF falhe. Essa seria a abordagem que eu tomaria, se estivesse em sua posição (ou isso, ou ir atrás dos administradores do servidor SMTP de entrada yyy.com com um forcado; que tipo de MTA não suporta nenhum tipo de endereçamento detalhado?!?)
Funcionará porque o MTA suporta “catch all”. Embora não suporte VERP, ele pode ser configurado para encaminhar todos os e-mails não especificados para um e-mail específico, para que as respostas de rejeição não sejam perdidas.
Além disso, se separarmos envelope-from e reply-to, envelope-from não precisa conter um endereço VERP. Pode ser um endereço simples como discourse@yyy.com. Assim, quando retornar uma rejeição, ela voltará para discourse@yyy.com, o que não falhará no SPF.
O reply-to pode ter um e-mail diferente que suporte VERP, como discourse-yyy+sdfkj33@gmail.com, para que, se entregue com sucesso, quando o usuário responder, chegue ao servidor do Gmail que suporta VERP e não falhará no DMARC, já que o from ainda é yyy.com.
Concordo, mas nós não os fabricamos. Como eles têm endereçamento “catch-all”, eles não suportarão VERP. Infelizmente, essa é a situação, espero que com um pequeno ajuste o Discourse consiga suportar um ecossistema mais diversificado. Muitos sites menores que usam o Gmail para lidar com respostas estariam nessa situação.
Se o seu MTA suporta catch all, por que você não pode encaminhar as respostas com o mesmo recurso e descartar o Gmail completamente?
O envelope from é o endereço que tem que suportar VERP, porque a única maneira de identificar de forma confiável a causa de uma rejeição é através das informações no endereço do envelope from do e-mail original, como Michael explicou anteriormente.
Tenho minhas dúvidas sobre essa afirmação. Usar um endereço do Gmail para respostas é gambiarra, e sempre foi gambiarra; o receptor de e-mail é uma maneira muito mais direta, confiável e com menos gambiarra de lidar com respostas (e rejeições).
Mesmo para esses sites pequenos que usam o Gmail, os realmente minúsculos provavelmente estão ignorando os Termos de Serviço e usando o Gmail para retransmitir a saída também, e a grande maioria dos outros provavelmente não está presa a um MTA que não suporta endereçamento detalhado.
Porque é um “catch all” para o domínio, apenas um e-mail está sendo usado para o Discourse.
Não necessariamente, estou usando atualmente sem VERP e está funcionando. Meu problema é que não posso fazer com que o usuário responda diretamente ao Gmail sem uma falha de SPF/DMARC devido à forma como o Discourse define os endereços envelope-from e reply-to. Em vez disso, tenho que fazer o MTA encaminhá-lo para o Gmail. Se eu pudesse fazer com que ele respondesse diretamente ao Gmail (sem uma falha de DMARC/SPF), então eu poderia usar VERP para proteger as respostas, mas sim, o VERP será ignorado para e-mails devolvidos. Ainda é mais seguro do que a implementação atual.
Essa não é uma opção, como expliquei aqui. Só é prático usar o Gmail para entrada. Configurar seu próprio MX de entrada direto quando você já tem um MX do seu provedor de hospedagem pode ser desafiador para os não iniciados. Respostas diretas do Gmail são muito mais fáceis e menos propensas a erros.
Talvez eu esteja perdendo algo em seu raciocínio. Só consigo ver vantagens em separar os endereços envelope-from e reply-to, ele suporta ecossistemas mais diversos e é mais seguro, ajudando a evitar falhas de SPF/MARC.
Meu raciocínio é que a resposta correta para o seu problema, como expresso até agora, é configurar o DKIM. Tornar a configuração de e-mail ainda mais complicada e propensa a erros não é justificado pelo seu caso de uso, na minha opinião.
O DKIM já está configurado, o problema é que o SPF está falhando.
Adicionar um campo extra para separar os endereços envelope-from e reply-to proporcionará muita flexibilidade e também permitirá que o SPF passe (o que não passará se houver um servidor SMTP que encaminha e-mails ou não suporta VERP). O campo pode ser oculto na interface do usuário ou até mesmo definido para corresponder aos endereços envelope-from e reply-to, a menos que os administradores decidam especificamente substituir. A descrição pode apontar para esta página. No entanto, não vejo como isso pode piorar, só pode melhorar - eles são iguais (caso em que o SPF falhará em qualquer cenário descrito aqui) ou melhorará a entregabilidade.