This help section describes the Greylisting feature and the related settings available under the page in the left navigation pane.
Greylisting is a powerful self-learning anti-spam technique. It is based on temporary rejection of emails from "unknown" senders (by returning an SMTP response which indicates a temporary failure). Per standards when a sender encounters such temporary rejection it must re-attempt the delivery later. If it does, the second attempt is allowed through Greylisting. If it does not, the email will not be delivered.
Since spammers usually give up after the first attempt, Greylisting offers an excellent spam catch rate, but it also causes about 15 minutes delay of incoming emails from legitimate senders, as their emails also get temporary rejected first.
Let's assume [email protected] sends an email to [email protected]. ORF records the sender IP, the sender and recipient addresses, and the time of the attempt in a database. This database record is called a triplet. It also tells your server to return an SMTP response to the sender server indicating the delivery failed due to a temporal problem.
The sender server acknowledge the failure and waits. The time spent waiting entirely depends on the server sender: Microsoft® Exchange servers re-attempt the delivery in 15 minutes for the first time, but other type of email servers may choose a different re-attempt wait time. Finally, when the sender resubmits the email for delivery, ORF will check the Greylisting database, finds the triplet and recognizes it is a re-attempted delivery, so the email is allowed through Greylisting.
Enable or disable the Greylisting test by clicking the ON / OFF button on top of the page, or on the page.
Configure how the Greylisting database records should be stored. See the Database Settings Dialog topic for more information.
The original Greylisting specification accepts the repeated delivery attempts as "known" only if they are coming from the same IP address. When this option is enabled, however, attempts will be accepted if they are coming from the same /24 (IPv4) and /64 (IPv6) subnet. This helps to avoid repeated temporary rejection problems with senders that have a pool of outgoing email servers (see Notes below).
Set how long ORF has to reject emails from unknown senders. When this limit is reached, unknown senders become "known" and the email is accepted. See the Notes section for more information.
Controls the number of hours for data expiration. The larger this value, the larger the database will grow.
Enable this option to skip the Greylisting Test if the sender publishes an SPF policy and the SPF evaluation ends with SPF "pass", i.e., the sender IP address is explicitly authorized to send in the name of the sender email address domain.
Some email servers, most notably Exim and Postfix, perform so-called Sender Callout Verifications, which is a controversial anti-spam technique. The verification is performed when the server receives email from someone. During the verification, the recipient email server connects back to the sender server and initiates an email sending process to check whether the sender email address is valid. This verification process may conflict with servers using Greylisting, because the verification may fail due to the temporary rejection caused by Greylisting and your outgoing emails will bounce back.
Moreover, some mailing list software use unique sender email addresses for each email they send, in order to track bounces. This can cause conflicts with Greylisting as the sender never gets "known". You may experience similar problems with senders using backscatter detecting solutions like Bounce Address Tag Validation (BATV), and forwarding servers using SRS, as the sender address will differ for each attempt.
To avoid the problems described above, you can add the sender email address used by the verification to the exception list. The list contains the Exim and Postfix verification addresses and exceptions for BATV or SRS rewritten sender addresses by default, it is strongly recommended keeping these.
Use this to verify whether the sender is actually authorized to send emails on behalf of the domain it claims to represent and not just spoofing it to bypass filtering: If the sending domain has a published SPF policy, the email must "pass" the SPF evaluation to be excluded from filtering.
The Recipient Exception List is for excluding specific mailboxes or domains from Greylisting-based filtering. This can be useful if you have mailboxes that must accept email immediately, without the delay caused by Greylisting or if some of your domains do not want to use Greylisting.
Add the IP address of servers that are incompatible with Greylisting to this list.
Greylisting works with so-called triplets (combinations of the sender IP, the sender email address and the recipient email address). Email delivery attempts from the same sender and IP address to multiple recipients will create multiple triplets, so even if [email protected] sent an email to [email protected] in the past, his attempt to email [email protected] will get rejected temporary by Greylisting, as the recipient address differs.
If the sender has multiple outgoing servers, it is not guaranteed the re-attempted delivery will come from the same IP. In such cases, ORF will not recognize that this is a re-attempt: it will create a new triplet (see the above explanation) and greylist (temporary reject) the sender again. The more servers the sender has the more times the attempt will get rejected again and again, causing unusually long delays in delivery or no delivery at all (as the sender will give up eventually).
To work this around, you can
but unfortunately there is no bulletproof solution for this problem (e.g., you do not know the sender, they have no SPF policy published and their servers are not on the same subnet).