Folks,
One of my goals for version 3 is that James can be the ASF mail server. As
you can see from the following message sent by Brian to me, and cc'd by him
to infrastructure@, this is a serious discussion. I also believe that it is
a realistic goal.
To fulfill these requirements, we need to significantly enhance mailing list
management, improve RemoteDelivery, support dynamic configuration, and
enhance some other areas. All in all, I do not see any showstoppers.
I would like us to adopt this set of requirements into the version 3
development plan.
--- Noel
-----Original Message-----
From: Brian Behlendorf [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 05, 2002 14:13
To: Noel J. Bergman
Cc: [EMAIL PROTECTED]
Subject: RE: Apache Mail Server requirements (was RE: Ugh, just DoS'd by
Klez)
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 [EMAIL PROTECTED] has to be equal to
[EMAIL PROTECTED]; 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.
Brian
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
