3 ms·

I'm surprise how long qmail lasted but it definitely has issues (some of them with patches, the patches definitely have much more flimsy security and realistica

I'm surprise how long qmail lasted but it definitely has issues (some of them with patches, the patches definitely have much more flimsy security and realistically you can't run it without many feature patches these days) I actually wrote a replacement for vpopmail called 'rmail' that stored the virtual user databases in cdb. I never liked requiring a central DB like MySQL for your mail receipt to work in real time in an otherwise relatively decentralised server protocol (despite literally working at MySQL for 9 years) and liked the idea of a file better. Powered 1000+ users for many many years. Now replaced with postfix for about 5 years :) Still, it definitely has a surprisingly solid place in my historic heart.

SwellJoe 9y ago
Postfix has always (or, at least, as long as I can remember) used something very similar to that idea for all of its various user, alias, virtual, etc. tables. It's mostly transparent to the user, but when you run postmap, you're creating a key/value database (for those who don't know, cdb was djb's efficient key/value database implementation way back when) of the things in the map file. It can even use cdb as a backend, but realistically for the kinds of map tables one works with in a mail server, any of them are Good Enough(tm) because the entire data set will always fit in memory (even if you have an absurdly large mail server with 100,000 mail users on a single system, it'll still fit in RAM). We used to get a lot of people wanting MySQL support in our mail stack, which I actively have always discouraged. It's (orders of magnitude) slower, harder to maintain, and provides no benefit for the vast majority of deployments. For whatever reason (maybe just that fewer people want to host their own mail beyond sending mail from apps and notifications from the system itself), we get a lot fewer requests for it lately. Maybe I finally convinced everyone it was a bad idea.
- jlgaddis 9y ago
  I'm responsible for several mail servers and all are them are running postfix with the user data stored in SQL (including my own personal mail server). The primary reason is to simplify administration (management of user accounts and such, using various scripts and webapps).
  - lathiat 9y ago
    The way we do it is the primary store is in SQL but I sync that data out to a file on demand
  - SwellJoe 9y ago
    There is an argument to be made for some sort of central backend store when you have multiple mail servers for the same domain(s) and users. SQL isn't terrible in that context (I would likely prefer LDAP for that, but SQL works, too). Most of our users have one server, and lots of tutorials and stuff are about one mail server. It just makes no sense to add that huge amount of extra complexity for that simple use case.

SwellJoe 9y ago

Postfix has always (or, at least, as long as I can remember) used something very similar to that idea for all of its various user, alias, virtual, etc. tables. It's mostly transparent to the user, but when you run postmap, you're creating a key/value database (for those who don't know, cdb was djb's efficient key/value database implementation way back when) of the things in the map file. It can even use cdb as a backend, but realistically for the kinds of map tables one works with in a mail server, any of them are Good Enough(tm) because the entire data set will always fit in memory (even if you have an absurdly large mail server with 100,000 mail users on a single system, it'll still fit in RAM). We used to get a lot of people wanting MySQL support in our mail stack, which I actively have always discouraged. It's (orders of magnitude) slower, harder to maintain, and provides no benefit for the vast majority of deployments. For whatever reason (maybe just that fewer people want to host their own mail beyond sending mail from apps and notifications from the system itself), we get a lot fewer requests for it lately. Maybe I finally convinced everyone it was a bad idea.

jlgaddis 9y ago
I'm responsible for several mail servers and all are them are running postfix with the user data stored in SQL (including my own personal mail server). The primary reason is to simplify administration (management of user accounts and such, using various scripts and webapps).
- lathiat 9y ago
  The way we do it is the primary store is in SQL but I sync that data out to a file on demand
- SwellJoe 9y ago
  There is an argument to be made for some sort of central backend store when you have multiple mail servers for the same domain(s) and users. SQL isn't terrible in that context (I would likely prefer LDAP for that, but SQL works, too). Most of our users have one server, and lots of tutorials and stuff are about one mail server. It just makes no sense to add that huge amount of extra complexity for that simple use case.