Slashdot Mirror

There is DBMail.

DBMail. I use it on a Linode host (small fee every month).

Databases suck as mail backends. However, there's http://www.dbmail.org/ and http://www.archiveopteryx.org/

The links:
- mailstore and IMAP server:
dbmail (postgresql, mysql)
decimail (postgresql)
oryx (postgresql)
- mailstore+MUA:
manitou-mail (postgresql)

Just last week I was wondering why no one used something like postgresql as an email storage system. Thanks for the tip on http://www.dbmail.org/ , posts like this are the reason I read Slashdot.

That's what DBMail http://www.dbmail.org/ does and I thought Dovecot was planning to do it too.

• Scalability
  

  Dbmail is as scalable as the database system that is used for the mail storage. In theory millions of accounts can be managed using dbmail. One could, for example, run 4 different servers with the pop3 daemon each connecting to the same database (cluster) server.

• Manageability
  

  Dbmail is based upon a database. Dbmail can be managed by changing settings in the database (f.e. using PHP/Perl/SQL), without needing shell access.

• Speed
  

  Dbmail uses very efficient, database specific queries for retrieving mail information. This is much faster then parsing a filesystem.

• Security
  

  Dbmail has got nothing to do with the filesystem or interaction with other programs in the Unix environment which need special permissions. Dbmail is as secure as the database it's based upon.

• Flexibility.
  

  Changes on a Dbmail system (adding of users, changing passwords etc.) are effective immediately.

• Scalability
  

  Dbmail is as scalable as the database system that is used for the mail storage. In theory millions of accounts can be managed using dbmail. One could, for example, run 4 different servers with the pop3 daemon each connecting to the same database (cluster) server.

• Manageability
  

  Dbmail is based upon a database. Dbmail can be managed by changing settings in the database (f.e. using PHP/Perl/SQL), without needing shell access.

• Speed
  

  Dbmail uses very efficient, database specific queries for retrieving mail information. This is much faster then parsing a filesystem.

• Security
  

  Dbmail has got nothing to do with the filesystem or interaction with other programs in the Unix environment which need special permissions. Dbmail is as secure as the database it's based upon.

• Flexibility.
  

  Changes on a Dbmail system (adding of users, changing passwords etc.) are effective immediately.

And another. DBMSs make integration with web applications a lot easier. Odds are there are already tools and classes and languages (like php) to easily mess with the db.

Also, if you want your email in a db without using exchange, try dbmail.

I've set up a dbmail/postfix installation to use with my company's web application we're developing. Though I have no idea how well these work with 1000000 users, they're worth exploring.

I'm not sure that there is any commerical solution that can support 1 million emails well. Hence why Yahoo and Google have built there own custom systems. Some engineering may need to be required.

For pop3 & imap4rev1, look at:
http://www.dbmail.org/index.php?page=overview

Still need an MTA, I think qmail is the fastest, best, but I'd used exim, as its easier.

Database - not sure if MySQL and PostgreSQL will scale with dbmail.

I'd say use FreeBSD, because of the ports collection (Don't linux Flame me). However, something like Solaris 10 x86 (or Solaris+Sun Hardware) might provide a bit better scaling, and HA hardware, SAN support, support in general, etc. Though, a bit tougher on the OSS software installs (In My Experience)

I've been trying to make a decision as to which open source SQL database to go with for use with the DBMail server that I plan on installing here at home. Considering that I couldn't give a rat's ass about web applications (which DBMail is not), it seems like PostgreSQL is the answer. And with the right optimizations, it's likely to be nearly as good a performer as MySQL. Fuck SCO and anyone who choses to work with them.

Fixed linky: dbmail :)

http://www.dbmail.org/

is one starting point, but there are a few others.

You're basically replacing /var/spool/mail with an SQL back-end. Things like MBOX or IMAP will suck for dealing with millions of records/messages, but SQL should handle it easily.

DBMail
Run your own :)

You're probably looking for something like this: http://www.dbmail.org/

If someone really wants maildir support, they can add it, or have it added.

Now, if they would just add a connector that allows the storage of mail in an SQL database...

You should check out the DBmail 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.

Gmail is a *huge* improvement over Hotmail on the user interface level.

1. There is no way to distinguish similarily named mailing lists. You can only filter based on "To, "From", and "Subject" headers. Let's examine the options:
   • To: Useless, as people will Cc a list, or the email will be sent to a smaller list which is then redistributed to the larger list. Bugtraq is an example of this.
   • From: Some lists set the "From" header to their own address, others leave it unaltered. In the latter case, the "From" header is useless, unless you happen to have a full subscriber list. Even if you do, you're screwed if somebody is subscribed to two different lists that you are on.
   • Subject: This usually works for lists that insert the list name into the subject. However, there are exceptions. I'm subscribed to the DBMail users list which inserts "[dbmail]" into the subject. I also receive bounce notifications from my mailer daemon which includes "DBMail" in the subject. If I set a filter to match "[dbmail]" in the subject, it ignores the square brackets and so tags the bounced messages as well. It also tags emails on the dbmail-dev list.
   By applying multiple labels I have it working after a fashion. It took way too much time however for such a simple task.
