― MozillaZine.jp フォーラムは Mozilla 製品に関する情報交換の場です ―



All times are UTC + 9 hours

新しいトピックを投稿する トピックへ返信する  [ 14 件の記事 ] 
作成者 メッセージ
投稿記事Posted: 2022年8月15日(月) 11:54 
imapにてメール受信をしています。
先日とある迷惑メールを受信してしまい、
Thunderbirdが「応答なし」の状況から回復しない症状に見舞われました。
メールの概要は以下の通りです。
 メールサイズ:約18MB
 宛先件数  :約90万件(メールアドレスとして成立していないものも含む)
 メール本文 :約20行程度のテキストとURL、添付ファイル無し

幸いWebメールのようにブラウザからも確認の取れるサービスでしたので、
Web上からメールを削除することで、上記の状況から脱する事が出来ました。

今回Thunderbirdで起きた症状が、アプリ自体の不具合なのか、
回避方法があるのかご教示頂きたく投稿させて頂きました。

・・・そもそも、そんなメールがフィルタリングされないメールサービスの問題ってのもありますが。

よろしくお願い致します。


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2022年8月16日(火) 00:15 
オフライン

登録日時: 2014年2月22日(土) 00:59
記事: 4056
kelpie11 さん、EarlgreyTea と申します。

kelpie11 さんが書きました:
Thunderbirdが「応答なし」の状況から回復しない症状に見舞われました。
kelpie11 さんが書きました:
宛先件数  :約90万件(メールアドレスとして成立していないものも含む)

私はそういうメールを受け取ったことはないですが、ヘッダーの To: に90万個のアドレスとはすごいですね。
そのメールがフォルダーに入っただけで、選択しなくても Thunderbird は索引(.msfファイル)を更新しようとしてフリーズしてしまいますね。

この種の問題は数年以上前からいくつかのバグとして議論されてきたようです。
しかし、具体的な対策として結果が出ていないみたい。
フリーズするような数を検出した時点で、To: や Cc: などの処理をスキップするような安全策を入れてほしいものですね。

kelpie11 さんが書きました:
・・・そもそも、そんなメールがフィルタリングされないメールサービスの問題ってのもありますが。

サーバー側で迷惑メールとして弾いてくれるのが望ましいですが、アプリ側が操作不能に陥るのは問題ですね。
迷惑フォルダーに振り分けさえできればなんとかなるので、ダメ元で少し考えてみたいと思います。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:103.0) Gecko/20100101 Firefox/103.0


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2022年8月16日(火) 10:23 
EarlgreyTea さん、kelpie11です。
お返事とご回答、誠にありがとうございました。

> 私はそういうメールを受け取ったことはないですが、ヘッダーの To: に90万個のアドレスとはすごいですね。
メールサイズの割に添付ファイルはついておらず、本文も短いのでおかしいと感じていました。
前述のWebサービスからメールをダウンロードして、中身を確認したらTo:にものすごいアドレスの羅列が :shock:

> そのメールがフォルダーに入っただけで、選択しなくても Thunderbird は索引(.msfファイル)を更新しようとしてフリーズしてしまいますね。
> この種の問題は数年以上前からいくつかのバグとして議論されてきたようです。
> しかし、具体的な対策として結果が出ていないみたい。
> フリーズするような数を検出した時点で、To: や Cc: などの処理をスキップするような安全策を入れてほしいものですね。
既に確認されている、既知の問題だったのですね。
今後のアップデートに期待しつつ、悪用されない事を祈ります。

> 迷惑フォルダーに振り分けさえできればなんとかなるので、ダメ元で少し考えてみたいと思います。
同じメールを受け取ったメンバーがいたのですが、振り分けフィルタでなんとかなったようです。
私自身はフィルタ設定をしていなかったので、該当メールが受信トレイに入ってしまい、
Thunderbird → 受信トレイを見に行く → フリーズ となってしまいました。
To: に設定値以上のアドレスが含まれたら迷惑フォルダに振り分ける、といったフィルタができると良いかな、と感じています。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2022年8月16日(火) 13:38 
オフライン

登録日時: 2013年5月19日(日) 13:46
記事: 1928
kelpie11 さん、maji とゆ者です。

