Mailing List Archive: DBMail: users

Retaining deleted messages

Index | Next | Previous | View Threaded

naz at mira

Apr 16, 2008, 9:01 PM

Post #1 of 15 (689 views)
Permalink

Retaining deleted messages

Is it possible to configure DBMail to not delete messages that a user
marks as deleted, but only mark them as deleted so they are deleted as
far as the user is concerned? We need to retain messages even after a
user deletes/expunges them from their client.
Thanks,
- Naz.
_______________________________________________
DBmail mailing list
DBmail[at]dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

aaron at serendipity

Apr 16, 2008, 9:05 PM

Post #2 of 15 (665 views)
Permalink

Re: Retaining deleted messages [In reply to]

This is already the case for normal message deletion. The dbmail-util
tool is used to actually purge messages from the database.

The exception is if a user removes a mailbox -- in that case, all
messages table entries are removed (the physmessage blocks, however,
continue to remain in the database until dbmail-util is used to clear
them out).

Aaron

On Apr 16, 2008, at 9:01 PM, Naz Gassiep wrote:
> Is it possible to configure DBMail to not delete messages that a
> user marks as deleted, but only mark them as deleted so they are
> deleted as far as the user is concerned? We need to retain messages
> even after a user deletes/expunges them from their client.
> Thanks,
> - Naz.
> _______________________________________________
> DBmail mailing list
> DBmail[at]dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail

_______________________________________________
DBmail mailing list
DBmail[at]dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

naz at mira

Apr 16, 2008, 9:28 PM

Post #3 of 15 (665 views)
Permalink

Re: Retaining deleted messages [In reply to]

I don't know enough about DBMail's internals to interpret the
implications of the second part of your reponse.

When you say "message table entries", what data is that? And
"physmessage blocks"? Are they the actual messages themselves? If so,
retaining those is fine for papertrailing, and I'd assume the path/name
of the mailbox they were in is there as well, so if need be, that can be
reconstructed?

- Naz.

Aaron Stone wrote:
> This is already the case for normal message deletion. The dbmail-util
> tool is used to actually purge messages from the database.
>
> The exception is if a user removes a mailbox -- in that case, all
> messages table entries are removed (the physmessage blocks, however,
> continue to remain in the database until dbmail-util is used to clear
> them out).
>
> Aaron
>
>
> On Apr 16, 2008, at 9:01 PM, Naz Gassiep wrote:
>> Is it possible to configure DBMail to not delete messages that a user
>> marks as deleted, but only mark them as deleted so they are deleted
>> as far as the user is concerned? We need to retain messages even
>> after a user deletes/expunges them from their client.
>> Thanks,
>> - Naz.
>> _______________________________________________
>> DBmail mailing list
>> DBmail[at]dbmail.org
>> https://mailman.fastxs.nl/mailman/listinfo/dbmail
>
> _______________________________________________
> DBmail mailing list
> DBmail[at]dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail
>
_______________________________________________
DBmail mailing list
DBmail[at]dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

aaron at serendipity

Apr 17, 2008, 12:14 AM

Post #4 of 15 (663 views)
Permalink

Re: Retaining deleted messages [In reply to]

Sorry for the jargon response. The schema is described here:

http://dbmail.org/dokuwiki/doku.php?id=er-model

users -> mailboxes -> messages -> physmessages -> messageblks.

The physmessages and messgaeblks tables holds the raw bytes of the
message. They doesn't know what mailbox it is in or which user owns the
message. It is the messages and mailboxes tables that contain those
mappings.

When a message is deleted in IMAP, it is flagged \Delete in messages.
When you expunge the mailbox, the message is internally marked with a
status = 'deleted' in DBMail. When you run dbmail-util, messages with
status 'purged' are destroyed, while messages with status 'deleted' are
marked to be 'purged'.

If you simply don't purge the messages, that's one approach to having a
forever record of the message.

Once a physmessages is no longer references by any messages, it is
deleted, and its messageblks are deleted, too.

