V1.43：受信サイズの相違 - 秀丸メール・バグ関係 - スレッド06018, 2001/10/30

V1.43：受信サイズの相違

江袋さん　01/10/30 19:12

秀まるおさん、こんにちは。

先ほどメールを受信していて気がついたのですが、受信中に

　受信済み／受信予定

といった具合に受信状況（サイズ）が表示されると思います。

このとき、受信予定サイズが最初162Kと表示されました。そして、順調
に受信が進み、受信済みサイズがカウントアップ。そのうち、162Kまで
カウントアップしたら、さらにカウントアップが進み、最終的には223K
に達してしまいました。

どうもこれは誤差にしては大きすぎる値なので、不具合なのかと思って
ご報告した次第です。

ちなみに、メール一覧の画面で問題のメールのサイズを見ると

　受信フォルダー：162K
　受信ログフォルダー：223K

と表示されており、このメールは

｜Content-Type: multipart/mixed; boundary="Boundary_3bde767749d0_Level0"
｜（この上までがヘッダー）
｜（この下からが本文）
｜--Boundary_3bde767749d0_Level0
｜Content-Type: text/plain; charset=iso-2022-jp

といったちょっと特殊かなと思われる「ヘッダー＋本文」の構成になっ
ているものです。

他にも必要な情報があればおっしゃって下さい。

RE:06018 V1.43：受信サイズの相違

秀まるお さん　01/10/31 17:14

　鶴亀メールの受信要諦サイズは、メールサーバーにLISTコマンドを送って返
ってくる結果から計算しています。たぶんそのLISTコマンドの結果が間違って
いるんだと思います。

　LISTコマンドを送ったとき、例えばメールが２通あったとすると、

1 1000
2 2000

　のような文字列が返ってきます。上記の場合、１番目のメールサイズは1000
バイトで、２番目のメールサイズは2000バイトという意味になります。鶴亀
メールはこの値を使って予定サイズを正しく計算していると思います。

　だから、たぶんメールサーバーがおかしな値を返しているんだと思いますが、
一応、「全般的な設定・基本・詳細」の、「dump.txtに記録する」と「UIDL/
LISTの内容」のチェックボックスをONにすれば、たしかにサーバーが間違って
いるのか鶴亀メールが間違っているのは判断できると思います。

　でも、もうそのメールを（サーバー上から）削除してしまったのなら手遅れ
ではあります。

RE:06022 V1.43：受信サイズの相違

江袋さん　01/11/01 07:52

>一応、「全般的な設定・基本・詳細」の、「dump.txtに記録する」と「UIDL/
>LISTの内容」のチェックボックスをONにすれば、たしかにサーバーが間違って
>いるのか鶴亀メールが間違っているのは判断できると思います。

さっそく前回同様の条件で試したところ、

S LIST
R +OK 1 messages (126980 octets)
R ...(13バイト)
S RETR 1
R +OK 224174 octets
R ...(224174バイト)
07:46:10.387 ( 973) Decoding BASE64 size=220700 sum=16655470 crc=0DEB07C8 st
art="0M8R4KGxGuEAAAAAAAAA" end="AALgEAAAAQAAAAAAAA.."
07:46:10.407 (1051) Result: size=161280 sum=1245 crc=0103A4B8 cCR=2830 cInva
lid=0
07:46:10.507 (1437) fSetReceivedIcon ++
S DELE 1
R +OK message deleted
S QUIT

という結果でした。

これは POPサーバー側の問題と見てよろしいでしょうか？

RE:06029 V1.43：受信サイズの相違

秀まるお さん　01/11/01 10:22

>S LIST
>R +OK 1 messages (126980 octets)
>R ...(13バイト)

　このLISTコマンドの中の「...」の部分を見るためには「UIDL/LISTの内容」
チェックボックスをONにしていただかないとダメなんですが、その前に

126980 octets

　と出てますので、たぶんメールサーバー上でのメールサイズの計算が間違っ
ているんだと思います。

　しいてその場合でも、

>S RETR 1
>R +OK 224174 octets

　と出ているのでその時点で修正するって手もありますが、そこまでサービス
するのも面倒かなぁと…。

RE:06031 V1.43：受信サイズの相違

江袋さん　01/11/01 11:28

>>R ...(13バイト)
>
>　このLISTコマンドの中の「...」の部分を見るためには「UIDL/LISTの内容」
>チェックボックスをONにしていただかないとダメなんですが、その前に

再試行したところ、

S LIST
R +OK 1 messages (126980 octets)
1 126980
.
R ...(13バイト)
S RETR 1
R +OK 224174 octets

となっていましたので、そうなるとサーバー側の問題となりますね。

>>S RETR 1
>>R +OK 224174 octets
>
>　と出ているのでその時点で修正するって手もありますが、そこまでサービス
>するのも面倒かなぁと…。

上記の
>1 126980
の部分で、正しいサイズが得られるというのがPOP3の仕様なのでしたら、
鶴亀側でそこまでサービスする必要はないと僕も思います。

ということで、LISTで得られるデータの不具合をサーバーの管理者に問
い合わせてみます。

RE:06034 V1.43：受信サイズの相違

江袋さん　01/11/02 10:54

>ということで、LISTで得られるデータの不具合をサーバーの管理者に問
>い合わせてみます。

回答が得られました。

参考までにご紹介しますが、LISTで得られる値がRETRで得られる値より
も小さいのは、そのメールサーバーが独特(!?)のメール管理をしており、
要するにメールを圧縮して管理しているため、LISTでは圧縮された状態
のサイズを通知し、RETRでは解凍後の実際のサイズを通知する『仕様』
になっているのだそうです。

ご存知の方がいらっしゃったら教えて頂きたいのですが、LISTで返す値
は、必ずしも実際に受信したメールのサイズと等しい必要はないのでし
ょうか!?

RE:06046 V1.43：受信サイズの相違

秀まるお さん　01/11/05 18:27

>要するにメールを圧縮して管理しているため、LISTでは圧縮された状態
>のサイズを通知し、RETRでは解凍後の実際のサイズを通知する『仕様』
>になっているのだそうです。

　メールサーバーがそれを仕様と言うのであれば、鶴亀メールとしてもメール
サイズの計算が狂うのは「仕様」ということで逃げます。

>ご存知の方がいらっしゃったら教えて頂きたいのですが、LISTで返す値
>は、必ずしも実際に受信したメールのサイズと等しい必要はないのでし
>ょうか!?

　たぶん圧縮したサイズでもいいなんて話はありえないと思います。それより
も、そもそもRETRコマンドの応答でメールサイズが返ってくるとはRFC上で決
められた物ではなく、単にいろんなメールサーバーがそうであるという事実だ
けだと思います。

　シンプルなメールサーバーは、単に「+OK」だけを返してきますし、もっと
派手なメールサーバーは「+OK ????octets (???? visible)」とか返す物もあ
るかもしれないです。

　ということで鶴亀メールとしては何もしないでおきます。

RE:06050 V1.43：受信サイズの相違

江袋さん　01/11/06 08:07

>　ということで鶴亀メールとしては何もしないでおきます。

はい、それでよろしいかと思います。

個人的にも、メールサーバーの仕様のほうに違和感を感じますし。

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