SPF (an anti-spam technology) is coming fast
An anti-spam initiative is about to become real, it'll hopefully help your ISP do much better spam filtering in the short term and cut down forged email headers significantly in the long term, and it'll likely matter to you how quickly you and your ISP move to ensure your outgoing email can be considered good.
For those of you who haven't been following, there are a few major anti-spam initiatives, all targeted at forged addresses in email. As of a few months ago, the three major approaches were SPF (pobox.com and others), DomainKeys (Yahoo), and Caller ID (Microsoft).
In the past month or so, there have been some notable advances. First, SPF and Caller ID merged into a single initiative called Sender ID. As far as I can tell, this is just SPF repackged into XML format, since at Microsoft, Everything Must Be XML. At least for the moment. I think it's unfortunate, because XML is verbose and DNS records are inherently small. But like many others, I think the most important thing is to Get It Done Now.
They all attempt to verify where an email comes from. They all add additional DNS records to hold the information necessary to carry out the verification. The primary use for DNS is to look up another computer's name (like www.amazon.com) to determine what Internet address to talk to (like 207.171.163.30); this just adds extra DNS records that won't get in the way of that. They all can produce one of three answers (good, bad, unknown). They vary in what email header field gets verified, what it gets matched against (the IP address of the server sending the message out, or a cryptographic digital signature in the message itself)
And that's what's happening. Sender ID hasn't escaped the standards committee yet. But major players are already saying expect emails to start using them.
I'm particularly confused by Microsoft's stance. After getting buy-off for some of their stuff by the Sender ID compromise, they seem to be somewhat endorsing the older SPF proposal. Their sponsored Sender ID wizard actually produces a record that's neither SPF nor Sender ID, it's a mix of both. eep!
What does this mean for you? I think that for now, this means that you should ensure your email passes SPF checks. If it fails, it'll almost certainly get flagged as spam, or worse, rejected or silently dropped. If it comes back as unknown, then it'll be more likely that it'll be misclassified as spam.
If you control the DNS records for the domain you use for outgoing email (more precisely, the domain of the envelope sender), use a SPF Wizard to publish your own SPF records. If you don't, you should either ensure your outgoing email goes through your ISP's SMTP server or work with your ISP to ensure that they indicate that where you send from is sanctioned. Either way, you should encourage your ISP to publish SPF records quickly. (I'll add a SPF validator link if I can find one. The one I knew about is being reworked to scale better.)
It isn't the entire solution to the flood of spam, but it's a good first step.
For those of you who haven't been following, there are a few major anti-spam initiatives, all targeted at forged addresses in email. As of a few months ago, the three major approaches were SPF (pobox.com and others), DomainKeys (Yahoo), and Caller ID (Microsoft).
In the past month or so, there have been some notable advances. First, SPF and Caller ID merged into a single initiative called Sender ID. As far as I can tell, this is just SPF repackged into XML format, since at Microsoft, Everything Must Be XML. At least for the moment. I think it's unfortunate, because XML is verbose and DNS records are inherently small. But like many others, I think the most important thing is to Get It Done Now.
They all attempt to verify where an email comes from. They all add additional DNS records to hold the information necessary to carry out the verification. The primary use for DNS is to look up another computer's name (like www.amazon.com) to determine what Internet address to talk to (like 207.171.163.30); this just adds extra DNS records that won't get in the way of that. They all can produce one of three answers (good, bad, unknown). They vary in what email header field gets verified, what it gets matched against (the IP address of the server sending the message out, or a cryptographic digital signature in the message itself)
And that's what's happening. Sender ID hasn't escaped the standards committee yet. But major players are already saying expect emails to start using them.
I'm particularly confused by Microsoft's stance. After getting buy-off for some of their stuff by the Sender ID compromise, they seem to be somewhat endorsing the older SPF proposal. Their sponsored Sender ID wizard actually produces a record that's neither SPF nor Sender ID, it's a mix of both. eep!
What does this mean for you? I think that for now, this means that you should ensure your email passes SPF checks. If it fails, it'll almost certainly get flagged as spam, or worse, rejected or silently dropped. If it comes back as unknown, then it'll be more likely that it'll be misclassified as spam.
If you control the DNS records for the domain you use for outgoing email (more precisely, the domain of the envelope sender), use a SPF Wizard to publish your own SPF records. If you don't, you should either ensure your outgoing email goes through your ISP's SMTP server or work with your ISP to ensure that they indicate that where you send from is sanctioned. Either way, you should encourage your ISP to publish SPF records quickly. (I'll add a SPF validator link if I can find one. The one I knew about is being reworked to scale better.)
It isn't the entire solution to the flood of spam, but it's a good first step.