We 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 »
Web Beacons (a.k.a Tracking Pixels) are images in HTML-formatted email messages that, when viewed, tell the sender of the message that you read it. This mechanism of obtaining essentially covert confirmation that (a) your email address is valid, (b) the email got past your filters, and (c) you actually read the message, is pervasively used by Spammers to identify what addresses are reading their messages. It is also used by email marketers to hep them measure the success of their email campaigns. 
