Lyris User's Guide
[previous] [next] [contents]
Why Does Lyris Not Use Sendmail?
Table of Contents
Lyris Email Commands
Web Interface for Users
Server Administrator
Site Administrator
List Administrator
Other Topics
Add-On Packages
Installing and Upgrading
Frequently Asked Questions
Running Lyris
How can I extend Lyris with my own programs?
How can I be Certain My Email Messages Were Delivered?
What Email Commands does Lyris Support?
Why Does Lyris Not Use Sendmail?
How do I subscribe people automatically?
Lyris Administration
Web Browsers
Usenet Newsgroups
Other FAQ issues
Mailing List Features
Perl/Lyris Toolkit
Unix Administration
Up & Coming

Why Does Lyris Not Use Sendmail?

> I just talked to our Unix guru who is responsible
> for setting up the networks and configuring sendmail
> and we wondered why a list server program relies on
> its own there a clever reason to tell
> why you thought Lyris needs its own sending and
> receiving mail feature - besides the multi-platform
> approach argument for NT/Mac/Be...?

Yes, many, many reasons. The major problem with list servers is maintenance. With Lyris having its own mailer, it knows exactly what the problem is, the instant it occurs. Also, if Lyris used sendmail to receive email, it would have to rewrite sendmail's /etc/aliases file like mad, and that wouldn't be very elegant.

More importantly, Lyris doesn't do what other list servers do for mail sending efficiency. The other list servers send one message to a list, and use a huge BCC: list to get it out. When someone posts to a mailing list, exactly the same message gets sent to every member of the list. The problem with this approach is that when bounces come back, it is very difficult to determine which user bounced it, because every message was the same.

Lyris makes every message unique, with a X-Lyris-Member-ID and X-Lyris-Member-Name SMTP header. Then, when a bounce comes in, it becomes very easy to tell who did it and to automatically process them.

If you sent every message uniquely with sendmail, you would get very little mail out, as sendmail forks (makes a completely new copy of itself in memory) for each message, and so the number of concurrent copies of sendmail you can run is fairly small. The Lyris mailer is multithreaded, so it takes up very little memory for each message send, and very little CPU time. Lyris can run several thousand concurrent mail sends, even on a 64mb machine.

We're also seeing very fast message delivery times as a result of the low CPU demands and efficient memory usage.

The decision to leave sendmail behind was crucial to the design of Lyris. Lyris will coexist with sendmail on the same machine. But, it will not use sendmail for its own mail operations.

If you are running sendmail, or some other mail transfer agent, Lyris will relocate it to another TCP/IP port, and take over SMTP port 25. All incoming mail is first received by Lyris. If the incoming mail is not addressed to a Lyris email address, Lyris automatically passes the email off to the relocated sendmail program that processes it as normal. With this technique, both Lyris and sendmail can coexist on the same machine, and there are no strange configuration tricks to play.

And, of course, having our own mailer means we can easily support many different operating systems, since we don't have to rely on the eccentricities of each platform's different mailing methods.

Other pages which link to this page:
  • Email
  • Page 522 of 556