I have customized Declude heavily, including integrating it with SQL to avoid performance problems and to work around a couple of bugs that I found. Unlike some of its bad press, Declude has been very stable for me over several releases of SmarterMail. Please understand that I wanted to buy a commercial product, but I kept finding vendors that did not understand the email security problem. I kept asking this question, and did not hear acceptable answers until I found Declude:
"Example.com has moved to outlook.com but has not updated their SPF policy. How do I configure an override that allows me to leave SPF enabled and does not enable spoofing of Example.com or Outlook.com".
To Proto's idea:
I have no objection, but I do not see us getting from here to there.
First, there is a trust problem. External origination is determined at the network perimeter, by the incoming gateway. In his model, banner generation is triggered by the email server and implemented by the email client. It is difficult for the email server to know with certainty that the message originated externally. The Authentication-Results header is the current effort to solve this problem, so it is possible, although the identity verification system is rudimentary.
You need an email filter that creates the A-R record, and a mail store that parses it. Both need to be configured with a secret code to distinguish between internally-generated and externally-generated versions of the header. Realize that the code is not really a secret because it appears as plaintext in every message header. So the email filter needs to strip any incoming A-R header which uses the internally-assigned secret code, and the code probably needs to be changed occasionally. This solution is probably doable if you use an Linux-origin product like Postfix for both roles, but I have not seen much evidence that the commercial market is moving in that direction.
Secondly, there is the Microsoft-proprietary problem. MAPI and Outlook are Microsoft-proprietary, and I am alarmed by the direction they seem to be moving with the technology. A real standard would need to address all user interfaces, and support multiple communication protocols between email client and email server, which MAPI does not. However, I have to grant that your linked article indicates that Microsoft has an interesting story for those who are willing to commit further to the Microsoft vortex. I am heading the other way right now.
An aside: One could fantasize that IETF will address this, but they will not. They do not consider communication between email clients and email servers to be an interoperability issue, and they do not expect any developers to listen even if IETF tries to tell them how email clients should behave.
Finally, you have to consider whether a standardized message is really what you want. I think your clients will have differing opinions about what the banner should say and how it should be presented. Additionally, their opinions will change over time in response to perceived threats. (I already find myself wishing that I had control over the webmail banner that SmarterTools has added.) After all, a standardized banner becomes easy to ignore, which will defeat the goal for which the banner was created..
Sorry, but I cannot find a winning path here. I wish there was.