Slashdot Mirror
Microsoft Releases 'Caller-ID For Email' Specs
gfilion writes "Microsoft has released a draft specification for Caller-ID for email, 'to address the widespread problem of domain spoofing' - the concept is similar to SPF, but is using XML. There's already an Caller-ID to SPF converter in the works. A few weeks ago, Microsoft discussed compatibility between the projects with Meng Weng Wong (SPF's project leader), but most SPF users are against using XML, so nothing has come of it thus far." We recently covered a brief article mentioning Microsoft's anti-spam work, though this is a clearer indication of their intentions. Update: 02/26 21:36 GMT by T : NewsForge is carrying a brief article with FSF counsel Eben Moglen's take on the draft; Moglen says it is "encumbered with unclear and unnecessary patent license claims."
While I acknowledge that XML is great for some things, why is it that it gets used for almost everything nowadays? Damn buzzword-dominated market...
Ok, I'll be quiet now :)
At least this is one area where MS will have a real problem using their monopoly to enforce a closed standard. A solution that doesn't work for people that don't use MS software just isn't going to fly.
Having done work on (opt-in) HTML newsletters for clients, I know that email clients used are really varied - more varied than web browsers for instance.
Why are SPF's developers against using XML? - because it's not more than a buzzword.
Why is Microsoft using XML? - because they're a business, they need buzzwords.
Whats to stop a spammer from signing up for a free email account with a false name, blast out a few thousand messages, drop the account (it'll be closed anyway by abuse), wipe hands and repeat?
True, I see how this may help stop some spam, but it also means (if I understood the article correctly) that everyone can find out where I mail from... and in some instances that could be a problem too.
Everything in the world is controlled by a small, evil group to which, unfortunately, no one you know belongs.
Why not have *real* caller-ID for email authentication? Before you can get on my white-list, you have to call a phone number for some sort of challenge-response. Caller-ID could be part of this.
Life is the leading cause of death in America.
Microsoft is one big player in the email world through their Hotmail service. They probably serve more spam to more places than any other single mail service. As such it makes sense that they would want to be at the forefront of spam-elimination technologies. They ought to be applauded for their initiative here, as well as their cooperation with SPF and Sendmail.
However, it disconcerts me that they are also applying for a patent in this area instead of engaging the community through a consortium-like committee that could share the technology across the board unencumbered by licensing fees. The specter of Hotmail becoming a proprietary mail system requiring foreign mail servers to run Microsoft-licensed "Caller-ID" to interact with Hotmail is a very legitimate concern.
I have been pwned because my
I've had the unfortunate experience of attempting to generate XML using Microsoft's MSXML object. What a piece of crap! In an attempt to completely abstract the format, the objects are obfuscated beyond reason. Even the simplest things require ridiculous complexity: just to escape-out special characters requires instantiating a new "entity" element in the middle of the text string element.
And I still haven't figured out how to make the thing give me a CRLF at the end of each element. No, XML doesn't require the whitespace, but it would have sure made it easier for my clients to read the file!
But the worst part is that I *succeeded* in using MSXML. Now, if I wanted to go back to just writing a text file (which I do!), I can't -- my code is tangled up in the objects to the point that it would take a complete rewrite.
That's the simple reason why, every time I hear about Microsoft doing something with XML -- like this proposal to use XML as part of email identification -- I cringe in ph33r.
Stressed? Me? Of course not. Stress is what a rubber band feels before it breaks, silly.
Caller-ID for email will help prevent spoofing, but will only increase spammers use of zombies. I wonder if increased exploitation of Microsoft OS weaknesses (to create spammer platforms) will have a long-term detrimental effect on Windows or whether it will hasten adoption of Trusted Computing? I wonder if Microsoft wants ISPs to become so sick of zombie boxen that the ISPs will prohibit all but a few chosen OS options (read the lastest version of Windows) for connection to their networks.
For a very well-entrenched provider, making everyone sick of you old product is a good way to force them to buy your new product.
Two wrongs don't make a right, but three lefts do.
if it will mean I have to pay fees to Microsoft to get my domain signed, I'd rather continue filtering out spoofed-bounces, thank you.
Interesting how instead of supporting a perfectly sound project that has been going for a year, everybody seems to have to come up with their own little *patented* scheme.
I hate XML, and a quick google reveals:
XML sucks = about 215,000
XML rocks = about 174,000
I'm pleased to see I am in the majority - I thought its buzzword status would have rated it higher.
I do believe this is one area we have to really keep an on eye on M$ in. Do they really want to stop the spam or is it just PR. They have the browser that doesn't block pop ups and on a default install of windows Ad-Aware will find things it considers an issue right after the default install.
This may just be a PR issue to show people they are pushing for it. When they implement something like this will they put their own hooks in it to allow what they want???
M$ really needs to be kept an eye on if they do this.
Evolution or ID?
They would have allowed a user to disable a the javascript popup function in the browser. Instead we have to rely on bandaids like googles toolbar to block popups from websites.
(From Microsoft's license.)
So by building support for "Caller ID for Email" into your software, you suddenly give Microsoft an unlimited license to use and sell it. And, in fact, not only Microsoft, but everyone else who writes software that supports "Caller ID for Email."
There is a word for this: Insane.
No thanks. I'll stick with SPF--especially since the two are essentially identical, just a slightly different parsing format.
It's hard for thee to kick against the pricks.
Micros4!t's sure into "Not Invented Here" syndrome, eh?
... because the performance is crap. This is true on my pc (with any parser you care to name - i've tried it) so what it'd be like on a mail server handling x thousand messages a minute I have no idea.
XML is great, but only when the underlying data is sufficiently variable within a pre-defined schema and where throughput is not an issue. It's not necessary here.
sean.
On a first reading, I thought the ideas seemed quite sensible. One problem they did address in an interesting way was that of people with several email identities. One of their suggestions is that whoever is hosting the incoming email provides outgoing smtp services too, which would be a change from the (outdated?) idea that one should always use the "nearest" smtp server for all email. Though ISPs who currently block outgoing port 25 (such as my University!) would have to think again.
N.
My Word (Office X) crashes consistently when I try to view the document. Ridiculous. Can someone mirror the spec as PDF or HTML please?
Did you consider that e-mail are used outside the US? I am certainly not going to pay a trans-atlantic call each time I want to send an e-mail to a new guy in the US. What about people that don't speak English? What about people who don't have a phone, or don't have a number on a system that supports caller id? With the advent of IP phones, this would become more and more common.
In General Ackbar's legendary words'It's a trap!'
I guess the Joe-Jobbers will be hard at work trying to find all the ways of spoofing SPF.
Zombie writers will be in even greater demand from the spam factories.
Apart from spammers using zombified users email accounts, are there any other possible ways around SPF?
Having read the executive summary and skimmed a few pages, the general precepts make sense.
At the very least, the transitional phase of mass implementation of SASL or similar (which IMO should be mandatory for mail servers anyway) is a Good_Thing_(tm)
Granted it will take a lot of time and effort for the second phase to be reached, but anything which cuts down on spam gets my vote!
smile, it makes everyone else wonder what you're up to
Not sure if this is mentioned in the .doc, but _ep.microsoft.com already appears to be doing this:
> <a>207.46.71.29</a><a>194.121.59.20</a><a>157.60.2 16.10</a><a>131.107.3.116</a><a>131.107.3.117</a>< a>131.107.3.100</a>" "</m></out></ep>"
_ep.microsoft.com. 1H IN TXT "<ep xmlns='http://ms.net/1' testing='true'><out><m>" "<mx/><a>213.199.128.160</a><a>213.199.128.145</a
This is a good idea, and we (tinw) has discussed this many times before, and various implementations already exists (that is - verifying the sender domain, not the specific MS implementation).
Now, what bothers me is this line:
Microsoft believes that it has patent rights (patent(s) and/or pending applications(s))
Given the latest stories on how easy it is to patent everything "over there", I am pretty sure MS is granted this patent. Now I don't know about you, but this geek ain't licensing nothing from MS.
The SPF guys have them: http://spf.pobox.com/caller-id/
Registering accounts later than some other chrisb since 1997
In the license Microsoft grant implementers there is the following nasty clause:
If you distribute, license or sell a Licensed Implementation, this license is conditioned upon you requiring that the following notice be prominently displayed in all copies and derivative works of your source code and in copies of the documentation and licenses associated with your Licensed Implementation:
"This product may incorporate intellectual property owned by Microsoft Corporation. If you would like a license from Microsoft, you need to contact Microsoft directly."
Isn't this incompatible with the GPL?
Rich
So make a BSD/LGPL licensed libcallid4email or somesuch and use that in all your projects. AFAICT code licensed under BSD/LGPL fulfils what MSFT wants here.
Rich
I looked into SPF, briefly, and it doesn't seem to solve a problem I have...
I have various (virtual) users (~20-25) on my domains.
These users use both my SMTP server (when using squirrel mail, or (ssh-)tunnelling to the SMTP server, itself), as well as their local ISP's mail server (sympatico, videotron, etc)... My SMTP server doesn't relay from anywhere except localhost.
So, in order for SPF to work, I need to allow email from my domain, and these ISPs.
The ISPs are large, and when an email virus goes around, mail is undoubtedly sent "From" me (actually from/by outlook users with me in their address books), through these ISPs' SMTP servers, making SPF useless.
Am I just missing something?
S
XML is awesome when you are looking for interoperability between different applications/systems. I would think that when the Internet community agrees upon whatever protocol, it should be a common standard and will not need the benefits of XML. Indeed, XML would actually be a bad choice, as the extra market will just use more bandwidth. Sounds like MS should just bow its head, say thanks to SPF, and adopt it. If they want XML on their side, then let them right an internal API/converter so those developing with Exchange or Outlook will have access to an XML version. By leave it off the pipe! And I say this as a guy who works with XML everyday and enjoys the benefits it provides my company.
Great ideas often receive violent opposition from mediocre minds. - Albert Einstein
because the Sendmail sender verification proposal (mentioned here) relies only on already existing tech (Domain Keys, mx records, and smtp auth) thaty is already incorporated into the vast majority of MTAs, it does not really make much sense (from a users, or a non-microsoft, point of veiw) to create a seprate and more complicated solution (even if the license is rather innocuous).
I cannot help but think that continuing to allow senders that do not have a mx record for the sending machine to bypass smtp-auth for sending messages will fail to curb the spam problem, as it fails to tie the sent mails to an actual domain, and it allows (encourages) ISPs to restrict mailing through their email services only. With smtp-auth, it is still possible to send using an smtp server connected anywhere on the net, which allows accountability, but also makes it more possible to identify those providers who are allowing their users to send spam.
Read, L
No, it is not insane. It is called cross-licensing. They are saying if you want to use this technology, then you agree that you are not going to come back and sue Microsoft (or any other licensee too!) for patent violations relating to this implementation. This is a good thing!! They are protecting themselves.
So by building support for "Caller ID for Email" into your software, you suddenly give Microsoft an unlimited license to use and sell it. And, in fact, not only Microsoft, but everyone else who writes software that supports "Caller ID for Email."
Absolutely not. There is something called copyright law. Microsoft or any other company cannot just go and resell your software on their own terms. The license just means you cannot sue them for patent violations when they choose to build software that implements technology similar to yours in this area (provided you had obtained additional patents relating to this 'Caller-ID').
Can you spam me now? Good.
Prospective station wagon buyer: "I know what you say is true...but...er...I don't know how to maintain a tank!"
XML has become what ASCII files were used for back in the 80s and 90s. From that perspective, we've come a long way. At least now we can make a rough guess at what the data inside the XML file represents (unless of course it was designed by a moron).
And as for speed, it's really a non-issue for email. Who gives a rats-ass if it takes your email server an extra 100ms to process an email. More then likely you have a email server that serves 1000 users or less. The amount of time you'll save processing XML headers vs. the shit your server process now will be infinitesimal compared to the amount of time it currently spends processing spam.
Say what you will about XML, but at least it's better then the custom format binary crap files that proliferate tons of legacy systems.
Actually, it doesn't say that. The important phrase is "Necessary Claims" and the word "reciprocal" gives a good hint too. This is just a defensive patent licence. It says that Microsoft won't sue you for breach of patent for implimenting the standard or dealing in implimentations and you promise the same to Microsoft and everyone else.
It is NOT a copyright licence to Microsoft to use and sell YOUR implimentation. It only affects you if you hold patents which Microsoft or someone else infringes by implementing this standard. It effectively sets implimentations of this standard in a "patent free zone".
I say ignore them.
Microsoft has never been interested in helping the community but rather wants only to further its own dominance of the market. When did they start being philanthropic?
What's to say in a few years time when everyone is relying on this that they don't pull some stunt and start charging people? Do you know enough about the law to say they couldn't?
Anyway their record on enhancing email is not good. I knew the first time I saw the ability to embed HTML and * SCRIPTS * into email that the virus writers would have a field day. I mean, what complete arseholes to allow code to be executed when someone just *reads* and email. It beggars belief!
If they are serious they could assign their patents over to the FSF and then we'll consider it. I bet they won't.
Shouldn't widespread adoption of PGP be the best solution? For me any implementation of PGP sig IS a Caller ID, only it is not XML, but it could easily be wrapped.
... but is should be easy to hook it up anything.
IMHO MS is reinventing a wheel, or trying to own it.
So, if everybody should become aware of the sense of a PGP sig, maybe with a service like "pgp://pgpserver.domain.tld" the problem is on its way to its solution... It shouldn't be part of SMTP sendmail or
Maybe the idea that mail could potentially be completely private (read:encrypted) is not that appealing to everyone.
So, tell them you read it here first. (Or point me to a similar idea.)
--------
* Sigh *
You know you're a slashdot user when the parent's link is in black instead of green.
This may be a stretch, but I can interpret that 'license' to allow Microsoft and it's partners to send spam from your machine to others. Think of targeted ads to those in your address book that appear to be from you personally.
You are being MICROattacked, from various angles, in a SOFT manner.
It's a fact of life that MS Exchange lives in corporate environments but ISPs and everyone use sendmail (or a sendmail derivative) for mail routing over the Internet.
It's actually in MS's interests to work with sendmail on an open protocol to do spam filtering properly (whatever that protocol is ultimately).
Remember that TCP/IP is an open standard and MS supports TCP/IP open protocols like FTP, HTTP, POP3, SMTP, etc. already in their products so this is no different.
Gentoo Linux - another day, another USE flag.
The skinny is: while spf on its own can't do prevent zombies from sending mail, if the upstream host routes port 25 through its own servers it can control this.
For example, my upstream hosts, Nildram, block all port 25 traffic outbound and inbound unless and until they have checked your (static) ip for open-relay-ness and then put you on a whitelist.
If all ISPs were like that, and spf were to become widely adopted, spam would be toast.
J.
You're only jealous cos the little penguins are talking to me.
Say, greater than 1 megabyte. I've been working with XML for a few years now and even DOM can handle simple messages in fractions of a second. How complex can this be? A tag defining a 'to' e-mail address, another for the 'from', a third for the relays. One for the signing authority. Tags for the subject, body, and attachments. No more than 10 tags, probably.
Best Slashdot Co
I wish you would learn something about existing mail standards before you say something so stupid. Email is primarily a simple text format, my HTML/word document/virus packed mailbox not withstanding. I am not surprised M$ would want to further polute the standards but why would you?
an ill wind that blows no good
It's is not a data format.
It's not a framework.
XML is a badly-formed roman numeral.
It should probably be written "MXL".
But even that might be a problem. You might need to use the Unicode Standard symbols: 2169,216F,216C
I have misplaced my pants.
I think that the ease and speed with which a cid2spf converter has been written is good illustration of the advantages of an XML based format. I wonder how long it would take to write a converter that goes the other way for comparison.
Isn't this likely Microsofts attempt to get everyone using passport of something similar?
Once they authenticate everyone using their anti-spam system, they'll be able to authenticate for financial transactions, etc...
I use a locally running postfix SMTP server on my laptop to send pretty much all of my email. Microsoft's proposal doesn't address this: of course, my laptop gets various IPs. I cannot use the SMTP server provided by my organization, as they firewalled it... With the MS proposal, I will have to go for VPN or talk to my sysadmins about smtp-auth -- and lose my independence...
So by building support for "Caller ID for Email" into your software, you suddenly give Microsoft an unlimited license to use and sell it.
No you give microsoft the right to sell compatible products! (As in "following an industry standard", quite a sane and even populair practice)
ianal, but the way I read that part is, if you license our patent(for free), you agree we and other patent licensees can make compatible implementations and rent/sell/lease/whatever them without you bugging us for money becouse we do your fancy patented features to. That sounds pretty much like something people once called an "standard", Am I just confused or didn`t we want microsoft to follow standards instead of breaking them? Now they are not only making new standards fixing problems their customers have, they also ensure nobody does a somewhat incompatible implementation breaking microsofts. (Now where would they get the idea a companey would do that?) Maybe I am old fashioned but isn`t using intelectual property laws to force people to play nice the cool thing to do here on slashdot (think: copyleft)?
Like caller ID worked for the phone system. About 90 percent of my calls were either "Unknown" or "Private Line", and some action was still requried on my part to respond to the ringing phone.
I don't have facts readily available to back this up but I'll assume somebody made money off caller-ID, as will Microsoft will attempt to do with their new "standards".
-Phil
Shoot questions, first ask later...
You work for SCO, don't you? ;)
--LordKaT
I don't see that this is any better than a PGP/GPG signed email.
In addition to what I just wrote here (which talks about user ability) there are other problems associated with using PGP sigs.
First, you have to receive the entire message before you can validate the sig, rather than being able to block receipt after the "MAIL FROM:" header.
Second, you have to go and fetch the sender's public key from the net somewhere.
Third, you have to validate the signature. That in itself is computationally expensive.
Registering accounts later than some other chrisb since 1997
http://www.microsoft.com/mscorp/ip/tech/fat.asp
...
December 3, 2003
Microsoft is offering to license its FAT file system specification and associated intellectual property. With this license, other companies have the opportunity to standardize the FAT file system implementation in their products, and to improve file system compatibility across a range of computing and consumer electronics devices.
If you are interested in obtaining a license, please contact our Intellectual Property and Licensing Group at iplg@microsoft.com for more information.
Pricing and Licensing
Microsoft offers a commercially reasonable, nonexclusive license so that other companies can use the FAT file system in their own products. Currently, Microsoft offers two specific types of licenses:
* A license for removable solid state media manufacturers to preformat the media, such as compact flash memory cards, to the Microsoft FAT file system format, and to preload data onto such preformatted media using the Microsoft FAT file system format. Pricing for this license is US$0.25 per unit with a cap on total royalties of $250,000 per manufacturer.
* A license for manufacturers of certain consumer electronics devices. Pricing for this license is US$0.25 per unit for each of the following types of devices that use removable solid state media to store data: portable digital still cameras; portable digital video cameras; portable digital still/video cameras; portable digital audio players; portable digital video players; portable digital audio/video players; multifunction printers; electronic photo frames; electronic musical instruments; and standard televisions. Pricing for this license is US$0.25 per unit with a cap on total royalties of $250,000 per licensee. Pricing for other device types can be negotiated with Microsoft.
Microsoft's FAT file system license offers limited rights to issued and pending Microsoft patents on FAT file system technology, as well as rights to implement the Microsoft FAT file system specification. In order to ensure interoperability between the licensed media and devices and Microsoft(R) Windows(R)-based personal computers and to improve consumer experience, the license requires that licensees' FAT file system implementations in the licensed media and devices be fully compliant with certain required portions of the Microsoft FAT file system specification. To help licensees implement the FAT file system, Microsoft will also provide certain reference source code and test specifications as part of the licensing package in both licenses.
In some cases, companies may wish to negotiate broader or narrower rights than the standard Microsoft license for FAT file systems. In this case, pricing may vary. Microsoft remains flexible to adjust terms to reflect crosslicensing, unit volume, version limitation, geographic scope, and other considerations.
FAT File System-Related Patents
The FAT file system licensing program includes rights to a number of U.S. Patents, including:
* U.S. Patent #5,579,517
* U.S. Patent #5,745,902
* U.S. Patent #5,758,352
* U.S. Patent #6,286,013
In addition, the FAT file system licensing package includes rights to FAT file system innovations for which Microsoft has filed a claim for a patent that the U.S. Patent Office has not yet granted. This licensing program also provides licensees rights to Microsoft FAT file system issued and pending patents outside the United States, and to the Microsoft FAT file system specification and certain test specifications.
This document describes the FAT file system specification and intellectual property licensing program as of December, 2003. Microsoft reserves the right to make modifications to the terms and conditions of this licensing program at any time. The licenses presented here do not provide rights beyond those explicitly stated above, including rights to other Microsoft patents, technical know-how or other forms of intellectual property.
Basically, it's a very poor re-implementation of SPF, with all of SPF's disadvantages and none of its advantages.
Under the MSFT scheme, the TXT records are verbose, likely requiring several records where SPF will probably fit in one. They have a hare-brained scheme to parse Received: headers to get around certain problems. Their scheme is absurdly complex.
And neither SPF nor MSFT's scheme do anything about spam coming from <>, cracked Windoze machines, or "valid" throwaway accounts. They also make forwarding more difficult than it should be.
It is being done. Microsoft just wants the PR and their hands in the door. http://spf.pobox.com
We need to tell the OS world that we want this. Sendmail or Postfix has yet to jump on this from what I've seen. We need to let them know that we want there support for it.
Slashdot, home of supporters of free software, free music, and free speech.Except for Moderators that disagree with you.
This may be a stretch, but I can interpret that 'license' to allow Microsoft and it's partners to send spam from your machine to others. Think of targeted ads to those in your address book that appear to be from you personally.
Yes, that's a stretch.
What it says is that you can impliment this standard in any way that you want and you can sell the resulting Work so long as you allow anyone else to impliment this standard and sell their Work as well. There is nothing these that in anyway implies that Microsoft would then gain control of your mailserver.
I have a lot of opinions about Cyborgs and Architects
Anyone want to place bets on how long it will be before MS announces this technology is IP belonging to Microsoft?
And hell yes, for telcos.
They sold CallerID to consumers.
Then they sold CallerID blocking to telemarketers
Then they sold blocked-CallerID call blocking to consumers.
And the cycle continues, or would have if the do-not-call list didn't enter the picture. For a while there it was a real arms race, with the telcos getting rich selling 'weapons' to both sides.
Let me see the address of the people who send me e-mail... On hotmail, there is no way or option to see the e-mail address of the sender without opening the e-mail and we all know those nasty verify address e-mails by asking for a picture...
This is kinda unrelated yet not. But it's MS and SPAM in the same topic area, so I wanted to vent.
Is there a website out there that tracks the different technological solutions to spam, with pro/con explanations?
Don't some of the open source agreements have similar clauses for "patent free zones"?
One line blog. I hear that they're called Twitters now.
I downloaded the latest version of OO the other day, but haven't got round to dealing with the installation issues yet. Something to pass the time this afternoon :-)
(For any other Mac users with the same problem, TextEdit, as of Panther (10.3), can open Word docs.)
Using HTML in email is like putting sound effects on your phone calls. Just say <strong>no</strong>.
Funny thing is my openoffice opens them just fine.
Wow. I looked at MS' proposal as well as SPF's, and darn if MS didn't do much better.
First: SPF's webpage is mostly slogans about how it makes the world better, but you have to dig around a lot to find out how their scheme works. Mostly you'll just find more of the same self-hugging and no real technical info.
Secondly: MS' scheme seems simple enough, just one addition to DNS (list those mailservers allowed to send mails from your domain), and a very nice, standard-compliant way of handling the mobile-user problem:
If you're away from home and you're sending from your name12@somefreemail.com account, and you want your From: line to be your standard Me.Myself@my-own-domain.cx, whatever actual account you're sending through, then just make sure that your Sender: is name12@somefreemail.com and you're set. This is a nice alternative if you can't list your freemail ISP's mailserver in your DNS (maybe you don't know its IP address, or it's changing all the time).
Maybe SPF's scheme is similar, but they sure didn't mention any Sender: header there. Seemed to be some home-cooked up non-standard header, and a lot of talking about forwarding not working etc.
The only thing I didn't like with MS' scheme is the XML thing, why would you want to put XML in your DNS records? Nothing else in DNS is XML. Oh well.
Given the effectiveness of caller-id when it comes to the spammers of the phone world, I don't think it's the best model. Basically, caller-id allows anybody who has a PBX connected with digital trunks to the network to forge whatever caller-id information they want. Most telemarketers left it blank. Lots of legit companies send the id information for their main switchboard number, no matter what actual phone line the call is travelling down.
Notice how three separate Mac users have posted about this in the space of two minutes? The first gets modded Offtopic, I get modded Redundant, you get modded Interesting. Looks like the mods are on crack again :-)
Anyway, enough of this OT babble; I've got to get Open Office working...
Using HTML in email is like putting sound effects on your phone calls. Just say <strong>no</strong>.
I think "do we want XML" vs. "do we want a series of header fields" is asking the wrong question. It's the schema that's wrapped up in the XML or fields that's important.
XML is great for expressing tree-like data structures, where as the "field-name: field-body" approach is probably better for expressing linear data. If you look at a schema it is usually obvious if XML is being used just for the sake of it, and parsing SPF as it stands is trivial.
Companies with an "embrace, extend and extinguish" mentality towards standards can leverage XML by using it without any formal machine-processable schema (DTD, XSD or RNG), whilst all the while insisting it is "standard" because it uses XML. Look no further than WordML for an example of Microsoft doing this.
... and saw two things immediately.
a) Only available as proprietary Word docs.
b) It includes a license to use a MS patent.
No need to even investigate any further - the old boys aren't even hiding this one.. MS cannot be allowed to embrace and extend and destroy something as vital as the free flow of email. Fight it.
Seriously, I have been thinking about this sometimes, and tehre are probably a lot of people thinking something similar.
The whole mail structure (headers, body parts, attachments) could be translated to XML with little overhead (brackets and closing tags) while enforcing at least syntactic correctness with well-tested parsers. I could even imagine some kind of "mail markup" bundled with that, containing just tags for quotes, emphasis and basic text flow (paragraphs and linebreaks).
Add to that standard and mandatory (and possibly signed) "Received" headers so that a mail server can immediately ask a message source "did you just say that?" and drop messages without any known origin. That would take care of faked mail routes outside of untrusted networks.
Fight hunger. Filet a politician and send him to a 3rd world country of your choice.
...is *exactly* what they want to happen. They want to tie you to their way of doing things and forbid you to do things your own way.
Seriously, that's something you have to worry about. Microsoft is changing and, although they haven't been big patent litigators in the past, these are new times. Times in which Microsoft has to cope with the fact that it can no longer grow faster than the computing industry.
Previous comments have been for or against XML being used to deliver this information. I don't have a strong opinion either way on that; it seems reasonable enough. What does seem silly is that this information is being stuffed into a TXT record, and limited to 2k. A goal of using XML should be to easily add information and to make the information hierarchical. But that goal will likely never be realized in a 2k string. The XML tags will eat away at the number of allowed characters pretty quickly. And the zone file examples in the document are pretty ugly.
SPF is better in that it keeps the information simpler. If XML is should be used, perhaps the TXT record should simply include an HTTP URL to the XML file. Alternatively, a simple URL standard could be used, such that one could reliably get Caller ID information regarding mydomain.com from http://mydomain.com/callerid or http://callerid.mydomain.com/.
Why can't they use a PDF like normal people? Word is such a poor program in which to read documents. Oh, right...nevermind.
spf.pobox.com has pdf converted versions of the docs.. as apparently some versions of M$ Word can't open the documents..
Caller-ID in PDF
They'll let you use their idea, but only if you grant MS the same rights to any of your implementations of their idea. They're working on patenting their "CallerID for email" idea.
CRLF is a Microsoft-ism??
Maybe you should read a few RFCs. Like for example the venerable SMTP RFC 821 from August 1982:
By including the above notice in a Licensed Implementation, you will be deemed to have accepted the terms and conditions of this license. You are not licensed to distribute a Licensed Implementation under license terms and conditions that prohibit the terms and conditions of this license.
I guess this means no GPL apps, but I will now head to Groklaw and refresh the page until some legal info comes up
Nicely rebutted.
Hey freaks: now you're ju
Yes he is you idiot. The whole point of XML is that it the raw data file can be read by a human!!!
This is like that idea of storring torrents in the DNS. SPF is a nice simple implementation of sender verification without excessive bloat.. Using XML in the DNS is excessive bloat, Sending 2k+ data through the DNS? Why? it could be much better done in like 50 characters (ie. fit in one packet). This will slow things down soo much.. And then DNS maintainers will start limiting the size of TXT records, or blocking them and then the whole system will fail.
what you were really looking for is
"xml sucks" - 672
"xml rocks" - 79
you are a bigger majority.
-- Avishalom is usually vish
It's about time someone does something. The largest problem threathening the useability of Internet is that old protocols, often UNIX-related, were made, then put in an RFC, and then nothing could change anymore.
No matter how broken it is (for example SMTP's trusting that anything specified in mail from/rcpt to/headers is correct, or FTP's incompatibilty with NAT, or IRC's general uselessness) once it is in use, nobody dares to phase it out anymore. Instead lame kludges are added like EHLO instead of HELO. All to preserve the sacred backwards compatibility, in case someone still runs System III, Ultrix 2 or BSD 2.4
It doesn't matter that the whole service (in this case email) becomes unusable due to massive abuse, UNIX zealots just say "that's the way it's supposed to work, read the RFC". Meanwhile nobody considers email serious anymore, people are forced to use spamblocks and throwaway addresses.
I don't care who invents something, just do something already !
I wish this wasn't true, but if Microsoft implements some sort of spam-blocking in Exchange, that's all the critical mass you'll need. Especially if they turn it on by default.
And that is why Microsoft is using it I'm sure. They have a bunch of nice GUI tools that parse XML, so anything they do now has to be XML.
It's the same as the way they do email. If I switch to source edit view, my simple text message (e.g. Got It.) balloons into ten lines of generated HTML gobbledygook. Yes, I really need to specify the font for *each* line...even the ones that are blank.
I really hope that the standard is not set by MS. Something very simple (this is who can transmit for this domain) could turn into something ugly. I can write SPF declarations by hand. Chances are that their XML declarations will be twenty times as long and will need tools to create them. Yes, the XML parsing tools are ubiquitous, but a simple format doesn't require a parsing interface to feed you info. I see no reason not to make a human readable interface.
Many here have pointed out flaws, problems or complications with the proposal, I have a fundamental problem with it. .doc file. Who releases a proposed "standard" in a proprietary format? Shouldn't this have been plain text, RTF, HTML or even PDF so that everyone could read it properly?
.doc formatting in TextEdit yet.
They released it as a
Using a Mac without Office installed I get lots of document formatting commands interspersed with the text. Apparently Apple hasn't figured out all of the
Article X: The powers not delegated... by the Constitution...are reserved...to the people
A quick US PTO search reveals the "Caller ID for E-Mail" is a trademark held by an individual in Houston, Texas. He filed in March 2003 and claims to have used it in trade since December 2002.
There are several other similar trademarks, like "Web Caller ID" and "SBC Caller ID Internet."
I wonder if the MS lawyers cleared that term or not.
If I understand right then MS provides you a licence to use their "innovation" (I leave in the middle if it's a real innovation or not) for free, provided you allow MS and everyone else a free licence on your product? So you can use it as long as you give it back to the community? hmm... What a quaint idea.
Well, that's typically Microsoft, not wanting to use well-documented existing standards, and to reinvent the wheel.
:D
Oh, wait.
perl -e 'print "Just another Perl newbie\n";'
People need to quit fucking around and just rewrite the damn protocol. Instead everyone is trying to market their own antispam technology so they can tag themselves as the creator. This problem is NEVER going to go away until the protocol is rewritten. Period.
I am more concerned with the generation overhead. I can write an SPF specification by hand (plus they offer a nifty web tool to do it for you). It is human readable. An XML format can easily balloon into something that is not simply readable.
Email and DNS are both currently simple text formats. If they want to offer a new format for email and/or DNS that is XML based, that's fine (although I'm not really interested in adopting it). They can try to push the whole thing through and people can adopt it or not as they choose.
However, if they want to extend the existing formats with spam protection, it should still be a simple text format. SPF does this. It uses a standard +/- system to include/exclude certain entities from sending email. It works through DNS. No worries about commas, tabs, ends of lines, etc. DNS parsers already exist. This just adds an extra element to an existing standard.
Everyone seems to be going on about the speed of parsing xml, but what I hate about it is the bloat required just to read the damn thing. This is particularly relevant to devices such as mobile phones where memory is a limited resource. The speed is also an issue here such as when dowloading email onto a phone via WAP, not only because of phone responsiveness but also due to increased call times which means increased costs.
Will this technique really reduce the amount of false-header spam or will is simply annoy the spammers a little? I think the latter, and I think that Microsoft did nothink about this before writing their standard.
I predict that if a "standard" such as this is proposed, there will be a temporary drop off of spam, then things will return to normal, and get worse.
Current situation:
Spammer sets up some machines to connect to foreign SMTP servers and send emails in bulk
Future situation:
Spammer sets up a domain name for $5 and free DNS hosting at any of several services
Spammer puts authoritative records for each spamming maching in the zone file
Spammer sets up some machines to connect to foreign SMTP servers and send email in bulk
In the end, knowing the domain name is legitimate is not worth much for limiting spam. Or are we going to propose as part of the standard that there are only allowed to be up to 5 legal sources for mail from any one domain?
We know that spammers and other malicious people can worm their way in to literally millions of systems, once compromised a system could "phone home" to have the master server update the DNS. Keep in mind that this master server does not need to be owned (in a legal sense) by the spammer. The domain names could be purchased with stolen credit cards. The whole process simply takes an extra three days for the DNS system to propigate completely and a minor extra hassle.
The result: Spammers spend an extra $50/year on domain names and an extra hour per month maintaining code and database files, this is trivial to them. Also, legitimate DNS servers must handle a larger load, network loads increase with all the extra XML crap floating around, and in general every mail server on the planet must be modified to work with the system, all for a plan that won't change much of anything.
Article X: The powers not delegated... by the Constitution...are reserved...to the people
from my understanding of the licence: If I want to implement a compliant implementation, I can go right ahead. (as long as I promise not to bother MS about patents that I might own on this technology).
If I then sell or distribute the software I wrote: Fine.
You however get to pay MicroSoft to use my software.
Oh, and they've included a GPL incompatible advertizing clause.
Comply? Don't you mean obey? Let skirt around the euphemisms,smoke and mirrors, for a bit. This is the beginning of some sort of licensing/ID of all internet users. This isn't this first time we've seen horse manure in a shiny wrapper. Don't start grumbling when the powers that be decide it's best for you to use a government ID on slashdot instead of Hard Code as your handle. Then, they can punch up your number anytime they please and check you out. Of course, they'll have some "noble" excuse. Maybe you think that's great, but not everyone enjoys big brother and its self-appointed elite running every facet of their lives.
Why isn't it just as well to investigate some type of software restriction of email volume from a particular connection, which will actually address the problem? Is it possible for a network to know when a major bundle of email has been released? How hard is Microdsoft working on finding out? If someone wants to blurt out thousands of email, let them get registered. The net Microsoft wants to cast is too wide.
Identification always precedes restrictions. So, you've just cast your vote for the government censoring/removing internet content, or hassling the web site owner until they pull it. For all we know, the spam is coming from outside of this country to force the very restrictions you support. What right does a foreign country have to influence US domestic law, if there is that possibility? Just like most laws these days, the ones causing the restrictions will get around it, the problem will remain, and the only loser will be Joe Grunt taxpayer who's getting checked out for any "suspicious" moves, forever. Who defines "suspicious", someone who sees me as a political adversary?
I guess it is.... those terms are pretty much a rewording of the GPL, but instead of being for the public, it can be between just you and microsoft.
NO SIG
Colossal drawbacks to text? LOL! It is a feature. You could say the same for most internet services. There are no standard client API's for FTP or Telnet or most other services either. Has that stopped their widespread adoption? Has it made them any less useful? No.
I am not concerned at all of people like you who make the internet groan under the weight of 20MB excel files wrapped in proprietary XML formats. MIME has done enough damage. Maybe the Standard should be a Microsoft (C, TM) paperclip icon that does a dance while he speaks your message in one of a hundred supported languages.
an ill wind that blows no good
"why is it that it gets used for almost everything nowadays?"
for me its amazing to see the tree root structure of project definition creation, ( that's a mouthful). i don't think xml is an end-all solution. but for uses of organizing one's orientation of a project; its got lots of advantages.
Wasn't there an article on /. about how Microsoft owned the copyrights on XML (which seems bizarre to me).
Has anyone else mentioned this? (too lazy to surf forums)
Sigs are for Terrorists.
No responses! Compare to SPF:
Here is the real reason Microsoft had to publish their Caller-ID spec now!
Before replying with "those 7500 domains are tiny", AOL is publishing a SPF record NOW. Microsoft is not publishing their own Caller-ID record yet.
PJRC: Electronic Projects, 8051 Microcontroller Tools
...more spam comming from all those junk domains that spammers buy. It's not like spammers only have a couple legitimate domains to work with.
I have a list of hundreds of such spam domains in the form
if expression both matches "*610000x*" delete ""
if expression both matches "*64.74.124.113*" delete ""
if expression both matches "*66.235.226.100*" delete ""
if expression both matches "*abcpills4u*" delete ""
if expression both matches "*about-mtg*" delete ""
if expression both matches "*adweawen*" delete ""
if expression both matches "*adweawen.biz*" delete ""
It's not going to stop spam. There's no shortage of DNS services to allow people with home connections the ability to set up Dynamic DNS so they can have a domain always pointing to their shifting IP.
The one advantage this has over filtering out links in e-mails is that I can do the filter with only the FROM and connecting IP. Currently I have to recieve the entire message. But since all this filtering happens server side, I still save at least 50% of the bandwidth.
In actuality the header is irrelavent. Spammers use affiliate programs. Nearly every spam has a link. And most of those links go to the same domains. Block 1 IP and you completely miss the target. Block 1 domain and you block every single spammer that uses it regardless of how garbled the header is or who it is.
Those few spams that don't have links just get deleted. By filtering links I reduce the amount of spam to a trickle, have 100% accuracy, and anything that manages to get through is so little that just hitting the delete button isn't an issue. Updating the filter is a quick and easy operation.
As for being anonymous. All you need to do is host a web-site and use a simple PHP script that connects through your mail server with a generic account and allows anyone to send e-mails to anyone using it. My contact form on my site uses such a script except the sender and recipient are hard coded. If someone wants to be contacted they just include their e-mail address and it's added to the message body.
By allowing the recipient to be set by the user you meet your good friend "plausable deniability."
And if you delete all the logs that the script generates, there's nothing for anyone to seize.
With a simple question/answer challenge you can prevent spammers from whoring your script out. Not using a generic script in a generic directory like "formmail" also helps.
And since unlike "sendmail" the PHP script isn't actually sending the messages so a valid account has to be given so it can log into the actual mail server where all the filtering and security rules are in place.
Ben
Work Safe Porn
This is completely unnecessary, and already handled by SPF. Use "name12@somefreemail.com" as the SMTP envelope sender, and "Me.Myself" as the From: header. Apparently, MSFT isn't the only one that doesn't understand SMTP. :-)
And here's why. Say that you have your own domain and your e-mail is being hosted at who ever is hosting it for you. Now when you send e-mail out from that domain, you're going to have to use that same e-mail server no matter what. But lets say you have a dynamic ip address, so ur hosting provider can't then let all that ip addresses range through to send out e-mail. The normal course of action is for you to use ur isp's e-mail server to send out e-mail for your domain that you own. With this you won't be able to do that and will just make it more frustrating for users. We need a transparent solution.
My Gawd WTF...
"caller-id" for email won't work, all they'll have to do is hit *67!
fact: microsoft > linux
This won't work.
A few years ago, I got flooded with out-of-office replies to e-mail people were getting. the thing is, I didn't send it; someone had used one of the names on their spam list as the from: and reply-to: fields.
as I understand it, there's nothing that will stop this. Translation: this will slow down domain-spoofing spammers not in the least.
weylin
67.5% Slashdot Pure I guess I need to work on that....
On the outgoing server? The relay? The receiving server? The receiving client? Also, what are you checking? If you're using SAX, you can get one or two tags and parse them in that partial ms. What's going to take time is verifying the data, which may require talking to a remote server.
Best Slashdot Co
Even caller ID is spoofable ...
http://artofhacking.com/orange.htm
Caller ID spoofing was demonstrated in the last H2K2 forum in NYC.
So what it comes down it are two options.
We can either...
1. Comply
2. Not Comply.
In my humble opinion, I say we all NOT comply. Let's keep it open standard. Let's keep it within our own community.
Hotmail may have a massive customer base right now, but think of how fast that would dwindle if not a single other ISP signed on to their ridiculous "caller ID mail." - How many customers would stay if nobody could send them mail?
M$ would quickly change their hard nose approach, and think of some pretty quick alternative solutions...
Don't think that for a minute that we, the readers of slashdot are a minority. In fact, I'd say it's safe to say that we are in fact the majority of geeks that make a difference.
To comply, or not to comply... THAT is the question.
Anyone have a .pdf of the specification? I don't do .doc (or other proprietary) formats.
Doesn't sendmail already have a similar feature turned on by default? You have to explicitly enable "accept_unresolvable_domains" in your sendmail.mc file or mail from servers with no reverse lookups will be rejected.
According to
bash# for x in $(antiword callerid_email.doc); do echo $x; done|wc -l
this is a thirteen thousand word document.
Can someone explain in a sentence or two what's different about what MS is proposing and what sendmial already offers?
Trust me, people will do anything for porn.
Karma: Excellent (fuck, even in the future moderation doesn't work!)
OK, if it is already so easy to find out whos machines have been zombiefied, can't we: Write a spam killing virus as follows: Virus identifies machine that is sending out spam. Goes to it takes over and looks for another spam machine. When it finds a new host it copies itself to the new host and sets the previous host to do a D.O.S. attack on itself. Thus the spam machine goes down until some bright boy fixes it so it stops sending out spam.
excitingthingstodo.blogspot.com
You said it! I'm sure we'll all regret using a standard format for hierarchically arranged tuples of name-value pairs. I only have to use this type of data in maybe 99% of my projects.
And the output files sure are difficult to understand if you've never seen any markup language before and don't have a file viewer that understands ASCII text.
Instead why doesn't everyone just make up their own format that is uniquely tailored for the individual application? You can leave off the attribute names since the recipient of the data should just know what they are anyway. And you can use a binary encoding to really add efficiency to the process. And developers love the challenge of trying to figure out new data formats on top of interpreting the data itself.
If Microsoft and Sendmail are working together on Spam Solution, then I guess we can all rest assured that whatever they build, it won't have any buffer overflow problems. I, for one, am looking forward to use 1.0.0 version on my production systems.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
The official SPF Objections page has several solutions for you. One simple option: put your local SMTP account on the From: line and your Yahoo address on the Reply-To: line.
Please mod parent up: +5, Funny!
openvms will never die.
This specification says to use _ep.domain.com records in DNS. Aren't underscores illegal in DNS?
No, it sounds like you must allow Microsoft to distribute "other" licensed implementations, not necessarily yours. Seems to be some sort of patent/lawsuit prevention. The GPL people may want to look at this and perhaps copy it if it is a clearer way of stating patent protection.
XML? BWUAHAHAHA LAME.
Why the FUCK does every piece of microsoft software have to be XML enabled? Its a fucking joke. And its incredibly LAME more than anything.
SPF is so horribly fucked in the head it should be put out of our misery right now. RMX is the way. SPF and everything else can fuck off thanks!!!
var msxml = new ActiveXObject ("Msxml2.DOMDocument.4.0");p ace = true;
msxml.preserveWhiteS
var foo = msxml.createElement ("foo");
var bar = msxml.createElement ("bar");
msxml.appendChild (foo);
foo.appendChild (bar);
foo.appendChild (msxml.createTextNode ("\n"));
bar.appendChild (msxml.createTextNode ("baz"));
msxml.save ("c:\\temp\\foo.xml");
output:
<foo><bar>baz</bar>
</foo>
MSXML is required by law (well, the XML spec) to normalize CRLF to just LF, so if your users demand a DOS-style end of line they're out of luck.
Yes, indeed!
I went to add the appropriate entries to a couple of my domains, and started getting errors up the wazoo!
From RFC 1034, on allowable names:
For more information, see Verisign's page information regarding using other characters in domain names, which includes the RFCs for their proposed encoding scheme for additional characters.
Stupid Microsoft! Their "Caller ID for Email" specification cannot even be implemented.
the sentance:
With smtp-auth, it is still possible to send using an smtp server connected anywhere on the net, which allows accountability, but also makes it more possible to identify those providers who are allowing their users to send spam.
should be corrected to:
With smtp-auth, it is still possible to send using an smtp server connected anywhere on the net, which allows annonymity, but also makes it more possible to identify those providers who are allowing their users to send spam.
As usual, my carelessness got in the way of my expression.
Read, L
How exactly would you use your "human-readable" text format to store name/jpg pairs?
I'm not saying text files have no place, but if you think they are the "solution for all life's problems" then you're wrong.
Get rid of everything Micro and Soft: Buy Viagra and/or Linux
All 3 of the main proposed systems (M$CID, SPF, DK) out there work over DNS.
DNS is normally UDP (fast, small, easy), with a fall back to TCP only if packets are over the 512-byte UDP max size.
SPF and DK make sure and do their best to squeeze all data inside of this limit, they must know that running DNS via TCP is untested and adds a lot of overhead in doing so.
But M$ must figure "oh well", better to have nice clear, already-coded-into-Windows-libraries XML - even if the added fat will break the UDP size limit much more often.
Basic culture issue...
oh, no need to mod this up based on M$ bashing...
...unless your own network is. DNS records: domain A's , mailserver MX's, or SPF, M$CID TXT records are cached locally by your own resolver. Once the initial lookup of that record takes place, every other one after that (up to the expire time) comes from your local system.
So tell us again what sort of DNS work you did? Some batch process of a bunch of never-before-resolved domains? Apples & oragnes bud, both fruit, but differnet trees.
ps. DNSBL lookups are Mangos!
It took 100 posts for this follow up, but right on!
DNS use of UDP limits packet size (512bytes) - and that's a good thing. Big bloated M$CID XML chunks force DNS onto TCP with all the handshake and handholding that goes along with it... laaaaaaaaaaame.
sheesh, shouldn't this entire thread be mod'ed down as Off-Topic?
...
:/
i had to page in 3 pages before i got to a discussion about the issue @ hand.
now i guess i'll wait to see *this* post get modded down as offtopic (what irony) or a troll
in this age of communication i'm just not getting through
Just read the spec and I think its horrible. In the preamble M$ talk about how DNS already has a record for where mail should be delivered TO, then they discount the idea of having a record of where mail should be delivered FROM and move on to creating a SUBDOMAIN with a TXT record. guess what the subdomain is called - "_mp". Yuck Yuck Yuck. And I'm not even going to talk about having XML (limited to 2048 bytes) which no longer leaves DNS as a text protocol. This is a complete ugly hack!
Clearly AOL's Sender Permitted From idea is laods more in the spirit of existing DNS usage.
SURELY NOT!!!!!
Lots of e-mail already gets rejected these days if the IP address can't be matched to the hostname (according to the MTA). Personally, I get around that problem by using my dyndns.org hostname, and dyndns.org is already using SPF, so you can too without losing anything.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Is a really smart guy. I went to high school with him and he kicked @ss in math, the sciences, and of course, comp sci. His webpage is here