Slashdot Mirror
SPF To Be Integrated With MS 'Caller ID' System
An anonymous reader submits "CNET's news.com is reporting 'An ongoing effort to consolidate antispam authentication schemes took a big step forward with the merging of Sender Policy Framework (SPF) and Microsoft's Caller ID for E-mail.' This is potentially good news." For more background, here are three previous mentions of Microsoft's proposed Caller ID-style system.
I have yet to see a good reason why XML is the choice for the payload. I'm not really buying the argument that it's easier to shoehorn XML into TXT fields rather than have another tag. Either way, in order to implement the proposal the MTA authors will have to do some work, and I don't think there's much to choose between the two...
I still can't really rid myself of the nagging suspicion that the extensibility of an XML-driven anti-spam system plays into the hands of 'embrace and extend' that MS has used successfully since time began...
On the other hand, getting some authentication that it really came from where it says it came from will be very useful. The corollory is that 'owning' a mail server will become a higher priority for the hacker/spammer coalitions. Look for more attacks on MX machines if this becomes widespread...
Next on the agenda - get everyone to use digitally-signed certificates
Simon
Physicists get Hadrons!
Now it sounds like a bad idea for both semantic (what it does) and syntactic (how it is coded) reasons!
The syntactic bit is easy -- XML is hardly appropriate for a DNS function. Mickeysoft is running around patenting XML schemas, and it adds a new layer of complexity to DNS. But then bad syntax is usually dealt with by code.
The semantic bit is worse -- SPF doesn't block spam unless the mail system makes it mandatory, after all, so until 100% compliance is reached, non-SPF mail will still have to be accepted. But wait -- SPF doesn't block spam! It just blocks spam where the From: is not right. Spammers can still create new domains on a hit-and-run basis, and they'll pass SPF. So it's another blast-proof vault door stuck onto a grass hut, a silly waste of time. The only potential real benefit, I suspect, would be to make phishing harder. The address will have to be slightly different from the spoofed domain. But that leaves plenty of opportunity to create deceptively-close hit-and-run domains (like, say, pay-pa1-approva1.com).
Worse, of course, is the collateral damage. How will I be able to send mail using my own business' domain, as I do today, when it is going out via an ISP server? My "from" address is an alias, not a real sender, and I use it to send via more than one ISP, depending on where I am. SPF seems to make this a lot harder, thereby forcing more people to put their ISPs' name in the From: field, rather than their own. Since email is not portable, a user's address is lost when they change ISPs, or when their ISP changes names (mediaone->attbi->comcast). Personal domains (forwarded via a service like mydomain) solve this. Will SPF kill mydomain?
I repeat what I've said before. The only way to kill spam is to stop having all email be totally, absolutely, "free" of charge in any quantity. This is not the topic to discuss solutions, but they are certainly possible, and they aren't SPF.
Because, since XML is not a format (but rather a standardized way of creating one's own formats) the issue of "creating a format" is not solved by the decision to use XML.
What XML "wins" is off-the-shelf parsers; one still needs to write some amount of code to convert dumb XML (elements and attributes and all that crud) into something with semantic meaning to your application.
For a simple application like this it's not clear that the overheads of XML (both in terms of size, computational complexity, and programmer overhead to make the aforementioned conversion) are at all worthwhile.
I think their main motivation is to stop the spread of virus attachments... anytime there's a MS-targetting worm going around, using similar distribution processes as spam, it creates an additional workload, not to mention that it tars Microsoft's image.
From my point of view, the spam cleanup would just be collateral.
...in a comment I made here.
Basically, this is a simply classic way to "embrace and extend" Microsoft's Caller ID. Before the flag day, SPF will work the way it is now. After the flag day, which will probably occur later rather than sooner, SPF will have all the functionality of Caller ID. The idea of allowing both XML and text descriptors is simply brilliant. Microsoft wanted to force everyone to use XML, but now you have a choice. I believe most (like 99.9%) will use the text descriptors, both because it is easier and because it is sufficient for 99.9% of the cases.
The net result is Microsoft can't claim ownership anymore. Caller ID will be a footnote in the history of email authentication.
The radical sect of Islam would either see you dead or "reverted" to Islam.
You know, people have been saying that for almost a decade now. Face it: digitally signed email isn't working. Key management is a pain in the ass, the bootstrapping necessary to check user's keys is a mess, and it doesn't really gain you that much in the end. We've had 10 years to get signed email working, and it didn't happen. Time to find another way (whether it's this SPF or something else is a point for argument).
Well, I'm a pobox.com customer, and my own experience of their new antispam measures is absolutely nothing but fantastic. They recently overhauled their spam filters, and the result (again, this is just my experience) has been stunning.
Of course, this says little about SPF itself, but at the very least, for what it's worth, the company that invented it comes with my recommendation.
Well, the way pobox.com has done it, you can choose to have your E-mail "flagged." SPF is one of those possible flags. If an E-mail gets X (a user-definable number) or more flags, it can be rejected as spam. This makes SPF useful even when there isn't 100% compliance.
How will I be able to send mail using my own business' domain, as I do today, when it is going out via an ISP server?
I would think that if your ISP is interested in doing honest business, they would make the effort to list their own mail server.
If you're running your own mail server, then, yes, this is a valid concern.
The only way to kill spam is to stop having all email be totally, absolutely, "free" of charge in any quantity.
I don't deny that that would be a very effective way, but I don't agree that it is the only way.
Accountability on the heads of the powerful.
Power in the hands of the accountable.
Uhhhhhhhh, because a DNS packet is limited to 512 octets??
-russ
Don't piss off The Angry Economist
In theory, SPF should make it easier for these people to send E-mail. They can publish a valid SPF record for their domain, which should make mail from their system more trustworthy than mail from dynamic IP space is generally. Ie, the reason people block mail from dynamic IP space is because of the incredible amount of crud coming from trojanned Windows machines in that space.
If a real sender can somehow distinguish themselves via a valid SPF record, they might actually have better luck sending mail than they do now.
It's simple really. DNS is one of the highest areas of traffic and hits out there. Every web page generates multiple DNS hits and so does email and P2P and everything else.
XML, is a bunch of text that wraps around a bunch of data and is called meta data. It's not the data you need, but data about the data you need. In DNS, you already know what you need, so the "meta" is silly.
Point being, you add a lot of extra characters to the data transmissions. UDP won't support it anymore so we have to to with TCP, which has even more overhead being added to the process.
Compound this with MSFT's tendency to send shitloads of data across every network they touch just because they can, and you've DDOSed the Internet.
XML may have a place, but DNS sure as hell isn't it.