Thunderbird を Windows のみで利用 している頃は
メールデータを別パーティションに置いていても
そういう症状は起きなかったのですが、
別パーティションのメールデータを
Linux と Windows
で共同利用するようになってから
下記の症状が発生するようになりました。
Linux のディストリビューションは Debian で、
Thunderbird というより Iceweasel の名称になっております。

どういう症状かといいますと、
既にダウンロードしたことのある既読メールが
メールソフトのメールボックスにおいて削除済み・未削除のいずれであるかを問わずに
サーバーに残っているもの全てが続々とダウンロードされてくる、
という症状で、時々発生しています。
ちなみに、
@nifty のアカウント方でこの症状が発生しており
gmail のアカウントではこの症状は発生しておりません。
(パーティションを共同利用する前は @nifty でも発生しませんでした)
ただ、 gmail においては
サーバ設定のユーザ名の欄で、メールアドレスの前に
recent:
をつけないと新着メールがダウンロードされないような状態です。
（これは直近１ヶ月分をダウンロードするための方法です）

ちなみに、
Linux は Windows とは違い
別パーティションは基本的にマウント操作をしないと認識しないので
(この機会に /etc/fstab を修正しておきます)
うっかりメールデータのパーティションを
未マウントの状態で iceweasel を起動した時は
ダウンロード済みのメールボックスが空であるように表示されてしまいますが、
ひょっとすると
このことと関係があるでしょうか？
ただし、既読メールの一斉ダウンロードは Windows においても起きるようになっています。

何か思い当たることがある方は、どうぞ情報をお寄せ下さい。
よろしくお願いいたします。

_________________
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0

　
＊質問・投稿する前に、サポートサイトやヘルプ、このフォーラム内を検索・閲覧して
　該当項目、同類・類似事例がないか、確認してみましょう。
　また、広くインターネット上でも、同類・類似事例がないか、調べてみましょう。
＊質問・投稿する前に フォーラムの利用について をしっかり読んで、その内容を理解
　した上で、それに沿って投稿しましょう。
＊ご自分の利用環境として、正確な OS の種類と Thunderbird のバージョンぐらいは
　書き添えましょう。
＊質問した後やアドバイスをもらった後は、放置せずに、結果や経緯を必ず書くように
　しましょう。ここは、ユーザ同士で、各種情報・事例を、シェアする場です。　
　
　
[その１]
「別パーティションのメールデータを Linux と Windows で共同利用」とは、具体的にどのように
されているのでしょうか？
例えば、次の内容です。

・Thunderbird のプロファイルの場所は、どこなのか
・Thunderbird のプロファイルは、ひとつなのか
　それとも Linux 用と Windows 用の複数利用なのか
　複数利用ならば、どのように設定・利用しているのか
・問題のメッセージデータは、どのフォルダあるいはファイルを指すのか
　また、それを、どこの場所に置いているのか
・Linux および Windows の双方からのアクセス権は、どのように設定しているのか
・「別パーティション」とは、具体的にどこで、どのような状態にしているのか


[その２]
問題の起きている @nifty のアカウント種別は、POP ですか？
それとも IMAP ですか？


[その３]
POP アカウントの場合、popstate.dat というファイルが、受信済みかどうかを識別する記録情報を
保管しています。
このファイルの情報を元にして、受信済みメールを区別して、新着メールのみを新たに受信するしく
みです。

このファイルがなかったり、正常に認識できない状態だったり、壊れている場合は、サーバ上にある
メッセージをすべて受信します。

この事から、推測ですが、何らかの問題があって popstate.dat ファイルを正常に扱えていないもの
と思われます。

問題の起きている @nifty のアカウントの該当ファイルが、どのような状態になっているか確かめて
みてはいかがでしょうか？
　＃別パーティションにあるということですので、Linux および Windows 双方からの
　　アクセス権などに問題がないかどうか、などになるでしょうか。


[補足]
当方は、Linux および Windows OS についてや、その相違点について詳しくありません。
が、異なる OS 間で Thunderbird のプロファイルなどのユーザデータを共有利用する際は、何かし
らの問題が起きてもおかしくないと認識しています。
　＃異なる Windows OS 間でも同様に。

理由は、OS が異なることから、その仕様・環境条件に依存や関連している部分が影響を受けると理
解しているからです。
　＃ファイル名やサイズ・容量の制限などの仕様の違いなど・・・。

また、Linux だけ、あるいは Windows だけで使用するファイル類や、書き換えなどをおこなうファ
イル類などがある可能性も考えられます。
よって、何らかの工夫をしないと、うまく共有利用できない可能性があるかも知れません。

_________________
Mozilla/5.0 (Windows NT 6.1; rv:29.0) Gecko/20100101 Firefox/29.0

早速回答いただきありがとうございます。

まず、Debian使いの皆さんはご存じのことですが
Debian版の thunderbird は
iceweasel（これはfirefoxの対応物）でなくて icedove でした。

共通パーティションは
Windows,Linux 共に特別なパッケージを入れずに読み書きできるようにFAT32 でフォーマットしてあります。
Windows,Debian が置いてあるのと同じ内蔵HDD(Linux流の表記だと /dev/sda)に置いています。

Windows,Linux 双方において
アクセス権は特に制限はしておりません。
コマンドでもってroot(Windows なら administrator)権限でicedove(thunderbird)を立ち上げる、
というようなことは行ったことがなく
普通にショートカットをクリックして立ち上げておりますので、
重複ダウンロードが起きる時と起きない時でアクセス権に変化はないはずです。

