Slashdot Mirror
Sendmail 8.10 Public Beta Released
Charles Ying writes "sendmail.net is reporting that Sendmail 8.10.0 Beta has been released to the public. The Sendmail Consortium hopes to get more wide spread testing from the open source community.
Sendmail 8.10 has a lot of new features such as IPv6 support, SMTP AUTH, multiple mail queues, improved anti-spam capabilities, and updated LDAP support. "
Sendmail is still necessary for certain special cases, like when you need BITNET support, or something else out of the ordinary.
But, I think for most users, Exim is a better choice.
If you haven't played with Exim before, you really ought to check it out.
--
Interested in XFMail? New XFMail home page
Sendmail may not be as hard to configure as most people think, but it IS riddled with security holes. Or at least, has been in the past, and most likely is now and will be in the future.
Qmail is simple and elegant. I think that there are three basic problems with Qmail, however:
1. Because there is no one right way to do things in qmail, trying to set up anything nonstandard can be confusing, if only because the qmail site lists many, many different sources of documentation for qmail, each of which says to do something different. That means that you have to understand alot about qmail (and the 15 other daemons that people have written to monitor, start, log, stop, police, etc qmail) to know which parts of a particular piece of qmail documentation applies to your site (are you running splogger? Are you using watch? fastforward? daemontools? countless other bits and pieces which your installation of qmail may or may not have?).
2. The qmail author seems to want to rewrite everything rather than use anyone else's code. libc is not used in qmail (or if it is, only a teeny little bit), in preference to the author's very cryptic, bizarre, and almost completely undocumented "replacement". So hacking the qmail code means puzzling over very strange, nonobvious, and undocumented C functions.
3. qmail spawns a separate process for just about everything. Kinda reminds me of the early days of web servers which spawned a separate process for every connection. I can't see qmail scaling to very large sites with a multiple-processes-per-email model.
On the other hand, qmail is *very*, *very* secure, and is, like I said, simple to install (especially with the RPM). It is also very good about logging what it is doing and a single person can understand, without too much difficulty, what is going on in the qmail system. And its performance is certainly adequate for small to medium sized sites.
There are somethings that sendmail, because of its "bloated" quality can do well. Ever try to do mail via BITNET or UUCP with qmail? Probably not - I'm not sure it can be done. But sendmail has hooks for those mechanisms.
Qmail is (argueably) easier to install, has a nice mailing list manager and IT WAS DESIGNED WITH SECURITY IN MIND. Sendmail wasn't. Thats not excusing its security holes - its just noting that the environments that shaped the two MTA is different. And perhaps its time to move away from a MTA that was designed wrong from the start. But you can disable alot of the unneeded features of sendmail if you want.
This is a near religous war (akin to emacs vs. vi). But for those of you who argue that sendmail has a difficult config file - have you ever read the README files on how to set it up? I'm working on installing a new mail server now, built around the Cyrus IMAP package and sendmail 8.9.3. Compiled Cyrus and supporting libraries (libsasl) on Tuesday and got it running. Compiled sendmail yesterday - install BerkeleyDB 2.77, got sendmail source, uncompressed and untarred, cd sendmail-8.9.3/src, ./makesendmail to generate Makefile, edit Makefile to point to Berkeley db stuff, make, make install, cd ../../cf/cf, create a 10 line .cf file, m4 miconfig.mc > sendmail.cf, HUP it and I have a MTA that hands off everything but a few local accounts (like root) to cyrus. Its got antispam features out of the box, it uses LDAP, its reasonably fast, and I did it in my spare time - cyrus install was about one hour and sendmail was about the same (less if you don't count the interruptions).
All the sendmail.cf file amounts to is an expansion of a ton of m4 macros. The .cf files are not difficult to generate at all - like I said, ten lines and I have a fully functional mail server. I don't profess to know what all the rules do - but I don't necessarily have to - it works.
Weird. I'd bet noone mentioning BITNET *knows* anything about it :) If I knew it, I would try it with qmail yes! I've run uucp over ssh with qmail, I've used FidoNET with qmail. No problem. My only problem with sendmail was that you can *fix* it to do something you want it, but you'll never understand it completely. On the other hand, if you take a few hours, and read all (included) qmail docs, and you know Unix, you can do *anything*, and you understood qmail totally.
If I let myself summoned with qmail bashing, let me share a few resources on it:
BTW, let me mention, Dan (the author of qmail) is the Math Professor on University of Illinois at Chicago, who sued the government to not restrict him distributing his crypto source at his web page (for his students!).
"Ten years from now, they could do it in a few seconds." -- The Racketeer of the Hellfire Club, 1993, Phrack 42
Ok, this might be true; but having things done in many ways is only confusing at first, i.e. bad from the user interface point from view. Alas, experts *prefer* things to be done any way they want. Or do you say perl is also bad? :)
Ok, bad from the engineering point of view, but the code he builds is superior from the viewpoints it needed rewriting. Not libc he avoids to use (it's quite difficult to do that in a portable Unix program), but stdio. Stdio is not quite designed for reliability (i.e. buffering, error handling), and security (overruns). His code is not quite nonobvious, I'd rather call it genuinely great. Too bad he doesn't have time to reinvent every part of Unix :)
You missed a qualifier: qmail spawns a very small separate process for just about everything. I think Ken Thompson, or some other old Unix guy said that if people understood fork() better, we would not need multithreading. Now, DJB *does* understand what is efficient in Unix, and small, cooperating processes are efficient, let me tell you. It is scalable really; although most of the top-volume email sites does not use it directly, it's just because no shrink-wrapped MTA does exactly what they want. hotmail.com uses/used qmail only for one of the in/outcoming directions, AOL uses sendmail, but on quite a few servers -- if I had 45 incoming servers, I could even run SMTP server written in BASIC on them.. :) For quite shocking loads however, qmail just works fine.
"Ten years from now, they could do it in a few seconds." -- The Racketeer of the Hellfire Club, 1993, Phrack 42
Being an end user I really saw no need to use a full blown mailserver which is capable to support a company with over 2000 employees
Sendmail is not about 'positive user experience'. It's about dealing with mail. Those who actually have to deal with sendmail (i.e. Unix network admins) are likely not too concerned about how much of a positive user experience they're getting from thier config files. They're most likely worried about whether or not Mr. Dumbass Veepee will be able to send mail.
It's not a user's program.
Which configuration file would that be? sendmail.cf? Even Eric Allman (author of sendmail) says he treats sendmail.cf as a binary file. Stick to the M4 files that are used to generate sendmail.cf and you'll be fine. They're certainly readable.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Sendmail 8.9 came out about 2 years ago.
8.10 beta is out now and, given a long beta cycle, would probably be released near year end or early next year (who's gonna change key software a month before y2k?). 8.10 has LOTS of changes, partly cause sendmail.com is paying people to work fulltime on the OSS version (kool). Reading the notice they sent, as a beta release, they can still make feature changes, so there may be more (if (client==exchange) {sleep 10;continue;}). So...
based on that, I'd guess that 8.11 would come out sometime in 2002 or so.
How long before 8.10.0beta7 is out? No guess. It's beta software. Real beta, not like Netscape/AOL or microsoft beta, but beta like "help us find bugs and work on this test version of the software" beta. It's running on the home machine as of noon, handling 10's of messages a month.
As a Sendmail, Inc. employee, I have to say it's worth it. 8^)
.m4) and map files. As a consultant, I am building lots and lots of client configurations, and without the GUI, I'm, quite honestly, lost. But with the GUI it is very easy to set up and maintain a sendamil.cf. *Plus* you can then delegate the maintainance to another user who may not be completely sendmail savvy, but the online help associated with the GUI (with numerous pointers to appropriate sections of the bat book) helps a lot.
The biggest feature of Sendmail Pro is the GUI front end to the sendmail.cf (actually the
The map editor is currently simplistic. But (AFAIK) that's being worked on.
Another huge feature associated with Sendmail Pro is support. If the open source sendmail breaks, who do you call? You can post to the sendmail.org mailing list or comp.mail.sendmail, and *hope* that someone replies. That is the one real downfall of open source (IMO).
With Sendmail Pro, we have real live bodies who do phone and email based tech support. We have consultants who can assist with setup and configuration/customization. For the base price, there's one level of support. You can opt to spend more, and get better levels of support. I can't say what those costs are (I don't know... I'm just one of our consultants... not a sales dude).
But many companies like spending that money when it gives them a body/organization they can point to (even if they never need to).
Regards,
Richard
Up untill the moment where I felt the need to learn more about the whole system and start fiddling with other options like mail, news, firewalls, etc, etc. I never had any major problems configuring programs like INN (I'm using INN stand alone to fetch & send my usenet messages, you don't need 'suck' and such if you know INN), ipfwadm/ipchains, etc. But the program which actually scared me off due to its allmost unreadeble configuration file has allways been sendmail.
Don't get me wrong here; I'm not saying sendmail is a bad program because of that but I do think its a major part which could be changed in order to make it a little more userfriendly. I know there are lots of programs around which can do most of the configuration part for you but I don't like that sort of stuff. Simply due to the fact that I like to have control over my computer and thats exactly why I like Linux so much. To throw this control away (sort of) sounds kinda silly to me.
At the moment I'm using QMail myself since I found the setup and configuration a breeze compared to sendmail. Being an end user I really saw no need to use a full blown mailserver which is capable to support a company with over 2000 employees (assuming sendmail can handle this btw). But its allways nice to see that there is still development going on and I think I'll take a quick peek in the weekend. Never hurts to keep up with the facts, even if you don't like the program in question all that much.
Why not use the much better 100% sendmail compatible program PostFix. It has better performance, easier (much easier) configuration and is easy to install? At least all of you sendmail users out there should give it a try.
For the record - I have nothing to do with the PostFix project, I'm just impressed since it's a much better program.