Modifying, Adding or Customizing Failure Codes

Applies to HMS Version: 1.0+

The Hurricane MTA Server (HMS) classifies failures as codes based on regular expressions in the response_translations.list and textbody_translations.list files located in the bin directory of your Hurricane MTA Server installation. If you want to change these files, first copy them to the config subdirectory off of your main installation path and make the changes there. Files of the same name in the config directory will be automatically used instead of the ones in the bin directory. If you change the files in the bin directory and later upgrade, these files may be overwritten. However, modified copies of these files in the config directory are not overwritten during an upgrade.

The codes defined in these files will be included in the BounceProcessed.log and the Processed.log and are also passed to plugin events that handle Failures and Bounces. For example, the codes are passed into OnBounce() and OnFail() as a FailureCode item in the
options parameter.

SYNCHRONOUS ERRORS (IN-BAND FAILURES)

In the case of synchronous errors the bounce processing engine will attempt to match the recipient server's actual SMTP textual response to one of the regular expressions in the response_translations.list file.

When a match is found, the bounce processing engine will use the corresponding code when reporting that event.

ASYNCHRONOUS ERRORS WITH DNS MIME PART (BOUNCES)

In the case of asynchronous errors that include a valid DSN MIME part as defined in RFC 1891, the bounce processing engine will attempt to match the Diagnostic-Code data included in the DSN MIME part to one of the regular expressions in the
response_translations.list file. The Diagnostic-Code is the same format as SMTP server responses, so the same translation file is used.

When a match is found, the bounce processing engine will use the corresponding code when reporting that event.

ASYNCHRONOUS ERRORS WITHOUT DNS MIME PART (BOUNCES)

In the case of asynchronous errors that do not include a valid DSN MIME part as defined in RFC 1891, the bounce processing engine will attempt to extract a standard response string from the text body part of the returned message. If this is successful it will attempt to match this response string to one of the regular expressions in the
response_translations.list file. If it is unsuccessful at locating a response string in the text body part of the returned message, the bounce processing engine will attempt to match the text body part of the returned message to one of the regular expressions in the textbody_translations.list file.

When a match is found, the bounce processing engine will use the corresponding code when reporting that event.

Any code may be used when creating a translation rule, with the exception of 0-999 and 9999 which are reserved by SocketLabs and will be used to indicate one or more error types which prevent Hurricane Server from attempting delivery, such as a malformed email address or in the case of 9999 to indicate that the specific failure did not match any of the translation rules.


Modifying, Adding or Customizing Failure Codes


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.