Delivery Status Notification and Message Disposition Notification

Outbound e-mails can include a request for a return message indicating whether and how the original e-mail was delivered. In Genesys eServices, you do this using the Send Email object in a routing strategy, as described in the Universal Routing 8.1 Reference Manual. The return message is of one of the following three types:

• If delivery fails: InboundNDR
• If delivery succeeds:
  • InboundReport
  • InboundDisposition

These types are represented as attribute values of the Interaction Subtype Business Attribute in Configuration Manager. E-mail Server assigns the return message to the appropriate type, and UCS stores it as a child of the outbound e-mail that contained the request.

The following sections describe each type and its contents.

InboundNDR

If one of the SMTP servers involved in the transport of the original e-mail fails to deliver it, E-mail Server submits the return message to the system with subtype InboundNDR (NDR stands for non-delivery report). There are two ways that E-mail Server can detect an inbound e-mail as an NDR:

RFC 3464

For this way, both of the following must be true:

• The e-mail conforms to RFC 3464, which means that it includes information about delivery status.
• That information indicates that delivery failed for at least one recipient.

In this case, E-mail Server submits the e-mail to the system with attached data.

Message Parts

For this way, all of the following must be true:

1. The e-mail contains either a message/rfc822 part or a message/rfc822-headers part.
2. The part referred to in (1) contains a Message-ID header.
3. One of the following must be true:
   • The e-mail’s From field contains one of the values specified in the E-mail Server ndr-senders-list option (the default is mailer-daemon,postmaster,mmdf).
   • The Message-ID header referred to in (2) matches the message ID of some interaction already stored in the UCS database.

In this case, E-mail Server submits the e-mail to the system with no particular attached data. The subtype InboundNDR indicates the failure of delivery; the message itself contains no additional information.

Structured Information

When E-mail Server attaches data to the inbound interaction, it is of two kinds. The first kind, structured information, is listed in the following table.

Key	Possible Values	Description
_DSNInfo.RecipientCount	Any integer	Number of recipient addresses covered in this DSN
_DSNInfo.Recipient1.Recipient	Any string	Recipient address
_DSNInfo.Recipient1.Action	delayed delivered expanded failed relayed	Action applied for this recipient
_DSNInfo.Recipient2.Recipient	Same as _DSNInfo.Recipient1.Recipient
_DSNInfo.Recipient2.Action	Same as _DSNInfo.Recipient1.Action
_DSNInfo.RecipientN.Recipient	Same as _DSNInfo.Recipient1.Recipient
_DSNInfo.RecipientN.Action	Same as _DSNInfo.Recipient1.Action

In RecipientN in the last two rows of the preceding table, N is the value of _DSNInfo.RecipientCount: the number of recipients covered in this InboundReport.

Important

A non-delivery report may arrive even if the outbound e-mail did not request it. If it does, E-mail Server still submits it to the system with the subtype InboundNDR.

Raw Information

The second kind of information that E-mail Server attaches is raw information. That is, all information included in the reply e-mail’s header is attached as key-value pairs, with the key name formed by prefixing _DSNRawInfo to the field name used in the reply. Some examples are:

_DSNRawInfo.Reporting-MTA
_DSNRawInfo.RecipientCount
_DSNRawInfo.Recipient1.Original-Recipient
_DSNRawInfo.Recipient1.Action
_DSNRawInfo.Recipient1.Status
_DSNRawInfo.Recipient1.Remote-MTA
_DSNRawInfo.Recipient2.Final-Recipient

For details, see RFC 1894.

InboundReport

You request delivery status notification (DSN) by selecting the Delivery status notification box in a Send Email routing object. The reply to this request receives the subtype InboundReport. This reply conforms with RFC 1894, and includes, as attached data:

• The structured information listed in Table 21 on page 203.

Note that if the _DSNInfo.RecipientN.Action key has a value of failed, E-mail Server assigns the reply the subtype InboundNDR, not InboundReport.

• The raw information contained in the keys whose names start with _DSNRawInfo, as described in the previous section.

Important

Depending on the implementation of the SMTP servers involved, there are the following possibilities:

• Individual DSN messages can be generated, each one related to one or several recipient addresses.
• A single DSN message can be generated, related to one or several recipient addresses.

InboundDisposition

You request message disposition notification (MDN, also called read receipt) by selecting the Message disposition notification box in a Send Email routing object. The reply to this request receives the subtype InboundDisposition. This reply conforms with RFC 3798, and includes, as attached data, the information listed in the following table.

Key	Possible Values	Description
_MDNInfo.ActionMode	manual-action automatic-action	Mode of the action applied to the e-mail
_MDNInfo.DispositionType	displayed deleted	What was done with the e-mail
_MDNInfo.SendingMode	MDN-sent-manually MDN-sent-automatically	How the message disposition notification is being sent
_MDNInfo.Recipient	Any string	Recipient address covered by this message disposition notification

This reply is sent as long as all of the following conditions are met:

• It was requested in the outbound e-mail. This is independent of whether a delivery status notification was also requested.
• Delivery succeeded.
• Either of the following:
  • The recipient agreed to send the read receipt.
  • The recipient mailer was configured to automatically send read receipts.

In addition to the structured information listed in the preceding table, all information included in the reply e-mail’s header is attached as key-value pairs, with the key name formed by prefixing _MDNRawInfo to the field name used in the reply. Some examples are:

• _MDNRawInfo.Disposition
• _MDNRawInfo.Final-Recipient
• _MDNRawInfo.Original-Message-ID
• _MDNRawInfo.Reporting-UA

For details, see RFC 3798.