Import_mbox.sh が、メーリングリストサーバー経由で送信されたSamsung製携帯電話からのメールで動作しません

私のテスト環境で、メールをDiscourseサーバーにコピーし、import_mbox.shを実行してそれらのメールをインポートしようとすると、奇妙な問題が発生しています。元のメールはリストサーブのメーリングリストからのものです。

Samsung製スマートフォンを使用しているユーザーが以前のリストサーブのメールに返信した場合、その結果のメールをDiscourseにインポートしようとすると、新しいコンテンツは抽出されず、返信した人が書いたように表示された元のメールの重複が表示されることがわかりました。

問題のある生のメールを「Emails/Advanced Test」ボックスにコピー&ペーストしても、同じ問題が発生します。メールを切り捨てて、Samsungが追加したいくつかの部分を削除すると、機能するようです。

この問題をトリガーするメールのコピーは機密情報のため、ここに掲載することはできません。インポートされないメールには、次のようなセクションが含まれています(人間が読めるコンテンツはなく、すべてbase64エンコーディングされています)。

[truncated headers here]
Content-Type: multipart/alternative;
	boundary="--_com.samsung.android.email_341310020171250"

----_com.samsung.android.email_341310020171250
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset=UTF-8

VGhlIGxlZ2lzbGF0aW9uI[truncated]
[...]
[truncated]X19fX19fX19fX18NCg==
----_com.samsung.android.email_341310020171250
Content-Type: multipart/related;
	boundary="--_com.samsung.android.email_341310031317791"

したがって、メールを切り捨てて、Samsungのくだらない部分を削除するように import_mbox.sh を変更する必要があります。

これらのメッセージは、メールで送信されたときに失敗する可能性があるため、コアで解決できる問題である可能性もあります(ただし、最近コードを見ていないのでわかりません)。いずれにしても、最も迅速な解決策は、これらのメッセージのインポートスクリプトを変更することになるでしょう。

あるいは、誰かがこれをコアの問題として認識し、修正してくれるかもしれません。

「いいね!」 1

さらに調査したところ、SamsungのメールアプリはプレーンテキストとHTMLの両方の部分をそれぞれbase64でエンコードしているようです。両方のエンコーディングの間に空行を追加すると、メールフィルターが正しく機能することがわかりました。Samsungが本来追加すべき空行を追加していないか、あるいはメールフィルターがプレーンテキスト/HTMLテキスト部分を正しく特定できず、HTML部分を見つけた後にヘッダーの終わりとメッセージコンテンツの開始を知る場所を認識できていない可能性があります。

Gmailから元のメールをコピー(元の表示 via)したり、Thunderbirdから同じメッセージをエクスポートしたりしましたが、結果は同じでした。

Samsungが生成したメールには、ヘッダーの下部に以下のようなものが含まれているようです。

Content-Type: multipart/alternative;

	boundary="--_com.samsung.android.email_396413402758380"

----_com.samsung.android.email_396413402758380
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset=UTF-8

WWVz[base64エンコードされたプレーンテキストメッセージがここに表示されます]

そして、これは以下で終わります。

[さらにbase64エンコードされたデータはこちら]19fDQo=
----_com.samsung.android.email_396413402758380
Content-Transfer-Encoding: base64
Content-Type: text/html; charset=UTF-8

PGh0b[同じメッセージのHTML版をエンコードしたbase64エンコーディング]

そして、これは以下で終わります。

[さらにbase64エンコードされたデータ]NCg==
----_com.samsung.android.email_396413402758380--

ここで、中央の部分を空行(“email_396413402758380” のビットの後)を追加して変更すると、すべて完璧に機能します!

[さらにbase64エンコードされたデータはこちら]19fDQo=
----_com.samsung.android.email_396413402758380

Content-Transfer-Encoding: base64
Content-Type: text/html; charset=UTF-8

PGh0b[同じメッセージのHTML版をエンコードしたbase64エンコーディング]

これはインポーターのバグを示唆していますか?

私にはサムスンのメーラーのバグを示唆しているように思えますが、どちらのバグかはわかりませんし、どちらのバグであっても関係ありません。

しかし、最も簡単な修正は、インポートスクリプトに gsub を追加して、あなたが説明している空行を追加することです。

おそらく、Content-Transfer-Encoding: base64 の前に一行挿入する方が簡単でしょう。

これで他に何も壊れないことを願っています。

しかし、Gerhard がより良い回答を書いています… 今すぐ

「いいね!」 1

それなら、使用している mail gem のバグか、Samsungアプリのバグのどちらかだと思います。RFCをざっと見たところ、おそらくパーサーのバグだと思います。

そのような問題のあるメールの完全な例を提供していただけますか?機密メールの作成者に、機密ではないメールを送ってもらうよう依頼してみてはどうでしょうか?

「いいね!」 2

Base64でエンコードされた電子メールをデコードし、文言を変更してから再エンコードして、興味深いものを発見しました。

元のメッセージの途中でスペース文字を削除すると、その上に書かれた返信を正しく抽出できます。

この例では、Base64でエンコードされたHTMLメッセージの途中で、[スペース] の後にスラッシュ div が含まれる行を見つけて削除します。つまり、次のように変更します。

