|Subject:||Re: Duplicate emails when emails left on server|
|Posted by:||Remy Lebeau (TeamB) (firstname.lastname@example.org)|
|Date:||Tue, 21 Dec 2004|
"Jon E. Scott" <NOSPAMsuppo…@blueorbsoft.comNOSPAM> wrote in message
> Users can configure this product to leave messages on server, otherwise
> we delete them off the server using the call TIdPOP3.Delete(). The
> problem arises when the next time our program checks for mail, the same
> emails are downloaded again and entered into our database resulting in
If you call Delete() and it does not return an error, and you then call
Disconnect() and it does not return an error, then there is no way for you
to be getting duplicate messages from the server. Are you clearing the
TIdMessage before each download?
The alternative is to look at the actual MsgID property of each message.
When storing a message to the database, if the MsgID already exists in the
database then ignore the new message.
> We have no problems with this using Extended MAPI or Lotus Notes,
> as those protocols give us an option to mark the emails as "read" when
> we're done and we only filter out new emails. I don't see this capability
> with POP3 and Indy.
POP3 does not support it, so neither can Indy, or any other POP3 client
component, for that matter.
> Does anyone know what to look for in the TIdMessage class to determine
> if a mail is already read or not?
TIdMessage has a Flags property, but there isn't any such information
provided when using POP3 since it has no concept of read/unread statuses in
the first place.
> I thought about maybe storing a list of TIdMessage.MsgID's retrieved
> in a permanent local file somewhere and skip the email if it's ID exists
> this file
That is one way to do it. If anything happens to that file, though, then
you might get duplicate database entries again. It would be better to store
the MsgID in the database itself, perhaps as its own field in each record.
You can then do a search on that field when needed.
Duplicate emails when emails left on server posted by Jon E. Scott on Tue, 21 Dec 2004