A Very Sensible policy, enforced by default in Exchange Server is to ignore rules automatically forwarding mail to external domains.
It’s fairly easy to see why this is, in fact, Very Sensible:
Your organisation assigned email addresses to people who have agreed to be bound by its policies (right?) – allowing auto-forwarding to any address outside that domain risks you being responsible for a breach of confidence.
I’m all for having the “secure” option be the default and for discouraging or preventing users from breaking that security in the name of convenience.
But there are times when other, less sensible policies are in place that I feel the users should have recourse to implement workarounds. One such policy might be (for example), having an email quota set to (purely hypothetically), 100MB.
This is ample space for email in 1997. This is hilariously limited space in 2016.
At this point, it would be Very Useful for users to forward all their mail to another account for posterity, particularly given the limited options available for auto-archiving Exchange mail (as a user).
As this isn’t an option, what other solutions exist?
You can use EWS to build a .Net application to manage the forwarding for you.
In fact, I did just that – the EWS Managed API is extremely easy to use, if sometimes sketchily documented. But then… I use a Mac at school, as do most of m’colleagues, so getting it to work in situ would require some kind of Mono shenanigans.
Oh, wait, you can create an addin for Outlook using Visual Studio. Which works great. On Windows.
When it comes to addins/apps/plugins etc for Office, Microsoft has done what it pretty much always does – try to cater to everyone and maintain backward compatibility.
The thing I ended up creating worked great. On Windows.
It’s bad enough that my version of Outlook on Mac is really just a desktop optimised mobile app running in a sandbox for OSX, trying to install some kind of web-based addin and hoping it’ll back deploy to my laptop through magical MS voodoo is a fool’s game.
I wasn’t about to waste another day trying to build something web based only to find it doesn’t do what I want.
So here am I – downloading Mono again to see if everything I’ve done has just been a big waste of time. I guess I’ll have to cut my losses sometime.
Making progress with Mono. They’ve come a long way since I last messed with it in 2008.
Some OSX specific issues with mkbundle (to create a standalone executable) were resolved in this SE query.
I am not a clever man, so I can’t pretend to understand how Mono takes .Net managed code and turns it into a 4 meg native binary for OSX, but I sure am impressed.