When a mailbox is deleted, however, those steps are not followed; the
messages rows are removed from the database directly; so in that
respect, it is not a good forever record of the message.

Aaron

On Thu, 2008-04-17 at 14:28 +1000, Naz Gassiep wrote:
> I don't know enough about DBMail's internals to interpret the
> implications of the second part of your reponse.
>
> When you say "message table entries", what data is that? And
> "physmessage blocks"? Are they the actual messages themselves? If so,
> retaining those is fine for papertrailing, and I'd assume the path/name
> of the mailbox they were in is there as well, so if need be, that can be
> reconstructed?
>
> - Naz.
>
> Aaron Stone wrote:
> > This is already the case for normal message deletion. The dbmail-util
> > tool is used to actually purge messages from the database.
> >
> > The exception is if a user removes a mailbox -- in that case, all
> > messages table entries are removed (the physmessage blocks, however,
> > continue to remain in the database until dbmail-util is used to clear
> > them out).
> >
> > Aaron
> >
> >
> > On Apr 16, 2008, at 9:01 PM, Naz Gassiep wrote:
> >> Is it possible to configure DBMail to not delete messages that a user
> >> marks as deleted, but only mark them as deleted so they are deleted
> >> as far as the user is concerned? We need to retain messages even
> >> after a user deletes/expunges them from their client.
> >> Thanks,
> >> - Naz.
> >> _______________________________________________
> >> DBmail mailing list
> >> DBmail[at]dbmail.org
> >> https://mailman.fastxs.nl/mailman/listinfo/dbmail
> >
> > _______________________________________________
> > DBmail mailing list
> > DBmail[at]dbmail.org
> > https://mailman.fastxs.nl/mailman/listinfo/dbmail
> >
> _______________________________________________
> DBmail mailing list
> DBmail[at]dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail

_______________________________________________
DBmail mailing list
DBmail[at]dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

naz at mira

Apr 17, 2008, 6:03 AM

Post #5 of 15 (662 views)
Permalink

Re: Retaining deleted messages [In reply to]

Thanks very much for taking the time to respond.

I assume that the physmessages table would contain the message headers, and in that sense it could be deduced who the message was from and who it was sent to. Is that correct?

On a side note, is there a reason that mailboxes are physically deleted from the DB? Surely taking a similar approach to mailboxes as is taken for messages would be better? I.e., when a mailbox is deleted, it is marked as deleted along with all messages in it, and it is only destroyed when a purge is done. Is there a reason that approach was not taken? Is there an easy way for me to implement this? We really do need a comprehensive perpetual record of messages.
- Naz

Aaron Stone wrote:

Sorry for the jargon response. The schema is described here: http://dbmail.org/dokuwiki/doku.php?id=er-model"]http://dbmail.org/dokuwiki/doku.php?id=er-model users -> mailboxes -> messages -> physmessages -> messageblks. The physmessages and messgaeblks tables holds the raw bytes of the message. They doesn't know what mailbox it is in or which user owns the message. It is the messages and mailboxes tables that contain those mappings. When a message is deleted in IMAP, it is flagged \Delete in messages. When you expunge the mailbox, the message is internally marked with a status = 'deleted' in DBMail. When you run dbmail-util, messages with status 'purged' are destroyed, while messages with status 'deleted' are marked to be 'purged'. If you simply don't purge the messages, that's one approach to having a forever record of the message. Once a physmessages is no longer references by any messages, it is deleted, and its messageblks are deleted, too. When a mailbox is deleted, however, those steps are not followed; the messages rows are removed from the database directly; so in that respect, it is not a good forever record of the message. Aaron On Thu, 2008-04-17 at 14:28 +1000, Naz Gassiep wrote:
I don't know enough about DBMail's internals to interpret the implications of the second part of your reponse. When you say "message table entries", what data is that? And "physmessage blocks"? Are they the actual messages themselves? If so, retaining those is fine for papertrailing, and I'd assume the path/name of the mailbox they were in is there as well, so if need be, that can be reconstructed? - Naz. Aaron Stone wrote:
This is already the case for normal message deletion. The dbmail-util tool is used to actually purge messages from the database. The exception is if a user removes a mailbox -- in that case, all messages table entries are removed (the physmessage blocks, however, continue to remain in the database until dbmail-util is used to clear them out). Aaron On Apr 16, 2008, at 9:01 PM, Naz Gassiep wrote:
Is it possible to configure DBMail to not delete messages that a user marks as deleted, but only mark them as deleted so they are deleted as far as the user is concerned? We need to retain messages even after a user deletes/expunges them from their client. Thanks, - Naz. _______________________________________________ DBmail mailing list DBmail[at]dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail"]https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________ DBmail mailing list DBmail[at]dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail"]https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________ DBmail mailing list DBmail[at]dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail"]https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________ DBmail mailing list DBmail[at]dbmail.org https://mailman.fastxs.nl/mailman/listinfo/dbmail"]https://mailman.fastxs.nl/mailman/listinfo/dbmail

