One of the things you have to be careful of with these tests is just how realistic is the test? We can come up with all these magic numbers about cps and #users, etc., but if the configs don't include sufficient security checks to make it safe to put such a server on the Internet then it could be a bit misleading. I like openser and I'm enjoying learning about it and experimenting. But I'm afraid that it's going to get a black-eye in the press due to some significant security scandal. We need to put together a "Security Considerations" section for the documentation, so that would at least increase awareness among users (I'll work with someone to do this, but I don't know enough yet to do it alone.) Now some of you are going to say: Hey, use a commercial package if you can't program the necessary security! But it's not me I'm worried about, it's everyone else (OK, I am worried about me too :-) Consider the path of sendmail. It took a long time for sendmail to "ship" with arbitrary email relaying turned OFF by default. This created big problems in the real world. Likewise look how long it took for the default inetd.conf to have virtually nothing defined in it, or for inetd itself to be turned off by default. Previous default configurations caused big problems in the real world. The only security note in openser I recall seeing in two months of reading and experimenting is about preventing someone from registering with the same IP as one of your gateways. Here's the thing: if you give people working configs then they will use them and some will use them on the open Internet. How does one person's deficient openser.cfg affect you? I don't know, but one thing I hope we've all learned from the past dozen of so years of Internet growth is that security at site A can be exploited to affect site B in ways that we hadn't previously thought of. Think of spam, distributed denial of service attacks, identity spoofing. Thanks, -mark