thunderbirdのプロファイルは一つです。
メッセージデータの保管場所は
そのFAT32形式のパーティションにはそのまま"FAT32"というラベルをつけていますので、
/media/FAT32/Thunderbird/Profiles/d27vgakb.default/Mail/pop.nifty.com/Inbox
/media/FAT32/Thunderbird/Profiles/d27vgakb.default/Mail/pop.gmail.com/Inbox
となっています。
これを見てもお分かりだと思いますが、どちらもpopアカウントです。
投稿しました後は重複ダウンロードはまだ起きておりません。
@nifty の popstate.dat を見てみましたが
少なくとも現在は特に異常はないようです。

少し実験してみたのですが、
この FAT32 のパーティションをマウントしていない状態で icedove を立ち上げると、
当然ながら過去にダウンロードして削除されていないメールは見えない状態ですが
やはりサーバー上に存在するメールが全て続々とダウンロードされました。
ただし、以前に重複ダウンロードが起きた時は
このFAT32形式のパーティションがマウントされていて
過去にダウンロードされたメールが見えている状態の時に起こっていました。

そのパーティションがマウントされていなくても
/media/FAT32 というフォルダ自体は存在し、やはり
/media/FAT32/Thunderbird/Profiles/d27vgakb.default/Mail/pop.nifty.com/Inbox
(FAT32 のパーティションに存在するものとは別物)
にメールは保存されるようです。

FAT32 のパーティションには他にも多くのフォルダやファイルが置かれて、
マウントされている時は当然ながら
/media/FAT32
の直下にそれらがファイルマネージャで見えています。
このパーティションをマウント解除すると
/media/FAT32
の直下には
/Thunderbird
のディレクトリのみが見えている状態に戻ります。
マウントされている時にこの別物のフォルダがどこに行っているのかは謎です。

さらに
/home/username/.icedove/u0xy47h5.default/Mail/pop.nifty.com/inbox
というファイルがありましたが、
メールを大量にダウンロードしてもサイズが全く変化せず
全然使われていないなので、これは何なのか分かりません。

あと、Windows,Linux での共有利用に関しましては、
最初は共有利用するつもりでしたものの
現在は Debian 一本で使っていっております。

重複ダウンロードは発生しても
それを一括削除するのはわりあい簡単ではあるのですが、
回数が多くなると削除するつもりのないメールを間違えて削除しても嫌ですし、
多くの方からアドバイスをいただいて
解決に至ることができればありがたいですところですが。


参考のために、
アクセス権につきましては次のようになっておりました。

$ ls -l /media/FAT32/Thunderbird/Profiles/d27vgakb.default/Mail/pop.nifty.com/
合計 42640
-rwxr-xr-x 1 username root 998 12月 5 11:46 Drafts
-rwxr-xr-x 1 username root 4098 1月 16 19:52 Drafts.msf
-rwxr-xr-x 1 username root 40418889 1月 16 20:14 Inbox
-rwxr-xr-x 1 username root 1056282 1月 16 20:14 Inbox.msf
-rwxr-xr-x 1 username root 33472 1月 16 19:52 Sent
-rwxr-xr-x 1 username root 6558 1月 16 19:53 Sent.msf
-rwxr-xr-x 1 username root 1225 12月 5 10:18 Templates.msf
-rwxr-xr-x 1 username root 0 1月 16 20:14 Trash
-rwxr-xr-x 1 username root 2414 1月 16 20:14 Trash.msf
-rwxr-xr-x 1 username root 27 1月 23 2010 msgFilterRules.dat
-rwxr-xr-x 1 username root 67228 1月 16 20:09 popstate.dat

$ ls -l /media/FAT32/Thunderbird/Profiles/d27vgakb.default/Mail/
合計 736
drwxr-xr-x 2 username root 16384 12月 13 17:53 Local Folders
drwxr-xr-x 2 username root 16384 1月 16 20:14 pop.nifty.com
残りは略

Local Folders
は使い方が分からずこれまで利用したことがありません。

一般ユーザー権限で書き込みができないようですので、
icedoveはroot権限で書き込みを行なっているということでしょうか。
この辺は私にはよく分かりません。

_________________
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131030 Firefox/17.0 Iceweasel/17.0.10

あ、それと、
メールデータのパーティションをマウントしてない状態で icedove を起動して
いくつかのメールが重複ダウンロードされてから、
そのパーティションをマウントして icedove を起動し直すと
重複ダウンロードされた分のメールは
ごっそり消えてくれます。
（再起動時に未読メール数として(238)などと表示されていても、受信トレイの中をスクロールしてみると、この表示もすぐに消えます）

_________________
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131030 Firefox/17.0 Iceweasel/17.0.10

　
ズバリ解決策そのものではありませんが、コメントを加えます。
ご了承ください。

　
[Debian 版の Icedove について]
最新バージョンは、Debian 7.3 のようですが、Thunderbird に相当する Debian 版の Icedove の
バージョンが、Windows 版の正規バージョンと一致していない場合は、ひとつのプロファイルの共
有利用で、問題を起こす可能性が考えられます。

Thunderbird (Icedove) 本体側のバージョンが異なれば、当然仕様も異なることになりますから、
注意が必要でしょう。

尚、最初にも書きましたが、Debian のバージョンと Windows の種類、Thunderbird のバージョ
ンと Icedove のバージョン（+ Thunderbird 相当バージョン）を明記されると、後から読まれた方
々から、何かしら情報が得やすくなるかも知れません。