paul at nfg

Apr 17, 2008, 9:16 AM

Post #6 of 15 (654 views)
Permalink

Re: Retaining deleted messages [In reply to]

Naz Gassiep wrote:
> Thanks very much for taking the time to respond.
>
> I assume that the physmessages table would contain the message headers,
> and in that sense it could be deduced who the message was from and who
> it was sent to. Is that correct?

No. Headervalues are in the header cache tables (dbmail_headervalue)
which are keyed to the physmessages table. The physmessages table is
just a link-table sitting in between the table containing the blobs
(dbmail_messageblks in 2.2 or dbmail_mimeparts in 2.3+) on the one hand,
and the dbmail_messages table on the other hand. If you delete a
mailbox, the messages table is cleaned out for that mailbox by the
foreign key restraints.

>
> On a side note, is there a reason that mailboxes are physically deleted
> from the DB? Surely taking a similar approach to mailboxes as is taken
> for messages would be better? I.e., when a mailbox is deleted, it is
> marked as deleted along with all messages in it, and it is only
> destroyed when a purge is done. Is there a reason that approach was not
> taken?

Legacy. Dbmail was originally developed as a pop3 server where users
have only 1 mailbox. What you propose is perfectly valid and already on
the TODO list.

> Is there an easy way for me to implement this? We really do need
> a comprehensive perpetual record of messages.

The simplest way would be:
- drop the foreign key restraints between dbmail_messages and
dbmail_mailboxes.
- setup a trigger that will update the status field of messages when a
mailbox is deleted.

doing it like that won't even require code changes, just schema changes.

But another approach (more flexible) would be to re-assign a deleted
mailbox to an internal system user like '__archive__' so you can allow
administrators access to deleted mailboxes in a dedicated namespace like
'#Archive'. If a user would delete a mailbox, or if you delete a
complete account, the 'deleted' mailboxes would become visible under:

'#Archive/someusername/some/deleted/mailbox/name'

--
________________________________________________________________
Paul Stevens paul at nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
_______________________________________________
DBmail mailing list
DBmail[at]dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

aaron at serendipity

Apr 17, 2008, 9:37 AM

Post #7 of 15 (654 views)
Permalink

Re: Retaining deleted messages [In reply to]

Yes, the headers are there, but the envelope information is lost.

If we allow mailboxes to stick around, we need a way to version them
so that subsequent mailboxes of the same name can be created. That's
not hard, it's just not been done.

Off the cuff, a way to do this would be to add a deleted_date and make
that part of the index with the mailbox name and user id. The code for
this all has to be written in C and be part of the code infrastructure
for managing mailboxes. Feel free to dig in if you have an inkling to
hack on it!

Aaron

