Slashdot Mirror
Sendmail Performance Tuning
This book was very easy to read and kept moving along. While I did not find it as much of a page turner as Douglas Adams' Hitchhikers Guide, it did keep me interested. One word of warning though: do not read this when you are tired. You will miss some really good information and have to re-read parts.
I was surprised and very pleased with how much I learned about so many things about Unix, networking and hardware while learning more about sendmail. There is a wide range of information presented that readers at almost any skill level would be able to use. The writing style and use of language was easy to read. The wealth of information packed into the pages of this book I found immediately usable on my Linux boxes and for my job.
I think the only drawback to the book was that there was not more specific sendmail information. Due to the nature of the topic, a lot of the book is devoted to how Unix systems work, more than specific sendmail configuration tasks. Time and detail is spent on other more important considerations such as logging, disk performance, test planning and file systems.
Chapter 1 gets us started with an overview of tuning in general. One of the more important themes of the book is established up front: It is that a cost/benefits analysis should be done for each step.
Sections 1.5, "Tuning Isn't Always Necessary" and 1.6, "Not So Fast ..." establish baseline considerations for making a decision on what, if any, tuning efforts should be made. Throughout the book Christenson reminds the reader to decide on a path that is most cost effective for his organization. Is it the most cost-effective use of the company money and time to have the IT staff hand-craft solutions, or is it better to throw some hardware at the problem?
Let's face it -- if you are running sendmail for a small company and only move a few hundred emails a week, how much performance tuning do you need? If, however, you are running an ISP, a mailing list server or a medium- (or even a large-) sized company mail server, then you need to tune your mail server. This is the book for you. The information in this book, while oriented for sendmail, is actually applicable for tuning any Unix based Mail Transport Agent (MTA) server.
Each solution is an individual matter, that is wholly dependent on several factors. Some of these factors are: volume of email, what the main use of the email system is, how the end users interact with the system, what hardware is being used, how much bandwidth you have and much time and money you have to throw at the problem. Of course, what management considers important is the overriding factor in all decisions.
Chapter 2 is a ten-page introductory overview to sendmail, covering versions, obtaining the (Open Source) code and building sendmail. One of the important things covered is the queue and message spool layouts and permissions. This is helpful for making sense of things later in the book.
A few very important pages are spent on creating the .cf file and why you should use M4, the macro language, for managing the configuration files. Having hand-crafted a .cf file myself several years ago then having to deal with maintaining it, I can vouch for the wisdom of using M4.
The maintainers of sendmail update the M4 macros for new features and changes. The 200 - 300 lines of M4 macro files are converted into a 1500to 2000 line configuration file. While it may be easier to figure out the configuration file to make changes, those changes may not be valid from one version of sendmail to the next.
Christenson admits that he does not always use M4 when in a rush or to test some things. What he does is copy the working configuration file to sendmail.cf.REAL before making changes and updating the .mc file afterward.
The next chapter, Chapter 3 'Tuning Email Relaying' starts with an overview of the email relaying sequence. Most of the discussion in this chapter is not sendmail specific. The importance of data synchronization is emphasized here. Section 6.1 of RFC 2821 is quoted, where it states the email server 'MUST NOT lose the message'. Once that is stated and understood all of the requirements that are discussed in the rest of the chapter are clear.
The next 17 pages are spent discussing how file systems, networking and effective use of file space support, and can detract from, meeting the edict of the RFC. For me, these sections are some of the most interesting, filled with information presented in a concise, readable and detailed manner. I learned a lot about what impact some very basic decisions have on email performance. I also learned how much better I could have made the email servers I have worked on. I will be turning to this chapter the next time I am putting together a box, be it a web server, mail server, file server or even a workstation or laptop. This is a great chapter that can help with any system configuration.
Email reception is covered in chapter 4. Different strategies for verifying recipient, tuning POP and IMAP are covered. Effective use of Local Delivery Agents (LDAs), including procmail, is covered here also.
Additionally, an excellent discussion of storage systems, including disks and solid-state disks, is in this chapter. The sections covering RAID levels, benchmarking and use are well written and informative. Available options on drives, ATA vs. SCSI, Solid State, are just as well done. Section 4.4.2, 'Stupid Disk Drive Tricks,' has some nifty information about how to set up disk drives for even better performance.
Sending email is the next chapter. Here we see some more sendmail-specific information. Tuning of mailing lists and mass mailing is part of the discussion here. One of the more important sections is 'Draining Queues.' How backups are caused and what to do to recover are discussed in this section. This has good information that can be used with any MTA.
One of the most important chapters for me is Chapter 6 'Configuration, Security and Architecture.' Sendmail specific configuration and tuning options are discussed. Section 6.1 covers configuration and is in many ways the heart of the book. This is where sendmail directives that can directly impact performance are covered. How a system's architecture (and DNS) is laid out can have a significant impact on performance.
The section on security is good, but brief. Most of the discussion is on privacy and stopping spam. The use of Transport Layer Security (TLS) is covered in less than a page. With a smattering of security in other parts of the book, this is the sum total of the security discussion of the book. Considering some of the problems with sendmail in the past, I would have liked some more information on this topic.
The next two chapters, 'Finding and Removing Bottlenecks' and 'Load Generation and Testing,' are good, solid, well-written sections that are applicable to most any email system. We are given some effective ways of making systems run better, and how to prove that the system actually does work better. This is where we justify to the boss that the work we have done is really cost effective.
Chapter 9, 'Conclusion' is basically a very brief wrap up and a list of books Christenson thinks we should read.
My own conclusion is that I have learned and relearned a lot of things about Unix and email. Even if you do not use sendmail, I recommend this book without reservation. It is an excellent reference on general system performance tuning, with information on making your sendmail installation run better.
Table of contents
- Introduction
- 1.1 Performance Tuning Examples
- 1.2 sendmail Versions Covered
- 1.3 Definitions
- 1.4 Email Server Tasks
- 1.5 Tuning Isn't Always Necessary
- 1.6 Not So Fast...
- 1.7 Email System Profiling
- 1.8 General Tuning Ideas
- 1.9 Summary
- Sendmail Introduction
- 2.1 Obtaining Sendmail
- 2.2 Building Sendmail
- 2.3 Creating a .cf file
- 2.4 Why Use M4?
- 2.5 System Setup
- 2.6 Summary
- Tuning Email Relaying
- 3.1 What Happens During Relaying
- 3.2 Synchronization
- 3.3 File Systems
- 3.4 File Space
- 3.5 Networking
- 3.6 Summary
- Tuning Email Reception
- 4.1 What Happens During Email Reception
- 4.2 Recipient Verification
- 4.3 Storage Systems
- 4.4 Disks
- 4.5 Solid State Disks
- 4.6 POP Tuning Specifics
- 4.7 Message Storage Hashing
- 4.8 IMAP Tuning Specifics
- 4.9 Summary
- Tuning Email Sending
- 5.1 Mailing Lists
- 5.2 Command-Line Message Generation
- 5.3 Draining Queues
- 5.4 Another Mailing List Strategy
- 5.5 SMTP PIPELINING
- 5.6 More Notes on Mass Mailing
- 5.7 Summary
- Configuration, Security and Architecture
- 6.1 Configuration
- 6.2 Security and Performance
- 6.3 Other General Strategies
- 6.4 Summary
- Finding and Removing Bottlenecks
- 7.1 Kernel Parameters Run Amok
- 7.2 The Quick Fix
- 7.3 Tools
- 7.4 syslog
- 7.5 Removing Bottlenecks
- 7.6 Summary
- Load Generation and Testing
- 8.1 Test System Setup
- 8.2 Testing Tools
- 8.3 Load Testing Pitfalls
- 8.4 Summary
- Conclusion
You can purchase Sendmail Performance Tuning from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Why use sendmail at all when you can use Qmail, which is smaller, easier, simpler, and faster by an order of magnitude???
I will buy this book, and file it under "oxymorons I have known and loved"
Invoicing, Time Tracking, Reporting
#rpm -i exim-foo.bar.rpm
That ought to do it... (Debian wienies can feel free to use apt there or *chortle* dselect)
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
i have seen many books on apache and sendmail. and i have quite a few of them. i rarely consult them. when i need to find out anything, i m most like to type it into google, or search newsgroup (deja). this includes apache/tomcat performance tuning.
I have administered NIS+ apache, and sendmail, and these topics are so vast, that buying books doesn't help. However searching through google/deja does help a lot.
But that is just my opinion....
Consensus is good, but informed dictatorship is better
Tuning Sedmail is about as smart as tuning MS Exchange. Both are fat, bloated, and have a history of secutiry holes. Performance tuning Sendmail is like performance tuning an AMC Gremlin made out of spare junkyard parts - you end up with a cobbeled peice of crap with a spoiler.
Sendmail is so bloated that it apparently takes books to get decent performance out of it.
Sendmail doesen't fit the one of the core Unix ideas - use simple, robut and elegent programs, chained together, to do cool things.
Check out Postfix or Qmail for decent replacements to Sendmail. Enjoy the performance of well toughtout software. Postfix was so easy to use, that I went from reading the man pages to a working system in one hour.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
The main problem with open source coders is their lack of formal technical training/education.
While open source developers tend to have a lot of heart and desire they simply cannot overcome the technical deficiencies that come from lacking a formal education. I've consulted with many firms who were attempting to integrate OSS projects and I've seen heinous code and design decisions in most of them, anything from using a fast fourrier algorithm in a GUI application (Duh) to using an Olog(n) algorithm when you clearly need an Olog(1). Simple things like that which on the surface a layman has no knowledge about but a well trained professional can pick out in a second.
For instance Robert Brooks in the "Mythical Man Month" cautions against using too many loops in your code as they can cause excessive wear on a CPU (by constantly hitting the same LII registers you cause a "burn in" on the bus which can lead to erratic and undefined CPU bahaviour) yet you continue to see OSS projects laden with FOR and WHILE loops. I have to wonder if perhaps there were some open source coding classes offered on the web that taught basic things like that if you wouldn't see a serious improvement in the underlying shoddy code written by most young hotshot coders.
Warmest regards,
--Jack
Wagner LLC Consulting Co. - Getting it right the first time
I'm trying to remember who said this:
This is not my sandwich.
This book by Avolio and Vixie was the best one I ever read.
Before I switched to Postfix...
Linux is UNIX.
One word of warning though: do not read this when you are tired. You will miss some really good information and have to re-read parts.
:-(
Damnit! I'm always tired. Guess I can't read the book at all.
I'd figure a Spoiler, a few 'Type-R' stickers, a coffeecan exhaust, and a bolt on Turbo kit should do the job. Who needs ruddy books?
Non impediti ratione cogitationus.
I've forsaken Sendmail's bloat and twisted configuration for the straightforward and secure nature of Postfix.
See http://www.postfix.org/
I'd rather use Postfix. Simple, powerful, secure and fast as hell.
.. always needs tuning. The strings need replacing, the wood frame warps in the humidity. It's a real bitch.
Trolling is a art,
Anything that makes sense of the configuration bloat is much appreciated. Its difficult to install the newer versions let alone configure them. Most of us don't have the time to go to class after class to learn the ins and outs of sendmail, or all the other services we have to maintain. A book that isn't used is fairly useless.
Just my 2c worth.
M. Felzien
Seriously people ... if you don't like sendmail, don't come in and bash it on a sendmail book review (btw: all of those posts SHOULD be modded off-topic).
... but nothing can ever replace "the real thing" ....
... and if you don't agree with me, be intelligent and post why ... don't moderate!
... preparing to dodge all of the "clippies" that will be thrown at me by the NT admins ... "
If you like another mail program, DO A BOOK REVIEW ON THAT MAIL PROGRAM and share your "wisdom" with the rest of us.
As for sendmail, it is not meant for Windows weenies or wanna be Unix sysadmins, only for "real" Unix admins and those that wish to use a VERY robust product and are willing to learn the product to reap the rewards. I personally feel that this book is a great quick reference for when you have a brain fart and don't feel like mulling through the O'Reiley "bat-book" for a simple answer
Just my $0.02 cents
HallmarkOrnaments.Com
"While I did not find it as much of a page turner as Douglas Adams' Hitchhikers Guide."
That's an unfair assessment. No book could compare.
(I have attempted to read the Bat Book on numerous occations, only to be reminded that it's topic is actually sendmail.)
http://use.perl.org
Ok, that could be considered a troll, but having worked with both, I really prefer qmail. It's smaller and I feel that its more robust than Sendmail. The fact that Sendmail is monolithic (one program does it all) where as qmail is modular makes it more secure too. A buffer overflow in one will not compromise the other modules. But no one has found a hack for qmail as yet.
Just my 2 cents.
The simple truth is that interstellar distances will not fit into the human imagination
- Douglas Adams
to hear a debian-using exim proponent CHORTLE?
HELLO?!?! MCFLY?!?!
Are you simple? The article *is* on Slashdot. If Slashdot gets Slashdotted, no one will be able to read you comment either, because it is *also* on Slashdot.
More like posting as AC because you were too dense to distinguish the 'login' slashbox from the 'jennycam' slashbox.
My former employer, AT&T Canada, who has over 150,000 home users and several thousand business
clients, dumped their Sendmail-on-Solaris servers in favor of Postfix-on-FreeBSD and have never been happier.
Pain is merely failure leaving the body
Hey man, don't "dis" the AMC Gremlin so quickly. Back in my hometown many years ago when I still was in high school, there was a locally famous AMC Gremlin street machine called the "Betty Boop". It was blue-ish grey in color and had the cartoon character painted on the upper rear quarter panels... similar to how WW2 fighter planes often had girls pained on them. Anyway, the "Betty Boop" had a souped-up 401 c.i. V-8 engine and she'd pull the front wheels off the ground a couple inches and run the quarter mile in the high 12's / low 13's on street tires. Not too shabby for a Gremlin.
Comment removed based on user account deletion
I know sendmail is installed by default in redhat 8 and thats why I was going to use it. I also know that there are some other good options out there. However, sendmail seems to be the most widely used. That said, I thought it was really strange that I could quickly and easy get things like apache and mysql working yet I couldnt get sendmail working for basic pop3 and smtp access.
That said, the other thing sendmail was lacking was something the entire linux world is lacking. Why is there no exchange server clone? Why is it that if I still want to share calenders and stuff in outlook, I still have to run Win2k Server + AD + Exchange Server? Thats just crazy. It blows my mind that there isnt an OSS option out there that does this type of work and is Exchange compatible!
The ultimate network admin tool needs HELP!
Look guys/gals, I have been using sendmail for years and I have had no problems with it that couldn't be solved by tweaking the config files. I like this hands on aproach because it gives me a chance to tinker with things..
"I bow to no man" - Riddick
Just my $0.02 cents you can either have $0.02 or you can have 2 cents but "$0.02 cents" makes no sense.. why dont you lern how to spell you fscking insensitive clod..
Works for more people than you might think... the rpm-based distros usually have sendmail configured to be reasonably useful right out of the box.
To be fair, though, I have been running sendmail for almost ten years and it is definitely a bitch to configure for large non-standard environments. And what "large" computing environment is really "standard" if you look at it closely? M4 (sendmail.mc) is the best thing that ever happened to sendmail.
Comment removed based on user account deletion
I have to disagree.
.cf file, the flexibility, and tweakability of sendmail is astounding. Not everyone needs it, but when you do, sendmail rocks.
Sendmail kicks ass.
In a former life, I had to build a mailing list manager that handled content generation, sub/unsub, bounce management, etc. for a large number of mailing lists that had to do about 1.3 million messages in 4 hours.
Without going through the whole set up, there were slave boxes that just delivered mail. They used pieces of postfix, which did a good job (I like postfix, BTW, my current company's primary mail server uses it).
The primary machine used sendmail. Once you get over the horror of writing a
A lot of people who don't really know what they're talking about rag on sendmail, echoing some very valid complaints that are mostly only of historical interest now. The most valid complaint these days is that it is arcane to configure. My take is, sure, it is, as it should be. Handling large volumes of email is second only to nntp for placing a heavy load on all sections of a network. If you don't know what you're doing, you shouldn't be doing it.
I use postfix because it is easy now, we're only handling a few thousand messages a day.Should that change, I'm back with my old pal sendmail.
I forget what 8 was for.
Because sendmail is incredibly powerful and flexible. In addition, the majority of complaints that have prompted people to use qmail no longer exist with sendmail. You'll in fact find that it can be extremely fast (LMTP, anyone?), very powerful (LDAP support, etc., etc.-- there's no end to the list), robust (extremely widely deployed and heavily tested), and quite secure. m4 is not hard to use, and sendmail is extremely well-documented and supported. Have you played with milter lately?
Had I known about that trick, I wouldn't have dumped Sendmail for Qmail back in '98.
So you can't distribute forked versions or versions installed in weird places. You've still got the source, and you can distribute patches if you think you can outcode DJB. I really don't understand the non-free label attached to Qmail by some people. But then, I don't understand the same people screaming that Linux has to be called GNU/Linux, but GNU/HURD doesn't have to credit the Mach people. Get over it, Qmail is free, it runs on the Linux OS (and the *BSDs), it has human-understandable configuration, and it doesn't require the security patch du jour that Sendmail does. Just because something is GNU/Free doesn't mean it's good, and something that doesn't meet the GNU definition of "free" isn't necessarily bad.
Unlike this article... NEXT!
The bashing, that is. Sendmail is a big. bloated, incomprehensible security hole. It could have been written by MicroSoft. There's a lot of (much) better MTUs out there. Why tune a lumbering wreck when you can replace it with something that will run quicker and safer without tuning, and without requiring a half ton of books? If you can spend the time required to admin Sendmail and keep it patched and configured, good for you. But *real* Unix Sysadmins have better things to do with their time than to continually patch and upgrade what should be a trivial SMTP daemon. There's life outside the server room, ditch Sendmail and you'll find that out.
Sendmail's default configuration is very conservative with respect to both your machine resources, and the resources of those with whom you exchange mail.
Run sendmail with
(or something bigger, if you want) and you can get past the biggest hurdle in sendmail performance -- by default, sendmail will handle all outgoing messages in a single queue. (Both qmail and postfix use multiple queues and/or runners by default.)Sendmail can relay messages without doing any disk I/O, thanks to the asynchronous I/O libraries; coupled with multiple queue runners, it's hard to get faster performance out of any MTA.
Nick's book is very good, and he has managed to "give away" a lot of the tricks of the trade that are used by Sendmail, Inc. Professional Services.
.cf directly. There be dragons there. Use M4.
Sendmail (the app, not the company) scales quite nicely if you know what you are doing - I've installed sendmail on a couple of old dual-proc HP's and they handle about 2 million messages a day. Yes, that's right; 2 MILLION. It's a "simple" matter of tuning and knowing the file system.
Don't hack the
And, if another tool works better for you (exim, postfix, qmail) - use it! I don't always recommend sendmail, either.
Bobcat
disclaimer: I used to work for Sendmail, Inc. - my cubicle/cage was about 40 feet from where Nick used to sit...
-- Ziggy Sig Sig
is you do not use Sendmail.
ya, ya, cheap play on fight club line... but oh so true.
...racing stripes
Sendmail configs are so horribly retarded that it boggles the mind. For simple jobs, I use Postfix, and for more complicated tasks I use Exim.
There are always special circumstances, especially with things that have been around as long as sendmail, when there is no alternative to complete a specific task, but I *never* have run into one (only heard about a couple).
Use Exim, and trust Cambridge over Berkeley...
These days, Red Hat's default install of sendmail does not accept remote connections. Red Hat tells you to use M4 to generate a new CF file to enable this functionality.
Here is what you really do...
Find the line in the CF file that reads:
O DaemonPortOptions=Name=MTA
and change it to:
O DaemonPortOptions=Port=smtp,Addr=0.0.0.0, Name=MTA
I picked this up from a bugzilla comment.
You can run dictionary attacks against domains I handle mail for, but at least it will take you a damn long time! I just wish everybody was doing it. Eventually it would take too long to spam effectively.
...to repeat it.
Um, wait. That didn't come out right.
Sendmail is so bloated that it apparently takes books to get decent performance out of it.
Seriously, a lot of people just don't understand sendmail and how difficult mail routing is. Sendmail is bloated because it tries to solve a very complex problem in an extremely diverse environment.
Postfix was so easy to use, that I went from reading the man pages to a working system in one hour.
Postfix and sendmail are going in two different directions. Sendmail == configurability, postfix == ease of use.
Sendmail is fast. Not because there's a book on performance tuning does it mean the software is slow. Sendmail is probably as fast as anything else out there.
Sendmail is configurable to no end. I run a sendmail setup with virtual domains, lots of address rewrite rules, spam filters. All my virtual users, and alias maps are in LDAP. I modify all my sendmail virtual users, virtual domains, aliases, etc through a PHP website. Try that with other mailers. They support LDAP, but they are no where as configurable as sendmail.
Then try running these mailers on Linux, bsd, solaris, windows, AIX, etc., etc. No OS lock-in.
Sendmail is well documented.
The prevaling mood on /. these days seems to be if it's not brand new, get rid of it. That's unfortunate.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
Yeah, I switched us to Courier recently.
I was running qmail, but then needed an IMAP server. Courier-IMAP was the best for Maildirs. Then I needed a web mail server. Sqwebmail (part of Courier) was the best for Maildirs, and used the same subfolder format.
Then I needed mail filtering, and wanted to use Maildrop because it works well with Maildirs. So I just bit the bullet and installed Courier.
Had some initial issues with configuration setup, but after that it's run pretty smooth. Now I just need to get SpamAssassin installed (need a new version of Perl on the mailserver).
Sendmail scared me off in the mid '90s. Haven't touched a .cf file since.
"Emacs Performance Tuning".
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
The author does not want his core code to be modified so that he can "garuantee" its security (i.e. make sure your setup is his setup). It is not free in the sense that you cannot freely distribute modified versions of the source or binary--you can only distribute non-applied patches with the source.
These days, I'd say that LDAP is a pretty important thing for messaging agents to support-- to the point that it's really essential for deployment in many organizations.
/in/ qmail...
/five years ago/. Messaging technologies have evolved quite a bit since then.
Although it's nice to know that those patches exist, they aren't AFAIK officially supported. I'd think that would seem to break qmail's much-lauded security model if they were used. Of course, the hole wouldn't be
As far as I can see, the current version of qmail is 1.03. That version was released in 1998,
Contrast this to sendmail. The current version is 8.12.7 as of today, and it was released on Dec. 29th (http://www.sendmail.org). It has engineers working on it full-time, and a lot of support and testing. Yes, there are also a lot of third-party patches.
The bottom line is that sendmail is a modern MTA with modern features, not half as klunky as many posters seem to make it out to be-- I think they're suffering from qmail FUD perhaps?
Well, I'm sure a lot of people have already read this. If not however, I offer The Case of the 500 Mile Email, a bizarre tale of debugging a sendmail problem.
my last employer handled hundreds of thousands of email accounts through exim/ldap...
however i find exim is difficult to set up (unless perhaps it's one of those things you've already done) to work in a simple sendmail-style virtusertable/aliases way.
So self-righteous in their quest to be important or "skilled." Face it, you'd haul freight in a Yugo if someone told you it was "l33t".
Before you throw up your hands and try something else, read this. I wrote this to clarify the concepts behind sendmail, and SMTP in general and to offer come canned configs for new users. If you use my HOWTO, you will be up and running in under 10 minutes, even if you are an MCSE. You don't have to be a 31337 UN1X DuD3 or anything to figure it out.
I have customers who run sendmail on very modest hardware that handle tens of thousands of messages per week for months on end with no attention required. I can do things that the other MTAs only wish they could do in their wettest dreams, even when installed on that old ProSignia sitting in the corner. Before you bash it, give it a try. If you still can't figure it out, send me an email.
It works out of the box (for some definitions of works - sending multiple messages to one MX for multiple recipients _is_ a massive waste of bandwidth and can be a DoS attack. Some people I've worked with on satellite links have had their costs blow out by factors of 300-400 thanks to list owners moving to qmail and there being a couple of hundred recipients on the receiving end, as a f'instance)
If you have to tweak it, go find something else. Qmail is NOT DESIGNED.
Where DESIGNED is in the engineering sense. Any changes are a kludge.
Sendmail is big and hairy, but it's still the most flexible package available. If you don't need all that flexibility (like multiple gatewaying), fine, use postfix or exim, depending on if you need UUCP or email->fax, etc.
Don't use Qmail for stuff it wasn't intended to do and avoid the DJB religious zealotry campaign.
Don't bang in nails with a carpenter's plane either. It will work, but that's not what it's for.
I'm not trying to start a "my MTA is better than your MTA" war, but for those of you who
are like me and got tired of trying to figure out sendmail, you should give XMAIL a shot
It is both a SMTP and POP3 server, will soon support IMAP, and has been incredibly reliable and easy to
set up for me, YMMV.
Sendmail as Rice-Boy -- what a concept :)
Esli epei etot cumprenan, shris soa Sfaha.
You mentioned a week or two back about working on an open source exchange mapi provider for outlook. Since this is the only way I can find to contact you, and I cannot find the original thread you posted, I would appreciate it if you could drop me a quick email at cfk@pobox.com. I don't know if you're interested in collaboration, but I've been starting some work on a similar project, and would rather assist someone else than duplicate effort (who needs another KDE/GNOME fiasco?).
Thank you
-Chris Kaminski