I have a few plans. And some of it is detailed in "The Case For Mail Services" off the project page. We'll have a system like JAMES's "mailets" and I also plan to have a mail scripting system. Aside from this, the basic SMTP protocol needs to change. I've started drafting some ideas: http://jboss.org/wiki/Wiki.jsp?page=MailFingerprints. Through open source we can push these changes back into the spec. (I plan to contribute support to open source mail clients).

The plugin idea will let you attach spam assasin, albiet slowly. Ideally we want a plugin which can load HAM (counter-spam) and implements bayesian among other types of filtering. Additionally, I'd like to do something like a syndicated and aggregated regexp and spam match scripts.. Basically you can pub your spam rules and I can aggregate them with mine and we can have kind of a trust circle for "not rules"...

In short, lots of plans but we just got basic protocol/mailbox support so its certainly not there yet. Performance vs Security/Spam control is a hyperbolic false delimma to be honest. If you take a look at "the case for mail services" you'll see that both are very much under consideration but obviously being able to speak SMTP/POP is necessary before we can even test for spam control :-)... While we're at it, we might as well do it well.

i'm not so sure SMTP needs to change, because ultimately everybody needs to have unknown or unexpected folks contact them via email, and that's precisely what SMTP does --- and precisely what whitelists or blacklists in their most strict forms prohibit. the U.S. postal service allows unexpected contact, and that's a good thing too. i think the difference, however, is in the cost of transport (a trivial and well-known statement), which makes the experience of email so different from that of snail mail, even though in principle we get spam via both modes. we get spam via telephone too, for that matter, but thankfully not (much) on cellphones yet.

nevertheless, i think whitelists and blacklists are certainly a good component of a larger system that integrates multiple indicators of whether an email is spam or not --- like bayesian methods for instance. but to deny an email based solely on 'white' or 'black' lists not only prohibits free communication, but i believe will also ultimately be hacked by spammers, and then used to the detriment of those employing such techniques.

one thing i fear is that if us techies advocate white/black lists too much, and implement them with fanfare as a 'save all' method, then some legislators might get the bad idea of legislating such technologies as best-in-class and necessary solutions, which would then take away our freedom to implement other novel solutions, based on what we think is best at any given moment. i'm not looking forward to the day when i have to go to the DMV not only for my driver's license, but also for my license to operate a mail server too...

personally, i've had a pretty good experience with a learning bayesian-type filter, which rejects about 100 spams a day for me with better than a 0.5% rate of letting spams through to my inbox. on the false positive side, i've configured it to notify each sender of a filtered spam a short note, in natural language, explaining how to circumvent the filter should they need to. thus, if a real person's mail gets filtered by mistake, the sender will most likely know about it --- if his filter doesn't filter the bounce message :-)

another idea which is useful is a 'disposable address', which can be created on the fly and used for a specific purpose --- like subscribing to nytimes.com. later, should such a disposable address become compromised with spam, it can be disabled with no detriment to one's other email addresses. a couple years ago i created a free service http://spamfreedom.com offering this option to friends and family, and i now find it to be a good 'front-line of defence' to the spam filter i use, effectively shielding it from onslaughts of pure spam rather than mixed bunches of spam and real-email on a permanent or public address.

mike

JBoss tests connections.. If it can't get a connection it blocks.. if blocking is set to true. Which is what you are witnessing. I believe jBoss 2.4 has a timeOut setting for blocking...