UPDATE: Check out the second part of this article.

In the past few days, new spam campaigns launched that use the ages old trick called “self-sending spam”, which is about sending spam to you in your name. Spammers probably hope to circumvent your spam filtering with this, and, surprisingly, they often succeed, because people tend to put their own email domain on the whitelist.

What we want to suggest in this article is doing the opposite: blacklisting your own domain. If you add *@example.com to the Sender Blacklist, you are defeating spammers easily by turning their own weapon against them. If we assume that all emails legitimately sent in your name are whitelisted in ORF, we can also tell that the rest is not legitimate and thus shall be considered spam.

So how do we know that all legitimate emails are whitelisted in ORF? Here are few things to be considered.

ORF only “sees” emails arriving via incoming SMTP connections. A legitimate scenario when email is sent in your name is when it is outbound. If ORF is installed on the Exchange server, you have probably Outlook clients. These use MAPI to submit outbound emails to Exchange, so there is no incoming SMTP connection and ORF will surely not blacklist these emails, because they are not “seen”. So, if you have a single Exchange server only, ORF runs on that Exchange server and you have Outlook clients only (in Exchange mode), you have nothing to do.

Relaying must be whitelisted. Still the outbound scenario, but with SMTP relaying. In this case, the SMTP client (Outlook in Internet mode, Outlook Express or another internal server) will use SMTP to submit an outbound email to the server where ORF runs, which in turn will deliver the email to the final, external recipient’s server. These connections are seen by ORF and must be whitelisted.
Relaying is controlled either by granting relay rights to IP addresses, or by using SMTP authentication. If you control relaying by IP address, the address of these relay-granted hosts should be added to the Intermediate Host List of ORF (Configuration / Global / Intermediate Hosts).
When using SMTP authentication, make sure that the “Exclude authenticated clients from filtering” checkbox is set on the Configuration / Global / Miscellaneous page. This is the default setting, but in any case, check it.
The above will take care of whitelisting relaying. If relaying is controlled by IP and adding the Intermediate Host List does not help, you can also try adding the IP to the IP Whitelist, although we recommend switching to SMTP authentication more.

Unauthenticated emails. Note that the above will not play well with some solutions that try to send in your name, without using your servers. Typically, websites with “Send this page to…” functionality tend to be broken by this, because they are not authorized to send in your name. When possible, reconfigure these solutions or whitelist them.

SPF. Using SPF can be a good alternative to blacklisting your domain. By publishing an SPF policy, you tell the world what hosts are authorized to send emails in the name of your domain. If you have a single inbound/outbound server only, or all your outbound servers are listed in your MX record, publishing an SPF policy is as easy as adding a TXT DNS record to your domain with “v=spf1 mx -all”. This will tell the world that only the hosts listed in your MX record may send emails in your name. As ORF has an SPF test, it can check inbound email against your policy and if it denies the sender server (in case self-sending spam, it will), the email will be blacklisted right away. You can learn more about SPF at Wikipedia or openspf.org and use our SPF Check and SPF Syntax Validator tools. Note that with SPF, you can expect the same problems as described in “Unauthenticated emails” above.

Auto Sender Whitelist issues. We got a couple of tech support requests where even though the domain was blacklisted, the incoming email was whitelisted by the Auto Sender Whitelist. In this case, you have the following options:

• Add your domain to the Auto Sender Whitelist Sender Check Exceptions (Configuration / Tests / Auto sender whitelist, click Settings, select “Check Exceptions” – from ORF 4.2 only)
• Disable the Auto Sender Whitelist
• Clear the Auto Sender Whitelist and fix the problem that led to this (see below)
• Manually remove the related ASWL entries (External Database only, using SQL administration tools) and fix the problem that led to this (see below)

Typically, internal addresses do not end up on the ASWL. When ORF is used on a front-end, in a pre-Exchange 2007 environment, configuration errors may lead to such problem, however. It is because ORF records sender/recipient data of all outgoing SMTP connections (that is, those connections initiated by the local server). When running on a front-end, these include connections used to relay incoming emails to the back-end server. ORF multiple default exception settings to prevent recording this type of relaying, but the best is still to add the back-end server address to the IP-based exceptions (Configuration / Tests / Auto sender whitelist, click Settings, select the Collection Exceptions tab and edit IP-based Exceptions).
Also, you may want to switch the ASWL into “Customized per recipient” mode, in the same dialog. This will prevent using the whitelist entries from someone else.