kelpie11 さんが書きました:
imapにてメール受信をしています。
先日とある迷惑メールを受信してしまい、
Thunderbirdが「応答なし」の状況から回復しない症状に見舞われました。
メールの概要は以下の通りです。
 メールサイズ:約18MB
 宛先件数  :約90万件(メールアドレスとして成立していないものも含む)
 メール本文 :約20行程度のテキストとURL、添付ファイル無し

その「Thunderbirdが「応答なし」の状況から回復しない症状」は
どの位の時間を待って判断されたのでしょうか?
もしかしたら
「ただ時間が掛かってるだけで,もう少し待てば復帰してた」なんて事はないですか?

試しに手元で To: に 1万件のアドレス(注:大半はダミー)のあるメールを作り
IMAPで受信トレイに Thunderbirdの外から貼り付ける形で置きましたが、
メール一覧でメールクリックしたり本文閲覧したりの一つヒトツの操作する間に
「 Thunderbird が「応答なし」の状況から回復しない」タイミングは生じ、
イライラしながら復帰するのを待ちましたた。
EarlgreyTea さんが
EarlgreyTea さんが書きました:
ヘッダーの To: に90万個のアドレスとはすごいですね。
そのメールがフォルダーに入っただけで、
選択しなくても Thunderbird は索引(.msfファイル)を更新しようとしてフリーズしてしまいますね。
とおっしゃってる様に、
索引( .msfファイル)の更新にソレナリに時間が掛かるのだと思います。

私の手元のテストで「応答なし」からの復帰に 30秒以上~1分弱 は待ったので、
1万件で 30秒とすると 90万件だと単純計算で 45分 かな。
さすがにこれは待てませんね。

# このあたりは Thunderbird 性能だけでなく
# PC自体のハード性能やネットワーク性能にも依存しますが、、、。。。

-----

kelpie11 さんが書きました:
今回Thunderbirdで起きた症状が、アプリ自体の不具合なのか、
回避方法があるのかご教示頂きたく投稿させて頂きました。

今回の事象が「待っても永久に復帰しない」のであれば
それは「アプリ自体の不具合」として
何とか Thunderbird側での「安全策」含めた対処を考えてもらえるように働き掛ける
しかないかな、と。

今回の事象が「待っていれば復帰する(ただし時間が掛かりすぎる)」のであれば
ある意味で Thunderbird の性能問題なので、すぐに対処は難しいかと。

-----

それにしても、
宛先 90万件のメールとは、、、、すごい迷惑メールですね。

では。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:103.0) Gecko/20100101 Firefox/103.0


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2022年8月17日(水) 00:14 
オフライン

登録日時: 2014年2月22日(土) 00:59
記事: 4056
EarlgreyTea さんが書きました:
この種の問題は数年以上前からいくつかのバグとして議論されてきたようです。
しかし、具体的な対策として結果が出ていないみたい。

関連バグを紹介しておきます。

Bug 460605 Message Reader: header pane right-click context menu popup takes too long for contacts in long list with lots of addresses
  • ステータス:NEW
  • 報告日:2008-10-18、最終更新日:2015-07-19
  • To:/Cc: 等に多くのアドレスを含むメールを右クリックした場合に表示遅延が発生する
  • 症状が深刻でなく、遅延は大量のDOMノードを処理する場合のGeckoの弱点が原因と考えられるため、処置なく放置状態

Bug 619493 Message with too many email addresses in TO: or CC: field hangs TB. Need to sanity check display of addresses.
  • ステータス:NEW
  • 報告日:2010-12-15、最終更新日:2020-10-29
  • To:/Cc: 等に20,000超のアドレスを含むSPAMメールを受信するとメッセージリストの表示だけでTBがハングアップして操作不能になる
  • 手動でファイル編集してSPAMを除去しないと復帰しない
  • 2017年時にプロファイラーでボトルネックになっている箇所を調べる話が出て以降の状況不明
  • 重大度: Critical に設定されている
  • テスト用の To: フィールドを生成するスクリプトあり

Bug 693295 Thunderbird freezes (unresponsive) when you open a message with too many recipients, with "View/Headers/All" mode
  • ステータス:NEW
  • 報告日:2011-10-10、最終更新日:2022-03-09
  • 表示>ヘッダー>すべての設定で多数の受信者を含むメールを開くとフリーズする
  • 重大度: Critical に設定されている

EarlgreyTea さんが書きました:
迷惑フォルダーに振り分けさえできればなんとかなるので、ダメ元で少し考えてみたいと思います。

