Summary:

EMF Supports three different types of Delivery Status Notifications (DSNs):

- delivery delay DSN
- successful delivery DSN
- delivery failure DSN

EMF supports the internet DSN (Delivery Status Notification) standard described in RFC 1893 (http://www.imc.org/rfc1893).

When EMF attempts to send out a message, and a connection to the destination server cannot be established, the mail is held in the Retry queue. EMF retries the connection at regular intervals, as specified by the EMF admin in the Retry queue setup. At a particular point in the retry period, EMF sends a delivery delay DSN to the sender. When the entire retry interval expires, and the message has not yet been delivered, EMF sends a failure DSN to the original sender.

EMF also supports successful delivery DSNs, which is also part of RFC 1893.

EMF also supports failure DSNs exclusive of message retry. Delay DSNs and retrying of the message occur when EMF cannot establish a connection to the remote host. But when EMF can establish a connection, and the remote host refuses to accept the message (for example, a "recipient not allowed" error), EMF can return a failure DSN to the sender.

The format of all failure DSNs are specified by setting the "Bounce Action" in the EMF Setup Relays section.

Detailed Information:

Delay DSN

EMF sends the following DSN back to the sender at the 3-hour mark (more specifically, after EMF has attempted to send the message at the last increment before it reaches the Retry Queue's Maximum retry Interval; see related article Retry queue on the right for more details):

Subject: Delivery Notification - Your message has been delayed

Body:

----------------------

Your message has been delayed. The server will continue trying
to forward the message. You do not need to resend the message.

Apparent cause of delivery failure:
Attempts to connect to the remote server have failed.

The delay affects the following recipients:

recipient@test.com

----------------------


The attachment annotation is:

----------------------

Reporting-MTA: dns;emf-server-name

Final-Recipient: rfc822;recipient@test.com
Action: DELAYED
Status: 4.4.0 (Delivery attempt failed)

[Note the 4.4.0 DSN code, according to the RFC.]

----------------------

The original message headers are also attached to the DSN.

Delay DSNs can be disabled; see related article Disabling non-failure Delivery Status Notifications (DSNs) on the right.


Failure DSN After Retry Expiration

At the expiration of the entire Retry interval (default 3 days), EMF sends the following failure DSN back to the sender:

Subject: Delivery Notification

Body:

----------------------

Your message could not be sent. The retry time limit has been exceeded.

Apparent cause of delivery failure:
Attempts to connect to the remote server have failed.

The following recipients have not received the message:

recipient@test.com

----------------------


The attachment annotation is:

----------------------

Reporting-MTA: dns;emf-server-name

Final-Recipient: rfc822;recipient@test.com
Action: FAILED
Status: 5.4.7 (Maximum retry time exceeded)

[Note the 5.4.7 DSN code, according to the RFC.]

----------------------

The entire original message is also attached to the DSN.

Please see the section below on General Failure DSNs for information on specifying the specific "Bounce Action" for a failure DSN.


If the original sender address is NULL or bad, event ID 1063 will be logged in the EMF event log at the maximum wait interval, and at Retry interval expiration:

Event Type: Warning
Level: Normal
ID: 1063

Event Class Description: Message has an invalid sender address.
Event Details: Address '<>'. Message will be placed in the Dead Letter queue.

and the message is Dead Letter'd.


Successful Delivery DSN

EMF also supports delivery success DSNs. This means that, if the sender has requested a delivery success DSN, EMF will send a DSN back to the sender after EMF has successfully relayed the message. Most sending email clients can request delivery success DSNs. Note that EMF will only send a delivery success DSN if the server to which EMF has relayed the message does not support delivery success DSNs, and hence that server itself will not send one. Therefore,

- if the sending email client has requested a delivery success DSN, and
- the message was successfully relayed by EMF, and
- the server to which EMF relayed the msg does not support delivery success DSNs

then EMF sends the following delivery success DSN back to the sender:

Subject: Delivery Notification - Message successfully relayed

Body:

----------------------

The following recipients have been successfully relayed.
recipient@test.com

----------------------


The attachment annotation is:

----------------------

Reporting-MTA: dns;emf-server-name

Final-Recipient: rfc822;recipient@test.com
Action: RELAYED
Status: 2.1.5 (250 Ok)
Remote-MTA: dns;relay-IP-address

[Note the 2.1.5 DSN code, according to the RFC.]

----------------------

The original message headers are also attached to the DSN.

Delivery success DSNs can be disabled; see related article Disabling non-failure Delivery Status Notifications (DSNs).

Note that if EMF sends back the successful delivery DSN, it does so regardless of the final disposition of the message at the destination email server (EMF does not know what the final disposition will be). It is possible for EMF to send a successful delivery DSN, and for the message delivery to fail at the final server (for example, a "user unknown" error). The sender will then get both notifications. If this behavior is not desired:

- the EMF admin can turn off non-failure DSN's as described above, or
- the msg sender can request a Read Receipt rather than a successful delivery DSN; most email servers support Read Receipts, which specify that the destination email server send back a notification to the sender that the email was read by the final recipient.


General Failure DSN

When EMF can establish a connection, but the remote host refuses
to accept the message (for any number of reasons, a common one of which is a "recipient not allowed" error), EMF can return a failure DSN to the sender, depending on what "Bounce Action" is specified. The contents of the failure DSN are configurable on a per-domain or per-address basis. The following "Bounce Actions" can be selected for the (FROM) domain or address:

1. Drop the original msg
2. Put the original msg in the Dead Letter Queue
3. Return the original msg as message headers only
4. Return the original msg in its entirety (default)

To change the Bounce Action for an entry, do the following:

1. Open Web Admin, go to Setup, then Relays.
2. In "Mail Routing Rules" click EDIT for the FROM domain/address entry you would like to modify.
3. In "Inbound Mail Acceptance", look for "Bounce Action" and select the desired action.
4. You must click SAVE at the bottom of the screen.

Note that you specify the Bounce Action for the original message's FROM domain, that is, the domain FROM which the ORIGINAL message came (which is also the domain that is the destination of the DSN). You do NOT specify the Bounce Action for the original message's TO domain.

Using the example of a remote 550 (recipient not allowed) error, the results of the various bounce actions are...

1) Drop the original message:

No DSN is returned, and the following event is logged in the EMF log:

Event Type: Info
Level: Normal
ID : 1059

Event Description : Returned message will be dropped


2) Put the original msg in the Dead Letter Queue:

No DSN is returned, and the following event is logged in the EMF log:

Event Type: Info
Level: Normal
ID : 1060

Event Description : Returned message to be placed in Dead Letter queue


3) Return the original msg as message headers only:

Subject: Delivery Notification

Body:

----------------------

Remote server rejected mail for recipient - 550 Requested action not
taken - Recipient not allowed

recipient@test.com

----------------------


The attachment annotation is:

----------------------

your.emfserver.com

Final-Recipient: rfc822;
Action: FAILED
Status: 5.1.0
(550 Requested action not taken - Recipient not allowed)
Remote-MTA: dns;remote.server.com

[Note the 5.1.0 DSN code, according to the RFC.]


----------------------

The original message headers are also attached to the DSN.


4) Return the original message in its entirety (default):

Same as (3), but the entire original message is attached to the DSN
instead of just the message headers.

Additional Info:

Also see the related articles:

- Retry Queue

- Disabling non-failure Delivery Status Notifications (DSNs)