Ahmad
02-17-2002, 12:34 PM
Does anybody have reasons to use one over the other (exim and qmail) for a virtual hosting environment?
Thanks
Thanks
![]() | View Full Version : Exim or qmail? Ahmad 02-17-2002, 12:34 PM Does anybody have reasons to use one over the other (exim and qmail) for a virtual hosting environment? Thanks cperciva 02-17-2002, 01:01 PM Yes. DJB wrote qmail. Depending upon what you think of DJB, this will inevitably lead to a choice of MTA. Ahmad 02-17-2002, 01:34 PM Originally posted by cperciva Yes. DJB wrote qmail. Depending upon what you think of DJB, this will inevitably lead to a choice of MTA. well :) I'm really a big fan of him, but that doesn't mean that his software is always the best. AFAIK, qmail haven't been updated since 1998, one might think that exim had more chance for improvement ;) Besides, my conscience wouldn't let me decide on qmail before asking people who tried the both of them :D cperciva 02-17-2002, 01:39 PM Originally posted by Ahmad AFAIK, qmail haven't been updated since 1998, Arguably, qmail doesn't *need* further updates. But it's a bit misleading to say that it hasn't been updated anyway; the array of patches and addon utilities keeps growing. Ahmad 02-17-2002, 01:44 PM Originally posted by cperciva Arguably, qmail doesn't *need* further updates. But it's a bit misleading to say that it hasn't been updated anyway; the array of patches and addon utilities keeps growing. But the array of patches and addon utilities are not written by DJB, which is the main feature of qmail! Mike the newbie 02-17-2002, 02:09 PM Originally posted by cperciva Arguably, qmail doesn't *need* further updates. But it's a bit misleading to say that it hasn't been updated anyway; the array of patches and addon utilities keeps growing. It is the "array of patches" that caused me to move from qmail to postfix. It got to the point where there were conflicts among the patches I needed to install, with no resolution possible. As an additional plus, postfix is around 10% faster than qmail, and a bunch easier to configure. As always, especially with MTAs and editors, YMMV. :D Ahmad 02-17-2002, 02:17 PM Originally posted by Mike the newbie It is the "array of patches" that caused me to move from qmail to postfix. It got to the point where there were conflicts among the patches I needed to install, with no resolution possible. As an additional plus, postfix is around 10% faster than qmail, and a bunch easier to configure. As always, especially with MTAs and editors, YMMV. :D The problem with Postfix is that it doesn't seem to be supported by the open source community because of its license :(. Its not so popular. clocker1996 02-17-2002, 03:52 PM I personally use qmail with vpopmail + qmailadmin for numerous websites.. its great Mike the newbie 02-17-2002, 04:19 PM Originally posted by Ahmad The problem with Postfix is that it doesn't seem to be supported by the open source community because of its license :(. Its not so popular. Yeah, the IBM Public License is not as wide open as GPL or BSD licenses, but then again, neither is the qmail license. :unhappy: Ahmad 02-17-2002, 04:56 PM Originally posted by Mike the newbie Yeah, the IBM Public License is not as wide open as GPL or BSD licenses, but then again, neither is the qmail license. :unhappy: qmail at least is guaranteed to be free :) .. not the case with IBM's license. And you can tell that to the open source community, maybe they will listen and postfix will become more popular. Being popular is good for both good support and PR reasons ;). Espicially that I intend to target the developers market. Mike the newbie 02-17-2002, 05:46 PM Originally posted by Ahmad qmail at least is guaranteed to be free :) .. not the case with IBM's license.... Well, the current versions of qmail are free, but the license (whatever the license might be --- there is no LICENSE file in the current tarball) could change with the next version. It is djb's prerogative to do with the license as he pleases, and I see nothing in his current license that says he is forced to release future versions of qmail for free. Even if such a provision were there, I doubt it would be enforceable. Once I get a copy of software under IBM's public license, that copy will always be free as well. As such, by my reading I see little difference between the two licenses, except that djb's is extremely restrictive regarding where files may be placed on the target systems. Starhost 02-17-2002, 06:13 PM I'm currently using EXIM and I have to say I really like it. Thefore I recommend it to you. It is running great :D priyadi 02-17-2002, 08:28 PM Originally posted by Mike the newbie As such, by my reading I see little difference between the two licenses, except that djb's is extremely restrictive regarding where files may be placed on the target systems. Yes, that prevented RedHat from using qmail as its MTA. Some qmail RPMs also cannot be distributed in binary format, only in source format. AFAIK, some control panels distribute qmail as its MTA (plesk comes to mind). I wonder how they did to qmail without breaking the license, as I find an unpatched qmail is not good enough. Ahmad 02-18-2002, 08:59 AM Originally posted by Mike the newbie Well, the current versions of qmail are free, but the license (whatever the license might be --- there is no LICENSE file in the current tarball) could change with the next version. It is djb's prerogative to do with the license as he pleases, and I see nothing in his current license that says he is forced to release future versions of qmail for free. Even if such a provision were there, I doubt it would be enforceable. Once I get a copy of software under IBM's public license, that copy will always be free as well. As such, by my reading I see little difference between the two licenses, except that djb's is extremely restrictive regarding where files may be placed on the target systems. I can see your point now, and I think that its safe to say that I agree with you :). I'm aware of DJB's rules, binaries must have certain md5 values to be destributed, meaning that you cannot even distribute the unchanged source if you compiled it with a different compiler (Assuming that different compilers generate byte code in different ways.) However, the problem isn't in the license itself as much as it is in the communities acceptance of the license. From the way I see it, Sendmail, qmail, Postfix and Exim are all the same. I won't use sendmail for obvious PR reasons. So qmail, Postfix and Exim are all equal to me. I hope that somebody will come up with a very convincing reason to use one MTA from the others before is start tossing coins to make that decision :) I hope I won't have to write my own BSD licensed MTA :mad: cperciva 02-18-2002, 09:07 AM I'd go with qmail. Quite apart from the issue of security -- DJB's record alone grants a certain degree of confidence -- the fact that so many patches and addons exist for qmail demonstrates how easily it can be extended. You're not likely to need to extend or patch qmail -- it's a very good MTA as it is -- but in the unlikely case that, for example, you want to filter messages before they hit the queue, or change POP3 authentication mechanisms, etc. you'll be able to do so with a simple extra program rather than trying to decypher the internal workings of whatever MTA you're using in order to know where to add extra code. cyansmoker 02-18-2002, 09:14 AM I believe that something very important, when you're a hosting company, is sendmail compatibility. Not full compatibility, just that perl and php programs be able to invoke sendmail, for instance. Many of our clients are running scripts they acquired for a hefty fee (professional mailing lists or forum program) and they would hate it if they'd lose sendmail compatibility. I believe qmail offers a certain level of decoration? cperciva 02-18-2002, 09:18 AM I haven't had any problems when using qmail's sendmail wrapper. It might not be completely compatible, but it's been close enough that I personally haven't noticed otherwise. Ahmad 02-18-2002, 10:12 AM Originally posted by priyadi Yes, that prevented RedHat from using qmail as its MTA. Some qmail RPMs also cannot be distributed in binary format, only in source format. I read that redhat tried to convince DJB to change his restrictions for a while but with no luck. AFAIK, some control panels distribute qmail as its MTA (plesk comes to mind). I wonder how they did to qmail without breaking the license, as I find an unpatched qmail is not good enough. It is possible that they put the unchanged source with the patches in the distrobution and have the installation script to automatically patch and then compile the source code. Another solution would be to include patches to be directly applied to the binary distrobution. Ahmad 02-18-2002, 10:15 AM Originally posted by cperciva I'd go with qmail. Quite apart from the issue of security -- DJB's record alone grants a certain degree of confidence -- the fact that so many patches and addons exist for qmail demonstrates how easily it can be extended. You're not likely to need to extend or patch qmail -- it's a very good MTA as it is -- but in the unlikely case that, for example, you want to filter messages before they hit the queue, or change POP3 authentication mechanisms, etc. you'll be able to do so with a simple extra program rather than trying to decypher the internal workings of whatever MTA you're using in order to know where to add extra code. Postfix also have the same design as qmail and I'm assuming by my quick look at the Exim manual that there is a well established API to extend it (transports, directors, ..). Ahmad 02-18-2002, 10:23 AM Originally posted by cyansmoker I believe that something very important, when you're a hosting company, is sendmail compatibility. Not full compatibility, just that perl and php programs be able to invoke sendmail, for instance. Many of our clients are running scripts they acquired for a hefty fee (professional mailing lists or forum program) and they would hate it if they'd lose sendmail compatibility. I believe qmail offers a certain level of decoration? If you mean programs that relay on 'sendmail' the binary file itself, then I guess that qmail's wrapper would be sufficient. However, If you are talking about other sendmail specific features, like the way it handles delivering messages to pipes, then thats a different story. Lots of websites today are moveing away from sendmail, so I would expect that those writers of hefty fee programs should take into consideration the different MTAs available today, espicially that it is very easy to write programs to handle such MTA interfacing. bobcares 02-18-2002, 11:21 AM Hi! I'm a very conventional guy when it comes to my MTA.... ;) Let's put it this way - 1) Sendmail - The grandma of the industry and if well configured the very best one can have.... 2) Qmail - Good in terms of performance and reliability. But not much in terms of future development. 3) Exim - Very popular especially because cpanel servers use it as the default MTA.... Have a great day :) Regards Amar bitserve 02-18-2002, 05:25 PM I did some work for a company with a Linux distribution, and we used qmail. Originally, I believe that DJB said that you weren't allowed to distribute binary versions of qmail unless you supported them and maintained the same directory structure. That's changed. Now, you need his permission. We got his permission, which was as simple as him saying "sure, just send me a copy of the source". Our alternative would have been to just install qmail at install time from a source RPM. qmail, with patches, is a very good program. Better than sendmail definitely. Honestly, I've never tried exim. priyadi 02-18-2002, 07:19 PM Originally posted by Ahmad It is possible that they put the unchanged source with the patches in the distrobution and have the installation script to automatically patch and then compile the source code. Another solution would be to include patches to be directly applied to the binary distrobution. Source patching is not an option for distributing a product, it will cause too much hassle for customers. Your second option is a good idea though, a nice way to get around DJB license restrictions. :) cperciva 02-19-2002, 12:18 AM Originally posted by priyadi Source patching is not an option for distributing a product, it will cause too much hassle for customers. How does that cause too much hassle? The customers don't have to do any of the patching. With the FreeBSD ports system (which works this way) I expect many people are quite unaware that FreeBSD-specific patches are being applied between downloading the source and building. After all, to the user it's just `cd /usr/ports/category/application && make all install`. priyadi 02-19-2002, 06:47 AM Originally posted by cperciva How does that cause too much hassle? The customers don't have to do any of the patching. With the FreeBSD ports system (which works this way) I expect many people are quite unaware that FreeBSD-specific patches are being applied between downloading the source and building. After all, to the user it's just `cd /usr/ports/category/application && make all install`. Yes, but how many people use FreeBSD ports to distribute THEIR own software? If I want to distribute a modified qmail along with my own software, I need a better method. The point is to reduce customer support, I can't just RTFM them when something goes wrong on their system. cperciva 02-19-2002, 07:41 AM My point was that distributing software as original version + patches doesn't necessarily make things any harder for the end user. Although, now that you mention it, when I distribute my customized qmail, I simply distribute a package which adds my personal diffs to /usr/ports/mail/qmail/files and then runs the FreeBSD ports make. *shrug* Ahmad 02-19-2002, 11:16 AM About the distribution debate :) .. source distributions are more portable, but there is a greater chance of something going wrong. This is because the installation process now involves linking and compiling the code. The user might experience problems with header files, linked libraries, compiler incompatabilities .. etc. On the other hand, binary distributions aren't as portable, but they have less [i]potential[i] for errors. Anyway, I would like to thank people reporting success with different MTA's. I would also like to hear more about it. I'm soon going to make a decision about what to install and learn. I know the basics of most of them, but I want to read all the details and know my software very well before I use it. Another point is, what would you suggest for reading? Oreilly have an Exim book. I've waited alot for their qmail book with no luck yet. I've heared about it for more than a year now. Sams have a qmail book and a postfix book, both by the same author. AFAIK, they are the only books available about qmail and postfix. The qmail books doesn't seem to get good reviews and recommendations. EDIT: some grammer bitserve 02-19-2002, 03:45 PM Of course there is no compatibility issue when releasing qmail as source for part of your linux distribution. Because your installer controls the entire environment. But we were able to just include the binaries with the image, which is faster if nothing else. Ahmad 02-21-2002, 12:36 PM Originally posted by bitserve Of course there is no compatibility issue when releasing qmail as source for part of your linux distribution. Because your installer controls the entire environment. But we were able to just include the binaries with the image, which is faster if nothing else. You are right. But for hosting controllers, its not the case. The reason why DJB doesn't allow redistributing modified versions of his software is compatability. He would give you permission to redistribute qmail with some little patches, but redhat for example wants to play around with files and change the path to the configuration file with every version they release, so I doubt that they will get permission from DJB to distribute their modified version. Anyway, my conclusion is that all four MTA's are the same, picking one is a pure personal/PR decision. |