As usual, Microsoft doesn't keep to the specifications and just looks at the file-type according to the header of the file (and maybe the extension of the filename). Then it takes an educated guess
That's not entirely correct, and it's not just a Microsoft problem, but an "everyone at fault" problem. Apache serves up files with unknown extensions with a default content-type (application/octet-stream), rather than with no content-type at all. Internet Explorer therefore doesn't believe the default types of octet-stream or text/plain and so looks at the content, and the file extension, and if it has that extension registered at an OS level processes it as if that content type was "correctly sent" for that file. It does not does this every time and ignores mime types as you suggest.
IE also has 26 hard coded MIME types it understands without having to refer to the OS (useful stuff like graphics and some sound files).
However now throw XP SP2 into the mix. Now IE, by default, no longer guesses, instead it will render according to the MIME type sent in the headers, unless you use advanced options to turn the new behaviour off and default back to the old way.
Finally note that the HTTP spec says
"If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URI used to identify the resource."
Apache's default installed behaviour of sending the content type as an octet stream breaks that.
Wardriving just won't be cool any more, not when you can sit in your front room, in your boxers/tighty whities watching star trek and hacking two towns away.
wonders what F-Prot and Command-com antivirus need to do to get on the "trusted" AV list at Microsoft.
Plug into a published (long before beta1) API, using WMI/WBEM. Even Symantec still haven't got it fixed for some versions of their pile of poo scanner.
Having gone through a week without RSS because my laptop keyboard died and it went away for repair, it was RSS I missed the most. It's the same problem I've seen with mobile phones, once you have the ability to save a number, or a URL, and not have to type it every day you forget the details.
And so, not having a recent backup of my OPML file, my lack of hourly updates on sites I like but can't remember where the heck they are was a real killer.
Actual web and browser access? Didn't miss it so much.
And whilst a new codec with Unix support is nice, and encoding is nice, how may average listeners are going to download mplayer?
Unless they produce a DirectShow filter for Windows (like ffdshow does for DivX), they're excluding that rather large desktop market of listeners. Their research page says they have volunteers to code the filter, but until that arrives the codec is playing to a very small audidence. (A bit like the BBC digital channels <g>)
There was spy/scumware that did that, editing the hosts files to redirect google.com and other search engines to themselves (hiding at http://64.191.95.139 - now offline) instead.
Not really. MS SQL used to be Sybase, and thus TSQL used to match. But since 6.5 Microsoft made SQL Server their own, changed the engine to be more ANSI SQL 92 Compliant (ANSI joins in Oracle? Hah), and now as SQL2005 comes over the horizon they've added more compliance with later SQL standards (although nowhere near fully compliant).
If you're expecting to take a recent Microsoft database script and run it on Sybase without any problems you're dreaming.
Nope, it still installs the "tkbell" startup. (Nice name there, it hides as a process that looks like a Windows system process). Whilst real says "Oh that's just for updates", it's not. It still dumps advertising icons onto the desktop.
I found this out because the mother in law installed it *sigh*
The author originally wrote this for Linux, but after spending 3 days looking at stolen pictures of Star Wars action figures, dust bunny cuddly toys, strange books with animals on and disgarded pizza boxes, noodle packs and tissues he rewrote it.
Except that's not exactly what real is doing is it? They may have reversed Apple's DRM, but only so they can translate their DRMed files into Apple format. So how is that consumer friendly?
That's usually because they install into c:\program files and require write access. Lazy programmers won't use the profile directory, or (in the case of C&C generals, dump stuff into My Documents instead of the Application Settings directory)
Install them into c:\games and away you go.
Re:I want an integrated tool!
on
Analysis of Spyware
·
· Score: 2, Insightful
You support a large corporate network that allows their users installation rights (face it, most spyware doesn't install unless you have rights to install BHOs, ActiveX controls or other rights)? You work in a large corporation who runs a windows network and doesn't know how to push patches out over AD, or the nicer 3rd party products out there that do it?
What's your ticker symbol, because I don't ever want to buy stock in a company that can't run a network properly.
"So, the license RMS is ranting about doesn't apply"
Yes it does (Published 23rd June 2004):
Clause 1.7 of the license (damned non-cut and paste pdf)
The "Caller ID for E-mail Specification" means the specification having submission ID "draft-atkinson-callerid-00.txt" and entitled "Caller ID for E-Mail," published by Microsoft Corporation on May 19 2004 and located at the following link: http://www.ietf.org/internet-drafts/draft-atkinson -callerid-00.txt.
From (an admittedly quick) reading the draft it is not the merged SPF protocol, it's the original XML based protocol. The merged draft is "draft-ietf-marid-core-01.txt". The license referred to does NOT apply.
So, the license RMS is ranting about doesn't apply, and there doesn't appear to be another license on the Microsoft site. Having said that the Microsoft license does not stop the distribution of source, in fact there's a specific clause allowing it (2.2), you just have to include a paragraph in the source code. Nor does RMS say what his problem is, aside from "Grrr, it's Microsoft".
Of course the SPF implementation is still "non-licensed", there's no mention of restrictions, although they do point out there are patents all over the anti-spam arena.
But hey, we don't expect people to look at this stuff, lets just add yet another protocol.
No, but some mail servers will refuse to accept your email, if yahoo and gmail have implemented SPF.
Mind you, gmail aren't very receptive to anti-spam concerns right now, they don't even stamp their outgoing mails with the IP of the sender, unlike hotmail, yahoo, lycos et al.
It's like anything else, it's just a text record. Use the online SPF generator (it's called a wizard, which should make MCSEs happy), then add a TXT record by right clicking on your domain in the DNS admin, choose add new record, choose TXT and paste the wizard results in.
OK how is that going to help? PGP means you know the sender, SPF means you are checking that the email address in the header is coming from a valid IP for that domain. Two completely different things.
Also PGP means you have to accept the message and it is up to the user to decide if the message is valid. SPF allows you to reject early during the message transmission, saving bandwidth and disk space if the message is from a forged domain.
Slashdot Mirror
... relate to state anti-competitive actions against Microsoft themselves? :)
As usual, Microsoft doesn't keep to the specifications and just looks at the file-type according to the header of the file (and maybe the extension of the filename). Then it takes an educated guess
That's not entirely correct, and it's not just a Microsoft problem, but an "everyone at fault" problem. Apache serves up files with unknown extensions with a default content-type (application/octet-stream), rather than with no content-type at all. Internet Explorer therefore doesn't believe the default types of octet-stream or text/plain and so looks at the content, and the file extension, and if it has that extension registered at an OS level processes it as if that content type was "correctly sent" for that file. It does not does this every time and ignores mime types as you suggest.
IE also has 26 hard coded MIME types it understands without having to refer to the OS (useful stuff like graphics and some sound files).
However now throw XP SP2 into the mix. Now IE, by default, no longer guesses, instead it will render according to the MIME type sent in the headers, unless you use advanced options to turn the new behaviour off and default back to the old way.
Finally note that the HTTP spec says
Apache's default installed behaviour of sending the content type as an octet stream breaks that.
Wardriving just won't be cool any more, not when you can sit in your front room, in your boxers/tighty whities watching star trek and hacking two towns away.
Plug into a published (long before beta1) API, using WMI/WBEM. Even Symantec still haven't got it fixed for some versions of their pile of poo scanner.
There was also the RvB TechEd video last year, with one of the soldiers talking about getting time off from the war to go.
3D Porn!
And so, not having a recent backup of my OPML file, my lack of hourly updates on sites I like but can't remember where the heck they are was a real killer.
Actual web and browser access? Didn't miss it so much.
Unless they produce a DirectShow filter for Windows (like ffdshow does for DivX), they're excluding that rather large desktop market of listeners. Their research page says they have volunteers to code the filter, but until that arrives the codec is playing to a very small audidence. (A bit like the BBC digital channels <g>)
If it's anything like the windows code that got leaked, it will be watermarked, so it can be tracked back.
There was spy/scumware that did that, editing the hosts files to redirect google.com and other search engines to themselves (hiding at http://64.191.95.139 - now offline) instead.
If you're expecting to take a recent Microsoft database script and run it on Sybase without any problems you're dreaming.
Nope, it still installs the "tkbell" startup. (Nice name there, it hides as a process that looks like a Windows system process). Whilst real says "Oh that's just for updates", it's not. It still dumps advertising icons onto the desktop.
I found this out because the mother in law installed it *sigh*
I'm going to karma hell now
Except that's not exactly what real is doing is it? They may have reversed Apple's DRM, but only so they can translate their DRMed files into Apple format. So how is that consumer friendly?
Unless the source IPs are in China, Korea or Brazil where no-one ever cares or fixes anything.
Install them into c:\games and away you go.
What's your ticker symbol, because I don't ever want to buy stock in a company that can't run a network properly.
You mean fast user switching that's been in XP since RTM? Or Dashboard that's a rip off of Konfabulator?
Yes it does (Published 23rd June 2004):
Clause 1.7 of the license (damned non-cut and paste pdf)
The "Caller ID for E-mail Specification" means the specification having submission ID "draft-atkinson-callerid-00.txt" and entitled "Caller ID for E-Mail," published by Microsoft Corporation on May 19 2004 and located at the following link: http://www.ietf.org/internet-drafts/draft-atkinson -callerid-00.txt.
From (an admittedly quick) reading the draft it is not the merged SPF protocol, it's the original XML based protocol. The merged draft is "draft-ietf-marid-core-01.txt". The license referred to does NOT apply.
So, the license RMS is ranting about doesn't apply, and there doesn't appear to be another license on the Microsoft site. Having said that the Microsoft license does not stop the distribution of source, in fact there's a specific clause allowing it (2.2), you just have to include a paragraph in the source code. Nor does RMS say what his problem is, aside from "Grrr, it's Microsoft".
Of course the SPF implementation is still "non-licensed", there's no mention of restrictions, although they do point out there are patents all over the anti-spam arena.
But hey, we don't expect people to look at this stuff, lets just add yet another protocol.
Of course it is, after all, why would a "homepage" about bees be able to stand the slashdot effect? <g>
Mind you, gmail aren't very receptive to anti-spam concerns right now, they don't even stamp their outgoing mails with the IP of the sender, unlike hotmail, yahoo, lycos et al.
I think that using PGP would be a better system, but I don't think it will ever actually happen...too difficult to implement.
Except PGP would mean you have to accept the complete message, then check the signature (and cache a signature for every from address).
SPF does it a lot sooner, from the FROM command, so you're not wasting that much bandwidth. Also there's less caching as it's one record *per domain*
It's like anything else, it's just a text record. Use the online SPF generator (it's called a wizard, which should make MCSEs happy), then add a TXT record by right clicking on your domain in the DNS admin, choose add new record, choose TXT and paste the wizard results in.
Also PGP means you have to accept the message and it is up to the user to decide if the message is valid. SPF allows you to reject early during the message transmission, saving bandwidth and disk space if the message is from a forged domain.