Slashdot Mirror

~ 1 million mailboxes, on qmail-ldap , plus a few patches (big-todo, qscanq and others). But, this will hopefully be migrated (to a postfix-based solution, but keeping the LDAP part) within a year.

I note that postfix with VDA supports almost all the qmail-ldap features (except "vacation" message that would normally be in the mailReplyText attribute), and most Linux distros ship with this patch.

Does anybody run an ISP mail system with Qmail featuring predominately as MTA of choice?

At my previous job we used to run qmail for our mailhosting boxes. I can tell you that we were really happy with qmail back then, with the right patches it can be a really flexible mailserver, and once you're used to how it works you'll be in SMTP bliss. However, when you need functionality that isn't provided by qmail, you're doing one (or some) of the following:

• patching qmail, recompiling, testing, deploying
• writing a perl/bash/whatever script that goes somewhere in the Big Qmail Picture
• muttering curses and djb's name for the licensing

I can't really bring myself to bashing qmail over these things because it's served me well and I've hardly had any "unexpected" things happen to me, which is something I can't really say of other MTAs I've tried and I've never had any security problems (altough you might want to read this page). There's a lot of information available on qmail, and you can check out this guide (although this may now be quite dated). An indispensible tool is qmHandle for inspecting and manipulating the qmail queue in case something did go wrong.

Finally, I have to admit that when I left that company my own mailhosting services are currently being run by postfix, simply because I don't have the time to build my own qmail packages whenever I need some feature. If you look at the postfix design, any qmail user will see similarities and the fact that you're not patching and rebuilding it whenever you need feature X sort of grows on you.

I know that if I were to start hosting a large mailserver, I'd have a hard time deciding between the two and I'd do a lot of testing before I made a choice.

http://www.nrg4u.com/

We have account data stored in an LDAP store, mirrorred to a second (read-only) store for redundancy/scaling when busy. LDAP scales wonderfully for read-heavy tasks such as this one.

As has been mentioned separately, separating recipient (edge), storage, and outbound mail servers is really important. Our edge servers perform RBL checks, greylisting (on some domains that want it), SPF (ditto), reject various attachment types, perform a reverse-MX check to try to accept from valid addresses only, and perform a recipient address check to quickly reject incorrectly addressed messages. That cuts down 80% of incoming mail (with very few false positives). Mail is then forwarded to a second set of edge servers that run SpamAssassin (set to flag spam, not stop it) and ClamAV on attachments. Finally, it goes into the storage servers. POP3/IMAP/Webmail points at the mail directories on these servers. Our outgoing servers are quite a simple setup, with SMTP Auth (also hooked to LDAP). We also have a few listservs setup, but they are a side issue.

Qmail is a bear to setup, and asking the author for advice is a good way to get flamed. Other than that, it works very well, we haven't had any security issues, and it's adequately fast - especially if you apply the "silly qmail todo" patch, fixing concurrency problems under high load. It's part of the Qmail-LDAP distribution (as is almost everything else I listed).

For servers, we use FreeBSD. I'm sure other OSes would do a fine job, but FreeBSD has been rock solid for us.

Here are a few to please corporate marketing, sales and management types (yes, they're work safe):

http://prague.tv/galleries/funny-pics7/freebsd.jpg -- Remember, sometimes less is more.

http://www.nrg4u.com/freebsd/baby-doll-1-small.jpg (yeah yeah, I know, but they could learn a thing or two from them)

http://intdata.homeip.net/img/freeBSD-girl.jpg (mmh, amazing how many critical pieces of infrastructure are held together by duct tape)

Redundant components: http://tinyurl.com/a2uhp

One for the marketing department: http://www.servepath.com/images/better_devil_250x2 80.jpg

One to compensate for corporate randomness: http://images-jp.amazon.com/images/P/483990930X.09 .LZZZZZZZ.jpg (what is it about Japanese graphics that just screams "weird!"?)

And finally of course, http://homepage.tinet.ie/~cullenm/2dart/regi.jpg (just to piss off the zealots)

Ok, of course I'm single-minded, but seriously, folks, stick to working on the (fantastic) OS, let the sysadmins smuggle it into the enterprise like they've been doing for years :)

Long Answer: The concern is the misdirected bounce. By default and in accordance with the RFC, qmail bounces messages it accepts then later decides it can't deliver back to the sender. Spammers use false return addresses, so you end up bouncing spam back to innocent third parties. When used with naive spam-filtering techniques, this can be a problem i.e. qmail accepts the message, but a spam filter rejects it, and it is bounced. Here's what SpamCop.net has to say about it:

Qmail: Qmail is one popular mail exchanger which suffers from this problem by default. If you use qmail, please apply a patch: spamcontrol or qmail-ldap.

There is also an experimental patch for qmail which allows you to send bounces, but isolate them on a different IP address (so that spamcop can block them without blocking other mail): Richard Lyons BOUNCEQUEUE patch

