Most of today’s SPAM comes in with a variety of hooks, the most dangerous being those looking to steal data and account credentials. Because criminals know that the weakest link is the human, it should be no surprise that SPAM continues to be one of the biggest issues facing many enterprises.
Sender Policy Framework aims to stop spam in its tracks. How successful has it been?
IT shops have thrown everything but the kitchen sink at the issue and more times than not, come up empty on long-term solutions. Lately we’re hearing a good deal about Sender Policy Framework (SPF) as the answer to our SPAM woes. Is it?
Nearly all abusive e-mail messages carry fake sender addresses. The victims whose addresses are being abused often suffer from the consequences because their reputation gets diminished and they have to disclaim liability for the abuse, or they waste their time sorting out misdirected bounce messages. Worse, a financial loss can be devastating to an organization should its domain end up on a black list because of SPAM runs done via a successful phish of a user account or the discovery of an open relay.
You probably have experienced one kind of abuse or another of your e-mail address in the past — e.g., an error message saying a message allegedly sent by you could not be delivered to the recipient, although you never sent a message to that address. SPF sets out to solve this problem and significantly mitigate SPAM.
So How Does It Work?
SPF is an open standard specifying a technical method to prevent sender address forgery.
SPF is the protocol-level identification of the delivering mail server, and it is usually invisible to recipients. It is mirrored in the Return-Path header, the address to which mail delivery errors (or bounces) are sent. For individual e-mail addresses or small domains, it may sometimes be set to the user’s e-mail address. But for larger and more professionally managed domains, it is usually a domain related to the mail server that sent the message.
SPF protects the envelope sender address, which is used for the delivery of messages. This allows the owner of a domain to specify its mail-sending policy by specifying which mail servers are used to send mail from the domain. The technology requires two sides to participate: The domain owner publishes this information in an SPF record in the domain’s DNS zone, and when someone else’s mail server receives a message claiming to come from that domain, the receiving server can check whether the message complies with the domain’s stated policy. If the message comes from an unknown server, it can be considered a fake.
Continue reading this article at Enterprise IT Planet.