アクティビティ要約メールのテキストからスペース文字が抜けている

プレビュー要約を自分宛に送信してみました。普段は受け取らないので。\n\nメール内の見出しやテキストに、ランダムですが一貫したスペース文字の欠落が見られます。フォーラムのコンテンツではこれらのスペースは欠落していませんが、生成された複数のプレビュー要約では、さまざまなメールクライアントで表示した際に、同じスペースが一貫して削除されています。\n\n元のスペースを削除して再追加してみましたが、効果はありませんでした。\n\n抜粋:\n\n

\n\n他のDiscourseフォーラムから受け取る要約を確認しましたが、他ではこのような現象は見られません。\n\n他にこのような現象を見たことがある方、または原因について何かアイデアがある方はいらっしゃいますか?

これはフォントまたは表示の問題である可能性がありますか?基になる生のコンテンツを確認しましたか?

Hm. フォント/表示の問題の診断方法がわかりません。メールは、Windows と Linux の複数のメーラーやブラウザで同じように表示されます。

フォーラム投稿の URL に .json を追加しましたが、「topic_slug」や「cooked」の内容に問題はありません…

生のコンテンツで他に確認すべきことはありますか?

「いいね!」 1

投稿ではなく、生のメールを確認する必要があります。

「いいね!」 1

わかりました。生のメールを確認したところ、HTML版でスペースが不足している箇所は、テキスト版では正しいスペースがあります。しかし、テキスト版では他のスペース文字が不足しています。規則性はありません。

文字化けの問題でしょうか? 編集:いいえ。現在の投稿でも、また要約だけでなく他のメールでも発生しています。

現在の投稿を含む、より最近のDiscourseの要約では同じ問題は発生していないので、このまま続くようでない限りあまり心配しません。 編集:続いています。

(余談ですが、このような事態に備えて、常にログインしているかどうかに関わらず、管理アカウントに包括的な要約を毎日送信するように強制できればと思います。)

そのメールを添付ファイルとして私に転送してもらえますか?

編集:完了しました

OK、生のテキストメールで確認できるのは次のとおりです。

[Mis/Disinformation starts to overwhelm civilization][2]

The dark side of generative AI is that it enables the production of misinformation (due to confabulation) and disinformation (i.e. deliberate production of fake news to achieve an end) at industrial scale. Renderingof web pages in the style of authoritative sources is straighforward, and progress in deep fakes will make video story complements easier. Asidefrom Vinge’s clouds of fake information to hide information (Rainbows End), which I don’t believe posed a solution, have any SF authors thought about this and how it might be tackled?

注:

  • to overwhelm :white_check_mark:
  • a paperback :white_check_mark:
  • Renderingof :x:
  • Asidefrom :x:

HTMLバージョンでは次のようになります。


<a href="https://forum.tasat.org/t/mis-disinformation-starts-to-overwhelm-civilization/66" style="text-decoration: none; font-weight: bold; color: #006699;; font-weight:400;line-height:1.3;margin:0;padding:0;text-decoration:none">
<strong >Mis/Disinformation starts tooverwhelm civilization</strong>
…
Rendering of web pages in the style of authoritative sources is straighforward, and progress in deep fakes will make video story complements easier. Aside from

注:

  • tooverwhelm :x:
  • apaperback :x:
  • Rendering of :white_check_mark:
  • Aside from :white_check_mark:

最も生の(つまりエンコードされた)形式でも、これらのエラーはまだ存在します。

[Mis/Disinformation starts to overwhelm civilization][2]

The dark =
side of generative AI is that it enables the production of misinformation (=
due to confabulation) and disinformation (i.e. deliberate production of fak=
e news to achieve an end) at industrial scale. Renderingof web pages in t=
he style of authoritative sources is straighforward, and progress in deep f=
akes will make video story complements easier. Asidefrom Vinge=E2=80=99s c=
louds of fake information to hide information (Rainbows End), which I don=
=E2=80=99t believe posed a solution, have any SF authors thought about this=
 and how it might be tackled?
Ken

<a href=3D"https://foru=
m.tasat.org/t/mis-disinformation-starts-to-overwhelm-civilization/66" style=
=3D"text-decoration: none; font-weight: bold; color: #006699;; font-weight:=
400;line-height:1.3;margin:0;padding:0;text-decoration:none"
                         <strong >Mis/Disinformation starts tooverwhelm civi=
lization</strong>

これらは、生の/調理済みの形式にはありません。

000000d0: 5265 6e64 6572 696e 6720 6f66 2077 6562  Rendering of web
000000e0: 2070 6167 6573 2069 6e20 7468 6520 7374   pages in the st
000000f0: 796c 6520 6f66 2061 7574 686f 7269 7461  yle of authorita
000000100: 7469 7665 2073 6f75 7263 6573 2069 7320  tive sources is
000000110: 7374 7261 6967 6866 6f72 7761 7264 2c20  straighforward,
000000120: 616e 6420 7072 6f67 7265 7373 2069 6e20  and progress in
000000130: 6465 6570 2066 616b 6573 2077 696c 6c20  deep fakes will
000000140: 6d61 6b65 2076 6964 656f 2073 746f 7279  make video story
000000150: 2063 6f6d 706c 656d 656e 7473 2065 6173   complements eas
000000160: 6965 722e 2020 4173 6964 6520 6672 6f6d  ier.  Aside from

私があなたを信じていなかったわけではありません :smiley:

