dev questions

[Craig Skelton <cs...@bridges.com>]

Hello fellow developers.

I'm very interested in James as a sendmail/qmail replacement. As an experienced systems admin and Java developer, I see
a real need out there for a quality replacement for sendmail and qmail. I believe James may prove to be that
replacement. I have a couple of development related questions:
1) The way in which james accepts mail and them makes decisions around mail routing may lead projects such as orbz and
RBL(maps) to believe that james is an open relay. I'll do my bit and study the code on that, but can somebody give me a
high level view of why james operates in this way? 
2) Is anyone looking into IMAP support at all? Do you have interested parties for taking the alpha stuff all the way? If
not, does anybody object to me taking a swing at it? (no, I won't use swing).
3) How serious and committed is this development group to seeing james become a serious replacement for sendmail/qmail?
(It's not far off, but it does need some more functions).

Thanks,
Craig Skelton

RE: dev questions

[Danny Angus <da...@thought.co.uk>]

> Hello fellow developers.
Hi Craig..

> 1) The way in which james accepts mail and them makes decisions
> around mail routing may lead projects such as orbz and
> RBL(maps) to believe that james is an open relay. I'll do my bit
> and study the code on that, but can somebody give me a
> high level view of why james operates in this way?

Actually there are three points here,
a) these blacklists are aware that simply accepting all mail doesn't, alone,
make you an open relay (see http://jakarta.apache.org/james/FAQ.html#2 ) and
we haven't (yet?) heard of any instance where anyone has had James
blacklisted for this reason.

b) We have been discussing implementing active SMTP sessions primarily so
that James can return 550 errors, but also because implementing a mailet (or
suchlike) container at this point in the process adds to the extensibility
of James, and properly done could provide support for pluggable ESMTP
command processors. Unfortunately none of us seem to have the time,
currently, to dedicate to major development effort at the moment (where's
the recession gone?!) so that is on the pending pile like a number of other
planned features.

c) Personally I believe that the use of the 550 error code for undeliverable
mail is flawed, and that James' approach, the blackhole, is a better
deterrent to spam.
Why? because I was spammed the other day with a mail offering me a piece of
software which would harvest addresses, I tried it out, it worked on the
simple principle of running hundreds, thousands, or millions of SMTP "RCPT
TO:<recipient>" commands against a mailserver and logging the ones which got
a 2** (ok) response.
Now the software I downloaded worked on a purely alphabetical sequence, so
it could take thousands of trys before it encoutered any real addresses on a
quiet server, but a busy domain (like yahoo or hotmail) would result in many
fewer tests per hit, and a more sophisticated programme could use lists of
names and phonetics to make better initial guesses.
This software works on servers which pass the non-relaying test with flying
colours, but *not* on James.....

> 2) Is anyone looking into IMAP support at all? Do you have
> interested parties for taking the alpha stuff all the way? If
> not, does anybody object to me taking a swing at it? (no, I won't
> use swing).

I'll let someone else answer that.


> 3) How serious and committed is this development group to seeing
> james become a serious replacement for sendmail/qmail?
> (It's not far off, but it does need some more functions).

We've certainly had a lot of people interested in using James as a sendmail
replacement, and I would like to too, any proposals that would help advance
this would be welcome.

d.


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>