The standard black/white/greylisting functionality should be sufficent. Your not doing anything wierd here, just backwards. I suspect the human in this process will be the limiting factor in its effectiveness. You might want to reconsider this approach.
Must be capable of only filtering mail from selected domains. I.E. Its default configuration will be to allow all mail through and we add the mail domain to be filtered afterwards.
Spam Assassin can certainly redirect mail it determines to be spam to a specifc account. What you do with it afterwards is your own business. If you wish to reinject it into the smtp server for normal delivery you will have to consult your mail server documentation on how to do it.
It should be capable of tagging mail as spam and forwarding it to a ‘parking’ account. It can then be released from this account should it prove to be a false positive. I.E. A mail addressed to anyteacher @ school.lancsngfl.ac.uk would be renamed to spam.anyteacher @ school.lancsngfl.ac.uk
The blacklists are text files. I'm sure the web team can cook up something. Or just use your favorite *nix text editor. You might want to use RCS on them too incase someone screws up.
It should have a web or terminal interface so as to be operated by the web team so as to be able to add addresses to blacklists
I vaguely recall SpamAssassin will support MySQL aswell if you compile it in. I'm sure the webteam can attack things from that angle if they prefer.
Have a look at Amavisd-new. Its what I'm using here. Also, if you wish to use Sophos aswell (I know you have it) you might want to plug it in using Sophie.
Should be capable of working in-line with our current mail server so as to filter mail as a separate physical server then pass the mail traffic onto our existing mail server.
It must be capable of existing with our AV solution (Trend AV) on the ‘in-line’ server.