To get to this page, to to Services → SMTP Server → Spam Reduction
DKIM & DomainKeys
The first part of this tab indicates whether the VPOP3 SMTP Service should digitally sign sent messages using the DKIM and/or DomainKeys systems.
DKIM is the current standard. DomainKeys was a previous system so should probably not be enabled unless you specifically need it. (It won't cause any interoperability problems, but it is probably pointless).
DKIM (and DomainKeys) add a digital signature to the message header which the recipient can use to check that the message has not been altered since it was sent. This will typically sign the message contents and important headers such as Subject, From, Date, etc.
Note that if the message passes through any other software which may modify the message after it has been signed by VPOP3, then that may cause the digital signature to fail, which may mean your messages are rejected. The type of software which may do this are some viruses scanners (which may add a 'scanned by XYZ Antivirus' line to the bottom of the message, for instance) or mailing list distribution software.
To use DKIM (or DomainKeys) you first need to generate a DKIM key pair. You publish the public key in your DNS, and put the private key in a PEM file in the VPOP3 installation directory called 'domainkey_<domainname>_<selector>.key'.
For instance, if you are sending mail from 'example.com' and have chosen the selector 'key1', you would save the private key in a file in the VPOP3 directory called 'domainkey_example.com_key1.key'.
The 'selector' is just a simple name you choose, which allows you to change the key without invalidating previously signed messages. If you change the key, you will choose a new selector, tell VPOP3 to use that, and leave the old selector's DNS entries online for a while so that messages in transit will still be able to validate using the old selector.
There are lots of resources online about DKIM key generation. If you search for 'DKIM key generator' you should find web pages that will generate the public & private keys in PEM format and tell you how to publish the public key in your DNS server.
When people send messages through VPOP3 it will look for a KEY file for the appropriate domain of the sender and use that. If such a file doesn't exist, then the message won't be signed.
Greylisting
Greylisting is an anti-spam technique where the server (VPOP3) temporarily rejects incoming SMTP messages. Legitimate mail servers will handle this seamlessly and will retry sending the message again later. VPOP3 will remember that the same mail server has tried to send the same message earlier, so it will accept the message the second time and remember the sending server is OK. Much software which sends spam will not retry the message, so the spam will disappear, so this simple technique can help to reduce spam quantities. It will lead to a short delay the first time someone sends a message to you, but it will not delay regular correspondence.
The Wikipedia article on Greylisting has more details on the process.
One of the problems with Greylisting is that it requires the same server as originally tried to send the message to be the server which retries the message later. In the vast majority of cases this is what happens, but some mail services have large farms of mail servers and don't manage them so that the same server handles the retries. This means that it may be a different server which tries to send the message the second time. VPOP3 will again delay that, because it sees it as a new message, and so on. Google's mail service is one of the prime examples of this. The Customise Greylisting option lets you configure IP addresses or sending domains which will not be Greylisted.
Starting in VPOP3 v6.20 there is another option which may be useful - the Skip Greylisting if SPF check passes option. If this is checked, then if the SPF check (see below) results in a Pass, then the Greylisting will be skipped. This is usually OK because the main spam sources which will be defeated by Greylisting are 'spam bots' which will not usually pass SPF checks.
If you want, you can specify text in the ...with one of these SPF domains box. Each line will be compared with the domain name for the SPF check which passed. If it matches then Greylisting will be skipped, but other SPF passes will still trigger Greylisting (if the box is left blank then all SPF passes will skip Greylisting). For instance, domains which use Google Apps should use the SPF domain _spf.google.com, so if you put "_spf.google.com" in the text box anyone using Google Apps with a correctly configured domain should skip Greylisting.
The ...with one of these SPF domains box needs each domain entry to be on a line of its own, and * & ? wildcards are allowed.
Realtime Blacklist Rules
Realtime blacklists are databases which use DNS to identify 'bad' IP addresses which send mail. VPOP3 will query the blacklists whenever an incoming SMTP connection occurs to decide if it should accept mail from that IP address. There are many, many different blacklists. You can use the Edit Realtime Blacklist Rules button to edit which blacklists VPOP3 uses. We don't recommend that you use a lot of blacklists or it can slow things down too much.
SPF
SPF (Sender Policy Framework) is a way of publishing in your domain's DNS records which IP addresses are allowed to send mail from your domain. This can be used to help the recipient know that the message really came from the sender it claims to have been sent from.
It is normally trivial for an email sender to pretend to be someone else, which can cause security problems if a malicious person pretends to send messages from your bank or manager. It can also cause problems with 'backscatter' or your company's reputation if they send spam using your email address as the sender. SPF allows the recipient to check that the message came from an 'authorised' mail server.
SPF records are set in your DNS, not in VPOP3. There are websites which will help you configure your SPF record. If you send mail through an ISP's mail server, then your ISP should be able to tell you which SPF record to use.
You should not have VPOP3 performing SPF checks on incoming mail if you receive incoming mail but it comes via another company's mail server (eg your ISP or a mail filtering company) because that will cause all the SPF checks to fail. Instead that other mail server should perform the SPF checks and react accordingly.
The SPF Whitelist allows you to bypass the SPF checks for known senders who have their SPF record configured incorrectly.
An SPF check will result in several different possibilities:
•None - there is no SPF record defined for the sending domain
•Pass - the SPF record indicates that the sending IP address is allowed to send from this domain.
•Fail - the SPF record indicates that the sending IP address is not allowed to send from this domain.
•Neutral - the SPF record doesn't indicate whether the sending IP address is good or bad. Often this is used when testing SPF.
•SoftFail - this is between Fail and Neutral. Often this is used when testing SPF. The message should be accepted but may be treated as more suspicious by a spam filter.
•TempError - this is usually caused by a DNS error at the recipient or sender end
•PermError - this is usually caused by a configuration error in the SPF record (eg invalid commands)
Reject message if SPF check result is
Starting in VPOP3 v6.20 you can tell VPOP3 to immediately reject messages if the SPF check fails in some way.
VPOP3 can be configured to reject different sets of results. It is not recommended that you reject SoftFail results, but this option is available if you wish.
TempError results will be rejected with a temporary error, telling the sender to try again later.
The None option means that VPOP3 will never reject mail based on SPF checks.
Also, if you are using the VPOP3 Spamfilter, there are various 'SPF' spam filter rules which can lead to mail being quarantined if it fails SPF checks.
