Differences between revisions 2 and 3
Revision 2 as of 2006-06-30 11:45:25
Size: 2934
Editor: dslb-084-057-249-136
Comment: hope this fixes the layout as it was intended to look in the first place
Revision 3 as of 2009-09-20 22:58:52
Size: 2934
Editor: localhost
Comment: converted to 1.6 markup
No differences found!

This page describes requirements that must be met in order for Apache to host e-mail on the James mail server.

I'll start this page by including an e-mail from Brian Behlendorf representing his first cut at a list of requirements. To fulfill these requirements, we need to significantly enhance mailing list management, improve RemoteDelivery, support dynamic configuration, and enhance some other areas. I would like us to adopt this set of requirements into the version 3 development plan.

From: Brian Behlendorf [mailto:brian@collab.net]
Sent: Thursday, December 05, 2002 14:13
To: Noel J. Bergman
Cc: infrastructure@apache.org
Subject: RE: Apache Mail Server requirements (was RE: Ugh, just DoS'd by

On Wed, 4 Dec 2002, Noel J. Bergman wrote:
> Yes, it would be just fine if you went off and wrote up requirements.  :-)
> As I said, I just wanted to understand what they would be so that we could
> make a goal to meet them.

Infrastructure list: this is to explore the idea of using Apache James as
the MTA for apache.org.

Off the top of my head (which is about the best I'll be able to do before
I leave):

a) handling of virtual hosts in a programmable way (for legacy reasons, we
have cases where alias@vhost.apache.org has to be equal to
vhost-alias@apache.org; not that James needs to support that directly, but
I need to be able to write Java code that can support that cleanly)

b) spam filtering using
{{{   1) Perl-style regular expressions that apply to the headers or body 
   2) RBL lookups 
   3) DNS lookups on the hostname 
      hard DNS error = reject, soft DNS error = defer 
   4) Vipul's Razor? 
   5) Virus pattern filtering? 

c) mailing lists {{{ 1) web-based configuration

  • 2) web-based archives (if it's not there, maybe integrate
    • eyebrowse.tigris.org?), searchable
    3) digests

    4) customized per-list error text & messages 5) moderation, and moderate-if-not-a-subscriber 6) automated bounce handling using VERP (see the ezmlm FAQ) 7) bidirectional NNTP gateway }}}

d) reliable, reliable, reliable. :)

e) I would like most of the configuration to be run-time changable using SOAP or XML-RPC. For example, adding an alias or vhost, perhaps even adding a new spam or virus filter pattern.

f) a good way to monitor and manipulate the delivery queue - to set timeouts for delivery, or to mark certain hosts as "hopeless" and pluck all mail destined for them out of the queue, etc.

Between Nagoya (which handles all the jakarta.apache.org mail) and
daedalus (which handles everything else) I bet we do 1M+ deliveries per
day, and at peak we have about 1000 concurrent connections, with 50-100
deliveries per second.  I'd like to be able to support all of that on a
dual-P3 Linux (or ["FreeBSD"] :) box of some sort, without consuming all the
CPU and memory.


HostApacheOnJames (last edited 2009-09-20 22:58:52 by localhost)