Share it !
From time to time, I get customer requests for assistance on stopping phishing messages that spoof the sender’s own organization.? For example, I might get mail from cliff @ microsoft.com, sending mail to myself.? As a user, I might be tricked into thinking that since this is an internal message, the message is legitimate.? Furthermore, that email address might be in my address book and therefore once it hits my inbox, supposing that it gets past my spam filter, the message is rendered using the full first name and last name of the actual person with that email address (note: that email address does not actually exist internally).
This is important in phishing campaigns because phishers will attempt to fool users by sending mail internally.? One way to combat this is using SPF records.? If you set up your SPF record with a hard fail (-all), then if anyone tries to send mail to you spoofing you, then the spam filter will look at that and because of the hard fail, will have a much greater chance of assigning the message as spam.
However, more domains on the Internet use soft fails, ~all, as opposed to hard fails.? I’ve even seen some other writers recommend the use of ~all instead of –all because if you don’t remember all the IPs that you send mail as, using hard fails hurt you more than soft fails do.? Conversely, soft fails do less damage and assure better delivery.? Microsoft, in its SenderID wizard, recommends the use of hard fails (in order to combat spoofing) but both arguments have their points.? I usually recommend hard fails if you know all the IPs that send mail as you (and most big organizations don’t know), or don’t have to worry about forwarding mail like Hotmail or Gmail.
Unfortunately, if you use a soft fail, then the spam filter will only use that as a weak input into the spam filter.? The fact is, SPF is designed to assist others in determining if your domain has been spoofed, but it functions better as a whitelisting technology.? But here’s the problem:
You don’t want your domain to be spoofed. You don’t know all of your IP addresses and don’t want mail from you to be blocked, so you use an SPF soft fail.This is a contradiction using today’s technologies.? DKIM certainly won’t help you block spoofed mail unless you use ADSP (and even then it’s not great at it), and SPF works better with soft fails.? So what do you do?
What you could do is create a one-off rule for your own domain.? I’m going to get specific to our own service, but you could do the following:
Set up SPF records for your down with SPF soft fails.Create a rule wherein you look for mail “from” your own domain and soft fails an SPF check.
Using this, outbound mail from one of your 3rd party associates like marketers will most likely make it through others’ filters since they use an SPF soft fail as a lower weight in the filter.? However, if anyone tries to spoof mail to you, the mail will be flagged as spam because it will fail the SPF check and you are blocking anyone who sends mail as you and fails that check.
The trade off here is that there exists a possibility that legitimate mail “from” you (sent by others) to the Internet might get flagged as spam.? However, that same legitimate mail, when sent to you will be flagged as spam.? So, let the buyer beware – if you want to get tighter on security and protect your own organization, you will get some false positives (probably).
Of course, if you are a high risk target, you’re probably prepared to accept that risk and the quality of the content of those messages is not that important anyhow.? If it were a legitimate mail, it would be in your SPF record and pass the check.
This is not foolproof, of course.? However, it is one mechanism that you can implement to stop spammers from taking advantage of you.
This post will contain some generic information about whitelisting, but also some specific information that pertains to our service (Forefront Online).? But the process would be similar for any email server.
Over the past couple of weeks, I have received a couple of inquiries about spam leaking through our filters.? When I examine the messages, it’s because our customers have created rules to Allow messages from a certain sender to get through the filters.? For the sake of discussion, let’s say it is UPS (ups.com) because UPS is a frequent victim of spoofing attacks.
Because UPS is such a large organization, a lot of our customer base communicates with them. This is perfectly normal and expected.? However, our customer base also is worried about missing emails from UPS.? It doesn’t matter if it is one-to-one communication (which is less likely to get filtered) or automated reports (which for some reason are always more likely to get filtered no matter which spam filter you use).? To circumvent this, customers sometimes create Allow rules – if the mail comes from ups.com, allow it to pass through without being filtered.
The problem, as I discussed above, is that UPS is a frequent victim of spoofing.? Spammers will say you have a package and include either a malware attachment or a link to a malware site.? They then send zero-day spam before it arrives on any IP blocklist.? The filter is about to execute but the customer rule says “Because it is from ups.com, skip filtering and deliver.”? The result is that malicious mail gets to the end user’s inbox.
The correct way to allow mail from ups.com is not through a simple Allow rule that operates on the sending domain.? Because mail can be spoofed, looking at the sender (either the P1 From address or the P2 From address) is not good enough.? When people want to receive mail from ups.com, they want to receive mail that is actually from ups.com, not mail that claims to be from ups.com.
So how do we do this?
The correct way to do this is to create an Allow rule that combines the sender and the results of an authentication check.? In our environment, the simplest way is with an SPF Pass.? Since an SPF check authenticates the sending domain, and because ups.com is someone you want to hear from, the Allow rule must contain both of those components.? Below is a screenshot of how you would do it in our User Interface:
Breaking it down:
The rule is an Allow rule The sender domain is ups.com The x-header to look for is Received-SPF and the value is pass.Doing it this way lets you receive mail from UPS while avoiding malicious content from spoofed senders (spam from a compromised UPS account will sail right through, however).
Some notes about this solution:
You don’t have to do an SPF check.? This would also work with DKIM validation.? Our service does not do DKIM validation but others do.? Most of the time it doesn’t matter because most domains that you want to hear from and safelist that sign with DKIM also publish SPF records. Some domains don’t sign with DKIM or publish SPF records.? In this case, you need to create allow rules on the sending IP addresses and either combine it with the sender or drop the sender altogether. Our service strips pre-existing Received-SPF headers.? If you do this on your own, if a spammer spoofs it, you must either strip it and restamp it, or use the one that your own service stamps if you don’t strip the pre-existing one (i.e, you could have multiple Received-SPF headers). If you create allow rules on sending IP addresses because the sender doesn’t publish SPF records, and the sending IP address is shared among several domains (more common for small organizations), then you run the risk of safelisting other domains that use the same IP. You can still create safe senders with no SPF checks or IP address checks, but you should only do it on a specific email address (i.e., john.example@ups.com vs @ups.com).? This makes it less likely for a spammer to guess what is on your safe senders list (a single address) vs sending from any random email address and getting through.And that’s the proper way to implement a whitelist.
