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."
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?
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.
XML is not a data format. XML is an idea. You still need the DTD.
RTFA - Microsoft proposes a standard which any vendor can implement and provides a license for its use on the website describing the process. There sis nothing client specific about the implementation.
Parent is +5 interesting? Could anyone who moderated it up provide a reason other than they're bashing MS, that's +1 baby!
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.
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.
Sort of. You don't REALLY need a DTD - you only need one if you are validating the XML. XML can still be used as a generic ad-hoc hierarchical data format... of course you'd only want to do so because by now XML parsers are pretty ubiquitous and it makes it as good a choice as P-lists, or any other ad-hoc format.
It's 10 PM. Do you know if you're un-American?
The SPF guys have them: http://spf.pobox.com/caller-id/
Registering accounts later than some other chrisb since 1997
It shouldn't have taken so long, but they claim that it's coming.
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
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)
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".
One of the most effective ways I've ever seen to filter out mail is to just simply follow the RFC. When you get mail from a domain name, look up the ip address, when you get the ip address, reverse lookup the name. If forward and backward don't match, reject the mail.
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
sig?
Have you ever used office XML? I have. Their namespace is of course proprietary, but EVERYONE's namespace is proprietary. There isn't a standard document schema out there. (And no, OpenOffice and StarOffice etc are not standards, they may be open, but they are not a standard.)
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 just like to bash MS.
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 *
Reread it.
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.
Ooh, edifact! I dream of edifact! We're still using ANSI/X12 EDI.
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!
SPF is already a IETF draft, the first stage towards RFC-style standardisation.
Rich
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
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.
too bad MS has patented XML(or attempted to before it gets shot down)..jsut another MS land-grab
D'oh!
Did you read the licence file? It grants you "a fully paid, royalty-free, non-exclusive, worldwide license under Microsoft's Necessary Claims to make, use, sell, offer to sell, import, and otherwise distribute Licensed Implementations"
that is, it's free, so long as you grant a reciprocal licence to microsoft for your implementation.
You can't win Darth. If you mod me down, I shall become more powerful than you could possibly imagine
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.
The SPF website gives the solution for the 'roving user' and 'mail forwarding' problems.
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 forwarding problem can be fixed by rewriting the envelope. The solution is shown on the SPF website.
Oolite: Elite-like game. For Mac, Linux and Windows
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>.
Problem solved.
A host is a host from coast to coast...
Unless it's down, or slow, or fails to POST!
True, XML is overkill for many many uses, but the matter of fact upside is ubiquity. I disagree in that a DTD gives you anything other than validation. Even if you have a DTD you can only validate the STRUCTURE of the XML...you still can't glean any MEANING from it. Which is why a lot of platforms simply choose to parse XML loosely with regular expressions and just treat it as a simple hierarchical format.
There are certain discrepencies between XML and S-expressions. It is true that any of these other formats "would do", and believe me, I am by no means an advocate of inappropriate, and over- use of XML, but the reality is that the proposed format is so tiny to begin with, and XML is so universally accepted, that it is practically moot whether this or that format would be "better". There are already a wealth of tools to index, mine, translate, etc. etc. XML.
It's 10 PM. Do you know if you're un-American?
And considering how they treat other standards, why should anyone trust them? Look at what they tried to do to Java... it was intended as a standardized programming language that would work exactly the same on any platform to allow the creation of truly portable applications, and they decided to use their browser dominance to get people to start using a non-complying implementation and writing code that wouldn't work except on Windows machines. This, more than IE's HTML and CSS extensions that make the vast majority of the pages on the web non-valid HTML, shows their complete disregard for the concept of "standards". They only like a standard insofar as it can help them control the market.
Don't blame me; I'm never given mod points.
One could also use "pop-from" authentication for roving users.
I've got a whole mail server with 20k users on it that only half of whom connect to the same network.
"Pop-From" just makes the user check for mail first, when a successful authentication for POP3 has been completed, SMTP traffic is opened up for 30 or so seconds after the last download. The email software then can have SMTP accepted by the server to send out their mail.
It works great, no messing with settings for roving users at all. Just about any email program I have run across works with it without further messing around, though Outlook has to be told to no "send immediately" otherwise the mail gets stuck in it's outgoing queue.
And I still haven't figured out how to make the thing give me a CRLF at the end of each element.
Tabbing, spacing and linefeeds are not required in XML, and everybody wants to use them a little differently. No, MS' API doesn't do it automatically, but you can do it programmatically fairly easily by appending an XmlWhitespace object after each XmlNode. You can retreive one of these from an XmlDocument by calling the doc.CreateWhitespace(sting whitespace) method.
I do that at the beginning of the program, assing the whitespace to a variable called xCRLF (along with another called xTAB), then every time I do a Node.AppendChild(element), i call Node.AppendChild(xCRLF) as well. Result is perfect tabbing.
MS' xml API is pretty robust and fairly easy to use, even if it gets a little crazy. For the longest time they had a superior XSL processor (now it's about equal to XALAN), at least from a "I am an XML idiot trying to learn how to use the technology BEHIND the keynote speeches" standpoint.
Hey freaks: now you're ju
XML parsing isn't that slow, I bet the time it takes to download each message will be the bigger bottleneck until latency and throughput for in-home internet connections is to the point where we need gigabit ethernet to get connected.
The point for XML is that it's a standard way of presenting data. No issues with using commas, tabs, or INI-style presentations (or issues presumably with the differing end of line format between *nix and Windows/DOS).
IOW, I sincerely doubt the overhead is going to kill anyone.
All I know about Bush is I had a good job when Clinton was president.
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.
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.
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
CRLF is from CP/M, which was based mostly on the Dec operating systems such as RSTS/e and RSX-11M, and on the pdp8 systems (I forget what these were called).
The original reason for it is that mechanical teletypes did not have enough power in their motors to both advance the platen and return the carriage to the left border at the same time. So they split these into two steps and built "CR" and "LF" into the 5-bit baudot code. Believe me they did this only because they needed to, the most popular baud rate then was about 50 baud so the time wasted was considerable, and certainly there was no precedence for such a design in existing typewriters. ASCII teletypes were made with minimal changes and thus inherited the CR LF pair.
It seems until K&R thought it was acceptable to put some smarts into the terminal driver so it would translate a single character into a pair, everybody was forced to copy this standard so that text files would print correctly on a teletype. Why K&R chose LF instead of CR is confusing, but I think they wanted to keep CR for overprinting, while the old function of LF was pretty useless. They should have made input turn CR into LF, however.
In any case if anybody asks, MSDOS is based on 1940's technology. At least Unix is based on 1970's technology.