This is a very flawed benchmark from an empirical point of view (it's even worse than lies, damn lies, benchmarks, really), it HOWEVER has some real world resemblance still considering that most people will run it on hardware in the same general class which is really doing something else, too!

On my Sempron64 2800+ workstation, I'm running PHP4.4+eaccelerator + phplist feeding mails to postfix. With usual background load (some 30% I'd guesstimate), phplist pushes about 3000 mails an hour, which is just about 1 mail per second. (and no it's not postfix or IO limited, outbound IO peaked at half my upstream).

As a longtime ezmlm user, that's truly disappointing to me, but OTOH ezmlm serves a very different field (i.e. classical mailinglists with the same message to everyone, perhaps minus VERP features).

They argue phplist is so slow because of all the customization it does but then again, I don't think I actually need that! I wont have the users unregister via link but rather via login to ezp which will have the very same URL for all of them. If they cant remember the pw, ezp will send it to them. If they wont bother with that, well they dont deserve to unsubscribe, really.

What now? Truth to be told, I don't really know. The following options spring to mind:

• I was thinking that maybe I could force mailman to work with ezpublish but then again, that one is a pain to get up running correctly for people without MTA experience (I've set up my share of mailservers but still struggle with it if I try to do weird stuff with it).
  
• ezmlm is likely fastest of them all (maybe aside of spam tools that have their own, multithreaded mini MTA) but even more so a PITA as it only runs on qmail which is best filed under the "deprecated MTA" category these days (tho for other reasons than why I'd put sendmail there, obviously).
• Writing my own? The thought crossed my mind, obviously. But it ain't easy, especially if you're not to use VERP for bounce handling (discounting the lazy approach of just not dealing with bounces, of course). Leaving bounce handling aside for the time being, the following features would be a must:
• Multiple lists, same user subscribed to any number of them
  
• HTML
• maybe multipart with embedded images (I do have some reservations about that)
• Storage of users in a simple MySQL table, no 40 (!) tables like phplist
• Handling of archive is left to something else, i.e. ezpublish in my case.
• thus comes ezpublish integration
• means I want to have a "Send this content object" to that list option
  
• And finally, phplist's handling of external URLs is nice by any means but not necessarily needed from begin width.