On Apr 17, 2008, at 6:03 AM, Naz Gassiep wrote:
> Thanks very much for taking the time to respond.
>
> I assume that the physmessages table would contain the message
> headers, and in that sense it could be deduced who the message was
> from and who it was sent to. Is that correct?
>
> On a side note, is there a reason that mailboxes are physically
> deleted from the DB? Surely taking a similar approach to mailboxes
> as is taken for messages would be better? I.e., when a mailbox is
> deleted, it is marked as deleted along with all messages in it, and
> it is only destroyed when a purge is done. Is there a reason that
> approach was not taken? Is there an easy way for me to implement
> this? We really do need a comprehensive perpetual record of messages.
> - Naz
>
> Aaron Stone wrote:
>>
>> Sorry for the jargon response. The schema is described here:
>>
>> http://dbmail.org/dokuwiki/doku.php?id=er-model
>>
>> users -> mailboxes -> messages -> physmessages -> messageblks.
>>
>> The physmessages and messgaeblks tables holds the raw bytes of the
>> message. They doesn't know what mailbox it is in or which user owns
>> the
>> message. It is the messages and mailboxes tables that contain those
>> mappings.
>>
>> When a message is deleted in IMAP, it is flagged \Delete in messages.
>> When you expunge the mailbox, the message is internally marked with a
>> status = 'deleted' in DBMail. When you run dbmail-util, messages with
>> status 'purged' are destroyed, while messages with status 'deleted'
>> are
>> marked to be 'purged'.
>>
>> If you simply don't purge the messages, that's one approach to
>> having a
>> forever record of the message.
>>
>> Once a physmessages is no longer references by any messages, it is
>> deleted, and its messageblks are deleted, too.
>>
>> When a mailbox is deleted, however, those steps are not followed; the
>> messages rows are removed from the database directly; so in that
>> respect, it is not a good forever record of the message.
>>
>> Aaron
>>
>>
>> On Thu, 2008-04-17 at 14:28 +1000, Naz Gassiep wrote:
>>
>>> I don't know enough about DBMail's internals to interpret the
>>> implications of the second part of your reponse.
>>>
>>> When you say "message table entries", what data is that? And
>>> "physmessage blocks"? Are they the actual messages themselves? If
>>> so,
>>> retaining those is fine for papertrailing, and I'd assume the path/
>>> name
>>> of the mailbox they were in is there as well, so if need be, that
>>> can be
>>> reconstructed?
>>>
>>> - Naz.
>>>
>>> Aaron Stone wrote:
>>>
>>>> This is already the case for normal message deletion. The dbmail-
>>>> util
>>>> tool is used to actually purge messages from the database.
>>>>
>>>> The exception is if a user removes a mailbox -- in that case, all
>>>> messages table entries are removed (the physmessage blocks,
>>>> however,
>>>> continue to remain in the database until dbmail-util is used to
>>>> clear
>>>> them out).
>>>>
>>>> Aaron
>>>>
>>>>
>>>> On Apr 16, 2008, at 9:01 PM, Naz Gassiep wrote:
>>>>
>>>>> Is it possible to configure DBMail to not delete messages that a
>>>>> user
>>>>> marks as deleted, but only mark them as deleted so they are
>>>>> deleted
>>>>> as far as the user is concerned? We need to retain messages even
>>>>> after a user deletes/expunges them from their client.
>>>>> Thanks,
>>>>> - Naz.
>>>>> _______________________________________________
>>>>> DBmail mailing list
>>>>> DBmail[at]dbmail.org
>>>>> https://mailman.fastxs.nl/mailman/listinfo/dbmail
>>>>>
>>>> _______________________________________________
>>>> DBmail mailing list
>>>> DBmail[at]dbmail.org
>>>> https://mailman.fastxs.nl/mailman/listinfo/dbmail
>>>>
>>>>
>>> _______________________________________________
>>> DBmail mailing list
>>> DBmail[at]dbmail.org
>>> https://mailman.fastxs.nl/mailman/listinfo/dbmail
>>>
>> _______________________________________________
>> DBmail mailing list
>> DBmail[at]dbmail.org
>> https://mailman.fastxs.nl/mailman/listinfo/dbmail
>>
>>
> _______________________________________________
> DBmail mailing list
> DBmail[at]dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail

_______________________________________________
DBmail mailing list
DBmail[at]dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

naz at mira

Apr 17, 2008, 6:35 PM

Post #8 of 15 (647 views)
Permalink

