iCloud IMAP 運用での受信エラーNo.05192
zurarin66 さん 19/05/25 22:25
 
秀丸メールの利用をしている者です。

Apple の iCloud を IMAP アクセスで使用していますが、
いつからか受信時に下記エラーが出て、受信できなくなっていました。
下記 "AAAA/BBBB" の場所は不規則です。

> I メール一覧を取得中
> S C116 SELECT "AAAA/BBBB"
> R * 86 EXISTS
>   * OK
> 〜
>   C116 OK [READ-WRITE] SELECT completed (took 55 ms)
> S C117 UID SEARCH NOT DELETED
> R ...(314バイト)
>   C117 OK SEARCH completed (took 41 ms)
> E IMAPサーバーからエラーが返りました。エラー内容=* OK SEARCH T:1 done
> (内部情報)mode=69 line=15532

使用している秀丸メールのバージョンは、
 Ver.6.91
です。
解決方法を教えてください。よろしくお願いいたします。

[ ]
RE:05192 iCloud IMAP 運用での受信エラーNo.05194
秀まるお2 さん 19/05/27 09:28
 
 連絡いただいた状況によると、秀丸メールが「SEARCH NOT DELETED」ってコマンド
を送って、それに対する応答がおかしいような気がするのですがちょっとはっきりし
ないです。

 とりあえず、現状、秀丸メールの設定が標準じゃない所があるので、それを標準に
戻していただくことで回避できそうな気がします。

 「設定 - 全般的な設定...」の「上級者向け - デバッグ - IMAP」の中にある
 「IMAPサーバーからのメール一覧の取得方式」

 が、今は、

 ● 「SEARCH NOT DELETED」を使う方式(1番高速)

 になってると思います。これを

 ● 標準方式

 にしてもらえれば大丈夫じゃないかと思います。

 ちなみに僕の所でテストした限りは、どっちの場合もエラーにはならないようで、
ちょっと再現条件が分かりませんでした。

 たぶんサーバーからの応答がおかしいんだと思うですが、それを調べるには、「全
般的な設定 - 上級者向け - 動作の記録」の

 □ 秀丸メールの動作をdump.txtに記録する
   □ UIDL/LISTコマンドの内容

 の2つのオプションをONにしてdump.txtのログを取って、エラーになった時の応答
の部分をコピペして教えていただく作戦になるんですが、もし可能でしたらこれをお
願いしたいです。

 例えば僕の所でテストすると、

09:19:50.828 S C4 UID SEARCH NOT DELETED
09:19:50.828 (4162) IDTIMER_SOCKET_IDLE 0 set
09:19:50.859 (4162) IDTIMER_SOCKET_IDLE 0 set
* SEARCH 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 2
6 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51
 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76
77 78 79 80
C4 OK SEARCH completed (took 23 ms)
R ...(241バイト)
  C4 OK SEARCH completed (took 23 ms)
09:19:50.999 (9721) メール一覧を取得中(2/3)

 みたいな感じになりまして、特にサーバーからの応答がおかしいことが無いようで
した。

[ ]
RE:05194 iCloud IMAP 運用での受信エラーNo.05195
秀まるお2 さん 19/05/27 09:59
 
 ちなみに別件にはなるんですが、このテストをしてたら

    IMAPサーバーから届いたメールが期待したメールと違うかもしれません(UIDの
不一致)、
    「アカウント毎の設定・メールサーバー・詳細2」の「IMAPゆっくり受信」をON
にするの
    がお勧めです。

 のエラーが出るケースが見つかってしまいました。

 秀丸メールが要求したメールのIDの順序と実際に届くメールの順序がでたらめに入
れ替わるケースがあるようです。僕のテスト用アカウントのSent Messagesフォルダ
で起きます。これについては今から対応させていただきます。

[ ]
RE:05195 iCloud IMAP 運用での受信エラーNo.05213
zurarin66 さん 19/06/01 22:05
 
遅くなりましたが、ご回答ありがとうございました。

〉  「IMAPサーバーからのメール一覧の取得方式」
〉  ● 標準方式

上記を試してみたのですが、やはり同様のエラーとなりました。
下記に、dump.txt の抜粋を添付します。

21:56:53.907 (9721) メール一覧を取得中(71/80)
S C141 SELECT "Private/ZZZZZZ"
R * 5 EXISTS
  * OK [UIDVALIDITY 1425909778]
  * OK [UIDNEXT 6]
  * FLAGS (\Answered \Flagged \Draft \Deleted \Seen \Recent $MailFlagBit0 $M
ailFlagBit1 $MailFlagBit2 $Forwarded Redirected $NotJunk NotJunk)
  * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \Recent $Ma
ilFlagBit0 $MailFlagBit1 $MailFlagBit2 $Forwarded Redirected $NotJunk NotJun
k \*)]
  C141 OK [READ-WRITE] SELECT completed (took 53 ms)
21:56:54.126 S C142 FETCH 1:* (UID)
* OK FETCH T:1 done
* 1 FETCH (UID 1)
* 2 FETCH (UID 2)
* 3 FETCH (UID 3)
* 4 FETCH (UID 4)
* 5 FETCH (UID 5)
C142 OK FETCH completed (took 14 ms)
R ...(116バイト)
  C142 OK FETCH completed (took 14 ms)
21:56:54.444 E IMAPサーバーからエラーが返りました。エラー内容=OK FETCH T:1 done
(内部情報)mode=69 line=15669
21:56:54.448 (13408) tid=2676 ThreadExit 2676

>  「アカウント毎の設定・メールサーバー・詳細2」の「IMAPゆっくり受信」をON
も試してみましたが、IMAPサーバーのディレクトリ
 "Private/ZZZZZZ"
が異なっていました。

