メッセージのUniqueId(UID)を使いたいとします。これが特に作成された理由です。
要求された最後のUIDを追跡し、メッセージセット "[UID]:*"を使用するすべての新しいメッセージを要求する場合は、[UID]は実際のUID値です。
たとえば、最後に取り出されたメッセージの一意のIDが「123456」であるとします。あなたはフェッチう
123456:*
その後、最初の返されたメッセージを破棄します。
UIDはセッション全体で安定していて、決して変更されず、常に値が増加すると想定されています。これを確認するキャッチは、フォルダを選択するときにUIDValidityをチェックすることです。 UIDValidity番号が変更されていない場合、UIDはセッション間で有効である必要があります。
ここにRFCからの関連部分があります:
2.3.1.1。一意の識別子(UID)メッセージ属性
一意識別子有効値で使用した場合(以下を参照)は、各メッセージに割り当てられた32ビット値は、他のメッセージを参照してはなりません64ビット値 を形成
同じ名前のメールボックスまたは 後続のメールボックスに永久に保存します。ユニークな識別子 は、メールボックス内で厳密に昇順に割り当てられます。各 メッセージがメールボックスに追加されると、それ以前に追加された メッセージよりも高いUIDが割り当てられます。メッセージシーケンス の番号とは異なり、一意の識別子は必ずしも連続している必要はありません。
メッセージのユニークな識別子は、 セッションの間に変更してはならず、セッション間で変更しないでください(SHOULD NOT)。セッション間での の一意の識別子の変更は、以下で説明する UIDVALIDITYメカニズムを使用して検出できなければなりません。永続的な一意の識別子 は、クライアントがサーバーとの以前の セッションから状態を再同期するために必要です(切断された、またはオフラインのアクセス クライアント)。これについては[IMAP-DISC]で詳しく説明します。
注:次のユニークな識別子の値が に意図された任意の メッセージが、それはこの値をチェックし 前回以降のメールボックスに配信されているかどうかを判断するために、クライアントのための手段を提供します。ここで
は、より多くの情報とのリンクです:
http://www.faqs.org/rfcs/rfc3501.html
私はどうなるのか、また、ダウンロードしたメッセージのINTERNALDATEを追跡しています。こうすることで、UIDの同期を失った場合でも、少なくともメッセージを繰り返して、メッセージのInternalDateに基づいてダウンロードした最後のメッセージを見つけることができます。
はい、これは完璧です!予期しない結果を返すだけの "123:*"ではなく、 "UID 123:*"コマンドを実行してください。 client.Folders.Inbox.Search( "UID 123:*") –