Re: Retaining deleted messages [In reply to]

DB programming is something I can do, however I have never programmed in
any language other than PHP. I would love to help out (I'm quite excited
about getting into DBMail, I haven't been this excited about a softwre
package since I first started using PostgreSQL all those years ago) but
unfortunately, I don't think I have any skills that the DBMail project
could use.
- Naz.

Aaron Stone wrote:
> Yes, the headers are there, but the envelope information is lost.
>
> If we allow mailboxes to stick around, we need a way to version them
> so that subsequent mailboxes of the same name can be created. That's
> not hard, it's just not been done.
>
> Off the cuff, a way to do this would be to add a deleted_date and make
> that part of the index with the mailbox name and user id. The code for
> this all has to be written in C and be part of the code infrastructure
> for managing mailboxes. Feel free to dig in if you have an inkling to
> hack on it!
>
> Aaron
>
>
> On Apr 17, 2008, at 6:03 AM, Naz Gassiep wrote:
>> Thanks very much for taking the time to respond.
>>
>> I assume that the physmessages table would contain the message
>> headers, and in that sense it could be deduced who the message was
>> from and who it was sent to. Is that correct?
>>
>> On a side note, is there a reason that mailboxes are physically
>> deleted from the DB? Surely taking a similar approach to mailboxes as
>> is taken for messages would be better? I.e., when a mailbox is
>> deleted, it is marked as deleted along with all messages in it, and
>> it is only destroyed when a purge is done. Is there a reason that
>> approach was not taken? Is there an easy way for me to implement
>> this? We really do need a comprehensive perpetual record of messages.
>> - Naz
>>
>> Aaron Stone wrote:
>>>
>>> Sorry for the jargon response. The schema is described here:
>>>
>>> http://dbmail.org/dokuwiki/doku.php?id=er-model
>>>
>>> users -> mailboxes -> messages -> physmessages -> messageblks.
>>>
>>> The physmessages and messgaeblks tables holds the raw bytes of the
>>> message. They doesn't know what mailbox it is in or which user owns the
>>> message. It is the messages and mailboxes tables that contain those
>>> mappings.
>>>
>>> When a message is deleted in IMAP, it is flagged \Delete in messages.
>>> When you expunge the mailbox, the message is internally marked with a
>>> status = 'deleted' in DBMail. When you run dbmail-util, messages with
>>> status 'purged' are destroyed, while messages with status 'deleted' are
>>> marked to be 'purged'.
>>>
>>> If you simply don't purge the messages, that's one approach to having a
>>> forever record of the message.
>>>
>>> Once a physmessages is no longer references by any messages, it is
>>> deleted, and its messageblks are deleted, too.
>>>
>>> When a mailbox is deleted, however, those steps are not followed; the
>>> messages rows are removed from the database directly; so in that
>>> respect, it is not a good forever record of the message.
>>>
>>> Aaron
>>>
>>>
>>> On Thu, 2008-04-17 at 14:28 +1000, Naz Gassiep wrote:
>>>
>>>> I don't know enough about DBMail's internals to interpret the
>>>> implications of the second part of your reponse.
>>>>
>>>> When you say "message table entries", what data is that? And
>>>> "physmessage blocks"? Are they the actual messages themselves? If so,
>>>> retaining those is fine for papertrailing, and I'd assume the
>>>> path/name
>>>> of the mailbox they were in is there as well, so if need be, that
>>>> can be
>>>> reconstructed?
>>>>
>>>> - Naz.
>>>>
>>>> Aaron Stone wrote:
>>>>
>>>>> This is already the case for normal message deletion. The dbmail-util
>>>>> tool is used to actually purge messages from the database.
>>>>>
>>>>> The exception is if a user removes a mailbox -- in that case, all
>>>>> messages table entries are removed (the physmessage blocks, however,
>>>>> continue to remain in the database until dbmail-util is used to clear
>>>>> them out).
>>>>>
>>>>> Aaron
>>>>>
>>>>>
>>>>> On Apr 16, 2008, at 9:01 PM, Naz Gassiep wrote:
>>>>>
>>>>>> Is it possible to configure DBMail to not delete messages that a
>>>>>> user
>>>>>> marks as deleted, but only mark them as deleted so they are deleted
>>>>>> as far as the user is concerned? We need to retain messages even
>>>>>> after a user deletes/expunges them from their client.
>>>>>> Thanks,
>>>>>> - Naz.
>>>>>> _______________________________________________
>>>>>> DBmail mailing list
>>>>>> DBmail[at]dbmail.org
>>>>>> https://mailman.fastxs.nl/mailman/listinfo/dbmail
>>>>>>
>>>>> _______________________________________________
>>>>> DBmail mailing list
>>>>> DBmail[at]dbmail.org
>>>>> https://mailman.fastxs.nl/mailman/listinfo/dbmail
>>>>>
>>>>>
>>>> _______________________________________________
>>>> DBmail mailing list
>>>> DBmail[at]dbmail.org
>>>> https://mailman.fastxs.nl/mailman/listinfo/dbmail
>>>>
>>> _______________________________________________
>>> DBmail mailing list
>>> DBmail[at]dbmail.org
>>> https://mailman.fastxs.nl/mailman/listinfo/dbmail
>>>
>>>
>> _______________________________________________
>> DBmail mailing list
>> DBmail[at]dbmail.org
>> https://mailman.fastxs.nl/mailman/listinfo/dbmail
>
> _______________________________________________
> DBmail mailing list
> DBmail[at]dbmail.org
> https://mailman.fastxs.nl/mailman/listinfo/dbmail
>
_______________________________________________
DBmail mailing list
DBmail[at]dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