お手数ですが、ご確認お願いします。

[ ]
RE:05213 iCloud IMAP 運用での受信エラーNo.05217
zurarin66 さん 19/06/02 18:34
 
補足です。

> とりあえず今日中に修正版(V6.92β6)をアップロードさせていただきます。少々
>お待ちください。

上記と同じ現象かと思い "V6.92β8" に更新しましたが、変わらず同じエラー内容で
した。

IMAPの動作モードとしては、
 POP3風に〜モード
  重複メール受信しない(有効)
としています。

[ ]
RE:05217 iCloud IMAP 運用での受信エラーNo.05219
秀まるお2 さん 19/06/03 09:31
 
 dump.txtに「UIDL/LISTコマンドの内容」をONにして出力された内容を教えていた
だければ確実にテストできるんですが、とりあえず、エラーで止まってしまうことが
無いように、エラーを無視して続行するようにして一回β版(V6.92β9)をアップ
ロードさせていただきます。

 少々お待ちください。

[ ]
RE:05219 iCloud IMAP 運用での受信エラーNo.05220
秀まるお2 さん 19/06/03 14:27
 
 今β版アップロードしました。

32bit版:
https://hide.maruo.co.jp/software/bin3/hmmail692b9_signed.exe

64bit版:
https://hide.maruo.co.jp/software/bin3/hmmail692b9_x64_signed.exe

 とりあえず、これで、サーバーの応答に理解できない文字列があっても無視するよ
うにしつつ、無視した行についてはやりとり記録に内容をそのまま出力するようにし
ました。

 一応これで大丈夫だと思うんですが、もしかして無視した内容の中にメールのID
(UID)が入っていて、それを正しく解釈しないといけないってことになると、何か
大事なメールがダウンロードされないことが起こりえるかもしれません。

 今回のβ版に入れ替えてから「直前のやりとり記録」で出てくる内容を教えていた
だければ、問題無いかどうか僕の方で判断できると思います。

 よろしくお願いします。


[ ]
RE:05220 iCloud IMAP 運用での受信エラーNo.05221
zurarin66 さん 19/06/03 23:17
 
ご対応ありがとうございました。

Ver6.92b9_x64にバージョンアップし、エラーなく受信できるようになりました。
引き続き、Ver6.92b9_x64を使用していきます。

ログ設定で、「UIDL/LISTコマンドの内容」をONにする前に、バージョンアップして
しまったので、念の為Ver6.91_x64に戻してログ取得しました。
("UIDL,/""すべての〜"を両方有効にしています)

23:09:13.638 (9721) メール一覧を取得中(40/80)
23:09:13.638 (10886) 40/80)
S C80 SELECT "ISP/*****"
R * 33 EXISTS
  * OK [UIDVALIDITY 1507947082]
  * OK [UIDNEXT 35]
  * FLAGS (\Answered \Flagged \Draft \Deleted \Seen \Recent $MailFlagBit0 $M
ailFlagBit1 $MailFlagBit2 $Forwarded Redirected $NotJunk NotJunk)
  * OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \Recent $Ma
ilFlagBit0 $MailFlagBit1 $MailFlagBit2 $Forwarded Redirected $NotJunk NotJun
k \*)]
  C80 OK [READ-WRITE] SELECT completed (took 116 ms)
23:09:14.155 S C81 FETCH 1:* (UID)
* OK FETCH T:1 done
* 1 FETCH (UID 2)
* 2 FETCH (UID 3)
* 3 FETCH (UID 4)
* 4 FETCH (UID 5)
* 5 FETCH (UID 6)
* 6 FETCH (UID 7)
* 7 FETCH (UID 8)
* 8 FETCH (UID 9)
* 9 FETCH (UID 10)
* 10 FETCH (UID 11)
* 11 FETCH (UID 12)
* 12 FETCH (UID 13)
* 13 FETCH (UID 14)
* 14 FETCH (UID 15)
* 15 FETCH (UID 16)
* 16 FETCH (UID 17)
* 17 FETCH (UID 18)
* 18 FETCH (UID 19)
* 19 FETCH (UID 20)
* 20 FETCH (UID 21)
* 21 FETCH (UID 22)
* 22 FETCH (UID 23)
* 23 FETCH (UID 24)
* 24 FETCH (UID 25)
* 25 FETCH (UID 26)
* 26 FETCH (UID 27)
* 27 FETCH (UID 28)
* 28 FETCH (UID 29)
* 29 FETCH (UID 30)
* 30 FETCH (UID 31)
* 31 FETCH (UID 32)
* 32 FETCH (UID 33)
* 33 FETCH (UID 34)
C81 OK FETCH completed (took 27 ms)
R ...(697バイト)
  C81 OK FETCH completed (took 27 ms)
23:09:14.662 E IMAPサーバーからエラーが返りました。エラー内容=OK FETCH T:1 done
(内部情報)mode=69 line=15669
23:09:14.663 (13408) tid=2868 ThreadExit 2868

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

[ ]
RE:05221 iCloud IMAP 運用での受信エラーNo.05222
秀まるお2 さん 19/06/04 09:02
 
 ログありがとうございます。

> 23:09:14.155 S C81 FETCH 1:* (UID)
> * OK FETCH T:1 done
> * 1 FETCH (UID 2)
> * 2 FETCH (UID 3)
・・・

 ということは、1行目が想定外の内容になるんですが、今回のバージョンでこの行
は無視されつつ、2行目以降は正しく解釈されてるので、大丈夫になったと思います。

 なぜにこのフォルダに限って「* OK FETCH T:1 done」のような1行目があるのか
が謎ではありますが、とりあえずそういう事例があるということで、また早めに正式
版をアップロードしたいと思います。

[ ]