There are two types of delivery failures you can encounter when sending outbound email.
- 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.
Why Are Some Failures Synchronous And Others Asynchronous?
This is up to the sole discretion of the receiving server. One reason a server may wish to return 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.
Most mail servers naturally handle synchronous failures because the remote mail server outright refuses to accept your outbound message.
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.
Our system automates the processing of bounced messages by:
- Automatically creating a return path for each outbound message that points back to the running instance of Hurricane Server
- Embedding identifying information (including user defined) into the return path that is specific to the individual outbound message using a Variable Envelope Return Path
- Intercepting the NDRs/bounces that come into the server destined for the return path
- Parsing the message-specific identifiers from the return path
- Analyzing these messages using sophisticated bounce analysis technology
- Recording the results in the reports on your server