I am trying to set a mailbox up so that users can read but not delete
emails, but, for the mailbox to still be able to receive new emails. I've
changed the permission field of the mailboxes table from 2 to 1, this
stops users from deleting emails but when sending dbmail-lmtpd returns the
message
I think ACL/Shared Folders should be the right for you
So you can give any user the same folder in his IMAP-Account
and control permissions without really touching the account
from each user
Am 10.12.2009 14:41, schrieb Robert Rose:
I am trying to set a mailbox up so that users can read but not
Thanks Reindl,
What I'm trying to do is to have a personal read only mailbox that say a
supervisor sends mail to, so when an email is received from a particular
account the users sieve script redirects the email to the read only mailbox,
so the mailbox is not shared, I've tried creating an entry
Guys, I really2 need help..
Are there anyone out there with suggestions or anything at all that might help?
Please help.
Thanx.
Sent via BlackBerry Storm from Maxis
-Original Message-
From: dbmail-requ...@dbmail.org
Date: Mon, 07 Dec 2009 12:00:01
To: dbmail@dbmail.org
Subject:
Correct solution is not to store email data in DB. I think any sane DBA
could say you that. Don't store binary data in DB.
In large mailbox setups you get best performance by storing emails in
filesystem (one email per file in hashed directory structure) and caching
email headers in DB.
Am 10.12.2009 20:23, schrieb Tomas Kuliavas:
Correct solution is not to store email data in DB. I think any sane DBA
could say you that. Don't store binary data in DB.
What stupid statement in context of DBmail
signature.asc
Description: OpenPGP digital signature
2009.12.10 21:55 Reindl Harald rašė:
Am 10.12.2009 20:23, schrieb Tomas Kuliavas:
Correct solution is not to store email data in DB. I think any sane DBA
could say you that. Don't store binary data in DB.
What stupid statement in context of DBmail
I am not DBmail developer or user. Maybe I
Reindl Harald wrote:
Am 10.12.2009 20:23, schrieb Tomas Kuliavas:
Correct solution is not to store email data in DB. I think any sane DBA
could say you that. Don't store binary data in DB.
What stupid statement in context of DBmail
Incidentally, if one were to do as he suggests, it
Reindl Harald wrote:
Am 10.12.2009 20:23, schrieb Tomas Kuliavas:
Correct solution is not to store email data in DB. I think any sane DBA
could say you that. Don't store binary data in DB.
What stupid statement in context of DBmail
Only because dbmail already does hte opposite.
On Thursday 10 December 2009, Tomas Kuliavas to...@users.sourceforge.net
wrote:
DBMail might find its niche in some setups, but large mailboxes are not
in that niche. 750 GB DB proves it. You can't do text search raw email
sources. There is no point of storing them in DB.
DBMail does store
I'd like to point out a few things:
* The added complexity of storing and synchronising files on disk with
records in tables, especially in a load-balanced, high available
situation, is much more work than any returns you'll ever get.
* Whether the emails are stored in the database or the
Josh Marshall wrote:
I'd like to point out a few things:
* The added complexity of storing and synchronising files on disk with
records in tables, especially in a load-balanced, high available
situation, is much more work than any returns you'll ever get.
* Whether the emails are stored in
On Donnerstag, 10. Dezember 2009 Tomas Kuliavas wrote:
DBMail might find its niche in some setups, but large mailboxes are
not in that niche. 750 GB DB proves it. You can't do text search raw
email sources. There is no point of storing them in DB.
And you believe doing a raw text search on a
I do not want to add to this quite hot situation, but there are two things
worth mentioning:
* I'd like to see impact-free daily backups for filesystem-based
systems. With dbmail, just have a slave replica you can pause
replication on to get a perfect snapshot, with no impact on the live
On Freitag, 11. Dezember 2009 Daniel Urstöger wrote:
the Full Text Index ( FTI ) is quite bad for searches
dbmail doesn't use FTI.
mfg zmi
--
// Michael Monnerie, Ing.BSc- http://it-management.at
// Tel: 0660 / 415 6531 .network.your.ideas.
//
// Wir haben
Hi,
I didn't think it was hot. I have seen this argument a few times
before, comparing apples and oranges and suggesting that dbmail does it
the wrong way and should change. Yes dbmail has a niche and it excels in
situations where filesystem-based mail systems can't cut it, and that's
why I'm
Never claimed it does ;)
Just saying that for bigger datasets it becomes more and more useless
but with Sphinx it remains blazing fast. So, for dbmail that would be
a nice to have feature ...
Am 11.12.2009 um 01:07 schrieb Michael Monnerie
michael.monne...@is.it-management.at
:
On
Oranges and Apples, I agree to that. I happily use dbmail as well as
my qmail/vpopmail setup. Every system has it quirks and shortcommings.
To address your two points though:
I have found that since linux kernel 2.6 series, LVM snapshots have
caused system lockups. I used it happily in the
On Fri, 2009-12-11 at 01:38 +0100, Daniel Urstöger wrote:
Yes, but after backing to the snapshot to some place one can remove
it
and the speed will be back to normal. So, running a db slave and
using
mysqldump for backups is not much different.
Not quite. Having a separate slave database
Am 11.12.2009 01:38, schrieb Daniel Urstöger dan...@gosi.at:
Yes, but after backing to the snapshot to some place one can remove it
and the speed will be back to normal. So, running a db slave and using
mysqldump for backups is not much different.
a) the slave can yun on one or more other
My message was not quite finished, sadly there isnt an App for that ;)
I have found that since linux kernel 2.6 series, LVM snapshots have
caused system lockups. I used it happily in the 2.4 series. Besides
that, I did mention *impact-free*. Adding a snapshot and reading
from a
snapshot
Not quite. Having a separate slave database server to do the heavy
work
of backups has no impact on the master database during the backup
period. Therefore the master database is always at normal speed.
Well, one can also do that with a filesystem based storage, you just
need something
On Fri, 2009-12-11 at 02:01 +0100, Daniel Urstöger wrote:
Not quite. Having a separate slave database server to do the heavy
work
of backups has no impact on the master database during the backup
period. Therefore the master database is always at normal speed.
Well, one can also do
2009.12.11 01:33 Michael Monnerie rašė:
On Donnerstag, 10. Dezember 2009 Tomas Kuliavas wrote:
DBMail might find its niche in some setups, but large mailboxes are
not in that niche. 750 GB DB proves it. You can't do text search raw
email sources. There is no point of storing them in DB.
24 matches
Mail list logo
