リモートメールでのTotal表示No.16178
ssk さん 04/01/13 20:44
 
はじめまして。

鶴亀メールはしばらく使っていますが、最近、リモートメールの機能を利用し始めま
した。

そこで、リモートメールの画面左下にサーバ上のTotalサイズと件数がサーバにより、
正しくない場合があることに気づきました。

サーバ1(正常)
 各メールのサイズの合計(と思われる数値)が表示される。

サーバ2
 Totalサイズにメール件数 Kバイトと表示される
 例: Total=105.0 Kバイト/105通

どちらのサーバもメール一覧のSizeの欄は正しい値が表示されています。

対応方法?回避方法などありましたら、お教えください。

よろしくお願いします。

[ ]
RE:16178 リモートメールでのTotal表示No.16179
ssk さん 04/01/13 20:50
 
環境を書き忘れました。

OS:Windows XP Professional SP1
鶴亀メール:Version 3.11

OSはWindows XP HomeEdition SP1でも同様です。

>はじめまして。
>
>鶴亀メールはしばらく使っていますが、最近、リモートメールの機能を利用し始め
>ました。
>
>そこで、リモートメールの画面左下にサーバ上のTotalサイズと件数がサーバにより、
>正しくない場合があることに気づきました。
>
>サーバ1(正常)
> 各メールのサイズの合計(と思われる数値)が表示される。
>
>サーバ2
> Totalサイズにメール件数 Kバイトと表示される
> 例: Total=105.0 Kバイト/105通
>
>どちらのサーバもメール一覧のSizeの欄は正しい値が表示されています。
>
>対応方法?回避方法などありましたら、お教えください。
>
>よろしくお願いします。

[ ]
RE:16178 リモートメールでのTotal表示No.16181
秀まるお2 さん 04/01/14 01:23
 
 ソースコードを見直したら、そこのトータルバイト数表示は、メールサーバー
にSTATコマンドを送って帰ってくる値をそのまま使ってるだけみたいです。

 なので、たぶんですが、そこのサーバーがそのような適当な値を返してるせい
じゃないかと思います。

 問題のアカウントにてリモートメールの一覧取得をやり直して、「送受信・直
前のやりとり記録...」コマンドにて出てくる内容の、STATコマンドについての
応答部分を見ればはっきりすると思います。

 どうでしょ?

 普通は、

        S STAT
        R +OK 4 6279

 みたいに、+OKの後にメール数、その後ろにバイト数が入っているようです。

[ ]
RE:16181 リモートメールでのTotal表示No.16185
ssk さん 04/01/14 16:30
 
正しく表示されるサーバと、正しく表示されないサーバの両方で、
ログを確認してみました。

ご指摘のとおり、STATコマンドの応答のサイズが表示されていました。


メールサーバを変更することはできないため、次のような機能はないでしょうか?
・実際の一覧のサイズを合計したサイズをTotalのサイズとして表示
・選択した際に「選択中 10/100」と表示されますが、
 選択したメールサイズの合計を合わせて表示


[ ]
RE:16185 リモートメールでのTotal表示No.16192
秀まるお2 さん 04/01/15 13:39
 
 STATコマンドでメールサイズの合計が正しく返ってこない件については、少な
くともメールサーバー側の問題なので、それについては、メールサーバーを管理
してる人に文句を言うべきことかと思います。

 せめて、文句を言うという以前に、そういうおかしいことになってることを管
理者に知らせてあげて、対処しないなら対処しないということだけ確認してもっ
て欲しいです。

[ ]
RE:16192 リモートメールでのTotal表示No.16196
秀まるお2 さん 04/01/15 18:12
 
 追加でコメントしてしまいますが、

 − メールサーバーの管理者は対応する気がない。
 − それなりに多数のユーザーさんが使ってるはずのメールサーバー・
   ソフトであるか、またはそれなりに多数のユーザーさんが会員となって
   いるプロバイダー会社内のメールサーバーである。

 という2つの条件が合うようでしたら、鶴亀メール側でもそれなりの対処をし
てもいいです。

 ただし、もしかすると、メールサイズを計算するための、LISTコマンドの応答
自体もおかしい可能性があります。その場合は対応できません。LISTコマンドの
応答で正しくメールのサイズ(バイト数)が返ってるかどうかも確認して欲しい
です。

[ ]
RE:16192 リモートメールでのTotal表示No.16300
ssk さん 04/01/21 15:35
 
