Exchange can't automatically transcode an email message.
Fortunately, with transport agents, you can script the hell out of exchange. Unfortunately, you're going to have to write the logic yourself. Let's go through it.
You can basically follow the instructions at http://msdn.microsoft.com/en-us/library/office/aa579185%28v=exchg.140%29.aspx
In your flow chart:
- You've already got this covered (right?)
- BREAK. We're never going to do this. Write a transport agent that changes everything we need to change. On the OnEndOfData event takes a delegate that has as an argument which contains a
MailItem
that has everything you need. First check if MailItem.Message.To
contains your MailBox-A. If it does, change everything you need to change:
MailItem.Message.To
add Maibox-B (optionally remove MailBox-A)
- Get the old body mimepart with
MailItem.Message.Body.MimePart
. Create a new MimePart
with the constructor
-
public MimePart(
string contentType,
ContentTransferEncoding transferEncoding,
Stream contentStream,
CachingMode cachingMode
)
You will need the contentType
"text/plain"
, ContentTransferEncoding
of the old ContentTransferEncoding
, a new content stream, and CachingMode
CachingMode.Copy
Write the contents of the stream of the old MimePart unchanged into the content stream of the new part (since you indicated you will not be using any characters outside of 7bit ASCII anyway, the content is actually identical. If it's not, read the stream as 7bit ascii, base64 decode the resulting string to a byte stream, decode the bystream with UTF-8 encoding to a string, replace what you need to replace, write to a bytestream with 7bit ASCII encoding, base64 encode the resulting bytestream, write the resulting string to the target stream encoding with 7bit ASCII) (phew!).
Replace the old MimePart with the new MimePart. You can use old.Parent.ReplaceChild(old, new)
.
Compile the thing and attach the dll with the compiled agent to Exchange. Copy-paste from the documentation: Execute Install-TransportAgent -Name "MyCustomAgent" -TransportAgentFactory "MyAgents.MyAgentFactory" -AssemblyPath "C:\myagents\MyAgent.dll"
in the Exchange Management Shell.
The adjusted email will now be in 7bit ASCII and have the correct recipient.
Is it possible? Yes. Is this all worth it? Probably not. What silly email clients can't read UTF-8 anyway? I personally wouldn't know of any, and the cost of supporting them is probably much higher than just upgrading the email clients.
If you are going to attempt this (I don't suggest you do) and get lost with the coding part, those questions would be in scope of StackOverflow.
Side note: you can't encode UTF-8 into US-ASCII as UTF-8 can encode all of unicode and US-ASCII can't. You'll need some handling of the missing characters. – Martijn – 2014-08-25T21:13:20.220
That shouldn't be an issue since I'm actually generating (well, sort of) the UTF-8 emails to begin with. Basically the program that generates the emails can encode the characters in many different charsets, but US-ASCII is not one of them. Since I'm creating the body of the email, I know that there won't be any non US-ASCII characters in the email. – romellem – 2014-08-25T22:54:43.950
1In that case, you don't have to do anything since the subset of Unicode that US-ASCII can encode is encoded identically in UTF-8 and US-ASCII. – user2313067 – 2014-08-26T04:53:53.840
That's not strictly true. An email in UTF-8 will have a
content-transfer-encoding
Base64 and a US-ASCII email generally 7bit (or omitted as that's the default) in its MIME. Whatever the case, theContent-type
will be different and will need to be changed. – Martijn – 2014-08-26T10:06:33.307