Becky! Ver.2 BBS

[57413] 通信中にエラーが発生しました No Response 頻発

返信　削除

▽ 2026/3/20 (金) 17:25:19 ▽ 通りすがりのおじさん

192.236.178.217.shared.user.transix.jp / Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36

Gmail IMAP、OAuth2利用で、メール一覧からメールを選択したり選択したメールを削除
使用とすると「メールサーバーとの通信中にエラーが発生しました""No Response""」が
ポップアップする事が頻発するようになりました。

根気よく選択し直したりで選択や削除出来るのですが、エラー頻発で困っています。
素人ながら
Beckyをアンインストール、再インストールして見たり
詳細設定のSSl/TLS関連の選択を変えたり

でも症状は改善しません。
確認箇所などありましたらアドバイスお願いいたします。

よろしくお願いします。

[57414] Re:通信中にエラーが発生しました No Response 頻発

返信　削除

▽ 2026/3/21 (土) 14:54:45 ▽ koi

public-nat-13.vpngate.v4.open.ad.jp / Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:148.0) Gecko/20100101 Firefox/148.0

> 確認箇所などありましたらアドバイスお願いいたします。

IMAPは使ってないので確証あるわけではありませんが
IMAPであるならサーバ上でのメール管理だと思うので
サーバにどれぐらいのメールため込んでいるか
といったことも通信負荷に関係してくるのではないかと思います
（数・容量）
↑　POPでも処理負荷が増えるという意味では同じですが
　　ローカル上操作になると思うので通信負荷は発生しません

時間経過で発生しだしたとか言った事であれば確認してみてはどうでしょう

[57415] Re2:通信中にエラーが発生しました No Response 頻発

返信　削除

▽ 2026/3/22 (日) 09:04:29 ▽ 通りすがりのおじさん

192.236.178.217.shared.user.transix.jp / Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36

▼ koiさん

> サーバにどれぐらいのメールため込んでいるか
> といったことも通信負荷に関係してくるのではないかと思います

> 時間経過で発生しだしたとか言った事であれば確認してみてはどうでしょう

koiさん、おはようございます。
使用頻度の少ないアカウントでは発生していませんし、おっしゃるとおり
心当たりあり。納得のお話です。
マジメに掃除を考えます。

負荷＝容量に対する割合で良いでしょうか。
容量MAX 10Gに対して 9Gは負荷が大きけど容量 100Gだったら 9Gなんて平気と言うこと？
いやいや、そもそも9Gなんて溜めてちゃダメだよ？

容量追加購入案内頻度が増えてきて、ちびちび消すようにしているのですが
一度しっかり掃除してみたいと思います。

ありがとうございました。

[57453] Re2:通信中にエラーが発生しました No Response 頻発

返信　削除

▽ 2026/4/29 (水) 04:49:33 ▽ 通りすがりのおじさん

143.202.178.217.shared.user.transix.jp / Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Safari/537.36

▼ koiさん

今晩は？おはようございます。
いつもありがとうございます。

結果
設定-->受信-->IMAP関連-->IMAP IDLEで新着メールを待機のチェックを
はずして解決出来ました。

結果論ですが、確かにこれにしたら??? と触った記憶が甦ってきました。

正常に利用出来ているところへこれしたら何か変わる？みたいな
好奇心禁止って事です(汗

素人なので要点だけをまとめられませんが、以下ＡＩにLogを投げてみた結果になります。
このログは、IMAPでメール本文を取得してから、正常終了してログアウトしているだけに見えます。

IDLE terminated (Success) の後に UID FETCH ... BODY.PEEK[] でメール本文を読み、その後 CLOSE → LOGOUT で接続を閉じています。

何が起きているか
IDLE が終わり、待機監視をいったん解除しています。
UID FETCH 320132 (BODY.PEEK[]) で、UID 320132 のメール本文を取得しています。
Gmail に再接続し、AUTHENTICATE XOAUTH2 で認証しています。
LIST でフォルダ一覧を取得し、STATUS と SELECT INBOX で受信箱の状態を確認しています。
最後に CLOSE と LOGOUT を行い、正常にセッションを閉じています。

これが繰り返される理由
新着監視のサイクルとして、待機 → 取得 → 切断 → 再接続を繰り返す設計だからです。

受信ソフトが「IDLEで待つ」だけでなく、一定のタイミングで本文を取りに行く実装だと、このログの流れになります。

Gmail IMAP と Becky! の組み合わせでは、OAuth認証や接続サイクルが何度か起きる報告もあります。

Becky! 側では、IMAPの新着チェック方法（IDLE／ポーリング）とチェック間隔を調整することで、再接続の回数や頻度をある程度減らせます。

調整できるポイント
メールボックスごとの新着チェック間隔

「IMAP IDLEで新着チェック」を使うかどうか

定期チェックをオフにして、手動受信中心にするかどうか

1. 新着チェック間隔を伸ばす
「メールボックスの設定」→その Gmail IMAP アカウントを選択→「受信」タブを開きます。

「定期チェック」または「定時チェック」の時間を長めに設定すると、サーバーへのアクセス頻度が下がります。

逆に、ここが短いと（数分など）、短周期で接続→検索→切断が繰り返されます。

2. IMAP IDLE の使い方を見直す
「メールボックスの設定」→「詳細」タブにある「IMAP IDLEで新着チェック」のチェックを確認します。

これをオンにすると、サーバーとの接続を保ったままリアルタイム通知を受けますが、環境によっては接続の張り替えが多くなることがあります。

「リアルタイム性はそこそこでよい」「ログを減らしたい」なら、

「IMAP IDLEで新着チェック」のチェックを外す

代わりに「定期チェック」を10～15分など長めに設定
とすると、再接続の頻度を下げられます。

3. 手動受信寄りにする
「このメールボックスを定期チェックの対象にする」等のチェックを外すと、自動チェックが止まり、手動受信したときだけ接続するようにできます。

この場合、ログに出る接続・IDLE・LOGOUT も大幅に減りますが、新着がリアルタイムでは来なくなります。

実際にやるなら
Gmail IMAP アカウントの「メールボックスの設定」を開く。

「受信」タブで

定期チェックをする場合は間隔を長く（例：10～15分）、

不要なら自動チェック関連のチェックを外す。

「詳細」タブで

「IMAP IDLEで新着チェック」のオン／オフを好みに合わせて切り替える。

このあたりを調整すると、「1～2分ごとにログが大量に出る」状態はかなり和らぐはずです。
今の使い方として、リアルタイム性（すぐ通知）とログの静かさ（回線負荷・ログ量削減）のどちらを優先したいか教えてもらえれば、具体的なおすすめ設定値も提案します。

[▼次のスレッド]

INCM/CMT
Cyclamen v3.84