90万件のアドレスのTo: フィールドを持つテストメールの.emlファイル作成して、それをD&Dでインポートしましたが、どうにもならなくなって「手動でファイル編集してSPAMを除去しないと復帰しない」状態となりました。
私が考えているのは、FiltaQuilla という拡張機能を入れて、メッセージフィルターにて JavaScript による条件を追加、受信者の指定数が一定以上の時にフィルターで移動できないだろうかというものです。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:103.0) Gecko/20100101 Firefox/103.0


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2022年8月17日(水) 19:46 
オフライン

登録日時: 2013年5月19日(日) 13:46
記事: 1928
EarlgreyTea さん、maji です。

EarlgreyTea さんが書きました:
90万件のアドレスのTo: フィールドを持つテストメールの.emlファイル作成して、それをD&Dでインポートしましたが、
どうにもならなくなって「手動でファイル編集してSPAMを除去しないと復帰しない」状態となりました。

私は 1万件までしかテストしませんでしたが、90万件のテストされたのですね。
そして「どうにもならなくなって」となった、と。
あらためて
宛先 90万件のメールとは、すごい迷惑メール、ですね。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:103.0) Gecko/20100101 Firefox/103.0


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2022年8月17日(水) 22:06 
kelpie11です。

majiさん
お返事、ご回答、誠にありがとうございます。
また検証までして頂いて、ありがとうございます。

> その「Thunderbirdが「応答なし」の状況から回復しない症状」は
> どの位の時間を待って判断されたのでしょうか?
> もしかしたら
> 「ただ時間が掛かってるだけで,もう少し待てば復帰してた」なんて事はないですか?
症状の発生時点では5~10分程度放置して状況を見ましたが、改善せず・・・。
諦めて一晩放置を決め、20時頃から翌8時まで放置をしましたが、やはり改善せず・・・。
流石におかしいと原因調査を始めて、前述のメールに行きつきました。
普段から仕事で利用していることもあり、中々検証できなかったのも事実ですね。。。

> 私の手元のテストで「応答なし」からの復帰に 30秒以上~1分弱 は待ったので、
> 1万件で 30秒とすると 90万件だと単純計算で 45分 かな。
> さすがにこれは待てませんね。
普段からストレスなく利用しているものが、これだけ利用できなくなると莫大なストレスになることを実感できました。。。


EarlgreyTeaさん
引き続きの調査と検証、誠にありがとうございます。
バグ認定はされているのですね・・・。
やはり首を長くしてFixを待つこととします。


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2022年8月17日(水) 22:18 
オフライン

登録日時: 2013年5月19日(日) 13:46
記事: 1928
kelpie11 さん、maji です。

kelpie11 さんが書きました:
諦めて一晩放置を決め、20時頃から翌8時まで放置をしましたが、やはり改善せず・・・。
流石におかしいと原因調査を始めて、前述のメールに行きつきました。

情報提供ありがとうございます。

実は、、、、、
maji さんが書きました:
もしかしたら
「ただ時間が掛かってるだけで,もう少し待てば復帰してた」なんて事はないですか?
なんて思ってたのですが、
そんなんもぢゃない、との事ですね。
maji さんが書きました:
今回の事象が「待っても永久に復帰しない」のであれば
の状況みたい、です。

状況、了解しました。

# と書きつつ、私には対応するアイデア思いつかない、、、。。。。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:103.0) Gecko/20100101 Firefox/103.0


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2022年8月17日(水) 22:35 
オフライン

登録日時: 2014年2月22日(土) 00:59
記事: 4056
kelpie11 さん

Bug 693295 からもわかる通り、
ユーザー側では「メニュー>表示>ヘッダー」の設定を普段は「通常」にして、「すべて」にしておかないほうが望ましいかと思います。
「通常」であれば問題のメールを表示してしまっても、宛先部分は一部だけ表示され、「MORE」を押さないとすべての宛先の表示処理は行われませんので、「応答なし」の状況を少しは軽減してくれるでしょう。

FiltaQuilla による JavaScript でのメッセージフィルターの件ですが、ちょっと作ってみましたのでご紹介します。