PZInternet.com reports chkuser is a very good qmail patch to avoid misdirected bounces - very easy to install too! http://www.interazioni.it/opensource/chkuser/

For users of qmail-toasters, check out the simscan patch

I've set up an email system for our student foundation, Overflow, which is located at http://www.overflowers.nl. It was built from scratch, but I suggest you look into qmail/LDAP.

If I remember correctly, Exchange is capable of serving LDAP, so you _could_ just do a ldap search on it and import that in the LDAP system. If you use the qmail/LDAP system, you don't need local accounts. Plus, it's all opensource, so you can pass the authentication towards another system if you like.

ldap integration

Well, qmail supports ldap integration but it sure lacks the other features :)

I've only had experience of qmail and sendmail, and qmail has been much better for us.

Qmail's modular approach makes most things easier, once you figure out how it all fits together. It chews through mail very quickly, has the (IMHO) benefit of Maildir support - great if you share mailspools, or have a lot of POP users with big mailboxes - and a really flexible alias/rewriting mechanism.

The downsides are that things get a little rocky off of the beaten track sometimes. You do come across situations where qmail behaves differently enough from sendmail to be a pain (though not wrong), and I've found the mailing list to be somewhat obtuse at times (I don't subscribe - just searching other people's queries).

The other thing is to make sure that the HOWTO's you use match the software you have - several ancillary programs used with qmail have changed in incompatible ways in the past (the logging system, and the supervise setup - aka daemontools). The names have not changed to protect the innocent.

I'd recommend qmail though.

If you want to check on qmail again, I think it has what you are looking for + it's more secure than sendmail.

using qmail with LDAP database
Using qmail with only one single user account

Use LDAP for all email accounts. The qmail-ldap patches are available at http://www.nrg4u.com.

Note: this is not for the faint of heart, and probably involves overhauling your mail setup.

I've also looked into setting up something like that. It came down to using something like LDAP which is scaleable, standard, and OS-nonspecific for mail users. Then I had Qmail and Cyrus on the backend. I applied the Qmail LDAP patch, allowing Qmail to use LDAP for its user list. For Cyrus, there is another pwcheck file here. It adds the ability for it to authenticate against an LDAP server. Finally (yay!) we need the Qmail/Cyrus glue (as Qmail uses a slow mail format compared to Cyrus, and has no IMAP support [yick!]).

Incoming mail goes to Qmail, which uses scripts to deliver to Cyrus (users LDAP listed). User logins go through Cyrus server programs (which use LDAP auth), and can get their messages that way. This should also support virtual domains.

All in all, it sounds good ;-) I have yet to implement it (I'm going slowly and testing every step. Right now I'm converting my user base to LDAP, then I'll update Cyrus, etc).

Have fun.

Machine-wise, PC hardware should handle this nicely. Take a few PCs and put them in 2U rackmount chassis with a hardware RAID adapter mirroring (RAID 1) the system disk. Put a layer 4 switch, such as a Foundry ServerIron or Alteon AceDirector in front of these machines. Need to take a machine down because of upgrades or hardware failure? Want to add more machines to the cluster to improve performance? No problem. Take the machine down and the switch automatically removes the downed machine from the available pool of machines.

Mount mail spools from a Netapp Filer. Put a few hot spares in the Filer and now you've got redundancy and fault-tolerance for your mail spools, too. Plus, it'll be fun if you give anyone tours of your facilities. Imagine their reaction when you nonchalantly yank a disk out of a Filer taking that kind of load, and then watch the Filer automatically rebuild the drive on the hot spares you have in it. :-)

You can also cluster Netapp Filers ( more info), which would allow you to have two Netapps that would automatically sync their contents. If one fails, the other takes over transparently.

Lastly, if you're going to be having all of this NFS activity with that size a user base, I would highly recommend putting a second NIC in each of your server PCs. Link these second NICs in each of the PCs into a physically separate network from the one the users will be using to retrieve their mail. Gigabit Ethernet may also be an option here depending on the traffic demands of NFS in your situation. There are two advantages to this separate network. 1) It separates your NFS traffic from your user requests and data transfers, thus preventing the network from reaching its saturation point as rapidly and 2) you can secure the NFS network and allow only NFS requests and other management processes to use this network. If your Filers are only homed to this NFS network, it would take a break-in to one of the PCs just to gain a chance at administrative access to the Filer holding all of your user data.

The only downside to all of this is that Qmail doesn't have a daemon to serve IMAP. I don't have any experience with it, but I've seen Cyrus recommended a lot for IMAP service. There are patches on qmail.org that patch Cyrus to authenticate against a CDB, the file format that qmail can use for authentication and other lookups. You might be able to do something along the lines of creating a cron job that checks for a timestamp on the LDAP entries, and updates the CDB entry for a user if the LDAP info has changed since the last invocation. Maildir support might be dicier; I only spent a few minutes on it, but I couldn't find any info on getting Cyrus to deliver to a maildir.