重複メールの残す方の選択 - 秀丸メール情報交換会議室 - スレッド27939, 2006/06/28

重複メールの残す方の選択

ごんべ さん　06/06/28 13:13

現在の仕様では「サイズの一番大きいメールだけ残します」となっていますが、「BC
Cのある方を残す」選択を出来るようお願いいたします。
私はBCC送信先記録の残った発信控を残したいのですが、職場の自分のマシンへも送
る設定のため、自分宛の着信も届きます。
すると、現仕様ではヘッダの長い着信メールが重複チェックで残され、BCCの入った
発信控が短いので削除されてしまうので、マニュアル操作でサイズ大の方を削除して
います。
何卒、よろしくお願いいたします。
同時に「重複チェック」のツール・ボタンもあると嬉しいです。

RE:27939 重複メールの残す方の選択

秀まるお2 さん　06/06/28 16:51

　たしかに、Bcc:ヘッダ付きの方というか、送信したメールの方が残ってくれる
べきかと思います。ということで、メールの種別を見て、送信系が受信系よりも
優先して残るようにしようと思いますが、それでいいですよね。

　というか、そういう動作に変更してみます。

RE:27945 重複メールの残す方の選択

ジンハジメ さん　06/06/28 20:09

重複メールの残し方については私も以前に要望をお願いしたことがありました。

Bcc の方ではなく，送信したメールの方を残すために「サイズの小さい方」を選
択できるようにはならないでしょうかというものでした。

そのときは，ダイアログボックスは変更が困難ということで，マクロにて対応を
頂きました（smallretain の追加）。

今回の変更でこういったマクロの動作に矛盾が生じたりすることはないでしょう
か。

RE:27945 重複メールの残す方の選択

きいろいまふらあ さん　06/06/28 20:40

ちょっと気になったので意見を言わせてください。

>　たしかに、Bcc:ヘッダ付きの方というか、送信したメールの方が残ってくれる
>べきかと思います。ということで、メールの種別を見て、送信系が受信系よりも
>優先して残るようにしようと思いますが、それでいいですよね。

例えば、自分がメーリングリストにメールをポストした場合、一般的に残したい
のはメーリングリスト経由で届いた方のメール（受信系）であるような気がしま
すが……。

人により希望する動作が違う、ということに尽きるのですけれど。（そもそも、
送信系と受信系を「重複」と見なすことに、私は違和感を感じます。まあ、私の
感覚の話なんかどうでもいいんですけど。）

RE:27947 重複メールの残す方の選択

秀まるお2 さん　06/06/29 08:17

> 今回の変更でこういったマクロの動作に矛盾が生じたりすることはないでしょう
> か。

　マクロで「サイズが小さい方」とした場合には、そっちが最優先される仕組み
にしました。ということでそれは大丈夫です。

RE:27948 重複メールの残す方の選択

秀まるお2 さん　06/06/29 08:31

　最終的には、そういう、重複の判定基準や残す方の優先順位までカスタマイズ
できねばってことになるかもしれまんが。

　今のところは、そんなに細かくルールを気にする人もいないと思うので、余計
な設定ばかり増やすのはやめておきます。

RE:27953 重複メールの残す方の選択

ごんべ さん　06/07/03 18:31

発信も着信もヘッダが欲しい方は両方残せばよいことで、違和感云々は、重複チェッ
クの仕様と関係ない話と思います。
BCC宛先という貴重な情報を残すことはメールの記録性機能面から大切ではないでし
ょうか。
マクロでも結構ですので、ぜひBCC記録のある方を残す手段をよろしくお願いいたし
ます。

RE:27962 重複メールの残す方の選択

秀まるお2 さん　06/07/03 22:46

> マクロでも結構ですので、ぜひBCC記録のある方を残す手段をよろしくお願いいたし
> ます。

　これはこれで、β15からそういう動作になってます。（今現在の最新版はβ16
ですが）

　送信系のメールと受信系のメールがある場合は送信系のメールの方が優先して
残るようになっています。

RE:27963 重複メールの残す方の選択

ごんべ さん　06/07/05 12:36

早速のご対応を有り難うございました。
使わせていただきました。
期待どおりでとても嬉しいです。