[Thunderbird (Icedove) のプロファイルについて]
別パーティションの Thunderbird (Icedove) のプロファイルが、マウントの有無によって、別物が
同じ場所に存在するというのは、当方にはわかりません。

また、以下のプロファイルが、Thunderbird (Windows) あるいは、Icedove (Debian) で作成され
たものかどうかにも原因があるかも知れません。
[/media/FAT32/Thunderbird/Profiles/d27vgakb.defaul]

通常の Linux 版の Thunderbird のプロファイルの場所は、次のとおりです。
[~/.thunderbird/Profiles/<profile folder>]

参照：プロファイル | 操作方法 | Thunderbird ヘルプ

ですので、以下のプロファイルは、Debian 標準の Icedove のプロファイルではないかと思われます。
/home/username/.icedove/u0xy47h5.default


以下の「-rwxr-xr-x 1」と「username root」が、どういう意味を表わすものなのかを調べてみれば、
判明しませんか。



[プロファイルの共有利用について]
Thunderbird は、異なるバージョンと、異なる OS 間で、ひとつのプロファイルを共有利用すること
を前提に、最適化されているとは思えません。
また、Debian 標準の Icedove は、Debian ディストリビューション用に最適化されたものだと理解
します。
Windows 版の Thunderbird も同様です。

別パーティション + FAT32 ドライブ + マウントの有無 などは、Thunderbird と Icedove から見
れば、異なる環境条件ですから、うまくいけばラッキーのように感じます。
がしかし、popstate.dat ファイルを、正常に認識して、扱えていない現状を伺うと、そうではない状
態のように見受けます。


[別パーティションのマウントについて]
以下のご自身で書かれている内容からですが、別パーティションのマウントの有無によって、問題が起
きているように見受けます。
ならば、マウントをおこなうようにすれば、いいように思えますが・・・。


ということならば、


とあるように、認識するようにされればいいのでは？

別パーティションをマウントすることで、Windows 利用で問題を起こすのならば、別の対処方法とし
て、


とのことですので、


も、よろしいかと感じます。


[補足]
Debian 系のディストリビューションのユーザサイトなどで、同様の事例や、仕様などを参照されてみ
るのもいいかも知れません。
もし、フォーラムがあるようならば、そこで質問してみるのもいいでしょう。

_________________
Mozilla/5.0 (Windows NT 6.1; rv:29.0) Gecko/20100101 Firefox/29.0

「別パーティションのメールデータを Linux と Windows で共同利用」というのは、以下のことをしている、ということですよね。

(1) WinのFAT32なりNTFSのパーティションに、ドライブをX:として、、X:\...\Mail\サーバー名\フォルダー名とかフォルダー名.msfとかフォルダー名.sbdがある。
(2) Winでは、C:\...\profiles.iniでポイントされたプロファイルを使い、その中のサーバー設定のメッセージの保存先で、X:\...\Mail\サーバー名を指定。
(3) Linuxでは、そのパーティションを/abc/.../xyzにマウントし、
Linuxの/.../profiles.iniでポイントされたLinux上のプロファイルを使い、
その中のサーバー設定のメッセージの保存先で、/abc/.../xyz/.../Mail/サーバー名を指定。

これをやった時、既にダウンロードしたメールのUIDLを保存しているpopstate.datは、どちらにおいても、Win上でX:\...\Mail\サーバー名\popstate.datになるファイルが使われ、共有されます。
このpopstate.datの中には、「サーバー名」として、mail.server.serverN.hostname に設定されたものが書かれ、
実際のログインには、mail.server.serverN.realhostname(なければmail.server.serverN.hostnameが使われる) に設定されたものが使われます。
従って、Win上のプロファイル内のrealhostname == Linux上のプロファイル内のrealhostname であって、ログインはできても、
Win上のプロファイル内のhostname != Linux上のプロファイル内のhostname の場合には、popstate.datの中の「サーバー名」のデータは、WinとLinuxで、異なるものが書かれます。

この時、Ｔｈｕｎｄｅｒｂｉｒｄにとっては、複数の異なった「サーバー名」のデータがpopstate.datに書かれるなんてなことは、想定外のそのまた外、の状態ですから、うまいこと自分が書いたpopstate.datの中の「サーバー名」のデータを先に検出すればいいいのですが、
最初から他のThunderbirdが書いた方を先に検出すると、このpopstate.datはきちんと初期化されていないとして、popstate.datのデータを無視し、全メールをダウンロードし直します。
この時、popstate.datは初期化し直されるはずですから、もう一方のOS上のThunderbirdがこのpopstate.datを使った時に、自分の定義上のmail.server.serverN.hostnameが書かれていませんから、こちらのThunderbirdも、同じように、全メールをダウンロードし直して、popstate.datを書き直します。
そして、Ｔｈｕｎｄｅｒｂｉｒｄにとっては、複数の異なった「サーバー名」のデータがpopstate.datに書かれるなんてなことは、想定外のそのまた外、の状態ですから、
いつどの時点でどちらが書いたどのpopstate.datの中の「サーバー名」のデータを検出するか、は、予告不可能。

この状態は、一種の、ユーザーによるppstate.datのデータの破壊と同じ、あるいは、全く異なるサーバー用のpopstate.datファイルをコピーしたのと同じです。

これがあったら話になりませんから、それぞれのTbでの定義、および、popstate.datファイルの中に書かれているサーバー名のデータを、チェックしてみてください。
、