つまり、メール本文、テキスト部分でもHTML部分でも、スペースが時々削除されているということです。しかも同じ場所ではありません!

これらのエラーは、次の4つの場所のいずれかで導入された可能性があると推測します。

  • Discourseで、メールを生成する際
  • メールをメール送信サーバーに送信する際
  • 中間/エンドサーバーにメールを送信する際
  • ユーザーのメールボックスに配信する際

おそらく最初から始めるのが一番簡単でしょう。

Discourseに、MTAが「実際の」メール配信サーバーに送信する前にキューで検査できるローカルMTAにメールを送信させてもらえますか?

マイケル、分析ありがとうございます!

私は高度なメール管理者ではありません。一般的な推奨のセルフインストールを実行しており、実際の送信メールは MailerSend.net 経由で、DKIM/DMARC などは正常に動作するように慎重に設定しています。私が読んだところによると、sendmail や Postfix のようなローカル MTA を組み込むことは、ほとんどの場合推奨されない高度な操作です… 動作中のパイプラインを混乱させる可能性があり、いじることに少し不安を感じています。:grimacing:

簡単に元に戻せる、トラブルシューティング用の MTA 実装があれば検討できますか?

上記編集で指摘したように、この問題は管理者によるコピー&ペーストだけでなく、ユーザーが投稿した現在のコンテンツでも続いており、サマリー、user_replied、user_posted の各メールで確認されています。

MailerSend のサポートは、Discourse からリクエストを受け取った際にスペース文字が欠落していることを確認しました。したがって、エラーは Discourse によるメール生成にあるようです。

参考までに、生成されたサマリーをプレビューする際にはスペース文字は欠落していませんが、メールとして受信する際には欠落しています。


同時に、他のユーザーも2月から報告しているこの問題がサマリーメールで発生しています。

これらの繰り返し投稿は、生成されたサマリープレビューに存在します。

編集 2024-04-26: サマリーの繰り返し問題は特定されました。修正待ちの間、設定変更により問題を軽減しましたが、このトピックとは関係ないようです。送信メールには引き続きスペース文字が欠落しています。


コマンドラインでアップデートと再構築を実行して、問題が解消されるか確認しましたが、効果はありませんでした。

テスト合格ブランチで最新の状態にしているすべての人にこれらの問題が発生していない場合、私のセットアップで他にどのような点を確認すればよいでしょうか?

サーバーとメール送信サービス間のTLSを一時的に無効にできれば、実際の通信を検査でき、Discourseがスペースを送信しているかどうかを最終的に明らかにできます。

それができない場合は、MITM(中間者攻撃)を試すこともできますが、それはより複雑です。

上記の両方が機能しない場合は、このケースではローカルPostfixを設定しますが、直接配信のために設定するのではなく、Discourseと同じ方法でメール送信サービスアカウントにメールを送信するようにします。

これにより、Discourseはいずれかの方法で送信でき、送信前にPostfixキューでメールを検査できます。

マイケルさん、ありがとうございます。「オン・ザ・ワイヤーでの検査」は初めてですが、見つけたことをお伝えします。

MailerSend は TLS とポート 587 を必要とします。そこで:

  • 無料の mailtrap.io アカウントにポート 2525 で送信するための代替 app.yml を作成しました。
  • DISCOURSE_SMTP_ENABLE_START_TLS = false を設定しました。
  • 以下のコマンドで変更を適用しました。
cd /var/discourse
./launcher destroy app
./launcher start app
  • tcpdump を使用してリモートトラフィックを監視するように Wireshark を設定しました。

Wireshark のメールコンテンツパケットと Mailtrap で受信した暗号化されていないメールには、今のところスペース文字の欠落はありません。元の設定でスペースが欠落し、Mailtrap バージョンでは欠落しない特定のテストダイジェストを、各設定で連続して実行しました。これは、問題が TLS 暗号化によって導入されていることを示しているのでしょうか?

編集: Mailtrap のテスト設定を十分に活用していなかったことに気づきました。その後、TLS を有効にしたポート 587 で、暗号化されたプレビューサマリーを数回 Mailtrap に送信しましたが、スペース文字の欠落は確認されませんでした。MailerSend は受信リクエストで問題が発生していると私に伝えていましたが、結局は彼らの側で発生しているのかもしれませんか?彼らに何を確認すべきか分かりませんが、これらの調査結果を彼らに伝えようと思っています。

「いいね!」 2

(参考までに:設定をざっと確認しましたが、問題は見つかりませんでした。そのため、設定に影響を与えるテーマやプラグインがあるのではないかと疑問に思いました。私がやったことは、mail-tester.comにアクセスして一時的な宛先を取得し、次にAdmin->Emails->Preview Summaryを使用して一時的な宛先にサマリーを送信し、次にmail-testerをクリックしてHTML版とプレーン版を表示することでした。同じ戦術を試して、何か違いがあるかどうかを確認する価値があるかもしれません。)

Ed、ありがとうございます。mail-testerに到達するためには、私のメールはMailerSendリレーを経由する必要があります。これは、私がチェーンから外そうとしていたものです。しかし、あなたのコメントにより、TLS暗号化を有効にしてMailtrapでテストを実行することになり、以前の投稿を編集しました。

「いいね!」 1

私も同様の可能性が高いと考えています。

確実なテストとして、次に、キャプチャしたプレーンテキストメールのいずれかを取得し、openssl s_client を使用して MailerSend アカウントから手動で送信することを推奨します。