Hmmm, nesse exemplo e no código-fonte completo do e-mail que você me enviou (obrigado!), o atributo moz-do-not-send não deve afetar a exibição das tags <img> ou <a> nas quais esse atributo aparece. O mozfilter está verificando apenas os valores no atributo class, e não consigo ver imediatamente em nenhum outro lugar onde ele possa ser filtrado.
Por isso, não consigo entender por que o conteúdo e o href do link com alias são separados, a menos que, por algum motivo, o importador do Discourse esteja decidindo repentinamente usar a parte plain/text do e-mail codificado em Mime (que realmente tem o texto e a URL separados). Por que ele faria isso, não sei.
Em sua configuração de teste do Discourse, você pode tentar importar/enviar por e-mail um e-mail HTML do Thunderbird que contenha tanto um link com alias quanto, digamos, uma imagem incorporada ou algo mais que o identifique como a parte HTML do e-mail?
Ainda estou pensando que isso pode ser o Discourse usando as outras partes MIME (neste caso, uma parte plain/text seguida por uma parte image/… do e-mail para criar sua versão em Markdown), embora eu não saiba o motivo. Talvez um validador HTML esteja rejeitando a parte text/html devido a atributos estritamente não válidos, como moz-do-not-send!?
Você poderia fazer mais um teste com a mesma postagem (algum texto com uma imagem no meio, mas também deixe parte do texto em negrito, mesmo que apenas uma palavra). Acredito que isso determinará se a parte de texto está vindo de um bloco text/plain ou text/html.
E desculpe pedir, mas só para ter certeza: você tem incoming_email_prefer_html definido como true (marcado)?!
Obrigado, @Flominator. Percebi que o texto em negrito ficou em itálico, então definitivamente não está usando o HTML diretamente, mas de alguma forma está captando a ênfase. Estou me perguntando se a parte text/plain do e-mail recebe algum tipo de marcação ou código adicionado — você poderia me enviar por mensagem privada o código-fonte do e-mail como da última vez?
Olá @Flominator, obrigado pelo e-mail bruto. Analisando a parte alternativa text/plain do e-mail, de fato, há asteriscos ao redor do texto que está em negrito na parte text/html. A maioria dos renderizadores Markdown (como o do Discourse) interpreta isso como itálico. Aqui está o segmento text/plain copiado e colado isoladamente:
Bild in die Mitte dann wieder Text von dem ein Teil sogar fett
geschrieben ist
Gruß
Flo
o que parece idêntico ao seu print de tela.
Portanto, acredito que o que está acontecendo é que o segmento text/html está sendo rejeitado como HTML inválido (provavelmente devido ao nome do atributo não padrão moz-do-not-send nas tags a). Isso exigirá uma correção para alterar como o HTML válido é verificado (possivelmente apenas removendo esses atributos), e tenho menos confiança sobre quão estável isso será sem que entre no código principal. Vou dar uma olhada quando tiver um tempo.
Isso significa que o patch anexado em um comentário anterior falhará (provavelmente não “espetacularmente”, mas pode exigir uma reconstrução para que as atualizações funcionem novamente) ao atualizar para incluir este novo commit (provavelmente sua próxima atualização).
Se você o tem aplicado automaticamente (por exemplo, com um git applycmd em seu app.yml, como descrito acima), você deve removê-lo antes da sua próxima atualização. Na verdade, uma reconstrução pode ser necessária, pois esse commit pode falhar ao ser aplicado, já que o local em receiver.rb onde ele tentará aplicar a diferença do commit já foi alterado pelo patch.
Vou 1) remover o git applycmd do app.yml, 2) reconstruir o app, 3) atualizar (se já não foi feito na reconstrução). Avisarei como isso corre…
[10 minutos depois…]
No final, fiz o seguinte em vez disso, pois não requer nenhum tempo de inatividade durante a reconstrução.
remover o git apply para o patch do app.yml (só precisa ser feito antes da sua próxima reconstrução do contêiner do aplicativo)
reverter o arquivo corrigido com:
i) launcher enter app
ii) (agora no contêiner do aplicativo) cd /var/www/discourse git checkout ./lib/email/receiver.rb exit
atualizar o discourse usando a atualização de administração pela web
