I was thrilled when I came across the Apache James e-mail server a couple years ago, but after a bit of investigation, I decided not to embrace it. I really liked the Matcher / Mailet APIs, but honestly, I didn't like the idea that to use James, I had to embrace the Avalon server framework.
Then, when JBoss announced its Mail Services project, I was even more excited at the prospect of using a mail server that was integrated into my favorite J2EE container. However, as time has gone on, it seems like I will again be asked to embrace some unrelated APIs in order to handle my e-mail processing; i.e. People are talking about using scripting languages like JavaScript and BeanShell for e-mail workflow processing. I think it would be a mistake to require non-Java languages and APIs as an exclusive means for processing e-mails. So I wanted to get on the record what *I'd* like to see in any Java-based Enterprise E-mail server: - It should be J2EE-based Honestly, I don't want to have to revisit pooling, resource and thread management, security, datasource access and transactions, and all the other services provided by the well-documented J2EE API and JBoss implementation. - It should provide a clear separation of e-mail server behaviors that change rarely and those we might change often The standard e-mail server behaviors (as documented in various RFCs) are well known and essentially static since the backward compatibility is essential to successful Internet e-mail processing. However, new processing behaviors seem to crop up weekly, like anti-Spam processing and dealing with new Internet security threats. When once we were only worried about viruses carried in exe payloads, then we needed to worry about worms and trojans deployed in e-mail attachments, now including image files, etc. New threats like spyware and phishing attacks are not viral in nature, but a robust e-mail server should be extensible enough to allow me to "plug-in" processing code for the detection and removal of these threats. The separation of concerns issue is very important to me. Consider the highly successful Servlet API. It was written so that the servlet container could handle all the handshaking of the incoming web request, but what was done with that request was up to developers. Given that the servlet container handles all the nasty socket-level details of thread spawning, HTTP handshaking, connection timeouts, etc., we can focus on the "business end" of the processing. This has resulted in several excellent frameworks, like Struts, Tapestry, and WebWork to deal with the HttpServletRequest and Response artifacts created by the servlet container. As it stands, neither the James project nor the JBoss project seem to cleanly separate the core e-mail server functionality from the post processing activity. (There's some concern in the James community about the idea of accepting all e-mails rather than bouncing rejected ones, but I'll leave that discussion for another time.) For the JBoss e-mail server, it seems like this separation could be achieved by "publishing" the e-mail from the SMTP server as a JMS message and calling a stateless SessionBean from the POP server. (To prevent being falsely identified as an open relay and getting bombarded with spam, there could be some 0th order check for invalid server domains before delivering the message to JMS.) Developers (including JBoss.org) could then develop the mail processing APIs separately from the server-centric code to handle socket connections, threads, etc. Perhaps some Struts-like framework would emerge to process the SMTP e-mail. Or, maybe the James Matcher/Mailet APIs would be adapted for post-process workflow. Or, maybe someone will implement a Rules Engine approach (JESS, Drools) for complex processing of rules. Thus, JBoss 4.x/5.x could be shipped with default mail services (SMPT server, POP server) and instructions on how an application can subscribe to receive SMTP e-mail messages or extend a stateless SessionBean to override a default, simple e-mail fetching strategy. Then we can focus on implementing the business processing of the SMTP e-mails and returning e-mails to authorized users. - User and mail repositories must support virtual hosting; i.e. the same server instance must be able to distinguish john.smith @ acme.com from john.smith @ jboss.org. - Server must allow runtime changes to user repository without server restart. Ideally, e-mail processing rules should be able to be changed and picked up by the e-mail processor without a server restart - Any post-processing must allow use of different mailstores any kind, file system, datastore, EIS/Connector. By maintaining a separation of concerns of e-mail server vs e-mail processing, e-mail received by the SMTP server should be able to be processed in any way the user desires In summary, in the beginning JBoss needn't develop and deliver every possible implementation of all business e-mail processes. Just exploit the existing J2EE APIs to provide us hooks to access the SMTP e-mail messages as JavaMail Messages and deliver JavaMail Messages to the POP/IMAP server. From there, we can develop, or use, mail processing APIs such as the James Mailet / Matcher API. Maybe this is the way JBoss is doing it now, but if so, that's not at all obvious to me. Instead, it looks like JBoss is trying to develop the "be all and end all" of e-mail servers. That's also what James is try to do. And Exchange. And MDaemon. And PostFix. And QMail. And all the others. I'm just suggesting we take a smaller bite at the apple and deliver a solid Java-based SMTP, POP, and IMAP server with hooks accessible from existing J2EE services. I'm sorry for the length of this post, but I wanted to plead for "less sooner" rather than "more later". Jack View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3869959#3869959 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3869959 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ JBoss-Development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-development
