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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
