Hi Paul -
We're running a reasonably large site on MySQL. Approx 400GB of mail
storage, with 100k users. Currently Dbmail 1.x; although likely to move to
2.0 when I get back from holiday.
Won't say it hasn't been without its challenges. We've tried both MyISAM and
Innodb tables and due to
So, instead of 2 DBMail boxes, I will have one Cyrus box (which the users
will connect to), and a DBMail box which will only be used for statistical
analysis and archive purposes. DBMail is perfectly
suited for that purpose; it saves me a lot of coding.
Unless you've got a particular need to
MySQL 4.1 will only be supported starting in DBMail 2.0.1, which will be
released next week. If you follow the directions for CVS checkout of
dbmail_2_0_branch, you'll be in good shape.
Been waiting for 2.0 to get stable (been following the list, and seeing all
the patches) before deploying
Hi Guys -
We've just taken the plunge to go to mysql 4.1 on our dbmail database; and
all went extremely well except for one little glitch I've discovered.
This query, in mysql/dbmysql.c:
select message_idnr from messages where unique_id != '' order by
message_idnr desc limit 0,1
We've disabled the quota checks in a 1.x version and it has produced a major
speed gain in the database. Previously our database was spiking to high
loads doing the SUM() calcs, so I wouldn't underestimate the cost of this
when you get to large message stores.
If possible - it would be great to
Hi all -
I was wondering whether anyone had played using MERGE tables for dbmail?
I've currently got a MyISAM table that's about 171G for messageblks - and
was looking at converting it back to Innodb -- but the size of course is
horendous, so will take hours. I've also been wanting to setup a
My question is: Can I have two MX hosts updating the same database? What
if there is an insert at precisely the same time from both
MX hosts? Will each seperate message that is inserted get it's own
message_idnr? Will it all stay consistent?
We have had up to 9 MX hosts inserting into one
Try disabling dns lookups in the config file
/Mark
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gabriel Ricard
Sent: Wednesday, 14 April 2004 11:53 a.m.
To: Dbmail@dbmail.org
Subject: [Dbmail] dbmail causing excessive server load?
I've got
Ever think about trying postgresql? It is my understanding that it
scales up better with lots of concurrent access. Anyone have
any good
experience comparing the two for dbmail?
We have tried postgresql (not for dbmail), and I guess all I can say is
MySQL 'feels nicer' to me, and it's
Surely for webmail applications, etc you're after a join where you get the
headers as columns for displaying a message list; to avoid having nested
queries.
E.g. avoid select * from messages; then for each message select * from
headers where messageid=X
I know the goal is to have the headers
A flag on the messageblks field would certainly help, and allow webmail
applications to generate message lists with one query
E.g.select messages.*, messageblks.messageblk as headers from
messages,messageblks where
messages.message_idnr=messageblks.messageblks_idnr and
messageblks.isheader=1
Having a flag on the messageblks is great for joins (see previous post); but
if there is the possibility of multiple header blocks that may pose a
problem.
However -- you could set the value to 1 for 1 header block, 2 for
multiple header blocks (or qty, etc) -- and then if when you do the simple
!
Aaron
Mark Mackay - Orcon [EMAIL PROTECTED] said:
Using MySQL 4.0 already, but I'm pretty there are some
people still using
3.x.
Maybe until 2.1 or (2.0.x) there could be two sourcefiles
or a patch you
could apply which introduced the 'not-so-efficient' code
back again
Fine by me. As long as we don't require anything ahead of the current Debian
'testing' MySQL version ;)
/Mark
Or add the following line to at the top of /etc/apt/sources.list
deb http://packages.dotdeb.org
Way cool! Thanks for the info.
Much easier than my way :)
/Mark
Using MySQL 4.0 already, but I'm pretty there are some people still using
3.x.
Maybe until 2.1 or (2.0.x) there could be two sourcefiles or a patch you
could apply which introduced the 'not-so-efficient' code back again until
people are given a chance to upgrade.
It may not be worth the effort
While it's definitely annoying, that's one thing I love about dbmail: It's
an indexed SQL lookup, rather than a mbox-style
trudge-through-a-10Mb-file-to-fine-there-is-no-new-mail approach.
With enough memory, and especially with the MySQL 4.0 query-cache; it barely
causes a performance hit.
Expanding on this idea -- is there any way to do a 'status' message with
POP?
E.g. if doing server maintenance have the users download a message from a
bastion server saying 'server undergoing maintanance or offline/etc'
Problem I believe is the UIDL handling -- if you simply do a fake POP3
Hi Pablo -
Are you by chance using procmail to deliver your messages? If so, procmail
adds another line to the start of each message which would be present when
piped through to dbmail, and would either confuse the parser or email
clients. We had a problem similar to what you're describing in
Re: procmail -- never mind :)
/Mark
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Pablo León
Sent: Wednesday, 3 March 2004 7:33 a.m.
To: dbmail@dbmail.org
Subject: Re: [Dbmail] Date of mails without date
I'm using qmail, don't remember then
1. DBMail doesn't support shared mailboxes well -- where multiple
users can access the same mailbox. However I would assume it allows
multiple IMAP clients owned by the same user to access the
same folder
at the same time. This isn't explicitly stated, and I just
want to make
sure.
For mailbox delivery it must be a username, not an email alias - from
memory.
I don't know whether mailbox selection is enabled via alias expansion yet --
may need to wait for the Sieve work to be complete.
/Mark
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL
best scenario will be to have only DB settings and table
names in the conf
file.. and moving all the bulk like AUTO_* EFFECTIVE_* BIND into the
database , there's no point for them being there, anyway
without the DB
dbmail* is useless, also consider the fact the dbmail-smtp
doesn't
A few questions,
- What should the table structure be?
- What about automatic rebuilding the table cache, if you get a
query for a new header?
If you change the syntax, then as Jesse pointed out, dbmail-maintenance
would be a logical place. Failing that, based on the lifetime of most email
- you need a clusterable database (For 2.0 you should be able
to write a oracle driver in about 4 hours).
(real clustered databases partition automatically).
Heard scary things about Oracle from an admin point-of-view, but expect
unfortuantely I'll need to look at that in the future.
Hi guys -
Another quick question (first time I've really looked at 2.0 other than
listening to the list).
Is 2.0 going to have any type of header cache (something that's suited to
the native-webmail clients everyone's no-doubt hacking away at? We
implemented some patches to 1.x and posted them
Subject: Re: [Dbmail] 2.0 and header-cache
Em Quarta 03 Dezembro 2003 20:27, Mark Mackay - Orcon escreveu:
Is 2.0 going to have any type of header cache (something
that's suited to
the native-webmail clients everyone's no-doubt hacking away at? We
implemented some patches to 1.x
), it has to think about it. A table join is pretty efficient (with
the right keys).
Just my humble opinion :)
/Mark
/Magnus
Mark Mackay - Orcon wrote:
Hi guys -
Another quick question (first time I've really looked at
2.0 other than
listening to the list).
Is 2.0 going
From a recent post I made for the trackrecord list:
Status: O
We're currently running dbmail with:
- Dual Xeon 2.4G processors / SCSI Disks
- MySQL/InnoDB
- roughly 90k mailboxes
- 100G of mail data
- alias selection offloaded to smtp servers (we don't use aliases table we
deliver straight
Hi Feargal -
Christian Warden suggested using the -m flag of dbmail-smtp
to deliver it to a seperate mailbox. I wasn't actually aware
of that option as it's not mentioned in the man page, and it
does the job pretty well (although it'll hurt my head to
figure out the sendmail config...).
Hi all -
I'm just looking ahead now and trying to see how well dbmail will scale with
larger deployments.
We're currently running dbmail with:
- Dual Xeon 2.4G processors / SCSI Disks
- MySQL/InnoDB
- roughly 90k mailboxes
- 100G of mail data
- alias selection offloaded to smtp servers (we
Hi Robert -
If you're not, you should probably switch to using InnoDB tables; as from
memory on linux the maximum MyISAM table size is 4G (FS limatation - can get
around this by using XFS/etc).
Then just go alter table messageblks type=Innodb;
Keep an eye on show table status like
We do something similar - 24 hour grace period. I'd like to make it 7 days
for any message from deletion, not just say every 7 days. With the size of
our database, I need to run the purge every day unfortunately - so the
deleted timestamp would be more helpful. It would also allow us to
I totally second this idea!
Also on deletions - it would be great to have a 'deleted timestamp' (forgive
me if this is in the upcoming 2.0 release, I haven't checked the code).
That way you can purge messages from the database once they've been *marked
as deleted* for more than user configurable
N! Having the config info in the main database was the first method -
but unless you provide a per-client identifier (so that when the
pop/imap/smtp daemon connects you can give it a particular config); you
can't differentiate services, etc.
For example on some lower-spec'd servers I run
Check the unique_id column of the database. We had the same problem and it
was because the UIDLs were stuffed up.From memory i think we fixed it by
doing the following query:
update messages set unique_id=concat(message_idnr,'A',unix_timestamp());
i don't think it matters what the values are
I just did a make dist-clean, then compiled it and it seemed to fix it. But
I'd definitely did recompile it the before emailing the list (2-3 times), so
dunno why it didn't work. Oh well -- working now. Thanks for the email
replies.
/Mark
On 10/8/02 8:39 PM, Eelco van Beek - ICS [EMAIL
37 matches
Mail list logo
