振り分けと同時にサーバーから削除する動No.17594
Takahito さん 04/04/12 14:06
 
こんにちは。

現在、振り分け設定で特定の振り分け設定に割り振られたメールをサーバーから
削除する設定をしているのですが、現在の動きとして、

メールを1通受信

振り分け

サーバーから削除

次のメールを受信

(以下繰り返し)

この、サーバーから削除のシーケンスをを受信が一段落してから一度にやれるよ
うに変更はできないでしょうか?
多少レスポンスの遅いサーバーから受信する場合に、とりあえず一度ダウンロー
ドしてもらえた方が、1通1通削除されるより便利なのですが…


すみません、仕様だとは思っているのですが、改善等が出来るかどうか教えて
いただけますでしょうか?
それとも、マクロでもできますか??

鶴亀:Ver3.53

[ ]
RE:17594 振り分けと同時にサーバーから削No.17609
秀まるお2 さん 04/04/12 19:38
 
 技術的には改善可能だと思うし、たしかにそのようにしたら受信が高速になっ
ていいとは思います。ただ、受信関係をいじってレベルダウンのバグを発生させ
てしまうと怖いので、今はちょっと対応困難です。

 (他にもいろいろ懸案事項が溜まってまして、大変忙しいです)

 マクロでも出来ません。

 ということで、気長にお待ちください。(っと言ってる間に他の要望がどんど
ん届いて、きっと忘れるような気はします)

[ ]
RE:17609 振り分けと同時にサーバーから削No.17642
Takahito さん 04/04/13 12:40
 
お返事ありがとうございます。

> 技術的には改善可能だと思うし、たしかにそのようにしたら受信が高速になっ
>ていいとは思います。ただ、受信関係をいじってレベルダウンのバグを発生させ
>てしまうと怖いので、今はちょっと対応困難です。

> ということで、気長にお待ちください。(っと言ってる間に他の要望がどんど
>ん届いて、きっと忘れるような気はします)

とりあえず、ダイアルアップ時に気になるくらいですので
気長に待つようにいたします。

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

[ ]
RE:17609 振り分けと同時にサーバーから削No.17834
Salem さん 04/04/21 18:15
 
Salemです。

> 技術的には改善可能だと思うし、たしかにそのようにしたら受信が高速になっ
>ていいとは思います。…今はちょっと対応困難です。

個人的な環境で申し訳ないのですが、細い回線(ISDN)で、メールくらい
しか使わないので、ほぼ従量課金型のプロバイダ契約している私として
は、是非とも対応いただきたい機能です。
改善プライオリティの1票アップをお願いします。

[ ]
RE:17834 振り分けと同時にサーバーから削No.17835
takako3 さん 04/04/21 19:48
 
私もこのトピックを作成した方の要望が
将来的に実装されることを希望しています。

受信が終わるまでの時間が飛躍的にちじまりそうなので。

[ ]
RE:17834 振り分けと同時にサーバーから削No.17836
まんぼう さん 04/04/21 20:54
 
> 個人的な環境で申し訳ないのですが、細い回線(ISDN)で、

私もいまだにISDNなので、振り分けでサーバーから削除する場合の
動作速度の遅さは気になっていました。
受信だけ先にパーっとやってしまって、削除を、「*日前のメール
を削除中」のようなスピードでササっとやっていただけたらかなり
速そうだなと、毎日のように思っていました。

やはり難しいのでしょうか?

[ ]
RE:17836 振り分けと同時にサーバーから削No.17837
秀まるお2 さん 04/04/21 22:50
 
 アカウント毎の設定での「メール受信の高速化」がONでないと高速になりませ
んけど、そういうことですよね。

 んじゃ、「メール受信の高速化」がONの場合に限って、RETRが全部終わってか
らまとめてDELEするように修正します。

[ ]
RE:17837 振り分けと同時にサーバーから削No.17839
きいろいまふらあ さん 04/04/22 03:31
 
> んじゃ、「メール受信の高速化」がONの場合に限って、RETRが全部終わってか
>らまとめてDELEするように修正します。

手動で、ないし不可抗力で送受信が中断された場合はどうなりましょうか?
サーバに残す+○日後に削除の場合は、次の送受信の際に削除してくれそうです
が、今回の話の場合はそうもいかないような気がします。

そういうリスクもあるのでそれでも構わない人だけ使ってください、というオプ
ションにはならないですかね?
それとも、受信の高速化の恩恵を享受したい人はそのくらいのリスクは覚悟して
くださいってスタンスになりますか?

[ ]
RE:17839 振り分けと同時にサーバーから削No.17841
秀まるお2 さん 04/04/22 09:09
 
 少なくとも@niftyにおいては、DELEコマンドを送っても、QUITコマンドを送っ
て正常ログアウトしなければメールは削除されなくて、まぁそういうことだから
いいだろうと思ったんですけど…。今、うちのmiteneで試したら、QUITを送らな
くてもDELEを送った段階でメールが削除されました。

 ということは、やはりRETRした直後にDELEした方が無難なようです。といいつ
つも、じゃぁ@niftyの場合はそれでいいのかって気もします。

 まだ何も手はつけてないので、もうちょっと考えます。

[ ]
RE:17837 振り分けと同時にサーバーから削No.17842
Salem さん 04/04/22 09:50
 
しまった。また誤解してしまったSalemです。

(受信→振分→削除)xメール件数



(受信→削除)xメール件数→(回線切断OK)振分

にして欲しいという要望と勘違いしました。

私が1票入れたのは、メールサーバとのやり取りを一通りやり終わって、振り
分け処理をしてくれると、回線利用時間を短くできるのになぁと思ったからで
す。失礼しました。

[ ]
RE:17841 振り分けと同時にサーバーから削No.17843
ポン太 さん 04/04/22 10:05
 