naz at mira

Apr 26, 2008, 2:49 AM

Post #9 of 15 (521 views)
Permalink

Re: Retaining deleted messages [In reply to]

>> On a side note, is there a reason that mailboxes are physically deleted
>> from the DB? Surely taking a similar approach to mailboxes as is taken
>> for messages would be better? I.e., when a mailbox is deleted, it is
>> marked as deleted along with all messages in it, and it is only
>> destroyed when a purge is done. Is there a reason that approach was not
>> taken?
>>
>
> Legacy. Dbmail was originally developed as a pop3 server where users
> have only 1 mailbox. What you propose is perfectly valid and already on
> the TODO list.
>
>> Is there an easy way for me to implement this? We really do need
>> a comprehensive perpetual record of messages.
>>
> The simplest way would be:
> - drop the foreign key restraints between dbmail_messages and
> dbmail_mailboxes.
> - setup a trigger that will update the status field of messages when a
> mailbox is deleted.
>
> doing it like that won't even require code changes, just schema changes.
>
> But another approach (more flexible) would be to re-assign a deleted
> mailbox to an internal system user like '__archive__' so you can allow
> administrators access to deleted mailboxes in a dedicated namespace like
> '#Archive'. If a user would delete a mailbox, or if you delete a
> complete account, the 'deleted' mailboxes would become visible under:
>
> '#Archive/someusername/some/deleted/mailbox/name'

I've been thinking this over. I don't think I'm going to go the route of
making my own modifications to make this happen, as when it does get
implemented properly, I would then have to either migrate my existing
data or maintain repositories in both systems. Given that there is no
urgency for us to get this working in the immediate future, I think I
will opt to wait for the DBMail team to implement mailbox retention.

Is there any way I could get an indication of when this would be
implemented? Is it going to be in 2.4.x or is it on the "to-do at some
indefinite point in the future" timeframe? Were I a C coder I would
definitely help out, but I'm a rank newbie who can only do PHP so I
regret that I am only able to watch and wait.

Thanks,
- Naz
_______________________________________________
DBmail mailing list
DBmail[at]dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

paul at nfg

Apr 26, 2008, 3:26 AM

Post #10 of 15 (520 views)
Permalink

Re: Retaining deleted messages [In reply to]

Naz Gassiep wrote:

> I've been thinking this over. I don't think I'm going to go the route of
> making my own modifications to make this happen, as when it does get
> implemented properly, I would then have to either migrate my existing
> data or maintain repositories in both systems. Given that there is no
> urgency for us to get this working in the immediate future, I think I
> will opt to wait for the DBMail team to implement mailbox retention.
>
> Is there any way I could get an indication of when this would be
> implemented? Is it going to be in 2.4.x or is it on the "to-do at some
> indefinite point in the future" timeframe? Were I a C coder I would
> definitely help out, but I'm a rank newbie who can only do PHP so I
> regret that I am only able to watch and wait.

It's on the target list for 2.4 alright. As to a timeframe however - I
wish I could be specific there. I've got my hands full at the moment
rewriting the server core and sql layers: event-driven, threaded
database connection pools, prepared statements, etc. Most of the work
has been done already. What remains is making more imap commands
non-blocking (by delegating them to worker threads), but a nice pattern
is already emerging that can be expanded to the rest of the codebase.
But since the native sql layer has been replaced by libzdb, any bugs in
libzdb that are exposed by dbmail will have to be fixed by the libzdb
people. They have been very good at that, so I'm not worried. But it
also means I have to wait with releasing 2.3.3 (the first release with
libevent, libzdb and threading) until all supported backends pass the
tests. At this moment only the postgres driver is bug-free, but the bugs
remaining in the mysql and sqlite drivers are very minor.

Once the server-core stabilizes we will have a much better architecture
for dealing with scalability issues. That will also free my hands to
deal with the other main todos for 2.4:

- native SSL/TLS support (John Guthrie has done the groundwork there
already)
- IMAP THREAD=REFERENCES
- selected IMAP extensions (CONDSTORE, LITERAL+, MULTIAPPEND, UIDPLUS)
- archive mode (this is what you want)

Since I'm doing this on my own, don't expect a final 2.4 release before
october, unless a sponsorship deal comes along...

--
________________________________________________________________
Paul Stevens paul at nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
_______________________________________________
DBmail mailing list
DBmail[at]dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

naz at mira

Apr 26, 2008, 5:03 AM

Post #11 of 15 (519 views)
Permalink

Re: Retaining deleted messages [In reply to]

May I ask, how many people work on DBmail? I cannot help directly, but
if it would assist I'd be happy to donate to the project, given how much
easier DBMail will be making my life. I can't afford to sponsor the
project, but I would be happy to help in any way I can.
Thanks,
- Naz.

> It's on the target list for 2.4 alright. As to a timeframe however - I
> wish I could be specific there. I've got my hands full at the moment
> rewriting the server core and sql layers: event-driven, threaded
> database connection pools, prepared statements, etc. Most of the work
> has been done already. What remains is making more imap commands
> non-blocking (by delegating them to worker threads), but a nice pattern
> is already emerging that can be expanded to the rest of the codebase.
> But since the native sql layer has been replaced by libzdb, any bugs in
> libzdb that are exposed by dbmail will have to be fixed by the libzdb
> people. They have been very good at that, so I'm not worried. But it
> also means I have to wait with releasing 2.3.3 (the first release with
> libevent, libzdb and threading) until all supported backends pass the
> tests. At this moment only the postgres driver is bug-free, but the bugs
> remaining in the mysql and sqlite drivers are very minor.
>
> Once the server-core stabilizes we will have a much better architecture
> for dealing with scalability issues. That will also free my hands to
> deal with the other main todos for 2.4:
>
> - native SSL/TLS support (John Guthrie has done the groundwork there
> already)
> - IMAP THREAD=REFERENCES
> - selected IMAP extensions (CONDSTORE, LITERAL+, MULTIAPPEND, UIDPLUS)
> - archive mode (this is what you want)
>
> Since I'm doing this on my own, don't expect a final 2.4 release before
> october, unless a sponsorship deal comes along...
>
>
>
_______________________________________________
DBmail mailing list
DBmail[at]dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

paul at nfg

Apr 26, 2008, 7:36 AM

Post #12 of 15 (519 views)
Permalink

Re: Retaining deleted messages [In reply to]

