Why we should all be fighting SPAM with the SPF setting
At the moment, we are basically stuck with RFC 5322 which describes email format. Email is used by virtually every computer user, often each with multiple accounts (personal, business etc) and despite recent concerns about privacy, for some reason, the world has made lamentable progress on replacing the system with something much more secure and harder to spoof.
With SPAM, there are a couple of issues. The first is not really anything to do with the weaknesses of email and would occur if someone simply sent you an unsolicited email, either offering things for sale or perhaps offering malware or phishing. There are perhaps measures that could be taken in a future email protocol to help combat this but ultimately that would involve trust, verification, signing and a whole load of things that never sit terribly well on the web.
The second however is a very simple weakness with email and something that is perhaps more dubious from a SPAM point of view. This is when somebody sends you an email from any server in the world (which may or may not even stay alive for any period of time - it is untraceable) but in which the user has set the "from" address to something that looks genuine, e.g. admin@paypal.com and which then would probably contain information that looks like it comes from paypal. Many users would easily be fooled and could end up being fished/infected with a computer virus or whatever. RFC5322 does not provide a mechanism to ensure that the address of the user in the "from" field matches the ownership of the server that sent the email and in one sense, it would not be easy anyway. There are many reasons why a company might send emails from one server or another. Perhaps you outsource your marketing to another company and the mail is sent from their servers, perhaps you had to hire some servers while you were performing an upgrade on your own systems and perhaps the "from" address relates to someone who you want your customers to contact who doesn't work for your company.
Recently I received an email reporting to be from someone@red.com red.com sell film cameras but clearly, by not using a system called SPF, the email didn't raise any flags when it arrived in my in box - it should have.
SPF is a simple system that relies on DNS records and although not foolproof, is a good first step towards identifying SPAM. The idea is simple, if my mail client receives an email with a "from" address that contains e.g. somedomain.com, it makes a DNS request to somedomain.com and queries its SPF record (the same information should also be contained in the TXT record). This SPF record simply lists the server(s) that are permitted to send mail for somedomain.com and then provide an option to tell the client how harshly it should treat mail received from any other server. Theoretically, you can tell it to "hard fail" which means the client should instantly mark it as SPAM, you can also "soft fail" which says, "it probably is SPAM but I'm too scared to hard fail it in case genuine mail gets lost into SPAM folders".
If you use a single (private) mail server to relay your mail, this actually works really well because presumably no-one else can send mail from your server. It gets slightly more complex if you use shared mail servers (e.g. gmail or your hosting company) because naturally other people can send mail from the same servers that your SPF records authorise. This is a low risk for most people. In our case, we use GMail to relay mail and although they have lots of mail servers and many other customers sharing these, it would be fairly straight-forward to identify SPAM comping from a Gmail account and have it closed by Google.
So what are you waiting for? Update your SPF records or get your hosting provider to do it (if they manage the DNS for you) and start seeing more junk go straight into your SPAM folder and less of it in your inbox!
With SPAM, there are a couple of issues. The first is not really anything to do with the weaknesses of email and would occur if someone simply sent you an unsolicited email, either offering things for sale or perhaps offering malware or phishing. There are perhaps measures that could be taken in a future email protocol to help combat this but ultimately that would involve trust, verification, signing and a whole load of things that never sit terribly well on the web.
The second however is a very simple weakness with email and something that is perhaps more dubious from a SPAM point of view. This is when somebody sends you an email from any server in the world (which may or may not even stay alive for any period of time - it is untraceable) but in which the user has set the "from" address to something that looks genuine, e.g. admin@paypal.com and which then would probably contain information that looks like it comes from paypal. Many users would easily be fooled and could end up being fished/infected with a computer virus or whatever. RFC5322 does not provide a mechanism to ensure that the address of the user in the "from" field matches the ownership of the server that sent the email and in one sense, it would not be easy anyway. There are many reasons why a company might send emails from one server or another. Perhaps you outsource your marketing to another company and the mail is sent from their servers, perhaps you had to hire some servers while you were performing an upgrade on your own systems and perhaps the "from" address relates to someone who you want your customers to contact who doesn't work for your company.
Recently I received an email reporting to be from someone@red.com red.com sell film cameras but clearly, by not using a system called SPF, the email didn't raise any flags when it arrived in my in box - it should have.
SPF is a simple system that relies on DNS records and although not foolproof, is a good first step towards identifying SPAM. The idea is simple, if my mail client receives an email with a "from" address that contains e.g. somedomain.com, it makes a DNS request to somedomain.com and queries its SPF record (the same information should also be contained in the TXT record). This SPF record simply lists the server(s) that are permitted to send mail for somedomain.com and then provide an option to tell the client how harshly it should treat mail received from any other server. Theoretically, you can tell it to "hard fail" which means the client should instantly mark it as SPAM, you can also "soft fail" which says, "it probably is SPAM but I'm too scared to hard fail it in case genuine mail gets lost into SPAM folders".
If you use a single (private) mail server to relay your mail, this actually works really well because presumably no-one else can send mail from your server. It gets slightly more complex if you use shared mail servers (e.g. gmail or your hosting company) because naturally other people can send mail from the same servers that your SPF records authorise. This is a low risk for most people. In our case, we use GMail to relay mail and although they have lots of mail servers and many other customers sharing these, it would be fairly straight-forward to identify SPAM comping from a Gmail account and have it closed by Google.
So what are you waiting for? Update your SPF records or get your hosting provider to do it (if they manage the DNS for you) and start seeing more junk go straight into your SPAM folder and less of it in your inbox!