ORF can perform different actions when an email fails on a blacklist test. These actions can be configured on the page.
Specify a default action for all blacklist tests which will be used when there is no explicit action assignment for a blacklist test.
Click the three-dots (...) button next to the name of each test to assign a custom action to the selected blacklist test.
ORF provides five blacklist actions. These actions are performed when the email is blacklisted, e.g., due to a DNS blacklist or keyword filter hit.
You can choose to reject the email on blacklist hit, or accept it and perform further actions, like tag the email subject, tag the email header, or redirect the blacklisted email to a specified email address. The latter three actions can be combined (e.g., you can tag the subject and redirect the blacklisted email at the same time). The fifth action allows you to run the blacklist test in test mode and monitor its effectiveness using the Log Viewer and the Reporting Tool.
The above actions do not apply to the Attachment Filtering, the Recipient Blacklist, the Recipient Validation, DHA Protection and the External Agents tests. The Attachment Filtering test has its own actions, such as to replace the attachment with a warning text or drop the entire email. The Recipient Blacklist, Recipient Validation and DHA Protection tests work with recipients rather than emails, so different actions are used (e.g., it would be problematic to tag the email subject and deliver the blacklisted email to the intended recipient when the recipient does not exist). The External Agents feature gives you a finer control of the actions.
If you decide to reject the email, senders will get notified about the failed delivery, because their email server will send a bounce report to them.
Rejecting the email at an early stage of the SMTP transport saves system resources, but some information may not be available for logging before the email arrives. Set this checkbox to wait for the email subject and MIME Message-ID to arrive before dropping the email. This can be helpful when you have to find a rejected email in the logs.
This feature is automatically enabled and hardcoded for content-based tests, such as the Charset Blacklist, Keyword Blacklist, External Agents, SURBL Test, DKIM Test and DMARC Test.
Enable this option to terminate the SMTP connection after returning the configured SMTP response (only if the email was rejected).
Some spam software attempt to send the email regardless of the SMTP responses. Though they do not succeed, they waste bandwidth. By closing the SMTP connection you can stop these software from continuing the SMTP conversation.
The SMTP standards do not specify clearly what the sender server should do if the connection is closed unexpectedly after an SMTP response indicating an error. Some email servers may interpret it as a temporary connection error and retry email delivery later. Some others may process the SMTP response and do not retry delivery.
Click the SMTP Response button to edit the SMTP response returned to the sender server upon rejection. The response will be included in the Non-Delivery Report (NDR) generated for the actual sender, so they will be notified about the exact reason of the rejection. More about SMTP responses is available in the SMTP Responses section of the help.
In contrast with rejecting the email, if you decide to accept the email and perform further actions, the selected action(s) will be performed on blacklisted emails. Senders will not get notified about these actions, as their emails are not rejected.
When this action is selected, the blacklisted email is accepted, but the subject line is tagged with a customizable text (Subject Tag), either on the left or on the right side (Tag on the left / right side).
As the email is accepted, no bounce report is generated. The recipient can use automatic email rules to move the tagged email to a separate folder, e.g., Spam (both Microsoft® Outlook® and Outlook® Express support these kind of rules).
The subject tag is Unicode-supported.
You can combine this action with tagging the email header and email redirection.
If you have Exchange 2007 x64 or above, you can use subject tagging to redirect blacklisted emails to the Junk folder of each recipient for further review. For more information, read our article.
Select this action to accept the blacklisted email and add a custom tag to the email header. As the email is accepted, no bounce report is generated. The recipient can use automatic email rules to move the tagged email to a separate folder, e.g., Spam (these kind of rules are supported by Microsoft® Outlook®, but Outlook® Express cannot check the email header for rules). You may add the {TESTNAME} special field to the header tag (click the right side of the header tag box), which will be replaced by the name of the actual blacklist test that triggered the filtering action.
You can combine this action with tagging the email subject and email redirection.
Select this action to accept the blacklisted email and redirect it to another recipient. As the email is accepted, no bounce report is generated. The original recipient does not get the email (except if the recipient is the redirection address, of course).
You can combine this action with tagging the email subject and the header.
When this action is selected, the blacklist hit is recorded but the evaluation of the email continues with the rest of the enabled blacklist and whitelist tests.
Note that this option is meant for troubleshooting and fine-tuning individual blacklist tests and it does not reflect how the email evaluation process actually works (normally, filtering stops when the status of the email is determined). If you want to evaluate ORF, enable Demo Mode on the page instead.
Run the blacklist test at its normal place to see how it would perform normally or choose the before whitelists option if you want to test for false-positives or measure the effectiveness of a filter on its own.
Tarpit delay holds back SMTP responses sent by ORF upon blacklisting. As the sender server has to wait for each response, you can use this feature to "fight back" spammers by slowing them down or to make it virtually impossible for them to carry out a successful Directory Harvest Attack (DHA).
For more information, please see the Tarpit Delay Settings section.
If ORF is deployed behind other servers, make sure that Tarpit delay is disabled, otherwise you will "punish" your own front-end when delaying SMTP responses.
When ORF is running in Demo Mode, it works exactly the same way it would in "normal" mode, except no email blacklist actions are actually performed. Emails do not get rejected, tagged or redirected, but the blacklist test results are logged and can be monitored using the Log Viewer and the Reporting Tool. In other words, by using Demo Mode you can check what ORF would have done to incoming emails without affecting the flow of incoming emails.
Set the Enable Demo Mode check box to enable Demo Mode.