Microsoft Releases 'Caller-ID For Email' Specs 430
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."
XML... in its place. (Score:5, Insightful)
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 :)
Re:XML... in its place. (Score:5, Insightful)
While I agree that there are no absolutes, why not go with the path of least resistance when it doesn't really matter? XML has become the path of least resistance *at a macro level*. it's universally accepted these days, so unless there's a compelling reason *not* to use it... use it.
The reason I say at a macro level, is that yes, on an individual project using XML may be a bit harder -- though most development platforms these days have trivialized the difficulty of implementation.
Re:XML... in its place. (Score:3, Insightful)
And there's the rub. It's so damned easy to parse XML these days, why reinvent the wheel having to parse a comma delimited file, a fixed width file, a bizzare internal format?
Re:XML... in its place. (Score:5, Insightful)
Re:XML... in its place. (Score:5, Insightful)
agreed, if you want to be picky it's not a format by itself, but XML as a framework for structuring data (to include DTDs, XSLTs, etc.).
The term 'XML' is used generically these days as reference to a particular way of structuring data as contrasted to other ways.
What XML REALLY is.... (Score:5, Funny)
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 [unicode.org] symbols: 2169,216F,216C
Re:XML... in its place. (Score:5, Informative)
Re:XML... in its place. (Score:5, Interesting)
Assuming you don't have a DTD, you don't have a specification of what's in the files syntactically, let alone semantically. Maybe you can reverse engineer most of this (the tag "name" is likely to contain a name, etc.) but there will always be freakish exceptions and ambiguities that even DTDs and XML-Schemas don't address.
And the overhead of using XML is enormous.. All those possible encodings, character sets, namespaces, etc. S-expressions are really much, much nicer is you just want to parse without a formal syntax specification. And they've been around "forever".
Most irksome though, are so-called "XML databases".. Argh! I suppose the people who think that's a good idea also love "CSV databases" or "XLS databases"..
And that is why (Score:5, Interesting)
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.
Re:uh, yeah (Score:5, Insightful)
Nothing wrong with agreeing. Agreeing on a standard that's cruddy will bite you in the ass. There are many, many standards, and most of them are cruddy.
And "name-value pairs"? How do attributes figure into that? Well.. Cruddily, that's how!
Perhaps you're thinking of RDF (which has issues of it's own.. A lot..).
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.
XML allows for a lot more than ASCII.. Which is the reason a fully compliant XML parser is enormously bloated.
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.
Slippery slope? Or straw man? The latter. I never said no standard should be agreed upon. I would have preferred if it had not been something as complex and cruddy as XML. I even specifically gave S-expressions as an example that would be much simpler; you might note how that's not a binary format.
One day, ASN.1 was what XML is now (well, it still holds telecommunications and cryptography in its stranglehold). Do you propose we use ASN.1 because it's so well accepted and standardized and there are so many tools? Or do you recoil in shock at how bloated the featureset is, how convoluted the encoding, how shockingly incomprehensible the parsing process? XML is simpler than ASN.1, and XML is better than ASN.1 (except that ASN.1 has a cute way of compiling parsers from its syntax/schema language, which is a nice feature); but that does not mean XML is the best general purpose meta-syntactic language imaginable. It's not.
Re:How about text? (Score:5, Insightful)
I wish you would learn something about existing mail standards-- like their colossal drawbacks. SMTP is entirely "a simple text format", and that's one of its biggest problems. We have all kinds of lame hacks for mailing binaries around and handling attachments. Nearly everyone who writes a mail client writes a mail parser and a composer. Not just a formatter, or presentation-level stuff-- basic goddamn parsing and composition.
You don't seriously believe that any format that is newline-dot-newline-delimited is a good one, do you? SMTP is a relic, all the way down to the message format. I hope to god someone eventually succeeds in dislodging it.
Email standard proposal (Score:5, Insightful)
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.
sucks / rocks (Score:5, Funny)
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.
Re:sucks / rocks (Score:5, Funny)
XML Rules = about 2,580,000
Re:sucks / rocks (Score:5, Funny)
"XML rocks" = 79
"XML sucks" = 671
"XML rules" = 5630 (obviously they're actually talking about rules here, and not commenting on quality - perceived or actual)
"XML pwns j00" = 0
Obviously the poor kids using 1337 speak have obviously never picked up the standard...
Re:sucks / rocks (Score:3, Informative)
For those of you born after most mainfraimes, ANSI EDI is Satan's preferred method of data exchange. It is based on the assumption that characters are expensive to transmit, so they minimize the file to as few characters as possible using codes that might have had meaning when they wrote the standard, but not anymore. Most times, the files don't even transmit eol characters. It's a mess!
Re:sucks / rocks (Score:3, Insightful)
It's so much fun that it causes buffer overflows all over the place (Microsoft OSes, OpenSSL...)
Re:XML... in its place. (Score:4, Insightful)
XML is handy, and it's a lovely big hammer. Ooo, look at all the nails!
At least (Score:3, Interesting)
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.
Re:At least (Score:4, Informative)
Parent is +5 interesting? Could anyone who moderated it up provide a reason other than they're bashing MS, that's +1 baby!
Re:At least (Score:5, Interesting)
I did read the article. But MS has a history of breaking standards to create customer "lock-in", and also trumpeting open standards when in fact what they finally implement isn't open at all (Office "XML" for example). What I'm saying is that, in this case it would be difficult for MS to do that because email client software is very varied.
Re:At least (Score:3, Informative)
The XML is in plain english (well technical english maybe, but it isnt encrypted/encoded gibberish) , and very easy to use. I write applications all the time that output word, xl, and popwerpoint files from code.
I think you jus
Re:At least (Score:3, Insightful)
Re:At least (Score:3, Insightful)
Re:At least (Score:5, Funny)
Could anyone who moderated it up provide a reason other than they're bashing MS, that's +1 baby!
Well no. They can't comment if they moderate now, can they?
Ray
Re:At least (Score:3, Informative)
D'oh!
two things (Score:5, Interesting)
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.
Re:two things (Score:5, Insightful)
Re:two things (Score:5, Insightful)
Re:two things (Score:3, Interesting)
That's true in the real world too. They're called postmarks. You may have seen them stamped on your snail letters.
Don't like it? The don't send email that complies with the standard and hope that the people receiving are willing to read letters from people who aren't complying. Or use a messageboard. Or a
Re:two things (Score:3, Interesting)
You don't necessarily want customer B to know that you also work for customer A.
- Erwin
Re:two things (Score:3, Informative)
Problem solved.
Re:two things (Score:5, Informative)
I don't know about all free email services, but Hotmail does not allow this anymore. Accounts are limited in how many messages per day they can send out. This is why most spammers are still relying on open relays and zombie machines.
Re:two things (Score:3, Interesting)
Which begs the question, how does this solution deal with zombie machines, given that these are being used more and more to send spam? It shouldn't be too difficult to set up a trojan remailer which uses the user's email account to forward spam. Wouldn't this be declared as valid, and presumably laying the blame on the user.
Re:two things (Score:3, Insightful)
Yes - and then we'd know exactly who's machine has been trojaned with much less effort. The ISP can then disconnect them until they have patched their OS/removed the trojan.
Re:two things (Score:4, Insightful)
Having correct sender addresses would be nice, and would force spammers and virus writers to adapt somewhat. The question is whether the effort of implementing it is worth it for the gains available.
Re:two things (Score:3, Interesting)
A couple years ago I wrote a bunch of software for very large e-mail runs -- not spamming related, but the lists were in the high hundreds of thousands -- and to successfully blast out hundreds of thousands of e-mails in any reasonable amount of time requires quite a bit of planning, software built for that purpose (our eva
Re:two things (Score:5, Informative)
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.
I don't think so. What people can find out is what IP addresses are valid when sending email from a domain. Nothing more. All they are doing is a lookup on the connecting IP against the FROM: domain. Hell, that information is in your headers anyway. (Well unless you're using a remailer)
Re:two things (Score:5, Insightful)
The major problem with ALL these systems is critical mass.
Corporations are not going to be blocking mail based on a lack of SPF, Caller-ID, or anything. Too many companies are going to be slow to implement, or apathetic about it. No larger business is going to block mail and potentially lose contact with potential customers, or existing clients.
90% of the current crop of spam would stop if all ISP's would block outbound port 25 from dynamic IP clients by default (unblock if the client agrees to keep their system patched and secure and face penalties if found spamming.)
For the most part, open relays have been closed due to RBL like activity, as enough sites use RBL's to make life very difficult for admins that leave their systems open. So spammers have moved to dynamic's, which there is a virtually unlimited supply due to the piss poor security of Windows and clueless users. RBL's are helping with that too, but it's hard to keep up. Again, many corporations won't use RBL's due to problems noted above.
While I have not read the detail on MS's solution, SPF has the "roving user", "mail forwading" problem that there is no solution for that has been discussed to death. Anyone know if MS's solution has the same problem?
Re:two things (Score:3, Informative)
In summary, the 'roving user' problem can be solved by any of the following:
* SASL enabled SMTP on the SPFed SMTP server for the domain. Users then send their mail via that server instead of $RANDOM_ISP server. Port 25 blocking by the ISP isn't an issue since there's another port for SASL SMTP.
* Provide web mail access for roving users.
* Provide shell access for advanced roving users.
(Personally, I use the latter).
The
Re:two things (Score:5, Insightful)
For example, it allows me to tell SpamAssassin that IF a domain has SPF-records, and the email doesn't come from one of the ips that send mail for that domain, then in the spam-bucket it goes.
Thus, for example, all the spam that claims to be from hotmail is gone.
Secondly, I can, by publishing spf-records on my own domain eliminate the problem of spam bouncing back to me because it *claims* to be sent from me.
Third, once a sufficient part of the people I communicate with email from domains that *have* spf-records, I'm free to, for example, implement a challenge-response system for email coming from other domains. Yes, this will mean people using those domains gets some challenges based on spam that only *claimed* to be from their domain, but actually isn't. That migth serve as a good incentive to get them to also publish spf-records. It's not as if it's a huge deal to stick 2-3 extra records in your dns-info.
Re:two things (Score:3, Interesting)
TCP/IP
HTTP
SOAP
FTP
SMTP
If
Instead of complaining, contribute, find a good place to start with and improve it over time - that is what has happened to all the above protocols.
Imagine when Hotmail gets this (Score:5, Insightful)
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.
Re:Imagine when Hotmail gets this (Score:5, Informative)
It is called defensive patenting. There is nothing wrong with applying for a patent on this. We do not want another Eolas, where some other company that produces zero innovation gets a patent on it instead, and puts a strangehold on the industry. While not perfect, Microsoft has been pretty good about not going after other companies with frivolous lawsuits over patenting issues. Since the USPTO now seems to accept pretty much anything, companies have to apply for patents on whatever possible, so that they have something to use to defend themselves in the future.
Re:Imagine when Hotmail gets this (Score:4, Insightful)
From the "terms of the patent license for implementing this specification":
Re:Imagine when Hotmail gets this (Score:4, Informative)
If you implement the patented technology, you must allow MS to use and distribute YOUR IMLPEMENTATION if they want to.
I.e. Give them your code.
Re:Imagine when Hotmail gets this (Score:4, Insightful)
I don't want to have to make my mail servers compliant with this AND SPF, I also do not like the idea of sending XML packets to/from Hotmail (and other MS mail system) for every email allegedly from them.
Also I'd rather not use an MS solution since there are always security holes. How long till the spammers find a way around this and start sending out spam via a flaw in Hotmail?
MSXML experience (Score:3, Interesting)
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.
Re:MSXML experience (Score:4, Interesting)
Tell me about it. My favourite part is when you try to load one of their MSXML-generated files into their Visual C++ 6.0 product and it bitches about lines being greater than 2048 characters long and how it's going to shove random line breaks in the middle of tags.
Thanks, MS!
Re:MSXML experience (Score:5, Insightful)
Maybe that's the "right" way to do it, but I highly doubt that you cannot set the value of a text node to a string that contains an entity (i.e., "this is an ampersand: &"). That would be the more direct approach.
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!
First, you could have them read the file with Wordpad or just about any text editor other than notepad. And BTW, why are you complaining about MSXML not generating CRLF? You DO realize CRLF is a Microsoft-ism and not "standard", right? So you're complaining about MSXML generating text files in a manner more in line with the way every other system does it. Baffling...
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.
I've got news for you -- every decent XML parser library requires you to manipulate the XML tree in an object-oriented manner! It's called the Document Object Model for a reason -- you're not manipulating raw text! You can go ahead and do that if you like, and we'll see how much "easier" that is for any project requiring more than the most basic use of XML.
Mods, get a clue. The way the MSXML library handles XML is not unique in some "Microsoft always makes crap" kind of way. Every decent XML library handles XML the same way.
Re:MSXML experience (Score:4, Insightful)
This isn't true. The SAX API is event-oriented, and though it may be a little bit more difficult to wield than DOM it has the advantage of giving you complete control over memory allocation. That is, you can allocate as little as you need, and only when you need it, whereas DOM libraries allocate all that is required to completely represent the entire document in memory up-front.
Every decent XML library handles XML the same way.
Also not true; the same example suffices.
Re:MSXML experience (Score:3, Interesting)
Re:MSXML experience (Score:5, Informative)
Er... in that respect, Microsoft are following the standards, because that's how it's done with the W3C's Document Object Model. If you have a problem with it, you have a problem with the DOM, not with Microsoft.
Again, that's your fault, not Microsofts. Either live with it, or split out the XML-generation code into a separate module. The world and his dog has long since learned to separate out logic code and database-access code so that it's possible to change DBMS by just rewriting the database-access module rather than the entire application - exactly the same thing applies with XML.
Zombie Boxen hastens Trusted Computing? (Score:5, Insightful)
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.
Re:Zombie Boxen hastens Trusted Computing? (Score:5, Insightful)
As an aside, I set up a firewall, and the equivalent of Internet Connection Sharing (i.e. forwarding) on a Linux box the other day, IIRC it needed 4 lines of commands to iptables in one of the startup scripts, which being lazy I got out of a book. I went to grc.com for a test, and it was every bit as good as Zone Alarm, a product I use successfully on the inferior OS.
The point is that in an open OS, useful and essential things tend to be fully documented, visible, and easy to set up. I fear that in this case, Sir Bill's anti-spamming system will be obfuscated, needlessly difficult to configure, and will at the slightest provocation automatically default to doing it Sir Bill's way, even if that is not what you want. There is a precedent in every previous M$ application, the world's most unpopular Word processor being the prime example.....
It is of course another con trick to move us towards Longhorn, which on its own would get no acceptance whatsoever, because its drastically cut-down API set will break compatability with virtually everything. of course, if the Convicted Monopolist was competent, they would have had a much smaller, more manageable and properly documented API set in the first place, and we would not have nearly as many bugs, crashes or security holes.
It seems to me that someone needs start the RFC process right now, describing a properly working, non-proprietary system. Otherwise, the Convicted Monopolist will once again do as described in the Halloween Documents.....
Re:Zombie Boxen hastens Trusted Computing? (Score:3, Insightful)
I mean, wtf?
We can stop Zombies too... (Score:3, Interesting)
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 [nildram.co.uk], 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
thanks (Score:5, Insightful)
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.
Re:thanks (Score:5, Informative)
Unfortunately, this rarely is implemented. Why? People can't seem to figure out how to set up their DNS zones. So whenever I've implemented it, we always get calls from people saying "my mail is getting bounced, error code 0-B". And we go and look, and it's some client trying to send mail from their in-house mail server legitimately, but they don't have it configured properly in DNS.
The volume that we get of people complaining about it is high enough that we can't leave it turned on, and I'm unwilling to do tech support on someone else's name server. So, even though it blocks about 1/3 of all the spam we get, it stays off.
~Will
Re:thanks (Score:5, Insightful)
Mine you, you're talking about your block of residental DSL users that run their own mail server (commercial DSL users generally do get the reversing mapping through their ISP); they will most likely not be clients and may be a larger source of spam than other sources.
Re:thanks (Score:3, Informative)
PR Issue (Score:4, Insightful)
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.
If Microsoft cared about SPAM... (Score:4, Insightful)
Re:If Microsoft cared about SPAM... (Score:5, Informative)
Re:If Microsoft cared about SPAM... (Score:4, Interesting)
I think that's a pretty expansive definition of SPAM. Does everything annoying become SPAM? I see popups as advertising (and something that mozilla effectively killed for me), and SPAM as fraud.
Danger! Read the fine print! (Score:5, Insightful)
(From Microsoft's license [microsoft.com].)
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.
Pure FUD (Score:5, Insightful)
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').
Re:Pure FUD (Score:4, Interesting)
There is something called copyright law. Microsoft or any other company cannot just go and resell your software on their own terms.
Unless you grant them a license.
Which appears to be precisely what their license requires you to do. It's not clear to me precisely what you're licensing to them, maybe it's just any patents you hold on the techniques used, but it doesn't say that. What it says is that you grant them an unlimited license to "make, use, sell, offer to sell, import, and otherwise distribute Licensed Implementations", which certainly sounds like you're giving them permission to do what they like with your software.
I may be misreading this, but that's what the plain language seems to say. I'd want to get a legal opinion before I'd interpret it any other way.
Re:Danger! Read the fine print! (Score:5, Informative)
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".
Re:Danger! Read the fine print! (Score:3, Funny)
--LordKaT
Why we shouldn't use XML here... (Score:5, Insightful)
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.
Useless only for large documents (Score:3, Informative)
Re:Why we shouldn't use XML here... (Score:5, Insightful)
Oh, pleeeeeze!
Is there no end to the Microsoft-bashing in this forum?
If Microsoft had done this using a home-made format, then everybody would be screaming death to them for inventing their own standard "just like they did with Word documents".
And when they do use a public format like XML? Then we all scream death to them because XML is so bloated etc. etc.
It's time to grow up.
PS. I will NOT make the mandatory "I really don't like them, but in this case..." argument, which seems to be the only standardized way of saying anything positive at all about Microsoft here.
Re:Why we shouldn't use XML here... (Score:5, Interesting)
I ain't bashing Microsoft and I don't spell it with a '$' either. I've spent the last 14 years programming using their tools and operating systems, so quit with thinking i'm an OSS zealot.
So read my comment again - i'm not bashing them, and at least they're doing something about spam. But for such a simple datastream, with the throughput needed, it seems unnecessary to bloat it (cpu and memory wise) by having to use an XML parser, regardless of which evil/non evil company designed it.
Would YOU like your mail to be delayed because some bright spark decided to go all trendy and use XML in the mail processing rather than something which just does the job?
Port 25 (Score:3, Insightful)
N.
bad idea (Score:3, Funny)
Spoofing SPF? (Score:3, Interesting)
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!
microsoft.com already doing this (Score:5, Interesting)
_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
Good idea (Score:5, Interesting)
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.
Damn advertising-like clause again (Score:5, Interesting)
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?
SPF? (Score:5, Informative)
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
Re:SPF? (Score:3, Informative)
This is rather unfortunate... (Score:4, Insightful)
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.
Do you Microsoft (Score:4, Insightful)
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.
What is a PGP signature? (Score:5, Informative)
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.)
MS is trying to pull a fast one (Score:3, Insightful)
Once they authenticate everyone using their anti-spam system, they'll be able to authenticate for financial transactions, etc...
What about 'localhost' servers with dynamic IPs? (Score:5, Insightful)
Has caller ID worked on phones? (Score:4, Insightful)
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".
Summary (Score:5, Interesting)
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.
Poor Name (Score:3, Interesting)
It's not the metalanguage that's important (Score:3, Insightful)
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.
Dogfood (Score:4, Informative)
No responses! Compare to SPF:
Here is the real reason [infinitepenguins.net] 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.
Re:Dogfood (Score:4, Informative)
[craig@belphegore craig]$ IDN_DISABLE=1 host -t txt _ep.hotmail.com
_ep.hotmail.com text "<ep xmlns='http://ms.net/1' testing='true'><out><m><indirect>list1._ep.hotmai
[craig@belphegore craig]$ IDN_DISABLE=1 host -t txt _ep.list1._ep.hotmail.com
_ep.list1._ep.hotmail.
[craig@belp
_ep.list2._ep.hotmail.
[craig@belphegore craig]$ IDN_DISABLE=1 host -t txt _ep.list3._ep.hotmail.com
_ep.list3._ep.hotmail.
It' s not *just* that it's XML instead of more concise readable text, though that certainly is fucking idiotic.
Re:Why not? (Score:5, Insightful)
They already have systems that do this [challenge-response], you know. This doesn't require any changes to standards; but it does require that the sending user be clueful - and given how quickly Netsky.C spread, I think that's a hopeless cause.
In the US at least, caller-ID is not a challenge response system, it simply displays the originating phone number - and ONLY if you haven't requested that your number be hidden, and only if you live in an area that supports it.
So, what lessons can we carry from this fact to MS's suggestion of "caller ID" for email? 1. We'll still get emails that are unauthenticated, because it will take a long time for folks to upgrade MTAs to manage this - after all, there are still open relays - and 2. someone will figure out some way to sell a solution to get past the authentication system so blocked spam senders can still get through (can you say "sales@viagra.hotmail.com"???).
Re:Why not? (Score:3, Interesting)
So every person that wants to email you, now has the added burden of phoning some system and following the voice menu options? I think that most people will simply not bother and won't send the email at all.
Email is a great tool and easy to use. Even existing challenge-response systems have been found to have many problems. Let's not ruin email,
Re:Why not? (Score:3, Insightful)
Because it would not work... (Score:5, Interesting)
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.
Comment removed (Score:4, Interesting)
Re:Try OpenOffice.org (Score:3, Informative)
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.)
Re:MS 1, SPF 0 (Score:4, Insightful)
The Sender entry in the headers is often added by MTAs as the value in the SMTP envelope's MAIL field. This is the same value that SPF validates against.
Just because you don't understand SMTP and SPF is written in RFC language does not mean that Caller-ID is better. The XML in DNS TXT records is a big deal. The fact that with Caller-ID you have to validate after DATA is a big deal. But you won't understand these issues if you don't understand SMTP.