Future enhancement/changes for James

[Gordon Ross <G....@ccw.gov.uk>]

After using James for about a week, here are my bug-bears with James so
far.

1) Logging. James should NOT reset all it's log files when it
restarts.

2) Logging. It would be nice if James could log SMTP mail "better". For
example, most SMTP mailers log: Who an e-mail is from and who it is to.
This is hard to find in the James log

3) Message flow diagnostics/testing. JAMES can do some pretty complex
stuff with message processing. It would be nice if there was a "test"
mode, where by you can test a config to see what James would do with an
e-mail in various situations (i.e. setting the sender and receipiants)
As an example, think about the rule test mode in Sendmail. With this you
can input addresses and see what sendmail would do with them.

4) Spool dir listings. It's obvious that James stores information about
a message as serialized Java objects. It would be nice to have a command
to be able to list in a human form the messages in the queues and why
they are there.

5) Docs. The docs are a starter for ten, but they need updating and
expanding.

6) Queue processing. It *appears* to me that there is only one thread
that processes messages from a queue. Maybe we can have that
multi-threaded ?

7) Better SMTP error recovery. As I mentioned in a previous e-mail,
when JAMES has a problem delivering a message, it seems to get stuck in
a loop, and repeatedly tries to send the one message. It might also be
worth adding in a feature so that when James fails to deliver a message
to a host, it keeps the host "on file", and any other message will be
automaticly queued. (I'm going to log this as a bug)


I don't mean to knock James or the people who have put all their time
and effort into developing it. James is a good application,  but I feel
these enhancements would make James a GREAT application.

GTG

PS I might be able to provide some help for 4 and 5 if people can point
me in the right direction.

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

Re: Future enhancement/changes for James

[Serge Knystautas <se...@lokitech.com>]

Gordon,

Thanks for your suggestions and offer to help... some comments below.

----- Original Message -----
From: "Gordon Ross" <G....@ccw.gov.uk>


> 1) Logging. James should NOT reset all it's log files when it
> restarts.
Definitely needed... hopefully Steve and whoever can sort out why it's not
appending.

> 2) Logging. It would be nice if James could log SMTP mail "better". For
> example, most SMTP mailers log: Who an e-mail is from and who it is to.
> This is hard to find in the James log
Is this incoming or outgoing SMTP?  We'd probably want to add some channels,
and yes there is a lot of debug log that's still in there and not enough
administrative/diagnostic logging.

> 3) Message flow diagnostics/testing. JAMES can do some pretty complex
> stuff with message processing. It would be nice if there was a "test"
> mode, where by you can test a config to see what James would do with an
> e-mail in various situations (i.e. setting the sender and receipiants)
> As an example, think about the rule test mode in Sendmail. With this you
> can input addresses and see what sendmail would do with them.
Hmmm... what are you looking to test... like an individual mailet or a
matcher or the MailAddress parsing, or what exactly?  I don't know the rule
test mode.

> 4) Spool dir listings. It's obvious that James stores information about
> a message as serialized Java objects. It would be nice to have a command
> to be able to list in a human form the messages in the queues and why
> they are there.
If you look at the org.apache.james.mailrepository.AvalonMailRepository,
you'll see how messages are getting stored.  Basically just had
org.apache.james.core.MailImpl implements java.io.Serializable.

> 5) Docs. The docs are a starter for ten, but they need updating and
> expanding.
Yes docs are always appreciated.  Whatever you see undocumented that you
know about, just start writing. :)

> 6) Queue processing. It *appears* to me that there is only one thread
> that processes messages from a queue. Maybe we can have that
> multi-threaded ?
It should be multi-threaded... the repository code is written as such and
you should have multiple spool manager threads set in the conf file by
default.

> 7) Better SMTP error recovery. As I mentioned in a previous e-mail,
> when JAMES has a problem delivering a message, it seems to get stuck in
> a loop, and repeatedly tries to send the one message. It might also be
> worth adding in a feature so that when James fails to deliver a message
> to a host, it keeps the host "on file", and any other message will be
> automaticly queued. (I'm going to log this as a bug)
Yeah, not sure about this... I think Steve identified this and sent a patch.
I use the JDBC repository which doesn't seem to have the same issue.

I don't know about remembering that a host couldn't be delivered to, in fact
I pretty strongly disagree.  Mail and DNS servers go up and down all the
time, and there isn't much incremental cost to retry more frequently.  The
only thing I'd like to add perhaps is prioritization so that if a host did
fail, it would try to deliver to other hosts in the queue first.

> I don't mean to knock James or the people who have put all their time
> and effort into developing it. James is a good application,  but I feel
> these enhancements would make James a GREAT application.
Feedback and contributions are always appreciated.  I have a whiteboard
filled with things that I'd like to improve in James, but my calendar
doesn't want to cooperate.

Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/


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