秀まるお2 さん、こんにちは。ポン太 です。


> 少なくとも@niftyにおいては、DELEコマンドを送っても、QUITコマンドを送っ
>て正常ログアウトしなければメールは削除されなくて、まぁそういうことだから
>いいだろうと思ったんですけど…。今、うちのmiteneで試したら、QUITを送らな
>くてもDELEを送った段階でメールが削除されました。

これは@niftyの動作が正常だと思います。DELEを送った段階で削除されたら、
RSETの時にはどうしてくれるの?ってことになりません?
まぁだからといってそういう動作をするサーバーを無視して良いのか、っていう
と難しい問題ですね。


2004/04/22(木) 10:03 ポン太

[ ]
RE:17843 振り分けと同時にサーバーから削No.17844
秀まるお2 さん 04/04/22 10:53
 
 仮に、「DELEしてもQUITしなければメールが削除されない」というのが世の中
の当たり前だったとしたら、きいろいまふらあさんのご指摘された懸案事項は、
既に今の鶴亀メールでも起きてることになります。つまり、「サーバーから削
除」の振り分け動作をしたつもりでも、受信を途中でキャンセルした場合は削除
されずに残ってしまいます。

 はたしてそういうメールがいつになったら削除されるのかというと、最終的に
は普通のメールと同じように「一定期間置いてから削除」が有効であればその期
間後に消えるってことなんでしょうね。

 ということで、既にそういう状態なのだから、しいてDELEを最後に持っていて
もいいかなぁと思います。

 どうでしょ?

-----------
 DELE要求したメールは、受信を中断しても確実にDELEされるようにして欲しい
ということになると、例えば巨大なメールをRETRしてる最中に「中断」としても、
RETRが終了するまでずっと待ち続けないといけなくなります。これはかなりスト
レスになると思うので、対応不可です。

 試しに、RETRしてる最中に無理矢理QUITを送ってソケットをshutdown &
closesocketしてみましたが、QUITは無視され、メールは削除されませんでした。

[ ]
RE:17842 振り分けと同時にサーバーから削No.17846
秀まるお2 さん 04/04/22 11:23
 
 現状で、

 1.「メール受信の高速化」がONで、
 2.「受信したメールをサーバー上に残す」がONで、
 3.振り分け設定での「サーバーから削除」を1つも使ってない

 というケースであれば、振り分けおよびメールの保存をする前に、次のメール
の受信コマンド(RETRコマンド)を送ってしまいます。なので、振り分け動作に
かかる時間は受信速度にほとんど影響しないはずです。

 今回の話では、「サーバーから削除」の受信動作や、そもそも「受信したメー
ルをサーバー上に残す」がOFFであってもRETRコマンドをフライング送信して欲
しい(DELEコマンドはあとでまとめて送って欲しい)という話だと僕は解釈して
います。それはそれで、かなり高速化する可能性があると思います。

[ ]
RE:17844 振り分けと同時にサーバーから削No.17847
ポン太 さん 04/04/22 11:31
 
秀まるお2 さん、こんにちは。ポン太 です。


> 仮に、「DELEしてもQUITしなければメールが削除されない」というのが世の中
>の当たり前だったとしたら、きいろいまふらあさんのご指摘された懸案事項は、

世の中の当たり前というと微妙ですが、STD53的にはそれが正解です(RFCやSTD
に沿ってないものを受け付けないソフトは、それはそれでやっかいですが)。
http://rfc.net/std0053.html から引用

>     DELE msg
<snip>
>         Discussion:
>             The POP3 server marks the message as deleted.  Any future
>             reference to the message-number associated with the message
>             in a POP3 command generates an error.  The POP3 server does
>             not actually delete the message until the POP3 session
>             enters the UPDATE state.

>6. The UPDATE State
<snip>
>   If a session terminates for some reason other than a client-issued
>   QUIT command, the POP3 session does NOT enter the UPDATE state and
>   MUST not remove any messages from the maildrop.


> ということで、既にそういう状態なのだから、しいてDELEを最後に持っていて
>もいいかなぁと思います。
>
> どうでしょ?

鶴亀の仕様をどうするかという点では、スレッドを読んでいないので解りません。
(^_^;


2004/04/22(木) 11:23 ポン太

[ ]
RE:17846 振り分けと同時にサーバーから削No.17855
Salem さん 04/04/22 12:26
 
秀まるお2さん、Salemです。返答ありがとうございます。

┃ 現状で、

┃ 1.「メール受信の高速化」がONで、
┃ 2.「受信したメールをサーバー上に残す」がONで、
┃ 3.振り分け設定での「サーバーから削除」を1つも使ってない

┃ というケースであれば、振り分けおよびメールの保存をする前に、次の
メール
┃の受信コマンド(RETRコマンド)を送ってしまいます。なので、振り分け動
作に
┃かかる時間は受信速度にほとんど影響しないはずです。

振り分け処理は手動化で後回しにすると言う事で、了解しました。
私の場合、メールをサーバーに残したくないので、DELE待ちは残念ながら、無
理ですが、まぁその部分はしょうがいないです。

┃ 今回の話では、「サーバーから削除」の受信動作や、そもそも…
┃…という話だと僕は解釈しています。

はい。この部分が解釈ミスという事でした。

[ ]
RE:17847 振り分けと同時にサーバーから削No.17887
秀まるお2 さん 04/04/25 23:12
 
 やはりDELEコマンドは最後にまとめて実行するってことにしようと思います。
「メール受信の高速化」がONの場合に限ってそのようにしようと思います。

 っといいつつも、この修正は「メール受信の高速化」と密接に関係して非常に
ややこしいので、また今度の暇そうな時に修正します。

[ ]