bsoares
(Ben Soares)
2021 年 10 月 4 日午後 2:32
24
ええと、その例や、あなたが私に送ってくれた(ありがとう!)完全なメールソースでは、moz-do-not-send 属性は、その属性が含まれる <img> タグや <a> タグの表示には影響を与えるべきではありません。mozfilter は class 属性の値のみを参照しており、他にどこでフィルタリングされる可能性があるのか、すぐに確認できません。
そのため、リンク・エイリアスの内容と href が分離されてしまう理由がわかりません。何かの理由で Discourse のインポーターが突然、Mime エンコードされたメールの plain/text パート(そこにはテキストと URL が分離されています)を使用することにしたのかもしれません。なぜそうなるのかは私にもわかりません。
あなたのテスト用の Discourse 環境で、Thunderbird の HTML メールをインポートまたはメール送信してみてください。そのメールにはリンク・エイリアスと、埋め込み画像など、メールの HTML パートであることを示す他の要素の両方を含めてください。
試してくださりありがとうございます。
すると、メール本文の途中(左)にあった画像が、Discourse 上では末尾(右)に表示されてしまいます:
bsoares
(Ben Soares)
2021 年 10 月 5 日午前 8:52
26
これは、メールの他の MIME パーツ(この場合は plain/text パーツに続く image/… パーツ)を使用して Markdown 版を生成している Discourse なのではないかと考えています。なぜそうなるのかはわかりませんが。もしかすると、moz-do-not-send のような厳密な非検証属性のために、HTML 検証器が text/html パーツを拒否しているのでしょうか?
もう一度テストをお願いします。同じ投稿(中央に画像があるテキスト)で、テキストの一部(すべてではない)を太字にしてみてください。たった一つの単語でも構いません。そうすれば、テキスト部分が text/plain ブロックから来ているのか、text/html ブロックから来ているのか判断できると思います。
お手数をおかけして申し訳ありませんが、念のため確認させてください。incoming_email_prefer_html は true(チェック済み)に設定されていますか?
bsoares
(Ben Soares)
2021 年 10 月 25 日午前 10:50
28
@Flominator さん、ありがとうございます。太字だったテキストがイタリック体になっているのを見ると、HTML を直接使っているわけではないようですが、何らかの形で強調が適用されているようです。もしかして、テキスト形式(text/plain)のメール部分に何かマークアップや装飾が追加されているのでしょうか?前回のようにメールのソースを PM で送っていただけますか?
bsoares
(Ben Soares)
2021 年 10 月 27 日午前 11:13
29
@Flominator さん、生メールをありがとうございます。メールの text/plain 代替部分を確認すると、text/html 部分で太字になっているテキストの周りにアスタリスクが付いていることがわかります。ほとんどの Markdown レンダラー(Discourse のものなど)は、これをイタリック体として解釈します。以下に、text/plain セグメントを単独でコピー&ペーストしたものを示します。
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
これはあなたのスクリーンショットと全く同じに見えます。
私の推測では、text/html セグメントが無効な HTML として拒否されているようです(おそらく、a タグ内の非標準的な moz-do-not-send 属性名が原因です)。これには、有効な HTML のチェック方法を変更する(おそらくこれらの属性を単に削除する)パッチが必要になりますが、コアコードに組み込まれない限り、その安定性については確信が持てません。時間ができ次第、確認します。
bsoares
(Ben Soares)
2022 年 4 月 26 日午前 8:56
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 を使用している場合)、次のアップグレードの前に削除する必要があります。実際、コミットが適用に失敗する可能性があるため、再構築が順調に進む可能性があります。コミット diff を適用しようとする receiver.rb の場所は、パッチによって既に変更されています。
私は 1) app.yml から git apply cmd を削除し、2) アプリを再構築し、3) 更新します(既に再構築中に更新されていない場合)。それがどのように進むかお知らせします…
[10分後…]
結局、再構築中にダウンタイムが発生しないため、代わりに次のことを行いました。
app.yml からパッチの git apply を削除します(次のアプリコンテナの再構築前にのみ行う必要があります)。
パッチが適用されたファイルを次のように元に戻します。
i) launcher enter app
ii) (アプリコンテナ内)
cd /var/www/discourse
git checkout ./lib/email/receiver.rb
exit
ウェブ管理者の更新を使用して Discourse を更新します。
このパッチの作者は私です。私にとってはうまく機能し、欠点も見つかりませんでした。