Slashdot Mirror

Concur. Even beyond that, there's still plenty to respect about the software as well, that many folks don't bother thinking about.

True, Dr. Berstein can be a screaming asshole at times. However, if you RTFA, you'll see that even screaming assholes can learn from their mistakes, and Dr. Berstein has learned from some of his -- even to the point of acknowledging that he was saved from one of his mistakes only by a lack of bugs.

True, his software operates in a fundamentally different way than most daemons you're used to dealing with. That doesn't make it bad or evil or stupid, merely different. On the other hand, if you can't handle things that are different, you shouldn't try to simultaneously administer Samba and Apache, since they're different from one another as well.

False, his software isn't "undocumented." There are excellent resources available on the net (and at your local bookstore) for the software. The fact that Dr. Berstein didn't write them doesn't mean they're not useful. When in doubt, consult eg thedjbway or qmail.org or LWQ (Dave Sill's excellent howto, which is actively supported on the mailing list) or LWDJBDNS.

True, the people on the mailing lists can seem to be assholes. However, it has been my experience that if I scrupulously adhere to ESR's suggestions on How To Ask Smart Questions, I get much more helpful responses than when I do not. On the occasions when I've needed to go to the mailing list for help, when I failed to be clear and intelligent, I got useless garbage back. When I ask intelligent questions, I get back answers that either tell me what the mistake I made was, or (more often) point me in the right direction so I can solve the problem myself. Sometimes, just writing the question up will reveal the problem to me. If you don't like that, it's not a flaw in the software -- it's a flaw in your thinking.

There are lots of reasons I use djb software, but the most important is this: Once it's set up, I can forget it. In seven years of running qmail, I've once had to seriously jack with it after getting it going, and on that occasion I can't say definitively the flaw was in qmail (but I can say definitively that the trigger was me and my not paying attention to the box). I've never had to update for a security hole for either qmail or djbdns. It is one less thing to have to jack with, and I have plenty of other things that need my attention.

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.

A free book on qmail, Life with Qmail, is even available online and the quality is similar to Subversion's book which is among the best downloadable tech books available. It describes how to install netqmail-1.05 which is basically qmail-1.03 with a minimal recommended set of patches:

http://www.lifewithqmail.org/lwq.html

A company, Inter7, provides commercial qmail support but they publish most of their qmail-related software as GPL open source projects which can be downloaded and redistributed for free. They are super easy to use.

And then there's http://www.qmailrocks.org/ which offers installation scripts for qmail plus a dozen optional qmail-addons for these operating systems:

* Redhat Linux/RHEL
* Fedora Core
* FreeBSD
* Debian
* Slackware
* Solaris
* coming soon: Suse and OpenBSD

You can blame qmail for eating your system, but I was able to install it fine (manually from scratch) as my very first MTA ever and it worked fine. I didn't even fully understand bash or symbolic links at the time but managed to do fine.

NOTE: I installed (and still use) netqmail-1.05 + vpopmail-5.4.x + qmailadmin-1.2.x installation without all the extras available from qmailrocks.org

I chose qmail because it is currently the most secure MTA and that outweighed some of its disadvantages (like being slower than Postfix 2.2 by using more disk i/o and no-binary license). I'm considering a switch to postfix 2.3/2.4 when that branch is stable purely out of my curiosity and desire to be disloyal to every software/OS/distro I ever use. Switching whenever a *sufficiently* better software comes along (disloyalty) promotes better software all around.

UNBIASED SUMMARY OF MTA
(I'm using qmail+vpopmail in 2005-6, postfix in 2007-8, exim in 2009-10, qmail-2.0?)

qmail: most secure so far (amazingly so), easy to configure/admin after install, but not as good for relaying, slower than postfix, only unmodified source can be redistributed so installs are via patch+compile scripts, requires 'thedjbway' of doing things which I initially disliked but have grown to prefer it over init.d

postfix: 2nd most secure, fastest, not as mature as qmail but catching up fast

exim: monolithic & not as secure as qmail or postfix, usually fast but not for queued mails, Debian's default MTA means popularity will grow

I know some people think DJB (qmail author) is strange (he's a professor of computer science in illinois) but he managed to do 2 things that are rare:
1. write very widely used server-side software which managed to avoid serious security vulnerabilities for years: he helped us avoid using BIND and sendmail
2. fight the US govt. in court over cryptography

And for that, he deserves some respect regardless of what GPL fanatics say about him because of his unmodified-source-only distribution licenses. Their fanaticism is rivaled only by fundamentalist radicals infecting major religions like Christianity which ends up driving rational people away rather than toward it.

---

"Humans wrote the Bible. God wrote the world."
God vs Bible

I use qmail for my servers and it can do this quite easily in a number of ways. There are lots of good online documents about qmail as well as the official qmail site. The simplest method is probably a default install with a .qmail-default file in the alias directory which has two entries in it. Each entry could be a different destination email address or local account. This would certainly duplicate the email coming through, but may not be the best way to do your job. Working with the qmail-smtpd program may get you a solution closer to your needs. Good luck!

Qmail is most likely the best option, since it is very scalable.
the web site for qmail is :
http://www.qmail.org/top.html

you are going to have to add this patch for more than 256+ connection ( which you will need for safety's sake and scalability )
http://www.qmail.org/big-concurrency.patch

You are going to need to add preventive measure ...double email bouncing script http://www.30below.com/~zmerch/qmail/spambad.cfm

there are tons of patch's and how - too's for spam reductions.

read this http://www.lifewithqmail.org/ldap/
to get some better understanding of qmail

Now onto the server side .... well I use the basic thinking that each users will use 1 to 3 meg of space before downloading to there outlook account. You have some history, so check what the average file space used per user is. next don't forget to find out what the company's e-mail policy is ( do they have to save e-mail for xyz amount of time, back-up policy's ... ).

next don't forget that no mater what, each user gets 3 pieces of e-mail per day ( that's my number that I use for configuring the server ) ... so with your needs you'll require a 2 cpu system ( of which you'll share the spam software ) and an excess of ram ( to run the dns blacklisting or other cpu/ram intensive operation ).

File server... that's open, my thinking would be a true raid 5 system, hot swappable, build it yourself. here is a link to a do it yourself terrabyte server for under 10K way back from 2002 and posted at that time on slashdot http://home.fnal.gov/~yocum/storageServerTechnical Note.html or http://www.accs.com/p_and_p/TeraByte/index.html that should help you along the way

best of luck and enjoy

Onepoint

Umm, qmail is very open source. qmail has never been anything but open source. It may not be "free software" but it is most definately open sourced.

For what its worth, you asked about "within one year of being released due to the discovery of bugs by users"

The beta and gamma versions obviously don't count (WoW had a beta period as well). "Since release" would obviously be versions 1.0 to 1.03 (present) in the case of qmail.

According to LWQ, "Version 1.0, the first general release, was announced on February, 20, 1997. The current version, 1.03, was released on June, 15, 1998"

That said, it did have updates, but I can't say that any of them were because of bugs discovered by users.

See also the qmail challenge for information about the lack of security related bugs found in qmail (ever).

Get real. djbdns' source is 100% available for you to look at and patch to your hearts content. If you find an error, send a fix to DJB and he'll add it after review.

"Available Source" !== "Free Software".

You can't redistribute changed, patched DJBDNS. You can't fork it if you figure something requires a fundamental change in design philosophy. You cannot distribute binaries. DJB release a new version every millenium or so - so when you set up Qmail or DJBDNS, you spend a week applying patches and testing them just to get things like Qmail-ldap to work.

You'll never, ever find a pre-made RPM for DJB-DNS. Thus, things like "yum update" can cause all sorts of grief, and will certainly NEVER result in an updated QMail!

Where in ANY of this did you get the idea that just because you can download DJB sources, that it's "Open" or "Free"?

If you were SERIOUS about "Open Source", perhaps you should read a bit on what it actually means?

Read Life With Qmail

I will admit qmail was hard to setup. I will also admit it has been worth every second I spent setting it up.
Oh, to answer your question, 10 users on a Timex Sinclair with 4k of RAM. *smirk* Actually, started out on an AST Bravo P90 with 96 meg RAM. Got moved to a Compaq DP2000 P166MMX with 64 meg of RAM after the cache memory failed. Rock Solid every since. Oh, and did I mention it runs Debian?

Vertical

You do not need to be a programmer to set it up, unless the ability to follow directions makes you a programmer. As far as spam blocking goes, why would you expect a spam blocker out of an MTA? Most people would figure out that qmail is not for blocking spam and instead would use something like spamassassin and have the best spam blocker up and working within 5 minutes like I did.

I suggest buying the book if you plan on implementing it. The online version isn't enough (and covers about 1/3 what the printed version does).

Make sure you follow the relay-ctrl section very close. You could be a source of spam if you do it wrong!

But many people don't know how to setup qmail, or give up trying after grinding their teeth.

Then may be they should follow the directions.

...my only experence with qmail or postfix was reading the documentation to see how hard it would be to convert my sendmail setup...

I don't see anything unusual in your list. Do you think there aren't qmail users who have widely varied and specialised needs? I'm not going to pretend that you won't have to do any reading and learning in order to migrate to qmail, but that's very different than claiming that only sendmail has the features you need. Unfortunately, I am unable to give you step-by-step instructions, but given that you're intelligent enough to understand how to configure sendmail, you shouldn't have any problem starting with the qmail home page and proceeding from there. Also good is life with qmail.

You want to replace your entire MTA, one of the most notoriously difficult-to-imlement pieces of software on any internet-connected host, and you want it to work perfectly, but you don't even want to spend a day on the task?

Rotsa ruck, man.

The closest I can offer to this: download qmail, along with fastforward and dot-forward.

Install qmail by following the directions in the "INSTALL" documents exactly, then read djb's qmail to sendmail migration checklist and follow it's instructions exactly.

Assuming you haven't done anything really gonzo with your sendmail config, you should have a working system in a few hours. Then go read Life with Qmail so that you'll actually have an idea of what you've just inflicted on yourself.

An SMTP server doesn't speak LDAP? Why should it? You can add LDAP functionality from one of the patches on qmail.org or through the QMail-LDAP project.

I used qmail on my servers, it runs very smoothly and I haven't had any problems since I got it properly configured. I'm still trying to figure out how to use SMTP AUTH though (it seems that qmail requires the addins of others to use this) and having to change outgoing mail settings on my laptop whenever I go somewhere is a pain in the butt. life with qmail details all the necessary instructions except for SMTP AUTH configuration.

If somebody on /. would be so kind as to offer a good SMTP AUTH plug with a comprehensive set of instructions, I'd recommend you try it.

Depending on which MTA you're using, you can do this with address extensions too. Sendmail uses + as it's address extension, and postfix/qmail use - for address extensions. So for my email, for example, mark-foobar@hornclan.com will get delivered to the same mailbox as mark@hornclan.com. The MTA simply ingores everything after and including the extension delimiter.

Quick note: for qmail, you have to have a .qmail-default in place (either blank, which goes to your default delivery destination, or sent to somewhere specific) for this to work for an arbitrary address. Otherwise, it won't get delivered unless you specify the "extension" (ie. .qmail-foobar will allow email to mark-foobar@hornclan.com in the example above).

This also allows you to send specific addresses elsewhere automatically. If you know that mark-foobar is always crapola, then you can setup rules for just that address, leaving all of the still good ones alone.

For more info, check out Life With qmail.

I just wanted to point that out b/c I have learned more than I ever wanted to know about email in an attempt to migrate my email servers from Exchange/Winblows to Qmail/Linux. I would have tried BSD (since that is what it was developed on) but I have more experience with Linux.

Since I really DIDNT want to be an open relay I tested and tried a load of configurations. Sadly I was open for about 1/2 of a day (and of course some jackass sent about 20 messages through my server).

I've found the best way to setup QMail is to combine 3 sources (Life with Qmail, his book (which contains significantly more info and is DEFINATELY worth the price), and reading EVERY PROGRAMS file/man page to see how they are implemented (uscpi, daemontools, checkpassword, qmail, relay-ctrl, ...). If you take it slow the first time it works quite well.

Now just to get Courier/Horde/IMP installed.

My former university is using QMail for their Sooner Information Network On-line Mail. It seems pretty cool.

Life With Qmail

Building a Linux Qmail Toaster

Same thing, but with FreeBSD (more scalable, in my experience)

have fun

Ok, I can't believe I am going to bite on this troll but here it goes:

QMAIL is not your problem. In fact, even if you REALLY screw up in your setup qmail is still hard to use as a relay as you ACTIVELY have to open it up as one.
Now I'll get to your points (which are few):

I think you are saying that qmail allows relaying. -- That is false. If you read the relaying section in life with qmail you will notice that it says "If you follow the official directions for installing qmail, relaying will be turned off by default." -- Obviously you messed that up.

To monitor your rule you will look in the /etc/tcp.smtp file and find rules in this pattern:
IP address of client:allow,RELAYCLIENT=""
IP address of client:allow,RELAYCLIENT=""

Now unless you are using like pop-before-smtp then that' it. If you are using pop-before-smtp make sure your cron job is running every half hour to clear out old relay entries.

<RANT> PLEASE DON'T BLAME QMAIL FOR YOUR MISCONFIGURATION</RANT>

You can email me privately if you still need help and Cliff, you should not have posted this troll.

-dave

You say you might have relayed spam, but you offer no proof. In a properly setup qmail installation, you will not relay. You may accept messages that are spam (like any other MTA), but those messages won't go anywhere. Read life with qmail. If you have setup differently, then rebuild using lifewithqmail instructions.

I wasn't aware (read: didn't care) that RedHat was involved in any hullabaloo regarding qmail & djbdns. However:

Qmail and djbdns are each distributed under licenses which basically prohibit you from distributing modified binaries. You can redistribute the source, you can write patches for (and redistribute) it, you can distribute binaries. You may not redistribute patched binaries or directly modified source. The full text is here

This makes GPL die-hards pretty upset. If I'm reading this correctly, some folks petitioned RedHat to include both qmail and djbdns in their distribution, and RedHat balked because of license issues. The thing is, they already were distributing Netscape, so the license argument sounded kind of lame.