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
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
