" sender policy framework Archives - LuxSci

Posts Tagged ‘sender policy framework’

DMARC: The State of Domain-based Email Authentication – Part 2

Monday, September 11th, 2017

Building a safer email ecosystem with DMARC

In our previous post, we described two techniques for authenticating an email sender:

  • Sender Policy Framework (SPF), IETF RFC 7208, which verifies if the sending MTA is indeed authorized to send mail on behalf of a domain; and
  • DomainKeys Identified Mail (DKIM), IETF RFC 6376, where a domain shows “ownership” of a mail it sends by signing portions of it so that critical aspects cannot be forged by intermediaries.

Like most technologies, these are just individual weapons in the arsenal for fighting phishing and spam. Weapons, like all tools, need to be properly used if they are to be effective. Unfortunately, as we described in the earlier post, both SPF and DKIM are deployed in a manner that reduces their usefulness. With SPF, the validation policy set by the sender is often chosen in a manner that leaves handling authentication failures at the discretion of the recipient. DKIM, on the other hand, does not even have an explicit policy directive set by the sender. Moreover, in a heterogeneous mail environment, some perfectly legitimate MTAs might not be capable of signing messages.

Building a safer email system with DMARC

Thus, receivers in actual deployments tend to “soft fail” any SPF and/or DKIM validation failures as there are reasonable situations when legitimate mail can fail such checks. A common example is forwarded mail (which fails SPF), or mail sent via a mailing list (which fails DKIM). Mail providers consider it better to deliver most mail (even if some are fake or spammy) rather than risk dropping legitimate mail. Thus, neither of these techniques individually or combined provide clear guidance to receivers, and the resulting actions can be inconsistent.

Read the rest of this post »

Stopping Forged Email 1: SPF to the Rescue

Tuesday, February 17th, 2015

SPFWe have recently looked at how hackers and spammers can send forged emails and then seen how these forged messages can be almost identical to legitimate messages from the purported senders. We learned that generally, all you can trust in an inbound email message is the internet IP address of the server talking to your inbound email server. This cannot realistically be forged in any way that would still enable you to receive the message.

We know who the message is from and the server’s address that delivered it to us. How can we reliably prevent fraud by checking if the message was forged or not? Seems hard.

It turns out that a number (yes, more than one!) of techniques can be used to do this. The first and simplest is SPF – Sender Policy Framework. Below, we shall look at what this does, how it works, how to set it up, and what some of its deficiencies are. In future articles, we will look at the other techniques.

Sender Policy Framework: A Super Simple Explanation

Simply put, SPF is a way for the owner of a domain, such as bankofamerica.com, to publish information indicating what servers (internet addresses) are authorized to send email from that domain. Recipients (e.g., your spam filtering software) can check the internet address that is trying to send you an email from bankofamerica.com against this authorization list- if it is on it, the message is probably legitimate; if not, it’s probably forged.

Read the rest of this post »

Bounce Back & Backscatter Spam: Who Stole My Email Address?

Tuesday, September 24th, 2013

spamSo, you’re minding your own business, going about your daily tasks, checking your email, and suddenly your INBOX is flooded with a series of non-delivery reports (aka NDRs or bounce messages). But wait just a minute, you didn’t send these. How did this happen? Did someone steal your email address?  How is that possible?

What has most likely happened here is that you’ve fallen victim to “backscatter“, or as it’s commonly known, bounce-back spam. As spam-detection techniques have evolved and become more accurate, the spammers have been forced to devise increasingly complicated and devious methods of getting their messages delivered. For example: email forgery.

Read the rest of this post »