DSNConversionMode and You: An Administrator’s Guide


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.

Jason Nelson

Comments (20)
  1. Andre Luis says:

    What a great article, informative and fun at the same time! Keep the good work!

  2. Daniel Noakes says:

    Brillaint post. More toast (posts) like these please!

  3. Luke Edson says:

    Jason, thanks for making my day. :) I couldn’t stop laughing! This is how posts are ment to be. (I’ll remember it well too)

  4. bday says:

    Great post! In Massachusetts 511 is traffic information from your cellphone. :P

  5. alex says:

    Wow.  Great post.  Super funny and very informative.  This is what EHLO should be.

    Keep ’em coming!

    A

  6. Steven Presley says:

    I’ve been asking for this since the Exchange 12 beta…you have no idea how happy this makes me. Thank you.

  7. Jim Burke says:

    What an amazingly well-written post! Can we have more of these? :)

  8. Magnus says:

    Great article, fun to read and a good feature I have been longing for!

  9. Ronald says:

    Brilliant post! One to forward onto the rest of the team!

  10. susan says:

    Jason, that was truly an inspired piece…excellent!!

  11. austinmc says:

    The most informative and entertaining post on DSNs ever.

  12. Martin Edelius says:

    Fantastic article! Very funny /and/ informative at the same time.

    Well done indeed. :)

  13. David DV says:

    What an excellent article explaining DSN usage in a great details!  Fun to read and crystal clear explained!  

    Saved us quite some testing & playing ….

  14. John says:

    Jason, you are a loony (in the nicest possible way)!

    This is a great way to explain technical subjects. Do you think the MS Press boys would let you edit some of their books? ;-)

  15. Al says:

    Why did it take this long to get posts this good?  Technical detail AND entertaining.  I hope the other authors learn from your post.

  16. Matt says:

    Great post! Moral of the story – use DSN’s for what they are designed for!

  17. Brian Ross says:

    Speaking a sendmail administrator, I applaud the Exchange team for finally implementing an option to preserve DSN content in (roughly) its original form.  I know, I know… anyone who chooses to be a sendmail admin is a masochist and nuts to boot, but there is great value in those session transcripts.

    So, thank you for implementing this and thank you for the fantastic and funny write-up!  

  18. Mat says:

    I really wasn’t here to read about DSNs; your writing style got me all the way to the end of the article and I’m glad I learnt something new!

  19. nelson says:

    Very funny and informative article. If all technical papers were like this, I would read them all..

  20. Chris says:

    I just about died laughing, but I’m also thrilled to see the option to keep Exchange from messing up the nondeliveries. I had a case this morning where I could compare the Exchange NDR with the original, and it was criminal how much info Exchange lost. The "transcript of session" section, which contained an important clue, was simply omitted in the Exchange version, and the reporting MTA’s name was substituted for the remote MTA name, giving a false picture of where the problem lay.

Comments are closed.

Skip to main content