Thanks for your input. > Sounds kool. BTW are you aware of jakarta.apache.org/james ?
I'm quite aware of James. It was actually through looking at some of the problems James was having that I decided to start my own server. Things like the fact that they seem to be having some trouble hacking in IMAP support in retrospect. I noticed one bug report -- that messages of large sizes were processed extremely slowly or not at all (I forget which) -- where the response was that it either stemmed from JavaMail or JDBC, and not much could be done. I searched the net to see what other Java mail servers are doing and noticed that James has basically no real competition. There is no definitive reference for Java mail servers that implements the current standards gracefully. I'm hoping to get a well-factored bare minimum server going and open source it to get help with the tougher stuff. We'll see what happens ;). > Personally what I would do is have one component read the incoming mail, place > it in the spool. Have other components read mail from the spool and deliver > or operate on the main. My thoughts exactly. I was thinking a JMS queue could be the spool. I was also thinking that designing a good interface to allow pluggable mail storage systems (like maildir or JDBC) might be tricky, so I can put off the IMAP/POP3 implementations for a while by just having the SMTP server deal with spools. I might even have second incoming queue to allow a seperate layer for mail filtering stuff. I think it's the spam-fighting custom to always accept mail and then just send a failure notice later if it didn't work out. > BTW if you do go that path I would love to see the maildir handler as a > separate set of utility classes because it would be very useful in a number > of circumstances. If I included a maildir implementation, I would want to make it reusable -- I'm one of those OO abstraction-crazy people ;). Another problem I'm facing is the parsing of MIME messages. I don't trust Sun to take good care of JavaMail, so I want to do it some other way. I don't know what I'll do about that. I may eventually write my own parser. For the moment, my SMTP stuff tacks the trace info in front of a message without ever parsing it. This is the sort of issue I wanted to work out after going open source. > Phoenix is stable and only going to get more stable over time. The Avalon and Phoenix developers seem to be doing good work, and I feel comfortable tying my work to their's. David Weitzman -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
