MTA

[Michael Meskes <meskes@topsystem.de>]

I just found a mailer written by Wietse Venema (sp?) the author of the
tcp-wrapper, co-author of Satan etc. IMHO this one is the way to go. Just
check the goals from www.vmailer.org:

[Image]VMailer Goals and Features

  ------------------------------------------------------------------------
Table of Contents | Back: Wietse's VMailer Project | Next: Why Bother
Writing VMailer?

VMailer primary Goals

The goal of the VMailer project is to implement a viable alternative to the
UNIX Sendmail program. Specific goals, in no particular order are:

   * Wide dissemination. The attitude inside IBM Research was: if you don't
     give it away, you might as well throw it away. I have permission from
     IBM to write VMailer and to give it away, for which I am grateful.

   * Performance. VMailer is about three times as fast as qmail-1.01 and at
     the same time designed to be friendly to other mailers. With a US$
     3000,- desktop PC, VMailer can receive and deliver a million different
     messages per day. VMailer and qmail speed is the same when used as
     mailing list exploders. VMailer uses web server tricks to reduce
     process creation overhead and uses other tricks to reduce file system
     overhead.

   * Compatibility. VMailer is designed to be sendmail-compatible to make
     migration as easy as possible. By default, VMailer uses
     /var[/spool]/mail, /etc/aliases, NIS, and ~/.forward files. However,
     VMailer does not use sendmail.cf, and no part of VMailer is set-uid.

   * Safety and robustness. VMailer is designed to behave rationally under
     stress. When the local system runs out of disk space or memory, the
     VMailer software backs off, instead of making the problem worse. By
     design, no VMailer program keeps growing as the number of messages etc.
     increases. VMailer is designed to stay in control.

   * Flexibility. VMailer is built from over a dozen little programs that
     each perform only one specific task: receive a message via SMTP,
     deliver a message via SMTP, deliver a message locally, rewrite an
     address, and so on. Sites with specific requirements can replace one or
     more little programs by alternative versions. And it is easy to disable
     functionality, too: firewalls and client workstations don't need local
     delivery.

   * Security. VMailer uses multiple layers of defense to protect the system
     against intruders. Almost every VMailer program runs in a chroot jail
     with vmailer privileges. VMailer does not even trust the contents of
     its own queue files, or the contents of its own IPC messages. Unlike
     qmail-1.01, VMailer puts no sender-provided information into shell
     environment variables. No VMailer program is set-uid.

   * Last but not least, VMailer is an attempt to make sure that UNIX will
     be in the high-performance mailer market for a while.

Other significant features of interest

   * Multiple transports. VMailer treats all email transports as first-class
     citizens. In the past I have configured Sendmail systems that could
     relay between Internet, DECnet, X.400 and UUCP. VMailer is designed to
     be flexible enough that it can operate in such environments without
     requiring virtual domain or alias kludges. However, the initial release
     will only talk SMTP.

   * Virtual hosts done right. You can run multiple VMailer instances on the
     same machine, each listening on its own Internet address with its own
     Internet domain name, and each having its own resource budgets.
     Low-cost customers get two simultaneous SMTP sessions; premium
     customers can get a hundred.

   * Yes, it will support restrictions on what hosts can relay their mail
     through a VMailer system, and restrictions on what mail is allowed to
     come in, if only to preserve my own sanity.

  ------------------------------------------------------------------------
Table of Contents | Back: Wietse's VMailer Project | Next: Why Bother
Writing VMailer?

Michael

-- 
Dr. Michael Meskes, Project-Manager    | topsystem Systemhaus GmbH
meskes@topsystem.de                    | Europark A2, Adenauerstr. 20
meskes@debian.org                      | 52146 Wuerselen
Go SF49ers! Go Rhein Fire!             | Tel: (+49) 2405/4670-44
Use Debian GNU/Linux!                  | Fax: (+49) 2405/4670-10


--
E-mail the word "unsubscribe" to debian-firewall-request@lists.debian.org
TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble?  e-mail to listmaster@debian.org .