Hi Jerry, Globally, we expect users to rely on extensions mechanisms James provides, and not on DB schemas (that might change in the future!)
I would advise you to rely on MailboxListeners (that receives events from users mailboxes) The Added event is here the one that interest you. You can rely on the "MessageId" property to correlate with your bookmark content and thus being able to update it. MailboxListener is only supported by Guice... Best regards, Benoit Tellier On 12/10/2019 11:50, Jerry Malcolm wrote: > I need a little more education... I understand that fundamentally IMAP > and all mail storage is pretty much 'top down'. The user starts at the > top folder and drills down through sub folders until they locate the > email in question. And there are search engines that basically do the > same drilling down and find matching emails. Let's say I need to return > to a specific email often, so I set up an external 'bookmark' that > references the account and folder path of this email, and via IMAP I can > easily access this email at any time. No problems whatsoever with > that. The problem happens when the user decides to clean out a folder > and move the mail to an "Archived Mail - 2019" folder. From what I can > tell, it's a new sunrise for that email in its new location with no way > to back link it to my previously bookmarked folderPath. Is that > correct? Is there any unique database information for that mail record > that I could save and subsequently use to find it again once it has > changed folders? I'm simply looking for a guaranteed unique UID that > would allow me to keep track of an email as long as it is somewhere in > the database. This doesn't have to be something exposed in IMAP. I > have no problem going straight to the database and finding a record with > this 'possible' UID if that is necessary in order to update my > 'bookmark'. Is there any UID already available that persists for the > life of the email I've totally missed? Or is this just something I need > to live with for now? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org