_________________
Mozilla/5.0 (Windows NT 5.1; rv:22.0) Gecko/20100101 Firefox/22.0 SeaMonkey/2.19

kikiさん、WADAさん、
アドバイスありがとうございます。

現在調査中ですので、
しばらくお待ち下さい。
もう少し頭の中を整理してから
返信いたします。

_________________
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131030 Firefox/17.0 Iceweasel/17.0.10

WADAさんが書いて下さったアドバイスの
特に三番目の段落があまり理解できていないのですが、
やっと内容がまとまりましたので、ひとまず書き足させていただきます。
かなり長くなってしまい、申し訳ありません。

まず、前回書き漏らしていたバージョンについてです。
Debian のバージョンはインストール時は 7.2 だったと思うのですが
適用されたアップデートからOSは判断しているようで、
/etc/debian_version によると
Debian 7.3
さらに
Icedove 17.0.10
この Icedove のバージョンが Thunderbird のどのバージョンに
対応しているかは分かりません。
Windows においては
Windows 7 Professional
Thunderbird 24.2.0

昨日のことですが、
Windows 版の Thunderbird のバージョンを確認したついでに
Thunderbird で受信操作をしてみると、
HDD内にある未削除の過去のメールが見えている状態で
また既読メールが続々とダウンロードされました。
このように、別パーティションのマウント操作が必要ない Windows でこの症状が起きます。
途中で LANケーブルを抜いて再起動しDebianでログインし直すと、
Windows で重複ダウンロードされたものは残っていましたが
重複ダウンロードはそれ以上起きませんでした。

ちなみに、Thunderbird のプロファイルは
最初に XP で作成して使っていたものを
Vista に移して数年使用し、
さらに Win7 に移して１ケ月程前まで使用していて、
１ケ月くらい前からは Debian でも使うようになったものです。

それと、重複ダウンロードされたメールの削除が面倒だと書いてある過去の投稿がありますが、
未読・既読でメールを並べ変えるボタンを押し
未読をshiftキーで一括選択してゴミ箱に入れると簡単だと思うのですが、
その投稿の頃はこの機能がなかったのでしょうか。

さて、WADAさんのアドバイスに関することを以下で詳しく書きます。

profiles.ini がそれぞれ
Windowsのパーティション、debianのパーティション、FAT32のデータパーティション
に存在する三つがありまして、
念のために一応コピーしておきます。

パスは基本的に全て Linux で表示されたものを貼っつけておきますが
Windows のシステムパーティションは OS と自動的にラベルされていて/media/OS/Users/username/AppData/Roaming/Thunderbird/profiles.ini
(Windows では C:¥Users¥ysername¥AppData¥Roaming¥Thunderbird¥profiles.ini に相当。
Cパーティション内のファイルは /media/OS/ 以下に配置されているというわけ)
の中身は

[General]
StartWithLastProfile=1
[Profile0]
Name=default
IsRelative=0
Path=E:¥Thunderbird¥Profiles¥d27vgakb.default

debian のパーティションにある
/home/owner/.icedove/profiles.ini
の中身は

[General]
StartWithLastProfile=0
[Profile0]
Name=default
IsRelative=1
Path=u0xy47h5.default
Default=1

FAT32のデータパーティションにあった
/media/FAT32/Thunderbird/profiles.ini
の中身は

[General]
StartWithLastProfile=1
[Profile0]
Name=default
IsRelative=1
Path=d27vgakb.default

となっていたのですが、
これは WindowVista から Windows7に
プロファイルを移す時に自分でコピーしたもののような気がしまして、必要ないファイルかもしれません。

prefs.js の中の(real)hostname につきましては、
全てのケースで行番号が残ってしまっていますが
@nifty,gmail に関係あるところのみ全てコピーします。

/media/OS/Users/username/AppData/Roaming/Thunderbird/Profiles/q8mvw6gs.default/prefs.js
においては
49 user_pref("mail.server.server2.hostname", "Local Folders");
59 user_pref("mail.smtpserver.smtp1.hostname", "smtp.nifty.com");

/home/username/.icedove/u0xy47h5.default/prefs.js
においては
100 user_pref("mail.server.server1.hostname", "pop.nifty.com");
124 user_pref("mail.server.server2.hostname", "Local Folders");
145 user_pref("mail.server.server3.hostname", "pop.googlemail.com");
153 user_pref("mail.server.server3.realhostname", "pop.gmail.com");
165 user_pref("mail.smtpserver.smtp1.hostname", "smtp.nifty.com");
171 user_pref("mail.smtpserver.smtp2.hostname", "smtp.gmail.com");

Windows のシステムパーティションと
Linux のシステムパーティションとにこのファイルが存在しているのは、
おそらくメールデータを引っ越す時に
まずメールアカウントを新しい環境で作らなければいけなかったからです。
そんなことをせずに
プロファイルフォルダをコピーするだけでうまくできる方法があるかもしれませんが、
私はよく分からないものでして。

/media/FAT32/Thunderbird/Profiles/d27vgakb.default/prefs.js
においては
209 user_pref("mail.server.server1.hostname", "Local Folders");
229 user_pref("mail.server.server2.hostname", "pop.nifty.com");
252 user_pref("mail.server.server3.hostname", "pop.gmail.com");
287 user_pref("mail.server.server6.hostname", "smart mailboxes");
295 user_pref("mail.smtpserver.smtp1.hostname", "smtp.nifty.com");
317 user_pref("mail.smtpserver.smtp3.hostname", "smtp.gmail.com");
338 user_pref("mail.smtpserver.smtp6.hostname", "smtp.googlemail.com");
344 user_pref("mail.smtpserver.smtp7.hostname", "smtp.googlemail.com");

