I set up SPF (aka Sender Policy Framework, aka Sender Permitted From) on my vanity domain name yesterday.
SPF is a method of publishing a list of servers used to send mail from my domain. If any message arrives from another source it should be treated with extreme suspicion or discarded. It is yet another tool used to authenticate a sending domain. The hope is that this will slow down the amount of spoofed email.
Posts tagged ‘SPF’
I set up SPF
Greylisting
My personal ISP has started using Greylisting as a method to combat spam.
What is Greylisting?
Greylisting says that until proven otherwise we’re not going to trust an inbound mail connection. It takes the envelope from, the envelope to and the source IP address and forms a tuple. If it has previously let that combination through, then it will whitelist in. But for most mail it will give a temporary failure message. Real mail servers will try again at a preset time. Spammers wont. Even if spammer catch on to this game and reattempt delivery, the mail server can be set to not accept the new attempt for delivery for a default time period (20 minutes). This really throws a monkey wrench into the amount of mail the spammer can send. If the spammer is using a mail sender that will retry, perhaps by that point in time he would be blacklisted due to imput from other antispam sources.
Thus far I am very happy about this on my “vanity” domain name. Not sure if it would be good for business use. Some mail servers do not correctly retry after a transient error. (In my opinion non-RFC compliant mail servers should fix their stuff). Also in business use where a retry interval might be 4 hours minimum, it could really slow delivery. The auto-generating whitelist and manually generated whitelists for business partners would really help that. It remembers which tuple combinations “reattempted” delivery and adds them to a temporary whitelist. The greylisting server I use also adds people I sent mail TO to my whitelist.
I can see problems caused by things like SPF and ways around it. Greylisting has some interesting potential.
Check out the following links for more info. I certainly cant say everything about greylisting in a brief blog entry. I’m just trying to introduce a cool concept.
www.greylisting.org
http://projects.puremagic.com/greylisting/
FTC says NO to Do Not Email List
Although authorized by the (YOU)CanSPAM act to create a national email list, the Federal Trade Commission has declined to do so according to news.com. The article quotes commission members as saying such a list would be ineffective and burdensome to the consumer.
Instead the highlighted two emerging mail authentication technologies SPF and Domain Keys as like effective weapons in the anti-spam battle.
I tend to agree with this assessment. Unless your mailbox is already hopelessly over run with spam and cant get any worse, I would never risk giving out my email address to an anti-spam list.
Virus Alerts make the Virus problem worse
The traditional model of antivirus management on the SMTP gateway overloads the average users mailbox with unnecessary and confusing messages.
Originally, virus laden email were otherwise legitimate messages that just happened to contain a macro virus in a word document or something similar. It was desired therefor to clean the virus from the message and ensure delivery of the non-viral content. At the same time it was important to notify the sender of their virus infection so they could get the problem rectified.
The problem with this approach is obvious today. Viruses today have moved beyond the simple macro virus. Instead they are self-generating and contain no redeeming content that the user would want to see. The problem first manifested itself in unnecessary calls to the help-desk. The user would be worried that they received a message with the “subject” and the “from” line that we warned them about!!! Of course, if they had opened the message they would see that the attachment had been removed by the anti-virus software. Messages like this really waste the end users time and also the time of the help-desk. The problem came to a head with swen.a as some unlucky user accounts received thousands to 10s of thousands of virus messages, all appropriately defanged by the anti-virus software. This was basically a denial of service attack that could have been prevented if the anti-virus software ate the offending message.
The other side of the problem is the forged sender problem. Most email worms pick random return addresses. Antivirus systems that follow the old model and send a warning back to the supposed sender are generally going to be bothering an innocent party.
So what do you do about it? You dont want to participate in harassing innocent third parties, yet you dont want to harass your own employees. Common sense says you shouldn’t drop email messages down a rabbit hole. The compromise position is, if a message contains a virus do not deliver to the employee. If the virus is a network worm, then there is no need to tell the sender or recipient about the problem (there is no legitimate content). If the virus is not a network worm, then it is ok to tell the sender that their message was not delivered and why (we blocked it because it contains virus x in file y). This is a simple matter of adding a flag in the virus definition to describe which viruses are email worms. Many vendors have that now, and others are moving toward that model.
This will help cut down on the completely unnecessary mail traffic associated with many email viruses. Unfortunately, this will not stop the problem completely as not everyone will be running a good anti-virus product. Users will still receive email bounces (no such email address), and notifications for file removal for mail that they did not send. Until SMTP messages are secured in some manner (look into SPF) there isn’t anything that can be done on that part of the problem.