RE:27963 重複メールの残す方の選択

cuma さん　07/02/05 15:05

>　送信系のメールと受信系のメールがある場合は送信系のメールの方が優先して
>残るようになっています。

cumaです。
私もビジネス用途なので、BCCが残るのは大歓迎です。
確かにメーリングリスト投稿の場合は、メーリングリストから配信された方の受信
メールを記録として残したい気持ちはありますが、でもビジネス用途の方をとりあえ
ずは重視してうれしいです。

将来的にはメーリングリスト経由のメールの場合は受信を優先とかなったらますます
うれしいですが、私は現状でとても助かります。

RE:30220 重複メールの残す方の選択

cuma さん　07/02/09 19:39

送信系メールが残って良いと思っていたのですがトラブル？になるかもしれないです。
ビジネス用途のPCでBCC送信する理由の１つは自分のPCに戻ってくる内用を確認です
が、もう一つの重要な目的は、
BCCで自分の他の場所のPC（つまり会社と自宅とかデスクトップとノートとか）に同
一履歴を残したい場合です。
ところが現在の仕様だと重複メール削除の結果として送信系が残るので逆に言えばBC
Cで回って来て受信されたメールが削除されます。
ここまでは問題無いですが、これをゴミ箱削除した場合は、サーバーからもメールが
削除されるので、他のPCで受信した時にはすでにBCCで送信したつもりのメールは無
くなっているようです。
ゴミ箱削除とサーバーから削除を連動させなければと思っても、実際はふつうの話と
してはスパムその他の不要メールをゴミ箱から削除したらサーバーからも消したいで
すし。
どうしたら良いのかわからなくなりましたが、送信系を残すと言う案はユーザで逆に
設定も可能だと助かります。
話が変わって済みません。

RE:30292 重複メールの残す方の選択

hajimett さん　07/02/14 12:21

私も似たような運用を模索して色々悩んだ経験があります
件の問題は、今回の仕様変更に限定せず生じ得るのではな
いでしょうか
私の困っている点は、たとえば、「受信解析のやり直し」
をして、ダブったファイル、別のアカウントで受け取って
いたものについて整理した結果同じフォルダにダブったフ
ァイルなどの重複削除処理をしたときに、ゴミ箱を空にし
たところで、サーバのファイルも削除されてしまうという
事態です。そういうややこしいことをしたファイルこそ、
変に参照する必要が生じたりして、、「ああ、そうか！」
と見あたらない要因に納得した覚えがあります。安全を優
先するなら、多少の見栄えの悪さやディスクの圧迫は我慢
した方が良いと云うことかもしれませんが。スパムや異様
にサイズの大きなファイルはどんどん削除しておきたいと
いう思いもありますし、なかなか最適解が見つかりません。
皆さんは、どのように工夫されていらっしゃるのでしょう
か。

RE:30305 重複メールの残す方の選択

EA11R さん　07/02/14 13:16

EA11R＠一般ユーザです。

>私も似たような運用を模索して色々悩んだ経験があります
>件の問題は、今回の仕様変更に限定せず生じ得るのではな
>いでしょうか
>私の困っている点は、たとえば、「受信解析のやり直し」
>をして、ダブったファイル、別のアカウントで受け取って
>いたものについて整理した結果同じフォルダにダブったフ
>ァイルなどの重複削除処理をしたときに、ゴミ箱を空にし
>たところで、サーバのファイルも削除されてしまうという
>事態です。そういうややこしいことをしたファイルこそ、
>変に参照する必要が生じたりして、、「ああ、そうか！」
>と見あたらない要因に納得した覚えがあります。安全を優
>先するなら、多少の見栄えの悪さやディスクの圧迫は我慢
>した方が良いと云うことかもしれませんが。スパムや異様
>にサイズの大きなファイルはどんどん削除しておきたいと
>いう思いもありますし、なかなか最適解が見つかりません。
>皆さんは、どのように工夫されていらっしゃるのでしょう
>か。

特に不都合は感じてません。

spam扱いのメールはとりあえず隔離フォルダに優先的に振り分けているし、
本当に不要なメールしかなければ、ただ1クッション、「リモートメール-
現在メールを削除」をするだけだし。

