Delay Notifications: Informing users about delays in mail delivery

Users consider email to be a reliable communication mechanism - not as reliable as the dial tone, but pretty close. Most users expect mail to be delivered within minutes, if not seconds.

Many organizations, including those operating in the financial & banking sectors, have strict SLAs for mail delivery which specify mail delivery times granularly— for mail within a particular location (that is, within a Routing Group in Exchange 2003 and within an AD Site in Exchange 2007), between two locations, and to/from the internet.

Exchange Server sends a delay notification to inform the sender if delivery of a message is delayed beyond a configured timeout. The default delay notification timeout in Exchange Server 2003 is 12 hours. This has been reduced to a (comparatively) more realistic 4 hours in Exchange Server 2007.

When considering changing these defaults, it's a good idea to consider any SLAs and user expectations. Is it reasonable to expect a user to wait for 24 hours before informing him/her about a delay? 12 hours? 1 hour?


Figure 1: In Exchange 2007, the default delay notification timeout is 4 hours

You can change the delay notification timeout using the Exchange console (EMC) from Server Configuration | Hub Transport | SERVERNAME -> Properties | Limits tab.

To change delay notification timeout using the Exchange shell:

Set-TransportServer "SERVERNAME" -DelayNotificationTimeout 01:00:00

This sets the notification timeout to 1 hour. The value is specified in dd.hh:mm:ss (the standard format used by the shell). Valid values— minimum: 00:00:01 (yes, 1 second!) to 30.00:00:00 (30 days). It's recommended to wait till transient failure retries have been completed before sending a delay notification (that is, higher than TransientFailureRetryInterval x TransientFailureRetryCount).

In Exchange Server 2003, the delay notification timeout can be changed from SMTP Virtual Server | Properties | Delivery tab. There are different delay notification timeouts for outbound and local mail.

If you decide users don't need to know about mail delivery delays (and there could be perfectly legitimate reasons for that - although as I write this I can't think of any... ), you can disable delay notifications:

Set-TransportServer "SERVERNAME" -ExternalDelayDsnEnabled $false -InternalDelayDsnEnabled
$false

Have you changed the default delay notification in your organization? What is a reasonable time for notifying users about delays?

Related:

• SMTP Virtual Servers: Some irksome defaults you should change
  
• Set-TransportServer