拡張機能の FiltaQuilla ですが、Thunderbird のアドオンマネージャーで検索してもらえば見つかりますので「Thunderbird へ追加」してください。
追加できましたら設定が必要になります。
アドオンマネージャーにて FiltaQuilla の右側にスパナアイコンのボタンを押してもらって設定画面を開きます。
添付ファイル:
FiltaQuilla設定画面.jpg
FiltaQuilla設定画面.jpg [ 71.93 KiB | 表示数: 11205 回 ]
今回はフィルター条件を増やしたいので、「Search Terms」タブを開き、「Javascript(J)」にチェックを入れて「OK」で画面を閉じてください。
その後、いったん Thundebird を再起動すると、チェックを入れた項目がメッセージフィルターの条件として追加されます。

メッセージフィルターを新規作成して設定画面を開きますと、条件に FiltaQuilla で追加した項目が増えていますので「Javascript」「が次とマッチする」を選択します。
右側のアイコンを押すと「Edit Javascript」画面が開きますので、そこにスクリプトを入力します。
添付ファイル:
フィルター条件(Javascript).jpg
フィルター条件(Javascript).jpg [ 96.57 KiB | 表示数: 11205 回 ]

スクリプトは以下の内容になります。
コード:
const MAX_ADDRS = 2000;
// 個数上限つけてカンマ区切りで分割して配列に受信者をセット
let recipients = message.getStringProperty('recipients').split(',', MAX_ADDRS);
// エラーコンソールにログ出したい場合
let cs = Cc["@mozilla.org/consoleservice;1"].getService(Ci.nsIConsoleService);
let subject = message.getStringProperty('subject');
cs.logStringMessage('recipients num = ' + recipients.length);
// 条件判定 配列の長さが上限に達していたら true
(recipients.length >= MAX_ADDRS);

1行目:仮に受信者数の上限を2000にしています。状況により変更してください。
3行目:Thunderbirdが読み出したヘッダー情報にアクセスして、カンマ区切りになった受信者(ToとかCcの中身)リストを分割して、配列として recipients 変数にセットしています。
5~6行目:この部分は処理内容をエラーコンソールに出力して確認したい場合の例になります。いらなければ削除して構いません。
9行目:配列の長さ=個数が上限に達していたら true となり、それがフィルター条件の判定結果として返ります。

これにより、メッセージフィルターでメールの受信者が一定以上のものを判定できます。
あとはフィルターアクションで振り分けるなりできるかと思います。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:103.0) Gecko/20100101 Firefox/103.0


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2022年8月17日(水) 23:16 
オフライン

登録日時: 2014年2月22日(土) 00:59
記事: 4056
kelpie11 さん

kelpie11 さんが書きました:
バグ認定はされているのですね・・・。
やはり首を長くしてFixを待つこととします。

3つのバグチケットを紹介致しましたが、数年どころか10年以上昔に出されたものです。
それがステータス:NEWなのですから、待っているだけでは対策される見込みは薄いでしょう。
こちらからのアクションが必要かと。

時々起こるかもしれないパフォーマンスの問題ではなく、ユーザーに深刻な不利益を与える可能性のある脅威であるという切り口が有効でしょう。
少なくとも90万件という桁違いの宛先を含むメールが実際に受信され、それにより Thunderbird が長時間使用不能になるという事案が発生しているので、これは有効な検討材料となるかと思います。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:103.0) Gecko/20100101 Firefox/103.0


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2022年8月19日(金) 21:43 
オフライン

登録日時: 2014年2月22日(土) 00:59
記事: 4056
viewtopic.php?f=3&t=20187&p=72763#p72745
EarlgreyTea さんが書きました:
そのメールがフォルダーに入っただけで、選択しなくても Thunderbird は索引(.msfファイル)を更新しようとしてフリーズしてしまいますね。

上記発言は正確ではなかったので撤回します。
受信者が多数含まれるメールを受信、またはフォルダーにインポートした際に復帰が望めないハングアップ状態になってしまう症状ですが、 .msfファイルの更新はあまり関係はないですね。メッセージリストには多少の遅延で表示されますし。

これの主原因は、グローバル検索機能(gloda)のための索引データベース(global-messages-db.sqlite)の更新処理によるものでした。
設定エディターにて「gloda.loglevel」→「All」に変更してエラーコンソールへのログ出力を有効にしたところ、gloda でメールの受信者すべてを読み出して反映しようとしており、その途中で止まっていることが見て取れました。

設定>一般 の最後の方、「グローバル検索と索引データベースを有効にする」のチェックを外すと、この作品データベースの更新処理を無効にできます。
ただ、受信者90万件級のメールでハングアップしてしまう状況に陥った場合、何度再起動しても繰り返しになり、設定画面で設定変更をするタイミングがありません。

