You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2002/12/28 18:22:08 UTC
[V3 Proposal] Apache Mail Server requirements
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: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
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 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.
Brian
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [V3 Proposal] Apache Mail Server requirements
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I have some ideas when the time comes with regards to this one "improve
> RemoteDelivery"
Excellent. :-) Would you please post them with the prefix [V3 Proposal],
so that for now we can distinguish between version 3 and current
discussions?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [V3 Proposal] Apache Mail Server requirements
Posted by Serge Sozonoff <se...@globalbeach.com>.
Noel,
I have some ideas when the time comes with regards to this one "improve
RemoteDelivery"
Serge
----- Original Message -----
From: "Danny Angus" <da...@apache.org>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Sunday, December 29, 2002 11:47 AM
Subject: RE: [V3 Proposal] Apache Mail Server requirements
> add this to the wiki page you made Noel.
>
> > -----Original Message-----
> > From: Noel J. Bergman [mailto:noel@devtech.com]
> > Sent: 28 December 2002 17:22
> > To: James-Dev Mailing List
> > Subject: [V3 Proposal] Apache Mail Server requirements
> >
> >
> > 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: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
> > 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 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.
> >
> > Brian
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [V3 Proposal] Apache Mail Server requirements
Posted by "Noel J. Bergman" <no...@devtech.com>.
> add this to the wiki page you made Noel.
Done. Until we agree, we don't have any *requirements* for v3, just
discussions. But I would like to create a JamesV3Requirements page that
identifies those things that are required by us for James v3, as opposed to
nice proposals.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [V3 Proposal] Apache Mail Server requirements
Posted by Danny Angus <da...@apache.org>.
add this to the wiki page you made Noel.
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 28 December 2002 17:22
> To: James-Dev Mailing List
> Subject: [V3 Proposal] Apache Mail Server requirements
>
>
> 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: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
> 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 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.
>
> Brian
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [V3 Proposal] Apache Mail Server requirements
Posted by Jason Webb <jw...@inovem.com>.
Cool!
My comment are in the mail. ;)
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 28 December 2002 17:22
> To: James-Dev Mailing List
> Subject: [V3 Proposal] Apache Mail Server requirements
>
> 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: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
> 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 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)
>
Yes please!
> 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?
A lot of virus propagation can be stopped by attachment filtering (.vbs
etc)
I think spam should be stopped at the SMTP handler for most instances.
>
> c) mailing lists
> 1) web-based configuration
This goes for James proper, not just MLMs
> 2) web-based archives (if it's not there, maybe integrate
> eyebrowse.tigris.org?), searchable
Lucene is the true faith. Easy to use, scalable and quick.
> 3) digests
Mentioning digests in our office is a quick way of starting a 4 hour
argument. EZMLM does these best. Lyris is quite good at them as well.
> 4) customized per-list error text & messages
International as well
> 5) moderation, and moderate-if-not-a-subscriber
> 6) automated bounce handling using VERP (see the ezmlm FAQ)
VERP handling "kicks ass". It's the only vaguely reliable method of
dealing with bounces. We use VERP style addresses in our (mailing list)
product. Dealing with faulty vacation handlers is still difficult
though. We do it via. another piece of software OUTSIDE the mail system.
> 7) bidirectional NNTP gateway
I'd recommend divorcing the mailing list part from the main distribution
for James. A lot of the components are web based and I don't see them as
core to James.
>
> d) reliable, reliable, reliable. :)
I'd add bullet-proof as well ;)
>
> 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.
If it doesn't happen soon I'll have to write it anyway :(
>
> 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.
This would make James MUCH more likely to be deployed as THE mail
server. At the moment you can't see what's going on.
>
> 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.
We manage 5 deliveries/second off a Pentium III 800 Mhz (512 Mb) giving
about 400k deliveries/day. The system seems to be mostly I/O bound when
using the file system queue (unsurprisingly). The PC is also running
NuMega Java studio at the same time!
>
> Brian
>
>
>
> --
> To unsubscribe, e-mail: <mailto:james-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:james-dev-
> help@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>