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!
??
the user can set up their system to reject anything they damn well feel like rejecting.
the hard part is the testing, not the actions taken after testing...
Why build a new format when there is one already available that would suit their needs?
Hmmm.
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.
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.
Yes more people who will still use their email clients vs. switching to ones that block spam mail an other way. Plus they can say. We Stopped spam. Plus sience they have made the protocal they will be the first to implement it in their email servers and their clients giving a month lead over the rest, and obtaining market share and lockin.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Because the SMTP protocol requires two-way communications, the packet has to have a valid IP address, so that the TCP/IP traffic can go between the two mail servers (sender, reciever). Because of this, you are guaranteed that the IP address is correct to within a given sub-net. Within that sub-net, yes, spoofing is possible (convince the router that you are the real 131.107.3.124). This is definately "close enough" to usually be accurate.
Kinetic stupidity has a new brand leader: Allen Zadr.
...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.
Since the parent of my last comment was rated as a troll (I don't agree with that) here is the text:
---
Make sure you let them know that patents on email technology are unacceptable. Merging is okay, let's just keep the SPF license, not the Microsoft one.
---
It's just saying that patents on email tech are unreasonable. That's pretty reasonable to me.
æeee!
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.
Secondly if they have to buy domains they need to pay for them - that leaves a physical paper trail to spammers, now legislation can help.
Sorry, but I have to hit the bullshit button. Legislation hasn't helped yet, and I'm not talking about CAN-SPAM or any of the other anti-bulk mail bills, but the existing laws dealing with all manner of fraud, FDA regulations and any of the other various and sundry state and federal laws regulating the almost-universally fraudulent commercial content of spam.
You're suffering from the same delusion that many people, myself included, often suffer from -- "Can't we pass a *law*"? -- when there are many good laws already on the books that better deal with the problem in general.
I'd suggest a RICO investigation into some of the top-level spammers, their clients, and the people involved in the payments, the network access, and find out how dirty they really are. I don't know, but I suspect, that most of these people know they're involved in deeply fraudulent activity. A few racketeering convictions involving major ISPs, banks, spammers, and their business clients with some noisy investigation of other spammers could have a *real* impact -- squeezing the spammers out of ISP suppliers and banking services they literally can't do business without.
Wasn't XML last century's buzz word ? The old saying that "when the only tool you have is a hammer - everything looks like a nail" seems totally appropriate.
No it doesn't - SPF works on the _envelope_ headers and the fact that the forwarding machine is declared OK to send. Rewrite the envelope header (the one you never get to see in most mail clients) and make sure forwarding happens on a machine SPF-permitted for the rewritten address (or is routed via a mail gateway permitted by SPF).
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.
Besides, how can you say it's failed for 10 years, when it was never *even* tried. Thunderbird is the first mainstream e-mail client I've installed that supports Encryption out of the box. But calling it mainstream is a stretch, and it doens't really include key management. If MS is serious about fighting spam and improving security, I think they should start with *Implementing* technology and standards that have been around for 10 years.
so you are too lazy to register a domain name for yourself and name your email server mail.guywhohatesbmail.com??
sorry but I really believe that if you dont have a FQDN for your email server you need to be blocked.
Ip address only email servers are not a proper email server.
a modification of lumpy's solution would work. get a FQDN and reject all email not from a FQD...
simple as that. that way the offending server can be tracked down and blackholed easily.
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.
From the Caller ID for Spam page:
;-)
"Send your comments. We are circulating this initial technical specification for comment because we believe that your feedback can help make it stronger."
Is it just me, or does that process sound dangerously close to open source software development?
Double Compile