一応削らずに載せておきましたが
〜googlemail.com というのは
依然使用していた Livedoor mail のものと思われます。
gmail の Icedove での設定を見ると
popサーバ pop.gmail.com
smtpサーバ smtp.gmail.com
となっていました。

realhostname,hostname については
http://forums.mozillazine.org/viewtopic ... &t=1697195
に書いてありましたが
変更前の hostname を残してあるだけなのですか。
私のケースでは
/home/username/.icedove/u0xy47h5.default/prefs.js
において一カ所だけですが、紛らわしい感じがしますね。

また、
/media/OS/Program Files/Mozilla Thunderbird
には prefs.js はなし。

あと、「prefs.js」 で検索すると
prefs.js.msf
channel-prefs.js
なるファイルがありましたが、hostname とは書かれておらず、これは関係ないようです。

FAT32 パーティションの popstate.dat に書いてあるサーバー名は
@nifty の方が
4 *pop.nifty.com <@の前の@niftyアカウント名>
1675 *pop.nifty.com <@の前の@niftyアカウント名>@nifty.com
gmail の方が
4 *pop.googlemail.com <@の前のgmailアカウント名>@gmail.com
219 *pop.gmail.com <@の前のgmailアカウント名>
というように、現在は異常なさそうです。

Linux のアクセス権限については慣れてないものでして
前回、

などと寝ぼけたことを書いてしまいました。
私がいつもログインしている「username」アカウントが
Icedove を立ち上げるので、
Icedove はこれらのファイル所有者でもある「username」の権限で書き込みができているだけの話でした。
訂正いたします。

viewtopic.php?t=10179
に書いてあった３つの対応策も試して、
皆さんから何らかのアドバイスがもらえたりして
無事に解決すればいいのですが、
また重複ダウンロードが発生するようであれば、

拡張機能の「ImportExportTools」など使わずとも
複数のメールを同時選択して右クリック、「メッセージを保存」とやれば
簡単に同じフォルダ内のメールが .eml 形式で保存できるようですし
インポートはドラッグ＆ドロップするだけとさらに簡単なので、
Icedove をインストールし直して、
新たにプロファイルを作り直すのもいいのかな、と思い始めたところですが。

_________________
Mozilla/5.0 (Windows NT 6.1; rv:26.0) Gecko/20100101 Firefox/26.0

　
引き続き、気が付いた点だけ、コメントします。


まず、どのバージョンを利用しているのかを、ご自身で把握しておくのは、基本中の基本です。
質問する際は、書き漏らしのないようにお願いします。

先に書いたように、Thunderbird (Windows) と Icedove (Debian) の本体バージョンが異なる場
合は、仕様の違いから、リスクが生じることを、踏まえておいたほうがいいでしょう。

ちなみに、以下によると Icedove 24.2.0-1 パッケージが、すでに公開・配布されているようです。
おそらく、これが Thunderbird 24.2.0 に相当するものでしょう。

[参照]
Debian -- sid の icedove パッケージに関する詳細
Debian -- sid の icedove ソースパッケージに関する詳細

尚、Thunderbird バージョン 17.0 系（ESR 版も）は、すでにサポートが終了したバージョンです
ので、ご利用は推奨されません。

大きなお世話ですが、Debian および Icedove のセキュリティアップデートを適時おこなっていま
すか？
Icedove のアップデートの確認と、その適用は、ユーザ自身がおこなうものですので、OS まかせ
にするものではありません。



「その投稿の頃」が、いつを指すのか不明ですが、Thunderbird では、当初からそのようなメッセ
ージの選択操作はできます。

重複メッセージの場合は、重複したメッセージのどちらを削除対象とするかの選択が手間だというの
と、「未読」と「既読」の区別がつく場合とは、まったく同じではありませんので、正確に状況を読
み解く必要があります。

重複メッセージだと思っていた「未読」メッセージが、実は新着メッセージだった、ということもあ
り得るからです。

その状況・状態の違いによって、操作方法や対処が異なります。


次に、profiles.ini の内容を拝見して、気が付いた点です。

複数のプロファイルがあるようですが、
・Windows で Thunderbird を起動したとき
・Debian で Icedove を起動したとき
に、それぞれ、どのプロファイルで起動しているのかを、確認しておきましょう。

Thunderbird および Icedove 起動後に、ヘルプメニューにある [トラブルシューティング情報] の
中の プロファイルフォルダ [フォルダを開く] をクリックすれば、起動しているプロファイルを開く
ことができます。
そこで、プロファイルフォルダ名、場所を確かめることができます。

その理由は、本来ひとつのプロファイルを Thunderbird (Windows) と Icedove (Debian) で、共
有利用しているのならば、複数のプロファイルが、あちこちに存在していること自体が、おかしいか
らです。

gozilla人 さんが、提示された情報の中だけでも、以下の複数のプロファイルがあります。
・d27vgakb.default
・u0xy47h5.default
・q8mvw6gs.default

ご自身で、区別もつかない状況ならば、把握もできないし、問題も整理できないでしょう。
この機会に、きちんと整理して、きちんと把握しておくのをお勧めします。