Naz Gassiep wrote:
> May I ask, how many people work on DBmail? I cannot help directly, but
> if it would assist I'd be happy to donate to the project, given how much
> easier DBMail will be making my life. I can't afford to sponsor the
> project, but I would be happy to help in any way I can.

I'm the only one doing the coding at the moment. Aaron has done a lot of
work on different parts of the code over the years, esp. the delivery
chain given his sieve expertise, but he's been very busy lately. Of
course others have worked on different parts on and off over the years
(I didn't start this project after all), but at the moment it's just me,
myself and I :-(

If you want to help out: the website needs some serious attention. The
wiki needs to be cleaned up, the website needs a redesign, new
developers need to be attracted, etc, etc...

And if you have any wild ideas: feel free to persue them.

--
________________________________________________________________
Paul Stevens paul at nfg.nl
NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31
The Netherlands________________________________http://www.nfg.nl
_______________________________________________
DBmail mailing list
DBmail[at]dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

aaron at serendipity

Apr 26, 2008, 11:21 PM

Post #13 of 15 (507 views)
Permalink

Re: Retaining deleted messages [In reply to]

On Sat, Apr 26, 2008, Paul J Stevens <paul[at]nfg.nl> said:

> Naz Gassiep wrote:
>> May I ask, how many people work on DBmail? I cannot help directly, but
>> if it would assist I'd be happy to donate to the project, given how much
>> easier DBMail will be making my life. I can't afford to sponsor the
>> project, but I would be happy to help in any way I can.
>
> I'm the only one doing the coding at the moment. Aaron has done a lot of
> work on different parts of the code over the years, esp. the delivery
> chain given his sieve expertise, but he's been very busy lately. Of
> course others have worked on different parts on and off over the years
> (I didn't start this project after all), but at the moment it's just me,
> myself and I :-(
>
> If you want to help out: the website needs some serious attention. The
> wiki needs to be cleaned up, the website needs a redesign, new
> developers need to be attracted, etc, etc...
>
> And if you have any wild ideas: feel free to persue them.

Big +1 to all of that. I've been focusing a lot of time and energy on my
day job recently, and haven't had much time for other projects :-\

Anybody interesting in writing more code and working on other parts of the
project is more than welcome to pick up anything they like to do. I'm
available to answer questions on the parts of code that I'm most familiar
with, I just don't have time to actually write much code myself at the
moment. Explaining how things work and what design considerations were
thought of at the time the code was written and helping to get new coders
up to speed is something I am pleased to give a high priority to!

Aaron
_______________________________________________
DBmail mailing list
DBmail[at]dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

marc at electronics-design

Apr 28, 2008, 6:04 AM

Post #14 of 15 (493 views)
Permalink

Re: Retaining deleted messages [In reply to]

> Since I'm doing this on my own, don't expect a final 2.4 release before
> october, unless a sponsorship deal comes along...

Maybe as a side/note suggestion. If redoing the message delete
funcions, it maybe is possible to replace the integer "status" with
a date field. This way, the deleting of deleted message can be
a configured expire-time option in dbmail.conf, instead of the
the number of dbmail-util runs.
_______________________________________________
DBmail mailing list
DBmail[at]dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

aaron at serendipity

Apr 29, 2008, 3:29 AM

Post #15 of 15 (475 views)
Permalink

Re: Retaining deleted messages [In reply to]

On Mon, Apr 28, 2008, Marc Dirix <marc[at]electronics-design.nl> said:

>> Since I'm doing this on my own, don't expect a final 2.4 release before
>> october, unless a sponsorship deal comes along...
>
> Maybe as a side/note suggestion. If redoing the message delete
> funcions, it maybe is possible to replace the integer "status" with
> a date field. This way, the deleting of deleted message can be
> a configured expire-time option in dbmail.conf, instead of the
> the number of dbmail-util runs.

That's a neat idea, imo. Needs to be thought through and test-cased to
make sure that we don't have any magic numbers still laying around.

Aaron
_______________________________________________
DBmail mailing list
DBmail[at]dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com