The observant among you may have noticed that starting in Exchange 2007 Service Pack 1, Rollup 4, a new parameter debuted for Set-TransportConfig: DSNConversionMode. Those of you who like to experiment have probably already derived what it is that this does. Those of you who prefer a guide, read on.
A taxonomy of DSNs
The Delivery Service Notification, or DSN, is an ever present harbinger of problems. They crop up for a number of user, network, and occasionally server induced problems. They are your mail server's way of saying "I think something went wrong." The problem with DSNs is that they are generated by your mail server, and your mail server (unlike many humans) speaks raw SMTP. SMTP is completely readable in the same way that teenagers texting each other are completely readable. To the uninitiated, it looks a lot like garbage.
Your email server is initiated into the cult of SMTP. It eats it, breathes it, drinks it, and probably writes poems at night in SMTP while you are sleeping. To an SMTP server saying "511" is as clear as day. "Brother," it says, "I beg your pardon, but the individual for whom this message post is destined is unfortunately not available in my directory. I do apologize, and would you please be so kind as to notify the kind gentleman who originated this message of this situation?"
For meatbags and other mail administrators, 511 means the time of day they go home, or maybe their home address, or how much a gallon of gas costs.
Now, mail servers are like people. Some are from the north and brusque in their transactions with the end user.
MAIL DELIVERY NOTIFICATION:
5.1.1
This is straight to the point, conserving both ones and zeroes, and after all, what more could one want than a nicely printed 5.1.1 code?
Other mail servers are more "helpful". Pity the meat bags, say the mail servers. Their brains are squishy. They do not speak SMTP, or they do it poorly. Let's add some meatbag-friendly information to let them know what went wrong.
Mail Delivery Notification
Your message was not delivered for the following reason:
5.1.1 (Mailbox not found)
Wow. Now we are getting somewhere. 5.1.1 - the mailbox was not found. Hmmm. The problem here is that this message will be read by humans, many of whom fail to plug in the toaster in the morning and then wonder why their bread is cold and squishy. These same humans then conclude that the reason the toaster doesn't work is that it was made in China, as if an American toaster would have plugged itself in. The Japanese toasters, of course, include their own fusion reactors, bake bread and then slice it into toast. They also connect to the Internet and speak SMTP, so they know that anyone who cannot toast a slice of bread can't figure out what "Mailbox not found" means.
So then we have a third variety of mail server: That which attempts to be helpful.
Mail Delivery Notification
Your message ("I would like some cake") was not delivered for the following reason:
5.1.1 (Mailbox not found)
This may indicate a problem with the address you entered (unlebob@contoso.com)
This one actually has a chance of letting people know what is wrong, because if by some miracle they manage to read all the way to the bottom of the preview pane before something shiny catches their attention, the user may notice that they missed the "c" in Uncle Bob's address. While they eat their cold, soft toast a thought will form in their mind that eventually leads to the user resending the message, and this time, they'll be careful to add the C back in. (Unfortunately, they will add it at the wrong place and start the cycle over again).
Finally we have the mail servers who like to write. We are talking Robert-Jordan-Wheel-of-Time class length here, NDRs so long that they have to be broken up into sections just to avoid the message size limits (and everyone knows that NDRs to NDRs, well, that would result in a reality paradox that might well destroy the world and all the cold bread eating people in it). These DSNs, well, they not only include the error code, they feature a friendly description of the error code, a description of why the error might have occurred. How much would you pay for a DSN like that? Don't answer yet, because we're not done! They also include a transcript of the SMTP conversation that lead to the error code, a list of headers and diagnostic information for the user's help desk to ignore. But that's not all! If you act now we'll include the original message at no cost to you: That's right, return of content, twice the email for the same price, a history of famous celebrities who once encountered this error code, and a recipe for chocolate cake. These mail servers not only include all this information but they write the DSN in HTML ("Courier new is so 8-bit") and practically write the thing in iambic pentameter.
Exchange DSNs fall into this category.
You say Tomato, I say 5.1.1
So, to review: different mail servers add different information to DSNs, some more helpful than others, some more able to fit on a CD than others. Exchange, of course, does not speak DSN internally. Our messages are stored in a database, arranged in a series of key:value property pairs. The process that converts from MAPI to RFC822 format is called "Content Conversion", because it is the code that does the conversion, and the content of it is the subject of another article for another day. Keep in mind that it exists. Internally, Exchange uses "Message Classes" to divide up your messages into types. Normal messages, Appointment messages, those stupid "Go get the pizza" tasks your manager assigns, those are all different message classes.
Content conversion is responsible for taking an RFC/822 message and turning it into an Exchange message. Ideally, it will map it to the right message class. Internally we have Delivery Reports (and their Non- cousins), externally those will be DSN messages. Similarly, if we want the pretty little "Resend" form in Outlook, that inbound DSN needs to become an NDR/DR. In the process we have to make some decisions.
The primary decision we have to make is whether or not the mail server who created the DSN is a brutish beast who can't be bothered to even try to explain itself. If it is then during conversion we'll pick out the DSN code and attempt a mapping to a more helpful error string. In the process anything that was originally in the DSN gets whitewashed over and then rewritten. If we believe the message originated in another exchange server (and not one of those backwater uneducated E2k3 ones), we will let the message pass unmolested into the STORE. After all, it's a fellow Exchange 12 server. Exchange servers are always polite. Exchange servers are always helpful. Well, that's the theory.
You did what with that?
So far, so pretty much good. Like most things, everything worked fine until people got involved. And the people hatched plans that frankly we never considered. I'm not really sure about the thought process or conversations that lead to these kinds of things, but I've tried to reconstruct them here:
"What if we had people submit warranty forms for their toasters electronically? And instead of replying to them saying we received it, we'll configure our mail server to generate an NDR for everything even though it delivered it. Yes, yes, it all makes sense now. And if a question arises about whether or not a form was submitted, you just present the DSN that our server generated as proof. Make it so."
Or
"I believe in leadership by fear. Let's configure our mail server to generate our own DSN, letting people know that we were actually watching them, and we saw what you did. That way when the thought police arrive at their office the people won't be surprised. Oh, and let's warn them not to eat shellfish, because the truth serum has a nasty interaction with it."
If Exchange content conversion processes those DSNs, it will see that they did not originate on a fellow Exchange 12 server. And it will helpfully insert an "interpretive dance version of your error code." And the poor guy who just wants to return his toaster because it won't heat the toast, he is out of luck. When ToastCo demands his proof that he submitted the electronic warranty card, the DSN that is in his mailbox will not contain the original content as generated by ToastCo. It says something like
Message Delivery Failed:
Error code: 5.1.9
Reason: Mailbox unassigned
Toast man is out of luck. Worse yet, when denied his buttery creation he'll drown his sorrows in a breakfast buffet of shrimp scampi. When he gets home from work it will be with discharge papers from the hospital and firsthand knowledge of truth serum and shell fish allergic reactions.
The Edge of Reason
Not all situations are quite so bad. The man with the Japanese toaster is also having a bad day. His toast is also cold and soft. When he mailed it his morning toast order (from his Windows Mobile™ smart phone), the toaster tried to explain.
It generated a DSN with a wonderful HTML body with picturesque explanations of why it was genuinely sorry that the toast order could not be fulfilled. It put them in an HTML body with a four page explanation of what each step means and also yoga tips for helping digest toast.
This is actually quite helpful. The first drawing says that fusion cannot be supported in the toaster because there isn't enough fuel for the reactor. The second one says never to open the nuclear toaster without appropriate protection, even if you are in a hurry and will only get a little irradiated. The third one says that the toaster should only be powered by fuel bought from UN approved sources. The last one is a cat, because everyone likes cats.
Exchange will look at the DSN, and it will see that it was not generated by an Exchange 12 or higher server. So it will replace the HTML body generated by the fusion toaster with its own version based on the error code. Nuclear Toast Owner gets the following NDR:
Message Delivery Failed:
Error code: 5.6.1
Reason: Media not supported.
The results will be disastrous. Without the helpful text in the DSN Toaster man will decide (from the pictures in the manual) that in order to get toast he must gather some nuclear fuel, put it in a brief case, feed it to a pig in the middle east, and a cat must accompany him the entire way. A simple breakfast loving man will wind up in trouble with the department of homeland security, the entire middle east, and cat lovers everywhere.
It doesn't have to be like this.
DSNConversionMode
DSNConversion mode is a new option for set-transportconfig. It allows the mail administrator to control what processing Exchange does on DSNs that are not generated by Exchange 12. The possible options are:
· UseExchangeDSNs: This is the default, and it's what most people need it set to. All the processing above is performed.
· PreserveDSNBody: Nuclear Toast man, this one is for you. This preserves any HTML body attached to a DSN instead of overwriting the text with our own best guess. The message is still an IPM.Report message class, so outlook displays it as an NDR but the body is whatever was set. Companies who are merging and providing custom DSNs that say "Don't mail at company x, mail at new company y" will use this.
· DoNotConvert: For solutions that use DSNs in "special" ways, DoNotConvert is the answer. DoNotConvert means "DoNotConvert it into a report. Just turn it into an ordinary message, with whatever was attached to it and leave the text alone." Most people will not use this.
So, there we have it. Forms can be preserved. HTML bodies can be preserved, Diagnostic information can be retained. Email administrators can cackle in glee as yet another substitute for world domination is granted to them. Bread will be heated, butter melted. It's not world peace, but you can't spread butter on peace, eat eggs with peace and people never talk about having "Jam and peace" in the morning. I guess it will have to do for now.