More comments... GTG
>>> [EMAIL PROTECTED] 07/03/2002 13:47:20 >>> [snip] > 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. Both. > 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. With the range of possiblities with different mailets, it would be nice to see why/how james is chosing a mailet. Helps when working out why James isn't doing what you thought it should be doing. > 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. I'll have a look at the source.... > 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. :) How would you want it ? Just plain ASCII text, or fancy formatted ? > 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. I'll have a look and check. > 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'm not against James retying a failed delivery. In fact, any MTA which gives up after one attempt isn't much use. What I was more getting at, was that James didn't seem to be trying to deliver other messages, it just carried on (without pausing) trying to deliver the same message. I had one time whereby I had over 1,000 files in the spool dir 'cause James was trying to deliver one faultly e-mail. (Took my system a few hours to recover from that one...) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