> STATコマンドでメールサイズの合計が正しく返ってこない件については、少な
>くともメールサーバー側の問題なので、それについては、メールサーバーを管理
>してる人に文句を言うべきことかと思います。
>
> せめて、文句を言うという以前に、そういうおかしいことになってることを管
>理者に知らせてあげて、対処しないなら対処しないということだけ確認してもっ
>て欲しいです。

管理者に確認したところ、
・メールサーバはLotus Domino R5.0.8
・メールサーバは社内サーバのため更新は不可

と回答を得ました。

LISTコマンドの応答が正しいかどうかですが、どこを見ればわかるでしょうか?
リモートメールの一覧のSizeの項目は正しく表示されています。


[ ]
RE:16300 リモートメールでのTotal表示No.16302
秀まるお2 さん 04/01/21 16:40
 
> ・メールサーバはLotus Domino R5.0.8

 社内ネットワーク上ではよく使われてますね。

> LISTコマンドの応答が正しいかどうかですが、どこを見ればわかるでしょうか?
> リモートメールの一覧のSizeの項目は正しく表示されています。

 「全般的な設定・上級者向け・動作の記録」の「鶴亀メールの動作をdump.txt
に記録する」をONにして、さらに「UIDL/LISTコマンドの内容」もONにしてOKし
て、その状態で一度何かメールを受信して欲しいです。

 それで作成されたdump.txtを見ると、例えば僕の場合だと、

16:33:12.539 R +OK 1 1083
16:33:12.549 S LIST
16:33:12.549 S UIDL
16:33:12.589 R +OK 1 visible messages (1083 octets)
16:33:12.589 (3146) メール一覧を取得中(16%)
1 1083
.
16:33:12.619 (3146) メール一覧を取得中(50%)
16:33:12.619 R ...(11バイト)
16:33:12.629 (3146) メール一覧を取得中(50%)
16:33:12.800 R +OK uidl command accepted.
16:33:12.810 (3146) メール一覧を取得中(100%)
16:33:12.810 R ...(27バイト)
16:33:12.810 (3146) 0 / 1 済み (0.0K / 1Kバイト)
16:33:12.810 S RETR 1
16:33:12.850 R +OK 1083 octets
16:33:12.850 (3146) 0 / 1 済み (0.0K / 1Kバイト)
16:33:13.010 R ...(1086バイト)
16:33:13.010 (3146) 1 / 1 済み (1.0K / 1Kバイト)
16:33:13.090 (3525) 斉藤秀夫メイン,6 cEach=0

 みたいな記録が取れます。上記の場合、LISTコマンドの応答は

    1 1083

 でして、1083バイトのメールがあると返ってます。

 最後の「S RETR 1」の応答が、「+OK 1083 octets」となってまして、たしか
にLISTコマンドで返ってきたメールサイズとRETRコマンドで返ってくるメールサ
イズが同じになってます。

 実際に受信したメールデータのサイズは「R ...(1086バイト)」の部分で、
1086バイトってことになりますが、このサイズはメールサイズよりは少し大きめ
になります。

 この辺の動作を確認いただきたいと思いますが、分からなければ、上記のよう
な内容をごっそりここに書き込んでいただければ、僕の方で判断できます。

[ ]
RE:16302 リモートメールでのTotal表示No.16305
ssk さん 04/01/21 20:02
 
> この辺の動作を確認いただきたいと思いますが、分からなければ、上記のよう
>な内容をごっそりここに書き込んでいただければ、僕の方で判断できます。

一部抜粋した内容を転記します。
よろしくお願いします。

