www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <p...@betaversion.org>
Subject Re: WORA Considered Evil ;-)
Date Thu, 26 Jun 2003 23:03:42 GMT
On 26/6/03 23:37, "Noel J. Bergman" <noel@devtech.com> wrote:

>> Pier had pretty rock solid arguments *not* to use JAMES as a MTA
>> and all came from the sysadm paranoia
> One example would be that you run James as root in order to access the
> privileged ports.  And if James runs as root for the ports, all of the code
> runs as root.  There are OS specific workarounds, but it is a valid view.

Trivial argument... A couple of JNI calls, or a port redirector in front
would do the trick...

>> Unfortunately, I don't recall exactly what his arguments were, Pier, do
>> you have a minute to chime in? I think the JAMES people would love to
>> hear your criticism.
> Absolutely!  :-)  Although the discussion would probably be more appropriate
> on the James Developer mailing list than here.

Cced... But I ain't going to subscribe to YAML! :-)

> Actually ... hmmm ... now that you've got me thinking about it, it occurs to
> me that it should be possible even now to separate James into separate JVMs
> for the SMTP service, mailet pipeline, and POP3 service.

DO IT ! :-) NOW!

> [...]
> You know ... I think that would work just fine.  Maybe a bit of a tweak in
> some spooler code.

And remember to be able to read from and write to something looking (and/or
behaving) like "/usr/(lib|sbin)/sendmail", which is the de-facto standard.

>> Java doesn't have concepts like native process forking capabilities
> Java has threads, instead.  Not all operating systems support fork().  You
> can launch new processes, but they don't start as quickly as a fork.  It
> would be nice if JVM startup were light(er)weight in the presence of an
> already running a JVM.

If an OS doesn't have fork() and/or threads (both of them), it's a piece of
crap, and I won't use it... OSes I don't use for this particular reason are
the old distributions of BSD (they saw the light), Linux, and Winzop...

Till not so much time ago I was left with Solaris and Darwin... :-(

>> no notion of OS security
> The Java 2 security model and JAAS are different, but effective.  In terms
> of file system items, it seems to me that a JNDI service provider could
> provide full OS functionality by mapping file system specific properties to
> JNDI attributes.

Annnnnddddddd.... You need JNI to read those attributes from the
filesystem... GLUE, but polluted glue, evil glue, no WORA glue...

> So when you say:
>> I'm aware that Noel wants the apache mail infrastructure to run on james,
>> which is a goal I would *love* to see happening, but I fear that he's not
>> taking into account the sysadm paranoia that runs in the apache
>> infrastructure team.
> please understand that simply being the ASF mail server is only the
> destination.  The value comes from what will have had to happen to get
> there.  In other words, being the ASF mail server isn't the point.  Being
> good enough to be the ASF mail server is the point.

Me and Stefano both want James running on Betaversion (frankly Master Brian
is managing Apache, and he is doing an excellent job)... But when you
convince one of the Master's disciples (me) to run it, I can put a good word
in (or at least try to).

There is also a pretty peculiar problem with Qmail, it doesn't have a
license, and therefore it cannot be forked... It is not open source, you can
see the sources and publish your own patches, but the chance of seeing that
patch incorporated in the next distribution is zero, as the last
distribution was made 3/4 years ago now... (reason why I still didn't change
it is that I compiled it last 2 years ago, and it ran fine since then).

But of course Postfix is IBM Public License (OSI approved), and James is
ours, so, if James could handle the mailing list processing (no SMTP in
and/or out, only processing the lists) I bet that together with Postfix,
Cyrus and EyeBrowse they'd make a good team...


To unsubscribe, e-mail: community-unsubscribe@apache.org
For additional commands, e-mail: community-help@apache.org

View raw message