I see the immediate different options to do this as being
- run multiple but different qpsmtpd setups on different ports for internal and external users
This is, indeed, probably the easiest and best way to handle it (it requires the fewest changes). Using qpsmtpd-forkserver is actually fairly efficient in terms of CPU (if not of RAM), so the age of your hardware shouldn't be a big deal. Don't tell anyone, but my inbound servers are running on Cobalt RaQ3's upgraded to 450MHz AMD K6 CPU's (which is comparable to a Pentium II 500MHz) and I'm running two(!) AV scanners on most messages. If you aren't using forkserver (or pperl if desired), you are probably better off to stop using tcpserver than editing any code at all.
- a single qpsmtpd setup, but use tcprules with tcpserver to set an environment variable which could point at a different config folder in Qpsmtpd::get_qmail_config()
Interesting idea but I don't know how well that will work (since the config code is mostly interested in "get the qmail config files and if nothing there, use the local config files"). You could also look at the http_config plugin to see how you can leverage the config hook.
- modify individual plugins to do nothing depending on remote-ip
That's actually how the $connection->relay_client() is usually used. Normally, your internal or authenticated clients skip other checks in the connection and rcpt phase based on that value. It shouldn't be too hard to change other plugins to opt out if relay_client() is TRUE. Alternatively, you can use the plugin wrapper code to add the check without changing the original plugin. Robert posted some example code some time ago (which I can't quite place my hands on at the moment).
- change the core config mechanism to understand some generic "run this plugin if..." mechanism
- like above but also let plugins get/set internal state flags per connection and adjust their behaviour
These are probably out of the scope for what you want to do. The plugins are so varied in function that trying to create a general state management system would be very difficult.
Could just throw some more cycles at it, of course...
Hardware is usually pretty cheap, compared to the time involved in revamping the codebase. You should check out this great service called eBay, where people sell just about anything for sometimes very reasonable prices... ;-)
John