また、Debian の /home/owner/.icedove/profiles.ini のプロファイル Path が、
[Path=d27vgakb.default]
となっていますが、正しくは、
[Path=Profiles/d27vgakb.default]
になっているべきと思われます。
　注：但し、これは、Debian 上の Icedove の仕様なのかも知れません。



Thunderbird (Windows) で利用していたプロファイルを、Icedove (Debian) に移行する際は、プ
ロファイルの [中身] のコピー移行で済みます。

そうせずに、新しくプロファイルを作成し、アカウントも新しく作成したのならば、共有利用にはな
りません。

理由は、プロファイル自体（正確には prefs.js）が、まったくの別物になるからです。
prefs.js が別物であれば、アカウント情報も別物になりますので、共有利用すると不整合を起こして
も不思議ではなく、むしろ整合が取れなくなると思われます。

このことから、提示された次の過去トピックの事例とは、異なる問題かと思われます。
[参照：過去トピック事例]
MozillaZine.jp フォーラム - 1ケ月前からのメールを複数回　受信する


【お勧め】
先にも、参照として紹介しましたが、次のヘルプガイドを、今一度よく読んで、しっかりと正しい理
解をすすめてみましょう。

その上で、Thunderbird (Windows) あるいは、Icedove (Debian) のプロファイルのどちらかを基
本にして、正しく一本化して、最初から共有利用をやり直すのがいいでしょう。
　注：Thunderbird (Windows) 、Icedove (Debian) の再インストールではありません。

それでも、OS の違いや、Thunderbird (Windows) 、Icedove (Debian) 本体側の仕様の違いから
うまくいかない可能性もあるかも知れないことを考慮しておきましょう。

[参照]
プロファイル | 操作方法 | Thunderbird ヘルプ
複数のプロファイルを使用する | 操作方法 | Thunderbird ヘルプ

_________________
Mozilla/5.0 (Windows NT 6.1; rv:29.0) Gecko/20100101 Firefox/29.0

言ったとおりのことをしているじゃないですか...
どちらのプロファイルから見ても、自分のhostnameとは違うサーバー名がpopstate.datに書いてあるという大きな異常が発生している...

realhostname/realuserNameは、サーバー名/ユーザー名の変更があった時に、サーバー名/ユーザー名を変えるだけで、それまでの定義やファイルなどは変えなくても済むようにするためであり、ログインにおいて使われます。
realXXXXがなければ、realが付かないほうの設定が、ログインで使われます。
一方、内部的に使われるIdentiierとしては、hostname/userNameが使われ、こちらは、変更されることはありません。
たとえば、mailbox://userName@hostname/Inbox/sub/subsub が、Inbox→sub→subsubというフォルダー。
メッセージフィルターなどでこの形式で使われている可能性があるので、hostname/userNameは変更できない、ということです。
popstate.datに書かれて、popstate.datのデータが正しいかどうかのチェックに使われるデータも同じです。

従って、以下のようにすれば、簡単に問題を引き起こせます。
Profile-A : hostname=a.a.a,userName=userA / realhostname=pop3.gmail.com,realuserName=MyName@gmail.com
Profile-B : hostname=b.b.b,userName=userB / realhostname=pop3.gmail.com,realuserName=MyName@gmail.com
(1) 実際にbugzilla.mozilla.orgに報告された例
PC-1でprofile-Aを使っていて、PC-2のprofile-Bに、PC-1のメールデータとともに、popstate.datをコピーした、
(2) 今回のケース
Profile-AとProfile-Bで、このメールアカウント用のメールディレクトリーを共有　→　同じpopstate.datに、別のプロファイルから書き込み。

どちらも、上記のような明確に違いがわかるものではなくて、pop3.gmx.comでもpop3.gmx.netでも、あるいは、pop3.gmail.comでもpop3.googlemail.comでも、同じユーザーIDでログインできて、同じMboxにアクセスできる、というケースです。

