How to blacklist self-spam?

Introduction

Spam sent with the same sender and recipient address is nothing new. In this article we will discuss what you as an administrator and ORF can do against these so called "spoofed" emails that appear to come from your own organization or someone you trust.

What is email spoofing?

Email spoofing is when someone forges the sender email address in an attempt to fool the recipient into believing that email is from a trusted source, such as your own or another reputable domain. This is a very common spam and phishing technique, made possible by the lack of any authentication mechanism of the core email protocols.

What can you do about it?

The very first thing you ought to verify is whether your domain has a published SPF record. An SPF record is a TXT-type DNS record published by the domain administrator in the DNS zone file that states which hosts and IP addresses are permitted to send emails on behalf of the domain. It can be viewed by running the nslookup -type=txt example.com command from the command line, where "example.com" is your domain. If no TXT record is returned that starts with "v=spf1 ...", that means your domain name and its reputation can be freely abused by any person with ill intentions.

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

In case you have multiple outbound servers that are not covered by the MX record (e.g. emails are sent from your webserver or you use 3rd party services to deliver marketing emails in the name of your domain), then you will have to create a custom SPF record to include them. In that case, you should familiarize yourself with the SPF record syntax or use an online SPF record generator to create the appropriate policy.

Finally, make sure the SPF Test is turned ON in the ORF Administration Tool (Filtering > Tests).

Important

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

Still receiving emails spoofing your domain?

It is probably time to talk about a lesser known fact about emails. Namely, that an email can have two sender addresses:

The first one is called the (RFC5321.MailFrom) Envelope Sender Address, which remains hidden from view and is used by mail servers during the SMTP transmission. This is what ORF and your mail server logs and also what the SPF Test validates. It is also the address to which any undeliverable message notices, or bounce messages, are sent. You may find this address in the "Return-Path:" field of the message header. If we were to use an analogy, this is the sender address that you would write on an envelope for the post office to return your letter to in case it cannot be delivered for some reason.

The second one is called the (RFC5322.From) Display From Address, which is displayed by the email client (e.g. Outlook) when the recipient opens the email. This address cannot be and is not meant to be validated by the SPF Test (more on this below). This address can be found in the "From:" field of the message header. To continue the previous analogy, this would be the address of the actual author which would appear in the letterhead.

So how can we validate the Display From Address, since that is the email address which the recipients actually see?

Publish a DMARC policy for your domain

DMARC is an email authentication protocol that builds on SPF and DKIM and can successfully thwart scam and phishing attempts. Emails that appear as though they were authored by someone from a domain protected by DMARC must pass the SPF and/or DKIM tests, and – and this is the key part – the domain identifier used for the SPF/DKIM verification must match the domain in the Display From Address.

To verify whether you domain has a published DMARC record, run the nslookup -type=txt _dmarc.example.com command from the command line, where "example.com" is your domain. Unless you receive an answer TXT record starting with "v=dmarc1 ..." you will need to create and publish a DMARC record for your domain.

Similarly to SPF, this is done within the DNS registrar of your domain by adding a specific TXT record under _dmarc.example.com where "example.com" is replaced with your domain name (or subdomain). The simplest DMARC policy you can use is v=dmarc1; p=reject or v=dmarc1; p=quarantine, which tells the world to reject or quarantine the email claiming to be from your domain if it fails the DMARC check.

More complex policies can be created manually (consult the official DMARC site) or using one of the many online DMARC policy generators.

Once you are done with the above, make sure the DMARC Test is turned ON in the ORF Administration Tool (Filtering > Tests).

Important	Do not publish a DMARC policy until you confirm that your domain has a published SPF record and/or your emails carry a valid DKIM signature. Otherwise, DMARC-enabled mail transfer agents might reject emails coming from your domain.
Limitations	DMARC does not address “lookalike” domain attacks (e.g. email coming from “exampl3.com” ), or display names abuse (e.g. when only the displayed username is spoofed, but the email address is not). To combat these kind of phishing attempts we suggest that you create the appropriate regex-type Keyword Filter expression with an "Email Header (raw MIME)" search scope in ORF.

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 page.
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 will 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 [email protected] to [email protected] .
  • ORF thinks it is an outbound email and adds sender/recipient to the ASWL.
  • When email arrives from the outside from [email protected], ORF checks the Auto Sender Whitelist and sees that an email was sent to [email protected], thus [email protected] 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 [email protected] will be whitelisted only if the recipient is [email protected] 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).

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