E-mail, by design, is an anonymous service. Anyone can send a message saying they are anyone else. There are various discussions that can be had about whether this is a good thing or a bad thing. The important point is that spammers take advantage of this by pretending to be e-mail addresses they are not. This causes a loss in confidence of e-mail as a business tool, and in worse cases can generate a lot more spam to you... Think about that time you got a lot of e-mail rejection notifications, for e-mails you didn't even send! This was a case of a spammer pretending to be you, and you getting all of the spam rejection messages back in your Inbox. This happened in part because the mail server that was being spammed couldn't positively say, "no that is not from him, it is really spam", and drop the message accordingly instead of generating a rejection message.
SPF records are intended to address this by allowing receiving mail servers to look up which sending mail servers are valid senders of e-mail for your domain. The EYOND and MRSware domains have been set up this way for quite some time, as have all the sub-domains of MRSware.com (all of the "internal use domains" that we set up for you when you first start in MRSware).
Action Required
In order to enable SPF for your domain, you need to make an entry in your domain's DNS settings. This is something that is typically controlled through your domain registrar, the company you purchased your domain through (typical domain registrars are companies like Network Solutions and godaddy.com).
For more information on SPF and specifics on what needs to be done to set it up for your domain, take a look at their web site at
http://www.openspf.net/
They also have a tool to help you determine what the SPF record should be for your domain, based on some questions that you answer. Some of the questions are pretty straight forward, but some will ask you to consider those users at your company that may be using non-MRSware e-mail clients and what mail server(s) they are using to send their e-mail:
http://www.openspf.net/Tools
The implementation of SPF is a growing trend. In order for it to work, mail servers have to implement it in their design. In order for the whole thing to really work effectively, the use rate of this framework needs to continue to grow.
SPF, Sender Verification, & Spam Filtering
The implementation of SPF and similar authentication schemes from Microsoft (SenderId) and others is amazing similar to what we have been doing in MRSware since near the beginning of e-mail service (circa 2003). Our system of testing the validity of the sending mail server is called "Sender Verification". MRSware Users have certainly seen this if they have ever adjusted their spam settings. Sender Verification works very well for us in identifying incoming spammers. Similarly the SPF records help other mail servers do a similar thing on their receiving side. If they have implemented an SPF solution, we should get less spam rejection messages.
Does this replace Spam filtering? Not at all, the two work together -- Sender Verification to test if the mail server is a spammer, and Spam Filtering to test the individual e-mail for spam content... It is quite possible for a valid mail server to send spam (passing the first test but not the second).
As spammers change tactics, so do spam filtering and verification systems change to try to keep on top of it. There is no way to get rid of spam, but with diligence we can reduce its impact on our work day.
Action Required
In order to enable SPF for your domain, you need to make an entry in your domain's DNS settings. This is something that is typically controlled through your domain registrar, the company you purchased your domain through (typical domain registrars are companies like Network Solutions and godaddy.com).
For more information on SPF and specifics on what needs to be done to set it up for your domain, take a look at their web site at
http://www.openspf.net/
They also have a tool to help you determine what the SPF record should be for your domain, based on some questions that you answer. Some of the questions are pretty straight forward, but some will ask you to consider those users at your company that may be using non-MRSware e-mail clients and what mail server(s) they are using to send their e-mail:
http://www.openspf.net/Tools
The implementation of SPF is a growing trend. In order for it to work, mail servers have to implement it in their design. In order for the whole thing to really work effectively, the use rate of this framework needs to continue to grow.
SPF, Sender Verification, & Spam Filtering
The implementation of SPF and similar authentication schemes from Microsoft (SenderId) and others is amazing similar to what we have been doing in MRSware since near the beginning of e-mail service (circa 2003). Our system of testing the validity of the sending mail server is called "Sender Verification". MRSware Users have certainly seen this if they have ever adjusted their spam settings. Sender Verification works very well for us in identifying incoming spammers. Similarly the SPF records help other mail servers do a similar thing on their receiving side. If they have implemented an SPF solution, we should get less spam rejection messages.
Does this replace Spam filtering? Not at all, the two work together -- Sender Verification to test if the mail server is a spammer, and Spam Filtering to test the individual e-mail for spam content... It is quite possible for a valid mail server to send spam (passing the first test but not the second).
As spammers change tactics, so do spam filtering and verification systems change to try to keep on top of it. There is no way to get rid of spam, but with diligence we can reduce its impact on our work day.
RSS Feed
