Display a TLS icon for messages that are TLS secured (Outlook)

One of my colleagues at a large financial institution has customised Lotus Notes to show a TLS icon for messages that are TLS secured.

I'm interested in imitating this feature in Outlook, and believe this requires VBScript, custom forms, and possibly the Custom Forms Library in Exchange.

Has anyone experimented with changing the way an email displays based on either NamedProps, or text that is accessable in the email header?

Mutually enforced TLS, also known as Domain Security, is supported in Exchange 2007 and newer. Proper configuration of this feature is common vendor audit requirement in the financial industry: large financial institutions require their vendors and business partners to enforce TLS according to the e-mail domain names of partner institutions. This feature avoids relaying via untrusted SMTP servers by ensuring that messages are delivered directly to the recipient institution's Exchange server, encrypted via TLS, without passing through any untrusted mail servers en route.

The feature that you are requesting (identifying domain secured messages to end users) is already built into Microsoft Outlook. If Domain Security is configured correctly, any messages whose transport has been secured in this fashion will be designated with a green checkmark icon. You do not need scripting or custom forms to make this happen.

TL;DR

You can't do what you're asking. The only thing you can reliably verify with any real value from a security standpoint is encryption of the message itself (S/MIME, PGP, or similar).

The Long Version

From your comment

TLS secured on transport on the open internet is sufficient for the business (and many large peer businesses)

This sounds like your business (and its "many large peer businesses") don't understand what "TLS secured on transport on the open internet" means in terms of security for email.

Email (SMTP) is NOT a point-to-point connection. It is a relay race.
The security analogy is this:

1. SMTP + TLS puts your message in a blank envelope and hands it to a stranger on the street.
2. That person opens the envelope and reads the message to see who it's addressed to.
   • If the message is for them, they keep it.
   • If the message is for someone else, they put it in a new blank envelope and hands it to another stranger on the street.

It's at the second point under (2) where things go all pear-shaped as the message can be intercepted (copied or modified) with impunity - TLS is protecting the channel (so other people on the street can't see your letter when it's being handed off) but not the content, which the intermediate servers are going to need to decrypt in order to see who the message is addressed to.

Bluntly there's no way for you to verify SMTP TLS in messages sent over the public internet. You can consult the header data, but the header data is just a post-it note stuck on your letter by each stranger who touches it -- the headers can be a pack of lies.

You can verify that the last server that handled your message (the one talking to you) used TLS when they talked to you because you know the details of that connection, but that's all you can verify and that doesn't protect the rest of the chain (or the content of the message as noted above).

At least in my field (Medical) TLS in the message chain is completely inadequate as authentication/signature or encryption/confidentiality technology -- It's useful for its own purposes, but not reliable enough to hang your hat on in an audit.

There is some value in verifying that the reading connection (POP, IMAP, RPC/HTTP (Outlook), Webmail) is secured with SSL/TLS, but again this doesn't protect the message itself (nor does it ensure the SMTP half of the email process had any security whatsoever) -- it just keeps prying eyes from reading over your users' virtual shoulders when they're downloading their mail and protects their password (which is pretty important).