Exchange MVP Simon Butler posed what seems like a simple question: how do you stop a user from sending mail? The answer is deceptively complex; we’ve been debating this on an MVP list for a few days now.
Say you have a MAPI user. You disable the associated Active Directory account, either by disabling the account or by changing the password. In either case, the user can still submit mail to the information store! In the case of a password change, the user will be asked to authenticate again, but if she cancels the password dialog, she can still send– she just can’t receive new mail! That might be a problem in case of an employee who’s leaving (voluntarily or not), although a measure of physical access control will help.
You can kill the MAPI session, but that doesn’t do anything to stop the user from reconnecting from the client side, at which point you’re back to square 1: the user can still send mail. (This doesn’t seem to be true if the user quits and relaunches the client after you kill their session, though).
For other protocols, it’s easy to prevent users from connecting and sending mail. For example, for IMAP, POP, or HTTP connections, you can just remove the user’s ability to use those protocols by using the Exchange Features tab in AD Users and Computers.
If you want to block all users, you can do that too; KB 288894 describes how to limit MAPI connections to a particular version of Outlook (so just set the regkey to deny from the current version (which I think is 11.0.6352.0) backwards. For HTTP, you can either set an IP address restriction on the Exchange vdir (thanks, KC!) or stop the w3svc, although this will have other effects. For that matter, if you want to prevent all client access, stopping store.exe will do the trick nicely at the cost of a service interruption.
Perhaps MS will fix this in Exchange 12.
Paul's Down-Home Page 
Weekend reading
Weekend reading