GoogleのPOP3の場合は、POP3経由でメールをダウンロードしたら(RETR)、DLETで削除をリクエストしなくても自動的に削除する、という仕様なので、Profile-Aでメールをダウンロードすれば、サーバーに残す設定(DLETをださない）であろうがなかろうが、Profile-Bではメールをダウンロードできないのは、当然です。
GmailはIMAPをちゃんとサポートとしています。
何で今更、POP3?


prefs.jsというファイルのあるディレクトリーをTbのメールディレクトリーとして使えば、Tbにとっては「prefs.jsというメールフォルダー」用の「prefs.jsというファイル」があることになり、必要となる「prefs.js.msf」を作成、になります。
共有用のパーティションにあるプロファイルディレクトリーを、どれかのアカウントのメールディレクトリーとして使った、ということでしょう。

_________________
Mozilla/5.0 (Windows NT 5.1; rv:22.0) Gecko/20100101 Firefox/22.0 SeaMonkey/2.19

kikiさん、WADAさん、
たびたびお付き合いいただき、誠にありがとうございます。
特に WADAさんのお話は少し難しく
まだ頭の中がゴチャゴチャしていまして
よく整理できていないのですが、
とりあえず途中経過報告です。

Debian で Icedove を初めて使う時に、
メールデータの保存先をそれまでと同じFAT32パーティションの保存ディレクトリに指定して
読み込ませようと思いました。
しかし、Icedove 初回起動時に出てくるメールアカウント作成をスキップすると、
目的のアカウントを選んで
「このアカウントの設定を表示する」
「サーバ設定」
「メールデータの保存先:」
の部分に入力、
という手順を踏むことがをできなかったために、
まず @nifty,gmail のメールアカウントを手で設定してから
メールデータの保存先を入力しました。
そして再起動すると過去に保存してあったメールデータをちゃんと読み込んでくれましたが、
こうしたためにプロファイルが新たに
/home/username/.icedove/u0xy47h5.default/Mail
に作成されてしまったようです。

今回分かりましたが
Icedove(Thunderbirdでも) を初めて起動する前に
プロファイルフォルダをコピーしておけば良かったのですね。

これからはとりあえずは Windows の Thunderbird は使わず
Debian のみで Icedove を使うようにして、
/home/username/.icedove/u0xy47h5.default
のプロファイルのみを使うように Icedove で設定を行ったのですが、
早速全てのメールが重複ダウンロードされてしまいました。
しばらく様子を見たいと思います。



debian系統のディストリビューションにおいては
APT(RedHat系統においてはYUM) という強力なパッケージ管理システムがありまして、
$ sudo apt-get update
$ sudo apt-get upgrade
とやるだけで、OS本体とプレインストールパッケージだけでなく
自分がインストールしたソフト（とその依存パッケージ）まで
全てのパッケージの更新をやってくれます。

http://www.debian.or.jp/blog/news-2001.html

あと、debianには
安定版 stable (現在は wheezy)
テスト版 testing (現在は jessie)
不安定版 unstable (別名 sid)
三つの種類があります。

安定版においては
それぞれのパッケージのメジャーバージョンを据え置くという debian の方針のようで、
発見されたセキュリティホールに対しては
古いバージョンへのパッチを debian が独自に APT によって配布しているようです。
テスト版や不安定版はシステム全体の整合性が取れなくなることもよくあるという話ですので
エンジニア向けであり、
私のような初心者が手を出すべきではありません。



確かに popstate.dat に googlemail と書いてありますね。
また寝ぼけたことを書いてしまったようですが、
私のケースでよく分からないのは、
今のことから不備が分かる gmail の方でなくで
@nifty の方で頻繁に重複ダウンロードが起きている点です。
もう少しよく調査してみないといけないようです。



これはどういうことか分からないです。
重複してダウンロードされる、ということとは逆のことのように
私には感じてしまいます。
普段はスマホでメールを読んで PC にもメールデータを保存しておきたいから
POP３ にしています。
私の場合は、PCとスマホの両方から全く同じメール群が
きちんとダウンロードできています。

色々と試してみてまた進展がありましたら、報告させていただきます。

_________________
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131030 Firefox/17.0 Iceweasel/17.0.10

recent: をつけるのは、「メールアドレスの前」では無く、「ユーザーIDの前」ではないですか？
ユーザーIDの文字列=メールアドレスですが、「ユーザーIDの前」であるとちゃんと認識していないと、変な方向に行ってしまいますよ。
上記の説明は、何でまたユーザーIDの前にrecent: をつける、なんてなことをさせるのか、を理解するためのものです。

GmailのPOP3の仕様がそうなっていて、
普通のPOP3サーバーのように、メーラーの「サーバーに残す」設定によって複数のメーラーがPOP3経由でメールデータを共有できるようにするために、今更POP3のシステムをいじるのもお金と労力の無駄だから、
recent: を頭につけてログインしてきたら、Gmailのフロントエンドで、GmailのPOP3サーバーとは違うシステムにとばし、
Web MailとGmail IMAPで共通に利用している、GmailのメールのDBの中の「Inbox」というラベルのついたメールのうちの直近一ヶ月分だけを、POP3のプロトコルを使って返すようにした、というだけの話。
GmailのDBの中のメールには、少なくとも「アカウントのID+そのアカウント用のメールのID」でユニークになるキーがついていますから、
それをそのままUIDLに使うだけで、POP3でのUIDLがユニークになることが保証されます。
だから、単純に「SELECT WHERE アカウント=ユーザー名 AND Inboxというラベルつき AND 受信日<=一ヶ月前」みたいなことをして得られたメールをPOP3のプロトコルで送り返す、だけでUIDLの整合性が保たれますから、Googleにとっては雑作もないこと。
そして、POP3でアクセスすれば、まだ削除されていない(Inboxというラベルがまだついている)、その一ヶ月間のメール全部のUIDLが常に返されるんだから、
popstate.datの中身がおかしな状態を作り出せば、またRETRコマンドを出してメールデータのダウンロードが行われて当然、ということになります。

_________________
Mozilla/5.0 (Windows NT 5.1; rv:22.0) Gecko/20100101 Firefox/22.0 SeaMonkey/2.19

WADAさん、返信ありがとうございます。

こちらはその後、
今のところは重複ダウンロードは起きておりません。

やはり WADAさんのコメントは
私のような初心者には少し難しいお話が多いです。

「UIDLの整合性が保たれます」の部分がよく分からなかったのですが、
あまり重要なことでなければ、
お忙しい中にお時間を取っていただいて
コメントを書き込まれなくても大丈夫です。

_________________
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131030 Firefox/17.0 Iceweasel/17.0.10

popstate.datの中身に問題がないはずのNiftyの方で、LinuxのTbでだけこのpopstate.datを使っていても問題が起こる、
あるいは、LinuxのTbとWinのTbでこのpopstate.datを共有していて問題が起こる、というような場合には、
いずれ、popstate.datのある時点のバックアップをとって中身を調べる、などが必要になってきます。
そのときに、キーとなるUIDLについては、理解できようができまいが、多少なりともUIDLについて知らないと、お話になりません。

popstate.datの中身は、改行コードの違いはあるかもしれないですが、Linux版のTbであろうとWin版のTbであろうと本質的な違いはないはずです。
ですから、あるとすると、以下のバグのような問題かもしれません。
1. ログイン後、LISTコマンドで全メールのメッセージ番号を入手し、
2. UIDLコマンドで全メールのUIDLを入手。
3.　このとき、UIDLコマンドの応答(1メールにつき一行)の途中でネットワークエラーが起こると、それ以降のUIDLのメールはサーバーにない、と誤判定し、既にpopstate.datに書かれているUIDLを消してしまう、というような問題があったはずです。
こういった類の問題は、まだ解決していなかったように思います。

一万通のメールがサーバーにあれば一万行のUIDLレスポンスが返るわけで、大量のメールをPOP3サーバーのMboxにおけば、大量のUIDLレスポンス行の途中でのエラーの確率も上がります。
また、新着メールのダウンロードは、「setTimeoutで次回のダウンロードのスケジュール」の繰り返し、ではなく、setIntervalで各インターバルのダウンロードをスケジュール、です。
このため、ダウンロードの間隔が小さすぎて、一回のダウンロードの処理が完了していない時点で次回のダウンロードがスケジュールされると、実行中のダウンロードの処理が阻害される、というi懸念があります。
こういったことが起こっていてpopstate.datの中身がおかしくなっているかどうかを調べるには、popstate.datの中身を見るしかありません。

重要だからわざわざ書いているのですよ。
たとえ理解できなくても、書いておけば、自分でググるなりして調べるくらいは、誰でもできるでしょう。

Gmailの場合は、LinuxのTbでだけこのpopstate.datを使う場合であろうが、LinuxのTbとWinのTbでこのpopstate.datを共有している場合であろうが、
そのpopstate.datを使おうとするThunderbirdにとって、popstate.datの中のデータが、自分の外側で既に壊されている状態での話ならば、
単に、サポートなさろうとしている方に迷惑をかけるだけであり、お話になりません。
内容を理解して、Gmailの方で、自分のhostnameではないサーバー名がpoptate.datに書かれているという状態を、既にきちんと排除していますか？
Bug 843506は、
pop.gmx.deもpop.gmx.netも同じサーバーで、
hostname=pop.gmx.deで使っていたpopstate.datを、そのままhostname=pop.gmx.net で定義してあるThunderbirdにコピーした時の現象です(あるいはその逆)。
今のままでは、これと同じことが起こり得ます。

_________________
Mozilla/5.0 (Windows NT 5.1; rv:22.0) Gecko/20100101 Firefox/22.0 SeaMonkey/2.19

WADAさん、たびたびのコメントありがとうございます。
返信を急ぐよりも
理解すべきことをある程度きっちり理解してから返信した方がいいかなと思っていましたため、
だいぶ遅くなりました。

まず、これまでに重複ダウンロードは
@niftyの方で何回も起きたのは間違いないのですが、
Gmailで起きたかどうかは申し訳ないのですが記憶がハッキリしません。
これからは、こういうことはきちんと日時などと共にメモするようにしないといけません。

きちんと書いておかなかったのかもしれませんが、
それぞれのアカウントで
popstate.dat の削除、Inbox.msf の削除、各フォルダの最適化
はすでに行っておりました。

それと、UIDLという用語の意味自体は知っておりましたが、
理解の足しにするために
$ openssl s_client -crlf -connect imap.gmail.com:993
とやって、コマンドラインからのメールサーバーへのアクセスを
今回初めて試してみました。
Tbも全体の中の一部としてはこういう単純な動作を組み込んであるのですね。
色々と余計なご心配をおかけしてしまいましたようで、
申し訳ありませんでした。


の部分の意味につきましては、
一ヶ月分のメールを pop3 によってクライアント側が正常に受信し終えることができれば、
その一ヶ月分のものについては
Gmail のサーバーが持っている UIDL のリストと
popstate.dat に記述される UIDL のリストが一致して
整合性がとれた状態を実現できる、
という解釈で合っていますでしょうか？

Bug 843506
のリンクをざっと読んでみましたが、
WADAさんは開発者なのですね。
どおりで難しい内容が多いはずです。
しかし、おかげさまで多くの知識をつけて理解を深めることができました。
大変感謝いたしております。（kikiさんにもですね）
理解力が足りないのは、初心者ですのでどうぞご容赦下さい。

以前に profile を貼り付けた時は、
長時間の作業の後で少しぼんやりしていたために
hostname,realhostname のあたりの不備を見過ごしてしまいましたが、
この内容は今は理解できていると思います。

新着メールのダウンロードは１０分おきに設定しております。
メールは一日にせいぜい１０通くらいですので、
普段のメールチェックにおいて setInterval の問題は発生しないと思われます。

これからどのようにするかですが、
まず Linux,Win のTbで同じプロファイルを共有利用というのは
もうやるつもりはなくなりました。
Debian 一本で使っていきます。

もし次に重複ダウンロードが起きました場合は、
受信専用のアカウントを一つ作り
旧アカウントからそこに全てのメールを転送するようにして
（旧アカウントのサーバーには過去のメールを全て保存しておける）
受信専用のアカウントのサーバーには数週間分くらいのみメールを残しておくようにすれば、
UIDLレスポンス中のネットワークエラーが原因の不具合は
ほとんど起きなくなると思います。

とりあえず今はこう考えております。

_________________
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131030 Firefox/17.0 Iceweasel/17.0.10