Aaron Stone wrote:
So, all you can do is do a very fast search for known sources
of senders (customers and people) and either copy those
messages to other users or simply assign them to other users
(by assign, I mean do a SQL update on the underlying tables).
I have thought about this, and would like to discuss a good way to
implement it. Basically to change ownership of a mailbox. Something like
this:
# Change the name of the mailbox to avoid conflicts
dbmail-mailbox -u oldguy -m INBOX -n INBOX-oldguy
# Attach the mailbox to the new user
dbmail-mailbox -u oldguy -m INBOX-oldguy -x newguy
By 'attaching', do you mean a merge --i.e. if the target mailbox
contains a sub folder with the same name as the source one, the
contents are simply shoved in to the target sub folder (much like
folder copy of a file explorer), or does the target receive that
folder as shared folder (the way Cyrus does it) above the INBOX
namespace?
I would prefer the shared folder metaphor --that way no one gets
confused as to who has sent what to whom. Plus, they can be made
read-only.
One further thing [though this thread may not be perfect
to ask it, I'll ask anyway :-) ] Is there already a
functionality in DBMail that --whatever the user action--
*no* mail is actually erased from the mail storage.
This is needed for banks, for example. They are required to archive
everything. I think that it is better handled by using a domain alias in
combination with a local delivery. That isn't possible at the moment
because as soon as one delivery method is found, only that one is used.
In retrospect, I'm not sure why all three aren't tried. I suppose that in
the case of a username that is well formed address, but has an alias that
forwards to someplace else, you'd rather not also receive email locally.
But I could see a domain alias being used to capture all email for a
domain.
Perhaps this should become configurable?
At least with Postfix, there are options to catch all email and save it. I
would recommend using that instead of adding a DBMail config option,
unless we really want to.
We have been using the Postfix approach, which seemed great at first,
but, now that the numer of mails have reached into millions, the
[EMAIL PROTECTED] has become a burden as and in itself. It is
totally unmanageable. What I need is an untainted copy of mailboxes,
not a mialbox with millions of messages in it.
In retrospect, I dont think it is the MTA's job to handle that at all.
Postfix is not the storage keeper, it has no intelligence other than
redirecting traffic.
From where I am looking at it, it is the mail server that should do
it.
-- Any message sent or received should be hashed and stored as unique
blob in a pool, common storage (RDBMS, file sytem, cluster etc.).
-- Users should simply have pointers to the messages.
They should not be able to erase the actual message even though they
have 'deleted' and 'purged' it. They will simply end up deleting the
pointer: That particular message will not be visible to the user.
That's all.
Since *all* messages are in one single storage, an admin can
reconstruct a user's mailbox, if the need arises, without much load on
the system (CPU, storage etc.).
Having such a storage back end with pointers enables the admin to have
a shadow mailbox structure(in the british sense of shadow cabinet)
without much effort. That is, of course, if DBMail had the
functionality built in.
Cheers,
