Storing email in a database would be an interesting way to do things, but it sounds a bit overly complex for most mail readers out there... most of which (rightly, I think) spend the bulk of their effort focusing on the front end and actually reading the mail. Also, the word "export" seems to imply that you don't want to keep the database up-to-date with your email in real time.
I think it'd be very interesting to see an IMAP server that would manage mail folders in a database, though. That'd take a
There's at least one IMAP server that does use a database - Exchange. I don't know about you, but I don't find the results thrilling at least from an admin's perspective.
There has been repeated discussion on the Cyrus IMAPd list about mail-in-database storage, but the general consensus is that it would gain nothing over how Cyrus currently does things. Cyrus keeps its own header index and an optional body text index (searching a non-locally-cached 30,000 message mailbox in < 1 second, over dial-up = nic
That's a fair enough point. I guess the main advantage with using a database would be the ability to query your email a little more flexibly than what might be available in a mail client.
To elaborate more on what I said in the initial post, I must make it clear that:
(1) I'm talking from the point of view of a single user, not a sysadmin. (2) Email clients must be simple and snappy. (3) I have found they are not very appropriate to keep (and eventually search through) a large archive of old emails. (3) A database seems to be a good way to keep a larger archive of emails messages (including, of course) attachments. For huge archives containing many accounts there could be efficiency problems, b
In a sense, I guess I do keep my mail in a database - the Cyrus IMAPd mail store. There it's indexed (body and header indexes) and sorted. Sure, its a heirachal database otherwise known as "the file system" with additional files for the mail-specific header and body indexes, but it works very well.
Personally, I don't think a full RDBMS is necessarily the right answer, but I can see the appeal in some form of client-side database-like functionality, yes.
You should check out the DBmail [dbmail.org] project.
Speaking from experience, I can tell you there are some real performance issues once you get a big mass of e-mail into a database on lower-end hardward (read: affordable hosted box). But if I were running my own mailserver without paying monthly for the hardware, I'd throw everything into Postgres in a second.
"Well hello there Charlie Brown, you blockhead."
-- Lucy Van Pelt
I want a "Export to mysql" option (Score:5, Interesting)
Re:I want a "Export to mysql" option (Score:1)
Re:I want a "Export to mysql" option (Score:1, Insightful)
What's that got to do with mysql?
Perhaps with an IMAP server (Score:2)
Storing email in a database would be an interesting way to do things, but it sounds a bit overly complex for most mail readers out there... most of which (rightly, I think) spend the bulk of their effort focusing on the front end and actually reading the mail. Also, the word "export" seems to imply that you don't want to keep the database up-to-date with your email in real time.
I think it'd be very interesting to see an IMAP server that would manage mail folders in a database, though. That'd take a
IMAPd database (Score:2)
There has been repeated discussion on the Cyrus IMAPd list about mail-in-database storage, but the general consensus is that it would gain nothing over how Cyrus currently does things. Cyrus keeps its own header index and an optional body text index (searching a non-locally-cached 30,000 message mailbox in < 1 second, over dial-up = nic
Re:IMAPd database (Score:2)
That's a fair enough point. I guess the main advantage with using a database would be the ability to query your email a little more flexibly than what might be available in a mail client.
Re:Perhaps with an IMAP server (Score:1)
(1) I'm talking from the point of view of a single user, not a sysadmin.
(2) Email clients must be simple and snappy.
(3) I have found they are not very appropriate to keep (and eventually search through) a large archive of old emails.
(3) A database seems to be a good way to keep a larger archive of emails messages (including, of course) attachments. For huge archives containing many accounts there could be efficiency problems, b
I'm unconvinced (Score:2)
In a sense, I guess I do keep my mail in a database - the Cyrus IMAPd mail store. There it's indexed (body and header indexes) and sorted. Sure, its a heirachal database otherwise known as "the file system" with additional files for the mail-specific header and body indexes, but it works very well.
Personally, I don't think a full RDBMS is necessarily the right answer, but I can see the appeal in some form of client-side database-like functionality, yes.
(I've also replied to another repl
Re:I want a "Export to mysql" option (Score:2)
Speaking from experience, I can tell you there are some real performance issues once you get a big mass of e-mail into a database on lower-end hardward (read: affordable hosted box). But if I were running my own mailserver without paying monthly for the hardware, I'd throw everything into Postgres in a second.