Following up on my post about NDRs, this post describes how to work with custom DSN messages.
First, let’s talk a bit about DSN messages or Delivery Status Notifications. DSNs are system messages intended to report the delivery status of a messages back to the sender, informing him or her if and why the message fail for any reason. Delivery status notifications comes in three different types:
- Success (2.X.X numeric codes)
- Persistent transient failure (4.X.X numeric codes)
- Permanent failures (5.X.X numeric codes)
When a message can not be delivered for some reason a error is reported and the server maps this error to a DSN. The 5.X.X are described as permanent failures and are the most common messages. However, you may also see 4.X.X codes from times to times .
Delivery status notifications are addressed in RFC 1891 and 1893. More detailed information on codes can be found here:
http://support.microsoft.com/kb/256321/
http://support.microsoft.com/kb/284204
New Custom System Message
Now, on to the fun stuff! In my example, I will create a custom DSN for code 5.7.1 and enable it for external senders. I will also create a custom DSN for code 5.1.1 for internal senders. Lets start with looking at the commands…
New-SystemMessage creates a new custom system message. you will have to include the code you want to “replace” and also the message you want the DSN to include. In my example the command looks like this:
New-SystemMessage -DSNCode 5.7.1 -Text "This server does not accept relaying" -Internal $False -Language En
I also created one message for Swedish using -Language Sv.
In my second example i want my custom DSN to be sent to internal senders:
New-SystemMessage -DSNCode 5.1.1 -Text "The user does not exist, please contact the helpdesk for further assistance" -Internal $True -Language En
Again, I created a second message for Swedish as well.
And here are the result when I tried to send a messages to the non-excisting address test@sundis.local:
View Both Custom and Original System Messages
So, the message is created, now what? Well, if you want to view your new message you can use the following command:
Get-SystemMessage
This lists all custom system messages and note that the identity is presented in a path-like way starting with the language.
You can also list the original message that matches the newly created custom system message. If you run the following command you will list all system messages.
Get-SystemMessage –Original
To narrow it down, use where as in this example:
Get-SystemMessage -Original | where {$_.identity –eq ‘en\internal\5.7.1’}
Change a Custom System Message
If you want to change a custom system message you can do so easily using Set-SystemMessage as in this example:
Set-SystemMessage -Identity en\External\5.7.1 -Text "This server does not accept relaying, so don’t even try it!"
Remove Custom System Messages
And the last system message command that I’m going to cover is Remove-SystemMessage. In this example I will remove one of the messages I created before:
Remove-SystemMessage –Identity en\External\5.7.1
To remove all custom system messages use this command:
Get-SystemMessage | Remove-SystemMessage
I could have typed a to accept the removal of all messages instead of typing one y per message. But I wanted to show you that it removed all three messages in that single command.
One more thing…
Not that hard right? There is one more thing to consider though. Many email-servers have the habit of rewriting DSN messages to make it more user-friendly, including all Exchange servers. So even if you configure a neat DSN message for external senders they might not see it because their server applied a user friendly standard DSN.
In theory, if both servers run Exchange and they have the same version they should leave the custom DSN alone and present it to the user instead of rewriting it. I still haven’t seen this working in real life…
There is one thing you can do to prevent overwriting if you are running Exchange Server 2007 Service Pack 1 Update Rollup 4 or later. You can use the Set-TransportConfig -DSNConversionMode and the parameter comes with three different settings:
- UseExchangeDSNs
- PreserveDSNBody
- DoNotConvert
UseExchangeDSNs is default and you can change it with the following command:
Set-TransportConfig –DSNConversionMode DoNotConvert
That’s all for this time, good luck with the messages. Thanks for reading and please, don’t hesitate let me know if you run in to any problems!
Martin's Wonderful World of Unified Communications 