21  20:17  (GMT+00:00) </div><div>To: LIST@LISTS

次のように変更します。

21  20:17  (GMT+00:00)</div><div>To: LIST@LISTS

/div の前の [スペース] 文字を削除し、Base64で再エンコードして、管理設定のメッセージテストボックスに戻すと、フィルターが機能します。

必要であれば、ダイレクトメッセージで電子メールを投稿できますか?

これは問題を示すために作成した、こじつけの電子メールです。HTML部分を見ると、以前のメッセージへの返信が含まれています。インポータは元のメッセージがどこから始まったのかを見ることができないようです。

From someone@gmail
Delivered-To: someone@gmail
Importance: Normal
MIME-Version: 1.0
Message-ID: <E1mt6gg-00H2OV-6N@relay01.mail.eu.clara.net>
Date: Fri, 3 Dec 2021 11:25:05 +0000
From: someone <someone@somewhere.net>
Subject: Re: Example e-mail
To: <LIST@LISTSERV>
In-Reply-To: <007301d7e834$c268a3e0$4739eba0$@sslmc.co.uk>
Precedence: list
Content-Type: multipart/alternative;
	boundary="--_com.samsung.android.email_7076959834053910"

----_com.samsung.android.email_7076959834053910
Content-Transfer-Encoding: base64
Content-Type: text/plain; charset=UTF-8

Yes and we are getting lots in ABC and urgent care, along with vaccination side effects from flu + booster. Apparently DEF111 can't deal with this sort of query. Looking good for Xmas and NY week   2222

Sam

Dr Sam Smithy 

---- Original message ----
From: South Souths XYZ <enquiry@SSXYZ.CO.UK>
Date: 03/12/2021 10:59 (GMT+00:00)
To: LISTS@LISTSERV.ABC.ORG.UK
Subject: everything lands back at our door!

Practices reporting to get 2 or 3 queries/day from patients regarding five vaccine issues who have been referred to their GP by XYZ 123 or the NBS. These queries include scheduling doses for immunosuppressed pts as well as pharmaceutical questions. 
----_com.samsung.android.email_7076959834053910
Content-Transfer-Encoding: base64
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body dir="auto"><div dir="auto">Yes and we are getting lots in ABC and urgent care, along with vaccination side effects from flu + booster. Apparently DEF111 can't deal with this sort of query. Looking good for Xmas and NY week &nbsp; &nbsp;2222</div><div dir="auto"><br></div><div dir="auto">Sam</div><div dir="auto"><br></div><div id="composer_signature" dir="auto"><meta http-equiv="Content-Type" content="text/html; charset=UTF-8">Dr Sam Smithy&nbsp;</div><div dir="auto"><br></div><div><br></div><div align="left" dir="auto" style="font-size:100%;color:#000000"><div >---- Original message ----</div><div >From: South Souths XYZ &lt;enquiry@SSXYZ.CO.UK&gt; </div><div>Date: 03/12/2021 10:59  (GMT+00:00) </div><div>To: LISTS@LISTSERV.ABC.ORG.UK </div><div>Subject: everything lands back at our door! </div><div><br></div></div><div class="WordSection1"><p class="MsoNormal"><span style="font-family:'Arial','sans-serif';">Practices reporting to get &nbsp;2 or 3 queries/day from patients regarding five vaccine issues who have been referred to their GP by XYZ 123 or the NBS.&nbsp; These queries include scheduling doses for immunosuppressed pts as well as pharmaceutical questions.&nbsp; </span></p></div></body></html>
----_com.samsung.android.email_7076959834053910--

この問題は、他のメールクライアントからのメッセージにも影響するようです。現在、問題を引き起こしているメールを皆に見てもらうために公開することはできませんが、プライベートで誰かに見てもらうことは喜んで承ります。

現在の私のセットアップは、自宅のサーバーにDiscourseをインストールしており、メーリングリストへのメールは私に届きます(Gmailアカウントに届きます)。「宛先」フィルターがメーリングリストの名前に一致する場合、Gmailはメールのコピーをmailinglist@mydiscoursedomain.org.ukに転送するように設定しています。Discourseには、このメールを探すメーリングリストをミラーリングするように設定されたカテゴリがあります。

mbox.shスクリプトをインポートする場合も、手動でメールをコピーした後も同じ問題が発生するため、メッセージの新しい部分を探すコードの部分が混乱しているに違いありません。

Discourse で、以前保存されたインポート済み E メールをすべて高速処理し、元の E メールのプレーンテキスト部分を使用して再フォーマットすることは可能でしょうか。これにより、上記の問題の一時的な解決策となる可能性があります。インポート前は、HTML 部分を使用するように設定されていました。rails c を使用して確認したところ、各投稿には受信メッセージの全文(E メールヘッダーを含む)が保存されているようです。HTML オプションをオフにしてから rake posts:rebuild を実行してみましたが、メッセージをゆっくりと処理する間、何も変更されたかどうかはわかりません。たとえば、トリムされたコンテンツを表示するオプションのオンとオフを切り替えてみましたが、rake が終了した後も、投稿には3つのドットが表示される小さなボックスがまだあります。