この場合は、Thundderbird を強制終了した後、プロファイルフォルダーに下記を記載した「user.js」ファイルを設置してから起動することで無限地獄状態から抜け出すことができます。
コード:
user_pref("mailnews.database.global.indexer.enabled", false);

注意点としては:
  • ファイルはBOMなしUTF-8で保存してください。(BOMがついてたり、Shift_JISとかだと読み込みません)
  • 設定変更ができたら、user.js ファイルは削除(または今回追加項目の削除)を忘れずに。
    設定が固定化されてしまいます。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:103.0) Gecko/20100101 Firefox/103.0


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2022年8月22日(月) 13:22 
EarlgreyTeaさん、kelpie11です。

お返事頂きまして、ありがとうございます。
仕事が忙しく、中々回答ができず申し訳ありませんでした。

色々対策を考えて頂き、ありがとうございました。
私の会社の複数人がThunderbirdを利用していることもあり、
どの対策が、うまく全員に反映できるか検討した上で対応していきたいと思います。

> 時々起こるかもしれないパフォーマンスの問題ではなく、
> ユーザーに深刻な不利益を与える可能性のある脅威であるという切り口が有効でしょう。
> 少なくとも90万件という桁違いの宛先を含むメールが実際に受信され、
> それにより Thunderbird が長時間使用不能になるという事案が発生しているので、
> これは有効な検討材料となるかと思います。
→ 英語は少々苦手ですが、可能な限り早い段階で提案できればと思います。

EarlgreyTeaさん、majiさん、ご相談に乗って頂き、ありがとうございました。


通報する
ページトップ
  
引用付きで返信する  
投稿記事Posted: 2022年8月22日(月) 21:06 
オフライン

登録日時: 2014年2月22日(土) 00:59
記事: 4056
kelpie11 さん

kelpie11 さんが書きました:
私の会社の複数人がThunderbirdを利用していることもあり、
どの対策が、うまく全員に反映できるか検討した上で対応していきたいと思います。

その「複数人」「全員」というのは何名ほどのオーダーなのでしょう。
そもそも、多数の受信者が記載された迷惑メールによる被害というのは、今回はじめてでしょうか。それとも過去にも何度かあったことなのでしょうか。
そういったことで、対策の必要性、内容は変わってくるかと。

FiltaQuilla でメッセージフィルターを追加する方法は、多くの人にいきなり展開するのはリスキーだと思います。
また FiltaQuilla 自体がいろいろできてしまいますし、トラブルの元になることも考えられます。

とりあえずは、全員に
    「メニュー>表示>ヘッダー」の設定を普段は「通常」にして、「すべて」にしておかない
運用をお願いすることで、フリーズを軽減することになると思います。

kelpie11 さんが書きました:
→ 英語は少々苦手ですが、可能な限り早い段階で提案できればと思います。

これなのですが、私の方で Bug 619493 に2年ぶりのコメント投下する準備をしているところです。
ただの要望だと流されるかもなので、プロファイラーの情報を付けるつもりです。

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:103.0) Gecko/20100101 Firefox/103.0


通報する
ページトップ
 プロフィール  
引用付きで返信する  
投稿記事Posted: 2024年5月06日(月) 18:22 
同様の現象に手を焼いていたのですが。
開封確認を返信しない設定にしたところ、毎月発生していたフリーズが もう一年ぐらい発生していません。
情報まで


設定方法:バージョン 115.10.1 (32 ビット)
「ツール」ー「アカウント設定」-「開封確認」-「このアカウントでは共通の…」
 → [共通の開封確認設定]

● 開封確認は一切変身しない <= これを選択

_________________
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:125.0) Gecko/20100101 Firefox/125.0


通報する
ページトップ
  
引用付きで返信する  
期間内表示:  ソート  
新しいトピックを投稿する トピックへ返信する  [ 14 件の記事 ] 

All times are UTC + 9 hours


オンラインデータ

このフォーラムを閲覧中のユーザー: なし & ゲスト[44人]


トピック投稿:  可
返信投稿:  可
記事編集: 不可
記事削除: 不可
ファイル添付: 不可

検索:
ページ移動:  
Powered by MozillaZine.jp® Forum Software © phpBB Group , Almsamim WYSIWYG
Japanese translation principally by ocean