Rounded Top
Password Hint If you have not signed in recently, your password may be your Customer ID. Check your email archives for your Customer ID or reset your password.

How to blacklist self-spam?

Self spam example

Introduction

Spam sent with the same sender and recipient address is nothing new—however, a recent spam campaign does this forgery in large numbers and with surprising success in bypassing the filters.

This article discusses the remedies that ORF offers against this type of self-spam.


Solutions

ORF offers three solutions against self-spam, each of them capable of stopping the entire campaign. Before implementing a solution, make sure to review the Whitelist Issues section of the article. Regardless of your choice, we also recommend that you publish an SPF policy (which is itself Solution #2, by the way).

Solution #1: an External Agent

Vamsoft Self-Spam Protection Agent
selfspamagent.zip / 3kB / January 13, 2009
Vamsoft Self-Spam Protection Agent for ORF v2.1 and later. Follow the instructions of readme.txt from the package.
Download

The most direct approach is using an External Agent. This agent is a simple script that compares the sender address against the recipient address list and if they match, blacklists the email. The source code also demonstrates how agents can be written in JavaScript or VBScript.

  • Benefits: Simple; Can be installed in five minutes; Very low chance for false positives.
  • Drawbacks: Increases processor utilization a little.

Solution #2: Publishing an SPF Policy

SPF Explained

SPF on Wikipedia (external link)
openspf.org (external link)

SPF Tools

Vamsoft SPF Syntax Validator
Vamsoft SPF Checker

An SPF policy is a declaration of what hosts are authorized to send emails in the name of your domain. SPF-capable servers (like your server with ORF) can evaluate emails against the policy of the sender domain and thus identify and blacklist forged emails. It is the least direct approach of the three, but has the benefit of not only stopping self-spam, but reducing the forgery of your domain.

Publishing an SPF policy is usually very simple: if you have a single inbound/outbound server only, all it takes is adding a new TXT-type DNS record to your domain with the text v=spf1 mx -all. This tells the world that only the server(s) listed in your MX record may send email in the name of your domain.

When publishing an SPF policy and enabling the SPF Test (Filtering / Tests page in the ORF Administration Tool), you should be absolutely sure that all outbound emails are whitelisted in ORF. See section Whitelisting Outbound and Authorized Emails for more information.

  • Benefits: Gives you back the control of your domain; Makes the Internet a safer place; Can reduce or eliminate "backscatter" (bounce report flood caused by a spammer sending forged emails in your name – by the way, we also have an agent against this).
  • Drawbacks: Usually takes more than five minutes to implement; Breaks a few services that are actually sending forged emails, such as poorly implemented online email postcards, "send this article" links, web forms, and, in rare cases, automated email forwarding; Increases email check time by a few seconds.

Solution #3: Blacklisting your own domain

By blacklisting your own domain using the Sender Blacklist of ORF, you are basically telling ORF that you do not expect emails in your name from unauthorized senders outside of your organization. This is usually the case. The same considerations apply as in the case of an SPF policy: you have to be absolutely sure that everyone authorized is whitelisted (read more).

To blacklist your domain, launch the ORF Administration Tool, select Blacklists / Sender Blacklist and add *@yourdomain.com.

  • Benefits: Takes a minute to implement; Can reduce email check time.
  • Drawbacks: Same as with Solution #2 SPF - Breaks a few services that are actually sending forged emails, such as poorly implemented online email postcards, "send this article" links, web forms, and, in rare cases, automated email forwarding.

Again, no matter what solution you choose, adding an SPF policy to your domain benefits not only you, but the entire Internet, so it is a responsible decision.

Notes

Whitelisting outbound and authorized emails

There are two scenarios when an email is actually expected to arrive to your server in your name: when it is an internal email and when it is being submitted for relaying. Typically, you have nothing to do to whitelist these emails, because:

  1. ORF whitelists authenticated SMTP sessions and relaying is typically controlled by authentication. This whitelisting is enabled by default, but in any case check that the Authentication Whitelist test is enabled under Filtering / Tests and it is assigned to both filtering points.
  2. ORF whitelists emails originated from the intranet. This is when you see the message "Email whitelisted (email from a trusted intermediate host or intranet)." in the log.
  3. ORF usually does not see internal email, because it filters the SMTP traffic only and Outlook + Exchange communicate with each other using a different protocol, MAPI.

However, if you have any emails that are not covered by the above three rules (e.g. you control relaying by IP instead of SMTP authentication), you will have to whitelist these authorized sources, e.g. by using the IP Whitelist. Here are a few examples of scenarios not covered:

  • Although rare, some organizations allow employees to use their home ISP mail servers for sending email with their business email address. This is actually forgery and relaying with SMTP authentication will fix the problem without extra whitelisting.
  • When ORF is used on a front-end in the DMZ, it is a good idea to add the back-end server IP address to the IP Whitelist, especially if users outside the organization use the back-end server for relaying, because in this case the email may not be covered by Rule #2.

Whitelist issues

If your domain is whitelisted, none of the above solutions work. As whitelists take precedence over blacklists, this type of spam will get through. There are two typical cases:

  • Your domain is on the Sender Whitelist. Just go to Whitelists / Sender Whitelist and remove your domain.
  • Your domain is on the Auto Sender Whitelist, due to a configuration problem. As a workaround, do one or both of the following under Whitelists / Auto Sender Whitelist settings:
    • On the Check Exceptions tab, add your domain (*@yourdomain.com) to the check exceptions. This requires at least ORF 4.2.
    • On the Mode tab, switch the ASWL into Customized Per Recipient mode.
    Note that this was a workaround, you have not fixed the configuration problem yet.

    To understand how your domain ended up on the ASWL in the first place, consider what the ASWL does: it monitors your outgoing emails to build a whitelist. It assumes that someone you send an email to is not likely to spam you. Technically, what ORF monitors are the outgoing connections (i.e. SMTP connections initiated by your server) and collects sender/recipient information from these. Normally, ORF sees that an internal sender is sending to an external recipient. However, when your server forwards inbound/internal emails to another server (e.g. a front-end smart host in the DMZ), ORF will see that an external user is sending to an internal user, or an internal user is sending to another internal user. In the default ASWL mode, ORF whitelists the recipient of an outbound email for everyone (Global mode), so this is what happens when forwarding:
    • Your server forwards an inbound email from a@someotherdomain.tld to b@yourdomain.tld.
    • ORF thinks it is an outbound email and adds sender/recipient to the ASWL.
    • When email arrives from the outside from a@yourdomain.tld, ORF checks the Auto Sender Whitelist and sees that an email was sent to b@yourdomain.tld, thus b@yourdomain.tld as a sender causes the email to be whitelisted for everyone. This is why switching ASWL to Customized Per Recipient mode works, because email from b@yourdomain.tld will be whitelisted only if the recipient is a@someotherdomain.com and that will not be the case.
    Such forwarding scenario is common and thus by default ORF will not collect ASWL data if the connection is going to a server with an intranet IP address. If the receiving server has a public IP address, you will have to add that to the exceptions manually (Collection Exceptions tab, IP-based Exceptions).

Other campaigns: MIME sender spoofing

While the given recent spam campaign can be blacklisted as described above, other campaigns we have seen in the past spoof only the so-called MIME sender and these require a different blacklisting technique. You can implement this technique as prevention or when needed.

To understand how MIME spoofing is different, consider that email addressing is similar to real-life postal email addressing. Just like the post office delivers to the address on the envelope, emails are delivered to the envelope recipient. When mails or emails bounce, the mail or email is returned to the sender on the envelope, no matter what address is on the paper inside the envelope. Now, the sender and recipient addresses that you see in your email client are like the addresses inside the envelope. These are the MIME sender and MIME recipient and can be different from the envelope (SMTP or P1) sender and recipient.

ORF works with the envelope sender and recipient information, so if the spammer spoofs the MIME information only, the above solutions that use the envelope addresses will not work. If you check the ORF logs and you find that Outlook says a different sender than the log, it is MIME spoofing.

As MIME address information travels in the email header, you can blacklist these self-spam emails by a header filter on the Keyword Blacklist (available from ORF 4.1). The keyword filter can be added on the Blacklists / Keyword Blacklist page of the ORF Administration Tool. Click New, select search scope Email header (raw MIME). Select the Filter expression tab, set the expression type to regular expression and enter the following expression:

.*^From:[^\r\n]*\b[^\r\n]*@yourdomain\.com\b[^\r\n]*\s$

Make sure that when replacing "yourdomain\.com" with your actual domain, "escape" all dot characters with "\.", e.g. "mysubdomain.domain.com" will become "mysubdomain\.domain\.com".

TipFor more tips on fine-tuning ORF, check the Best Practices Guide.