Thunderbird 生成的回复中的 URL 被删除

支持
24

Hmmm, in that example, and in the full email source you messaged me (thank you!) the moz-do-not-send attribute should not affect the display of the <img> or <a> tags that that attribute appears in. The mozfilter is only looking at values in the class attribute, and I can’t immediately see anywhere else that it might get filtered.

As such I can’t work out why the link-with-alias’s content and href get separated out, unless for some reason the discourse importer is suddenly deciding to use the plain/text part of the Mime encoded email (which does have the text and URL separated). Why it would do that I don’t know.

In your test discourse setup can you try importing/emailing a thunderbird HTML email with both a link-with-alias and, say an embedded image or something else that will mark it out as the HTML part of the email?

1 个赞
25

Thanks for trying.

Then the picture which in the mail in between the text (left) turns to be at the end in Discourse (right):

grafik
grafik1823×472 37 KB

1 个赞
26

I’m still thinking this might be discourse using the other mime parts (in this case a plain/text part followed by an image/… part of the email to create its markdown version, though why I don’t know. Perhaps an HTML validator is rejecting the text/html part because of strictly-non-validating attributes like moz-do-not-send!?
Could you do one more test, with the same post (some text with an image in the middle, but also make some (but not all) of the text bold, even just one work. I think that will determine if the text part is coming from a text/plain or text/html block.

And sorry to ask, but just to make sure, you have incoming_email_prefer_html set to true (checked)?!

1 个赞
27

The email:
grafik

The post:

grafik
grafik705×639 93.5 KB

2 个赞
28

Thanks @Flominator . I see that the emboldened text has become italicised, so it’s definitely not using the HTML directly, but it is picking up on the emphasis somehow. I wonder if the text/plain part of the email gets some kind of markup/down added – would you be able to PM me the email source like last time?

1 个赞
29

Hi @Flominator , thanks for the raw email. Looking at the text/plain alternative part of the email does indeed put asterisks around the text that’s in bold in the text/html part. Most markdown renderers (such as the one in discourse) interpret this as italicised. Here’s the text/plain segment copied and pasted on its own:

Und nochmal soll ich für hier
https://meta.discourse.org/t/urls-being-dropped-from-thunderbird-generated-replies/163751/24
eine Testnachricht schicken.

Bild in die Mitte dann wieder Text von dem ein Teil sogar fett
geschrieben ist

Gruß

Flo

which looks identical to your screenshot.

So what I think is happening is that the text/html segment is being rejected as invalid HTML (probably down to the non-standard moz-do-not-send attribute name in the a tags). This will require the patch to change how valid HTML is checked (possibly just removing those attributes) and I’m less confident how stable that will be without it going into the core code. I’ll have a look when I get some time.

4 个赞
30

大家好，关注此话题的朋友们，

我刚刚发现（在更新之前），一个独立的修复（与此类似但更具体）已提交到此问题：
issue: FIX: properly clean Thunderbird emails, don't remove links by ValdikSS · Pull Request #16543 · discourse/discourse · GitHub
commit: FIX: properly clean Thunderbird emails, don't remove links (#16543) · discourse/discourse@f7540aa · GitHub

这意味着，当您升级以包含此新提交（可能是您的下一次升级）时，上面评论中附加的补丁将失败（可能不会“壮观地”失败，但可能需要重新构建才能再次进行升级）。
如果您已自动应用它（例如，在您的 app.yml 中使用 git apply cmd，如上所述），您应该在下次升级之前将其删除。事实上，可能需要进行重建，因为该提交可能无法应用，因为 receiver.rb 中应用该提交 diff 的位置已被补丁更改。

我将 1) 从 app.yml 中删除 git apply cmd，2) 重建应用程序，3) 更新（如果尚未在重建中完成）。我会告诉您进展如何……

[10 分钟后……]

最后，我改用了以下方法，因为它在重建过程中不需要任何停机时间。

  1. 从 app.yml 中删除补丁的 git apply（仅在下次重建应用程序容器之前需要执行此操作）
  2. 使用以下命令恢复已打补丁的文件：
    i) launcher enter app
    ii) （现在在应用程序容器中）
    cd /var/www/discourse
    git checkout ./lib/email/receiver.rb
    exit
  1. 使用 Web 管理更新来更新 discourse
1 个赞
31

我是此补丁的作者。它对我来说效果很好，我没有发现任何缺点。

2 个赞