Thanks for this very useful addin.
If you ever add new features, here is another very useful one. It would be an outlook general setting: On Send, if an email contains "Confidential" or "Internal Only", warn if a receipient doesn't belong to the same company as the sender.
I used to have a vba addin to do that. The main issue was to programmatically determine the recipients' email addresses; I couldn;t get it to work at 100%.
The code was checking for 'intern*' or 'confid*' in either the Subject or in the Body above the signature.
The problem lies in, as you said, determining email addresses reliably. The current version of the add-in has an option to disable reply-all on all incoming messages: I wanted to have a variant of that which would do that only if the user's email address(es) didn't appear in the TO or CC line (ie, the user had been BCC'd), but came a cropper at the same point.
While it is actually easy to get a list of the email addresses directly referenced on the address lines, if some of those are distribution lists, extra effort is required to expand those (potentially adding significant extra latencies), and that may have to be done recursively.
So, it would be easy to implement a half-baked solution, which checks only the addresses directly mentioned, but that leaves a hole for external people who happen to be included on internally defined distribution lists.
What problems did you have with determining email addresses - in my investigations, I grabbed the direct addresses by iterating over MailItem.Recipients and looking at the Address fields. I'm pretty sure that that is doable in VBA as well as C# or PowerShell - my initial exploration used PowerShell, which made for quick and easy exploration of the Outlook object model. I talk about this a bit in a blog post from a while ago.
As far as the add-in is concerned it certainly seems to be the case that the "Action" flags I'm using, to a good approximation, just affect the Outlook UI and thus prevent the user manually forwarding because the controls that would have to be used are unavailable. Automatic forwarding looks like it bypasses that.
However, if you take a look at the email rules definition tool, one of the options you can specify is to take some action if the email is "flagged for action" (where action is one of the flags I use, such as forwarding). I wonder if it's possible to use that to specify a rule which will fire on forward disabled messages which will prevent them from being forwarded automatically, perhaps by putting them in some subfolder of the inbox (if that would actually prevent forwarding). Of course, if autoforward is processed before the rules are run, that's no help at all :-|
Even if this does work, it does rely on having the rule set up for the recipient, which is a bit of a nuisance.
Do remember that the techniques I've been using here are quite light and fragile - a very weak "protection" against leakage. The robust way to protect email is to use some of the IRM or related technologies - some info at http://www.microsoft.com/exchange/en-us/information-protection-and-control.aspx.
Hi Gavin. My solution was definitely far from fullproof. I didn't look too far and it was only for my own use.... and a good exercise to learn a bit about the Outlook object model.
I too was doing all the work looping through MailItem.Recipients and reading the Address, splitting the cases based on recipient.AddressEntry.AddressEntryUserType. A couple issues I encountered were:
1) for some recipients the email address would be easy, but for some others it would be like "/o=mex07a/ou=Exchange Administrative Group (FYD..." making it sometimes difficult to extract the domain, and
2) some recipients would be Distribution Lists in which case I would only test first member using GetFirst; I thought about going recursive and saving the result "belong to the domain or not" for each list so I wouldn;t have to do this each time, but even that wouldn;t have been fullproof (eg:when lists are updated).