必要なメールが存在するかもしれないのに、ローカルから削除したらサー
バからも削除する設定にするのは、無謀な気はしますが…。

と言うか、アカウントの設定で「削除されたメールは次回送受信時に～」
をチェックしなくても、削除されたメールは、勝手にサーバから削除され
ちゃってるんでしょうか。

RE:30305 重複メールの残す方の選択

Iranoan さん　07/02/14 14:44

　hajimett さん今日は、Iranoan です。
> 安全を優
> 先するなら、多少の見栄えの悪さやディスクの圧迫は我慢
> した方が良いと云うことかもしれませんが。スパムや異様
> にサイズの大きなファイルはどんどん削除しておきたいと
> いう思いもありますし、なかなか最適解が見つかりません。
> 皆さんは、どのように工夫されていらっしゃるのでしょう
> か。
　私は安全第一です。スパムにしても重複メールにしても通常の削除にしても、
必ず一旦「ゴミ箱」に移すようにしています。完全削除はもちろん、サーバか
らの削除は使いません。その上で
・「ゴミ箱」は 3 ヶ月以上古いメールを自動で削除
・サーバのメールは受信後 2 日で削除
にしています。本当はもっと長くしたいのですが、あまり長いと持ち出しキッ
トで使う時に携帯ストレージに入りきらないので。
　また複数の場所からアクセスするので、何時も同期を取るようにしています。

　後は、重複メールが起きないように、ML に投稿するメールは、送信時に
「ゴミ箱」に振り分けています。

RE:30306 重複メールの残す方の選択

hajimett さん　07/02/26 15:08

EA11Rさん　コメントありがとうございました

>必要なメールが存在するかもしれないのに、ローカルから削除したらサー
>バからも削除する設定にするのは、無謀な気はしますが…。
>
>と言うか、アカウントの設定で「削除されたメールは次回送受信時に～」
>をチェックしなくても、削除されたメールは、勝手にサーバから削除され
>ちゃってるんでしょうか。

やはり無謀ですかね。
ローカルで削除したものがサーバからも消えていくという「削除された
メールは次回送受信時に～」ってオプションが、ローカルとサーバを一
致(同期？)させている感じで、発想として面白くて、活用してみている
のですが。
WebMailでアクセスするとき、サーバをローカルと同じようなラインナ
ップにしておくと良い感じなんです。といっても、結局振り分けとかも
してくれていないので、SPAMやトラフィックの多いMLの記事がリストか
ら消えていてくれるって程度の感じ良さなんですが。確かに、リスクと
のバランスは悪いかも知れません。。

Iranoanさん　コメントありがとうございました

>　後は、重複メールが起きないように、ML に投稿するメールは、送信時に
>「ゴミ箱」に振り分けています。

これは私も設定してあります。
これに気付いてからずいぶんとすっきり管理できています。

あとは、何かの拍子に生じた重複メールの扱いだけなんですが。

マクロで、
０）ゴミ箱のリストを提示し確認を求める
　　　＋中身を見たり確認ができる猶予を残す
　　　OKなり、なにか先に進めるアクションをおこすと
１）重複メールの確認処理する前にゴミ箱を空にする
２）重複メールの処理をする
３）「削除されたメールは次回送受信時に～」のオプションを外す
４）ゴミ箱のリストを提示し確認を求める
　　　＋中身を見たり確認ができる猶予を残す
　　　OKなり、なにか先に進めるアクションをおこすと
５）ゴミ箱を空にする
６）「削除されたメールは次回送受信時に～」のオプションを入れる
ってなことは、可能でしょうか。
重複メールの処理って、このオプションが絡むのですが、
手作業でけしちゃった場合の影響とか、あまり意識していない人が
居るかもしれません。
そんなことが影響する運用しているのはごくマイノリティかな？

実はマクロまだ使ったことありません。

RE:30428 重複メールの残す方の選択

Iranoan さん　07/02/26 17:59

　hajimett さん今日は、Iranoan です。
> マクロで、
<snup>
> ってなことは、可能でしょうか。
　あまりしっかり読んでいないけれど、おそらく可能です。ただ実用的な形に
なるかなどを考えると、とても作る気にはなりません。(どのオプションが影
響するか調べるのも大変だし。)