I had a slightly different suggestion, but I don't know your timeline prior to the failure of the present system, nor what type of resources you can throw at this situation. So with that being said.

Why not implement an intranet, WWW mail gateway, with a DB backend. Or at least look along theses lines.

Pros:
1) Platform independance
2) Can reallocate/repartition storage devices, with relatively little intrusion on the clients mail interface
3) You can remove the actual large data files (movies I think you said in CB), out of the mail box, and onto an optomized partition for d/l.
3a) Or maybe instead move the large data files into a partition which can then be automounted or mapped to via samba.
4) All administration of the system should be seamless, and this model provides a nice upgrade path as you can segregate the WWW from the maildata, and even the attatchments. If any piece is under excessive load, you simply add another server, and add round-robin DNS entries.

Cons:
1) You now need to figure out a clean consistant and stable method for uploading content to be sent out via email.
2) Your users now need to get acclimated to a new interface
3) Your systems complexity has gone up an order of magnitude. You are dealing with NFS, HTTP and HTTPS, samba, some type of DB backend, and subsystem I/O monitoring
4) You need to figure out a method for importation/exportation of "address book" type features. I've yet to see an outlook user who simply couldnt do without that feature.

So just some random thoughts, but it could be interesting. And even if you dont use this setup, it may help in the decision making as to what components you might like to see in the future, which defines what pieces you implement now to work your way there.

Happy Hacking

/* And the Creator, against his better judgement, wrote man.c */