It's true that I could make a version in which the recipient's controls are disabled - in fact, previous versions didn't have any recipient buttons at all. However, the "protection" provided by the mechanism used by this add-in is so weak that I felt that that would lull users into a false sense of security...
For example, the flags that are modified on the send side are honoured only by the desktop version of Outlook at the receive side: if the recipient is using Outlook Web Access or a mobile device, the flag settings are ignored. It also only works when sender and recipient are connected to the same Exchange server infrastructure.
Even if there were no recipient buttons, it's pretty trivial for the recipient to re-enable the disabled facilities via Outlook's build in macro editor. Scott Hanselman's blog post that inspired this add-in shows how easy it is to disable reply-all via macros; it's not too difficult to work out how to reverse the operation. (The top of this post gives you the answer!)
In addition, because I'm not preventing the recipient from copying the message body or saving attachments, it would be possible to simply create a brand new message and copy the contents of the reply/forward disabled one into it.
Finally, I've not actually seen any documentation that talks about the action flags I'm using, so there's no guarantee that the mechanism will continue to work in future versions of Exchange and Outlook - but that might just be a result of my poor search skills.
In summary, it would be possible to create a variant of the add-in in which the recipient doesn't have direct control, but it's such a weak limitation that I don't think it's worthwhile - and could fool senders into thinking the system is more secure than it really is and relying on it for something particularly sensitive.
If you do want a reliable and secure system for protecting emails, Information Rights Management is the thing you should really be using.
Because I realise there are people who don't believe me and still want a version of the add-in with no recipient buttons or otherwise have different requirements, I've started a series of blog posts on how to write such an add-in...
Gavin - Great concept for an add-in!! One question about the write-up - this sentence "the flags I mentioned are handled by Outlook and Exchange - as long as the sender and recipient are attached to the same Exchange servers, the flag settings get passed along..." So my customer is multiforest with Exchange installed in seperate forests/seperate organizations. In the centralized forest, there are multiple Exchange servers. In the "remote" forests, there is one Exchange server. So are you saying that the flag will be preserved 1) only between mailboxes in the same mailbox database, 2) only between mailboxes on the SAME server, 3) only between mailboxes in the SAME Exchange Organization? My assumption would be that the flag would be lost if it leaves that Exchange organization, but might be preserved to any recipeint within the org even if they are on a different Exchange server/different mailbox database. Thanks. - David