You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Jerry Malcolm <te...@malcolms.com> on 2019/10/12 04:50:38 UTC
Keeping Track of An Email That Has Been Moved
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-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Keeping Track of An Email That Has Been Moved
Posted by Tellier Benoit <bt...@apache.org>.
I agree organizing weddings is a hell of a mess, having been recently
gone through this process myself...
> (I have filmed over 600 weddings across nearly 18 years... so
> the maildb is huge. Searching is not trivial)
Well, scanning search sounds like a hell yes.
However hopefully some other options are available. James 3.x releases
includes some advanced search engines that should be relyable and
efficient up to a few million emails.
Lucene is the de-facto indexing choice we made for JPA Guice. It's also
available in Spring (indexer.xml file).
Searching large DBs should not be a problem.
> I figure I could just do
> a search on the entire maildb each time looking for any mail that
> matches any of 20+ email addresses.
I'd argue you'll end up with a functional issue: what if one the
previous bride gets a mum and emails you for marrying her daughter? :-)
You could:
- assign a custom mail header / custom flags upon the mailet pipeline
for a mail you correlated with a wedding
- Rely on multi-mailbox search using aforementioned (not yet
implemented) RFC-6237.
Cheers,
Benoit
On 15/10/2019 10:52, Jerry Malcolm wrote:
> Hi Benoit,
>
> When I'm talking with my own software clients, my standard line to the
> client is "don't tell me your recommended solution.... start with what
> the problem is that you want to solve, and we'll work together on the
> best solution." And here I find myself telling you what I think the
> solution is when there might be a totally different and much better way
> already architected into James to solve the problem.... So I'm hitting
> 'reset'. Here's the actual problem I want to solve.
>
> Totally separate from my software development and hosting businesses, I
> also have a wedding and event video business. When I book a wedding, I
> start having to deal with bride, groom, planner, Mother of Bride, Mother
> of Groom, etc. etc. Over the months before and after the wedding, I get
> a bunch of emails from each of these people. And to make matters worse,
> after the wedding, the bride often changes her email address if she
> changes her last name. In my CRM I have an entry for the "Smith/Jones
> Wedding". I have an "email history" log that is crucial to keeping up
> with all correspondence between me, my employees, and about 20 different
> email addresses for everyone I'm dealing with related to this wedding.
> I have mailets that monitor all outbound and inbound mail. If I find
> one to/from any of the email addresses I have on record associated with
> this wedding, I log an entry in the CRM email history log for this
> wedding. I want to be able to retrieve and open the email directly from
> the CRM log. My current implementation works fine until I need to clean
> up mail folders and archive older mail which loses the links to be able
> to open those emails since the paths change. I figure I could just do
> a search on the entire maildb each time looking for any mail that
> matches any of 20+ email addresses. But that seems to be a performance
> nightmare (I have filmed over 600 weddings across nearly 18 years... so
> the maildb is huge. Searching is not trivial). So I keep a separate
> log and 'try' to keep the entries pointed to the mail's location in
> james so I can access the email item on demand.
>
> So if there's a better way to create 'groups' for all mail in the entire
> email account for 20+ random email addresses and get a list
> (efficiently) of all matching to/from emails, I'm ready to learn a
> different way.
>
> Thx as always.
>
> Jerry
>
> On 10/14/2019 10:09 PM, Tellier Benoit wrote:
>> Hi Jerry,
>>
>> First I'd begin with a quick thought that might save you some consequent
>> development and configuration time.
>>
>> What exactly are the features of your bookmark?
>>
>> Because it sounds to me search and custom flags might be enough.
>>
>> RFC-6237 "IMAP4 Multimailbox SEARCH Extension" might also be a must read
>> for your feature. (not yet implemented in James but should be easy)
>>
>> Such an approach would avoid external state tracking (brittle) at the
>> cost of a simple IMAP extension development. If you don't have new
>> features in your "bookmark" application, then this might be the "most
>> standard way to go".
>>
>> That being said, I'll answer your other questions:
>>
>> 1) A bit of warning first: ToRecipientFolder is deprecated. The way to
>> do that is combining WithStorageDirective and LocalDelivery mailets.
>>
>> 2) Yes, a sample implementation is "random UUID"
>>
>> However some little dev might be required for JPA to persist messageId
>> (I just looked through the code)
>>
>> We wrote this tutorial
>> http://james.apache.org/howTo/custom-listeners.html for helping users
>> and devs write their own listener, this might be a good starting point
>> for you.
>>
>>> It looks like my next step is going to be moving to Guice.
>> Yeah!!!
>>
>> Cheers,
>>
>> Benoit
>>
>> On 15/10/2019 05:20, Jerry Malcolm wrote:
>>> Hi Benoit,
>>>
>>> Thanks for the response. I'm all for extensions mechanisms rather than
>>> using db schemas. If I understand what you are describing, and I can
>>> make it work, it's going to be a much simpler solution than the hack I
>>> put together a few years ago for my v3b5 installation.
>>>
>>> Just to make sure I'm hearing you correctly...
>>>
>>> 1) I recognize (in a "ToFolder mailet") that a particular email is one
>>> that I have a need to track and locate later.
>>>
>>> 2) I use the MessageId property on that email and externally store that
>>> MessageId: "abc" is stored in mail account folder "xxx/yyy". (and "abc"
>>> is a universally unique id across my James installation, correct?)
>>>
>>> 3) I write and register a MailboxListener to monitor all mailbox folders
>>> for this account
>>>
>>> 4) The user decides to move message "abc" to folder
>>> "/archive2019/xxx/yyy"
>>>
>>> 5) My listener recognizes the id and updates my external registry that
>>> "abc" is now in a different folder.
>>>
>>> I've got to dig in and learn about writing a MailboxListener. But
>>> assuming my assumptions for the steps above are valid, I can make it
>>> happen. If I don't have the steps correct, please set me straight.
>>>
>>> It looks like my next step is going to be moving to Guice.
>>>
>>> Jerry
>>>
>>> On 10/13/2019 10:11 PM, Tellier Benoit wrote:
>>>> 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-unsubscribe@james.apache.org
>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Keeping Track of An Email That Has Been Moved
Posted by Jerry Malcolm <te...@malcolms.com>.
Hi Benoit,
When I'm talking with my own software clients, my standard line to the
client is "don't tell me your recommended solution.... start with what
the problem is that you want to solve, and we'll work together on the
best solution." And here I find myself telling you what I think the
solution is when there might be a totally different and much better way
already architected into James to solve the problem.... So I'm hitting
'reset'. Here's the actual problem I want to solve.
Totally separate from my software development and hosting businesses, I
also have a wedding and event video business. When I book a wedding, I
start having to deal with bride, groom, planner, Mother of Bride, Mother
of Groom, etc. etc. Over the months before and after the wedding, I get
a bunch of emails from each of these people. And to make matters worse,
after the wedding, the bride often changes her email address if she
changes her last name. In my CRM I have an entry for the "Smith/Jones
Wedding". I have an "email history" log that is crucial to keeping up
with all correspondence between me, my employees, and about 20 different
email addresses for everyone I'm dealing with related to this wedding.
I have mailets that monitor all outbound and inbound mail. If I find
one to/from any of the email addresses I have on record associated with
this wedding, I log an entry in the CRM email history log for this
wedding. I want to be able to retrieve and open the email directly from
the CRM log. My current implementation works fine until I need to clean
up mail folders and archive older mail which loses the links to be able
to open those emails since the paths change. I figure I could just do
a search on the entire maildb each time looking for any mail that
matches any of 20+ email addresses. But that seems to be a performance
nightmare (I have filmed over 600 weddings across nearly 18 years... so
the maildb is huge. Searching is not trivial). So I keep a separate
log and 'try' to keep the entries pointed to the mail's location in
james so I can access the email item on demand.
So if there's a better way to create 'groups' for all mail in the entire
email account for 20+ random email addresses and get a list
(efficiently) of all matching to/from emails, I'm ready to learn a
different way.
Thx as always.
Jerry
On 10/14/2019 10:09 PM, Tellier Benoit wrote:
> Hi Jerry,
>
> First I'd begin with a quick thought that might save you some consequent
> development and configuration time.
>
> What exactly are the features of your bookmark?
>
> Because it sounds to me search and custom flags might be enough.
>
> RFC-6237 "IMAP4 Multimailbox SEARCH Extension" might also be a must read
> for your feature. (not yet implemented in James but should be easy)
>
> Such an approach would avoid external state tracking (brittle) at the
> cost of a simple IMAP extension development. If you don't have new
> features in your "bookmark" application, then this might be the "most
> standard way to go".
>
> That being said, I'll answer your other questions:
>
> 1) A bit of warning first: ToRecipientFolder is deprecated. The way to
> do that is combining WithStorageDirective and LocalDelivery mailets.
>
> 2) Yes, a sample implementation is "random UUID"
>
> However some little dev might be required for JPA to persist messageId
> (I just looked through the code)
>
> We wrote this tutorial
> http://james.apache.org/howTo/custom-listeners.html for helping users
> and devs write their own listener, this might be a good starting point
> for you.
>
>> It looks like my next step is going to be moving to Guice.
> Yeah!!!
>
> Cheers,
>
> Benoit
>
> On 15/10/2019 05:20, Jerry Malcolm wrote:
>> Hi Benoit,
>>
>> Thanks for the response. I'm all for extensions mechanisms rather than
>> using db schemas. If I understand what you are describing, and I can
>> make it work, it's going to be a much simpler solution than the hack I
>> put together a few years ago for my v3b5 installation.
>>
>> Just to make sure I'm hearing you correctly...
>>
>> 1) I recognize (in a "ToFolder mailet") that a particular email is one
>> that I have a need to track and locate later.
>>
>> 2) I use the MessageId property on that email and externally store that
>> MessageId: "abc" is stored in mail account folder "xxx/yyy". (and "abc"
>> is a universally unique id across my James installation, correct?)
>>
>> 3) I write and register a MailboxListener to monitor all mailbox folders
>> for this account
>>
>> 4) The user decides to move message "abc" to folder "/archive2019/xxx/yyy"
>>
>> 5) My listener recognizes the id and updates my external registry that
>> "abc" is now in a different folder.
>>
>> I've got to dig in and learn about writing a MailboxListener. But
>> assuming my assumptions for the steps above are valid, I can make it
>> happen. If I don't have the steps correct, please set me straight.
>>
>> It looks like my next step is going to be moving to Guice.
>>
>> Jerry
>>
>> On 10/13/2019 10:11 PM, Tellier Benoit wrote:
>>> 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-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Keeping Track of An Email That Has Been Moved
Posted by Tellier Benoit <bt...@apache.org>.
Hi Jerry,
First I'd begin with a quick thought that might save you some consequent
development and configuration time.
What exactly are the features of your bookmark?
Because it sounds to me search and custom flags might be enough.
RFC-6237 "IMAP4 Multimailbox SEARCH Extension" might also be a must read
for your feature. (not yet implemented in James but should be easy)
Such an approach would avoid external state tracking (brittle) at the
cost of a simple IMAP extension development. If you don't have new
features in your "bookmark" application, then this might be the "most
standard way to go".
That being said, I'll answer your other questions:
1) A bit of warning first: ToRecipientFolder is deprecated. The way to
do that is combining WithStorageDirective and LocalDelivery mailets.
2) Yes, a sample implementation is "random UUID"
However some little dev might be required for JPA to persist messageId
(I just looked through the code)
We wrote this tutorial
http://james.apache.org/howTo/custom-listeners.html for helping users
and devs write their own listener, this might be a good starting point
for you.
> It looks like my next step is going to be moving to Guice.
Yeah!!!
Cheers,
Benoit
On 15/10/2019 05:20, Jerry Malcolm wrote:
> Hi Benoit,
>
> Thanks for the response. I'm all for extensions mechanisms rather than
> using db schemas. If I understand what you are describing, and I can
> make it work, it's going to be a much simpler solution than the hack I
> put together a few years ago for my v3b5 installation.
>
> Just to make sure I'm hearing you correctly...
>
> 1) I recognize (in a "ToFolder mailet") that a particular email is one
> that I have a need to track and locate later.
>
> 2) I use the MessageId property on that email and externally store that
> MessageId: "abc" is stored in mail account folder "xxx/yyy". (and "abc"
> is a universally unique id across my James installation, correct?)
>
> 3) I write and register a MailboxListener to monitor all mailbox folders
> for this account
>
> 4) The user decides to move message "abc" to folder "/archive2019/xxx/yyy"
>
> 5) My listener recognizes the id and updates my external registry that
> "abc" is now in a different folder.
>
> I've got to dig in and learn about writing a MailboxListener. But
> assuming my assumptions for the steps above are valid, I can make it
> happen. If I don't have the steps correct, please set me straight.
>
> It looks like my next step is going to be moving to Guice.
>
> Jerry
>
> On 10/13/2019 10:11 PM, Tellier Benoit wrote:
>> 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-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Keeping Track of An Email That Has Been Moved
Posted by Jerry Malcolm <te...@malcolms.com>.
Hi Benoit,
Thanks for the response. I'm all for extensions mechanisms rather than
using db schemas. If I understand what you are describing, and I can
make it work, it's going to be a much simpler solution than the hack I
put together a few years ago for my v3b5 installation.
Just to make sure I'm hearing you correctly...
1) I recognize (in a "ToFolder mailet") that a particular email is one
that I have a need to track and locate later.
2) I use the MessageId property on that email and externally store that
MessageId: "abc" is stored in mail account folder "xxx/yyy". (and "abc"
is a universally unique id across my James installation, correct?)
3) I write and register a MailboxListener to monitor all mailbox folders
for this account
4) The user decides to move message "abc" to folder "/archive2019/xxx/yyy"
5) My listener recognizes the id and updates my external registry that
"abc" is now in a different folder.
I've got to dig in and learn about writing a MailboxListener. But
assuming my assumptions for the steps above are valid, I can make it
happen. If I don't have the steps correct, please set me straight.
It looks like my next step is going to be moving to Guice.
Jerry
On 10/13/2019 10:11 PM, Tellier Benoit wrote:
> 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-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Keeping Track of An Email That Has Been Moved
Posted by Tellier Benoit <bt...@apache.org>.
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-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org