Synchronous vs. Asynchronous Failures (NDRs/Bounces)

There are two types of delivery failures you can encounter when sending outbound email. You can think of them as synchronous and asynchronous.

A Synchronous Failure occurs when the remote mail server rejects our message during our conversation with it.

An Asynchronous Failure occurs when the remote mail server accepts our message and then later returns it by sending an NDR (Non Delivery Report) to the return path of the message. In this situation, since the remote mail server accepted our message successfully, we initially believe that the outbound message has been delivered. It is not until we receive a later failure notification from the remote server that we know the outbound message has failed. This is what is typically referred to as a bounce.

This is up to the sole discretion of the receiving server. One reason a server may wish to do asynchronous failures is to prevent dictionary attacks on itself. If the server accepts email for any address on one of its domains, it is not possible for a remote agent to poll the server for "good"/valid
addresses.

Hurricane server (and most other mail servers) naturally handle synchronous failures because the remote mail server outright refuses to accept your outbound message. Hurricane server, however, does something that no other server does. It fires an OnFail() event that you can handle with your own .Net code. Typical implementations of this event will contain code to update a SQL table and flag the failing address as invalid.

Handling asynchronous failures has traditionally been more complex because the SMTP protocol requires asynchronous failures to be sent to the return path of the message, rather than to the original sending server. The return path is usually the From address, but in automated mailing systems it is typical to set the return path to a common address, where all NDRs/bounces should go. Then some process would need to be run to gather these NDRs, parse, and analyze them.

Although there is a specific MIME format for NDRs, many servers do not support it and simply return the error in the text body of the message. This can make bounce analysis code difficult because each ISP can use their own NDR format, which requires complicated parsing code to perform the analysis. Hurricane Server automates the processing of bounced messages by:

1. Automatically creating a return path for each outbound message that points back to the running instance of Hurricane Server.
2. Embedding identifying information (including user defined) into the return path that is specific to the individual outbound message.
3. Intercepting the NDRs/bounces that come into the server destined for the return path.
4. Parsing the message-specific identifiers from the return path.
5. Analyzing these messages using sophisticated bounce analysis technology.
6. Reporting the results in the Hurricane Server logs and reports.
7. Firing an OnBounce() event that you can handle with your code and passing on the message-specific identifiers, reason for the failure, and failing address

Typically Hurricane Server users will handle the OnBounce() event with SQL code to update their databases as they see fit. In the most simple example, you could write SQL code to flag the failing address as invalid in your email address table. In more sophisticated scenarios, you could update your own tables with failure statistics for this outbound mailing or message. There are many possibilities.