2. New filters cannot be applied retroactively. If you receive a few hundred emails that need classifying and come up with a filter for them, you then have to manually apply it to the older messages. I still have about 8,000 unclassified emails because they came in before I created filters for them.
3. Their address book is terrible, and there isn't any way to import an existing one.
4. There's many more problems, including their stupid lack of a plain HTML version. That one I could understand if they were rushing to a launch date and wanted a feature-rich, IE only version out the door. They do not seem hurried at all though, so they really should have started with a simple standards compliant version and then added the per-browser bells and whistles. I have to go do some work however, so I'll end my rant shortly.

I know and understand Gmail is in beta. I have reported all the problems I have had months ago. None have been fixed. However, the very fact that you cannot search by a user-defined header baffles me. I can only assume they index the messages by to, from, and subject, and don't cache the rest of the headers in a usable form.

Shrug. In the end of the day, I don't particularily care, I'll continue using Sylpheed-Claws which copes extremely well. I would have like a web-based backup though for when I'm not near my laptop. I guess I'll have to finish writing my own.

Anyone here tried DBMail? I know it doesn't have the features of a full groupware server, but it looks promising, in that everything-- addresses, email content, etc... is stored in a PostgreSQL or MySQL database, and it supports Imap. Apparently for version 2.x, they are planning shared folders, etc... Also, it seems to be much simpler to install than these other behemoths. Worth trying?

I dumped sendmail and my unsuccessful attempts to compile qmail (no binary distributions allowed) when I "accidentally" discovered that one of my Mandrake installs had a working, non-relaying mail server running, without my having to configure it... it was postfix. Subsequently, our shop has standardized on postfix for the MTA, but not for deliverying mail to users. For that, we use dbmail, which uses either MySQL or PostGres as the mail storage handler. As part of building postfix and dbmail to work together, I found that a LOT of things become easier with postfix when it has SQL support... using MySQL to host the transport table (doubles as the mydestination table), virtual domains can be added without even restarting the daemons; just add them to the table. dbmail makes it possible to have overlapping user namespaces, if your users will tolerate login IDs of 'user@domain.tld' instead of juse 'user'. Postfix uses dbmail's alias table to determine if an address is local, so that it won't accept mail for non-existant addresses (one of the popular ways to bypass anti-relaying in Exchange and other MTAs that don't vet the destination address when accepting mail). All of my postfix non-regexp spam filters are stored in MySQL, so that I never have to run postmap. All in all, postfix was a good choice for me. Even though I can't use the default binary distribution anymore, it's been pretty easy to deal with. Wish I could have said the same about qmail... never did get that to compile to a usable configuration, despite the book...

And it isn't as if I'm adverse to compiling things... or patching them... after all, I'm one of the first sites to run dbmail on a production server (SQL-based back-end for mail, everything but the MTA), although I froze my installations 8 months ago... I'll wait until the final release ("Real Soon Now") before updating again, because it WORKS.

One of the things that attracted me to postfix in the first place was that, by default, it works. The first machine I had it on, surprised the hell out of me by forwarding web-generated emails before I'd even looked at the configuration, while still rejecting all attempts by spammers to use it as an open relay. I still have several boxes that have default postfix configurations, that are used merely to forward auto-generated mail for their daemons.

One of the things that continues to attract me to djbdns is being able to update a domain without restarting the server... but, that's also why I'm interested in a SQL-based solution, since I can administer those pretty easily... B-)

Personally, I'd love to see a Linux MTA/IMAP system which uses an SQL message-store. The ability to replicate a message-store across multiple physical sites without having to get into distributed filesystems like Coda would be a huge benefit for those who need to provide a redundant mail service.

I actually found a nifty little package called dbmail which uses an SQL messagestore. I've been playing with such things at work since they wanted me to write them a web-based mail client, and I wanted something which would let me deal with a MySQL database on the web client, but also allow people to connect to it via IMAP or POP3.

Of course, the whole replication part of it might be a bit more difficult, but it could probably be arranged as well. I'm pretty sure there are tools in existance for doing replication on a MySQL database (of course, don't ask me the names of any of them...)

The DBMail project is already well underway, with a fabulous beta 3 release and an active development team pushing towards a 1.0 release. The project is being supported by a Dutch ISP called IC&S. It provices an MDA interface for Postfix/Sendmail/Exim/Procmail/etc and POP3 and IMAP servers. MySQL and PostgreSQL are supported backends. The CVS tree has a non-relaying SMTP server, too.

http://www.dbmail.org/

There's also a solo developer working on a mail server called mmmail. It provides a non-relaying SMTP and POP3 with a MySQL backend.

http://mmondor.gobot.ca/software.html