We've done some performance testing pre-M1 but nothing recent so nothing valid. That will be a major goal of M4 is to make SpecJ happy. Pure numbers benchmarks are irrelevant because it is highly dependent on DB used, size of mails, hardware and network. So the numbers are never particularly good unless all variables except one are equivilent. Needless to say, public benchmarking doesn't work that way. Since we may work with the James guys in some areas, its unlikely I'll publish competitive to JAMES benchmarks just to antagonize them. It will come down to: if you want an apache style project with apache style support and you like or don't dislike JAMES's approach, use JAMES. If you want the "professional open source" style support, like or dont' dislike our approach, use JBMS. Likely we'll make ease of installation and ease of management a core advantage as well (not sure if they're working on it). In the end performance will be a matter of what you're able to achieve with a capital vs hardware. We aim high and I think we'll beat Exchange and Domino easily in this area (read: they're really slow and bloated). when finished, I suspect we'll beat postfix in this area (copies stuff around alot). We may beat others in some scenarios but its possible that a db backed mail server can't play as amusingly well in benchmarks as a file backed one (even if the db backed one scales up better). Not to say we can't create "fun for benchmarks" configs but frankly it won't be something I spend any time on (only real world).
However, JAMES and JBMS currently have a major bottleneck: JavaMail sucks. We'll need to address this. I approached JAMES on collaboration here but most folks seemed disinterested in that part. If that is the case we'll likely create a LGPL reimpelmentation once we're further along. At that point JAMES will have to reimplement as well or be left in the dust at least when running in a DB backed mode with high concurrency.