19:49:30.465 (5948) メール一覧を取得中
19:49:30.465 S STAT
19:49:30.465 R +OK 152 155648
19:49:30.465 S LIST
19:49:30.465 S UIDL
19:49:30.465 R +OK 152 messages.
19:49:30.465 (5948) (0%)
1 7760
19:49:30.512 (5950) -
2 13435
3 25566
4 13859
5 2525
6 17824
7 3228
8 1847
9 6308
10 2294
11 1905
12 4618
19:49:30.698 (5948) 4%)
13 302834
19:49:30.916 (5950) -
14 577654
19:49:31.133 (5950) -
15 1061823
16 5789
17 7636
18 14336
19:49:31.350 (5948) 6%)
19 56677
20 8708
21 19041
19:49:31.568 (5948) 7%)
22 577969
23 1745
24 2684
25 5340
26 19988
27 8110
28 3210
29 3948
30 5367
31 9765
32 12279
33 16463
19:49:31.785 (5948) 11%)
34 57150
35 37428
36 2678
37 2877
38 10209
39 5634
40 5245
41 34960
42 12894
43 3894
44 2187
45 6715
46 3162
47 7036
19:49:32.002 (5948) 5%)
48 5175
49 5647
50 4213
51 7258
52 8042
53 2767
54 2950
55 4498
56 72425
57 3971
19:49:32.220 (5948) 8%)
58 3249
59 26669
60 3524
61 15639
62 3874
19:49:32.437 (5948) 20%)
63 2759401
19:49:32.980 (5950) -
64 4773693
19:49:34.828 (5948) 1%)
65 68339
66 1807
67 7787
68 3037
69 2720
19:49:35.045 (5948) 2%)
70 461613
71 4579
72 2105
19:49:35.263 (5948) 3%)
73 84558
74 124640
75 4763
76 11625
77 2519
78 2906
19:49:35.480 (5948) 5%)
79 12852
80 5623
81 25578
82 3235
83 51097
84 4786
85 11698
86 8213
87 28375
88 3621
89 3731
90 14960
19:49:35.697 (5948) 9%)
91 4394
92 197380
19:49:35.915 (5948) 30%)
93 103919
94 5212
95 2547
96 20111
97 6398
98 1624
99 32908
100 11272
101 7481
102 40191
103 2005
19:49:36.132 (5948) 3%)
104 1836
105 7509
106 3720
107 40298
108 60621
109 79159
110 5197
111 6167
112 7437
113 37993
19:49:36.349 (5948) 7%)
114 2020
115 2190
116 8866
117 3646
19:49:36.567 (5948) 8%)
118 265772
19:49:37.483 (5950) -
119 64857
19:49:37.747 (5950) -
120 48058
121 6988
122 8646
123 2322
19:49:37.871 (5948) 40%)
124 1322628
19:49:38.445 (5950) -
125 4949
126 3187
127 7358
128 3908
129 8850
130 3018
19:49:38.631 (5948) 2%)
131 97742
132 2931
133 3746
134 8070
135 2203
136 3859
137 2616
138 3890
139 4972
140 1848
141 3020
142 3189
143 13620
19:49:38.849 (5948) 6%)
144 13683
19:49:38.957 (5948) 7%)
145 143447
146 2210
147 18068
148 1766
149 5024
150 2635
151 2956
152 1336
.
19:49:39.113 (5948) 50%)
19:49:39.113 R ...(1486バイト)
19:49:39.113 R +OK
19:49:39.113 (5948) 62%)
39 900CBE5D16E3D1FA49256E200007B16A

・ 途中抜粋します

152 FCBCAAE7C4BBBA0349256E22003B794D
.
19:49:39.283 (5948) 100%)
19:49:39.283 R ...(5671バイト)
19:49:39.283 (5948) 0 / 1 済み (0.0K / 1Kバイト)
19:49:39.283 S RETR 152
19:49:39.299 R +OK 1336 octets
19:49:39.299 (5950) -
19:49:39.501 R ...(1339バイト)
19:49:39.501 (5948) 1 / 1 済み (1.3K / 1Kバイト)



[ ]
RE:16305 リモートメールでのTotal表示No.16315
秀まるお2 さん 04/01/22 14:58
 
 LISTコマンドの結果もRETRコマンドの結果も正しくメールサイズを返すようで
す。ならば対応できます。

 V3.20系で対応しますので、それまで待って欲しいです。

[ ]
RE:16315 リモートメールでのTotal表示No.16323
秀まるお2 さん 04/01/22 16:37
 
 っといいつつ、V3.17を出さないといけなくなったので、ここの対応も今から
やります。

[ ]
RE:16315 リモートメールでのTotal表示No.16325
ssk さん 04/01/22 19:30
 
> LISTコマンドの結果もRETRコマンドの結果も正しくメールサイズを返すようで
>す。ならば対応できます。
>
> V3.20系で対応しますので、それまで待って欲しいです。

ありがとうございます。
対応バージョンで確認して、報告します。

[ ]
RE:16315 リモートメールでのTotal表示No.16454
ssk さん 04/01/30 20:01
 
Ver3.17で動作確認をしたところ、正常に表示できました。

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


[ ]