Posted by
CmdrTaco
on from the two-strikes-down dept.
NW writes "Following on the heels of Apache Foundation taking a stance against Sender-ID, the Debian Project announced today their rejection of Sender-ID as well."
I think you missed something - you say that like it's a good thing.
-- Karma: Segmentation fault (tried to dereference a null post)
Re:Perhaps
by
Anonymous Coward
·
· Score: 1, Interesting
it is the only way Microsoft knows to compete anymore. Rather than compete on a level playing field, Microsoft wants to lock you into their new "standard" rather than compete on the merits of their products.
Anymore? This is the only way Microsoft has ever competed! Bill Gates himself has always denied that a company's success depends on the quality of it's products. This becomes a self-fulfilling prophecy: Microsoft cannot compete on the quality of their products because their products are poor! If there is a lack of interest in pursuing quality from the very top down then the resulting products will have poor quality.
Anymore? This is the only way Microsoft has ever competed!
That's hardly accurate. At one point, Microsoft was a small company. I've even got a Z-80 card for an Apple II made by them in my garage somewhere. They didn't get to `lock people into their standard' back then. They had to compete just like everybody else.
They got quite a break when they bought DOS and got into the PC OS market, and some time after that, they did get into the habit of `embrace and extend', but there are areas where even today they're putting out fine products.
For example, their optical mice are top notch and well priced to boot. And they don't `lock you into any standard' either -- certainly, they work fine with Xfree86:)
Back to software, Windows (in it's various permutations) may not be perfect, but it's relatively easy for the end user to use, and highly featured. Same goes for Office.
And they have put out some good software titles lately, especially in the game area. Halo was excellent (though they did acquire the company that released Halo, so...), Crimson Skies, the later Mechwarrior games were good (but lacking the `atmosphere' of MW2), etc.
I like to bash Microsoft as much as the next guy, perhaps even more, but not all criticism directed at them is warranted.
Critical mass needed.
by
Talonius
·
· Score: 4, Interesting
We have many major players rejecting this proposal in public. Is it enough for critical mass?
Sendmail has a plugin available which allows for Sender ID compliance. Which other GPL software will be modified by third parties? This is the joy of GPL software, of course, to maintain it separately from the core. This is also the Achilles' Heel. If Microsoft wanted to do so it could produce the necessary changes for all of these dissenting software packages itself -- and distribute them itself -- and achieve dominance through this method.
The official group declaration would mean little if the availability of the encumbered proposal is enormous and well known.
Most importantly, why wasn't this type of public condemnation available for the various W3C proposals that had patents attached? We cannot pick and choose the fights we engage in - our opposition to patents and intellectual property in standards must be uniform and universal. Once a single standard is accepted despite being weighed down by IP concerns the floodgates will open.
-- My reality check bounced.
How risky is this?
by
johannesg
·
· Score: 4, Interesting
I'm assuming Microsoft will soon enough have mail servers that support (or worse, require!) sender ID, and will advertize heavily with this as a supposed extra security feature that OS cannot or will not offer. What I'm wondering: is this in any way a threat to OS and the infrastructure of the web?
Statements but little analysis
by
SilentChris
·
· Score: 4, Interesting
I've read both statements and, while I agree they can do whatever they want with their software/distributions/etc., I've seen little analysis.
What makes Sender-ID so bad, in comparison to other technologies that both do support (say ASP and SMB). Is it because they reverse-engineered those and MS is trying to release this into the "open"? Are they waiting for a reverse-engineered version?
I know some about coding but little about law. What in particular about this license is causing so much trouble? Could MS change a few lines and it would be accepted?
Re:Statements but little analysis
by
Alsee
·
· Score: 2, Interesting
Could MS change a few lines and it would be accepted?
Sure, it would be trivial.
This conflict is *not* a mistake or accident. The normal and widely used terms for standards submissions are perfectly fine. Microsoft's army of lawyers put signifigant effort into carefully crafting a non-standard licence to create the problem. Microsoft's own FAQ (question 15) admits they were aware of the conflict when they first submitted their non-standard licence. Microsoft's terms are an intentional effort to exclude GPL and related software. Microsoft's terms are intentional effort to sabotage the standard against GPL and related software.
-
-- - - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
Concern for all
by
MikeMacK
·
· Score: 4, Interesting
We are also concerned that no company should be permitted intellectual
property rights (IPR) over core Internet infrastructure.
This should be a concern for all, no matter how you feel about MS, or even if this was another company, like IBM, HP, etc. The standards which hold the Internet together cannot "belong" to one company.
Re:The new MS Word "standard"
by
remin8
·
· Score: 2, Interesting
What needs to happen is we need to develop an open Sender-ID format. Of course this would have to be different enough to sneak by the patent office but maybe we can sneak in interoperatability???
Sender ID - hell, how about reverse dns?
by
cluge
·
· Score: 5, Interesting
It's sad, but it seems that taking sometimes the most primitive steps to help secure one's mail server is over the heads of mail administrators. Even worse, the amount of resistance to having an MTA have proper reverse is incredible.
A short time ago the company I worked for started refusing inbound connections from MTA's that didn't have proper reverse DNS. By proper reverse dns I mean as per RFC 1912 section 2.1 . While the word must isn't used in the RFC, the word should is used, and the RFC even states "For every IP address, there should be a matching PTR record in the in-addr.arpa domain........Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all."
Imagine when I had to explain what proper reverse DNS was to an MCI "internet engineer" (That was the title in his e-mail). Imagine my suprise at the number of complaints generated - and even greater suprise that people simply REFUSED to fix their problem. Instead, bowing to our own customer pressure, we stopped enforcing the checks. We again became part of the problem, instead of part of the solution.
We did this because we saw lots of spam that came from MTA's with no reverse. Even more telling we found lots of spam that used "spoofed" reverse dns. I.E. the reverse had a pointer to some host like mx4.hotmail.com, when no forward with that IP existed. This is most common from spammers coming out of eastern Europe, and some out of china. By refusing to accept mail from these we lowered the amount of delivered SPAM.
Supposedly, AOL, Road Runner, and AT&T require reverse dns. In actuality they don't. If the community is truly serious about fighting spam then they would follow their own policies, and they would help. If AOL and hotmail alone required valid everse DNS the rest of the world would follow suit in short order. By not enforceing their own published rules, very large providers are part of the problem, and their laziness continues to perpetuate the problem.
Considering their inability to enforce something as simple and as easy as rdns (RFC 1912 published 1996) I see no hope for caller ID, or SPF records. They all sound like great standards - but we can't even enforce the standards we have had for almost 10 years.
Debian is correct to reject the "caller-id" feature. Not for any copyright reason, but because it won't work in the current environment with so many lazy administrators, and the only adoption being the spammers themselves.
cluge
-- "Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
It is very likely that Sun, IBM and RedHat will reject Sender-ID as well. Here is a very interesting read on News Forge
-- This is my sig. There are thousands more, but this one is mine.
Missing from the rejection notices...
by
WoodstockJeff
·
· Score: 3, Interesting
... is whether or not any of the projects are going to implement the unemcumbered SPF portion of Sender ID, or if they're throwing that out with Microsoft's enhancements.
You can implement handling the setup of the DNS TXT records without touching anything Microsoft claims ownership of. You can implement the checking of the HELO/EHLO and MAIL FROM via SPF with no patent concerns. Will Apache, Debian, et al dismiss this, simply because the most popular implementations of SPF also support checking the header FROM field, which is supposedly Microsoft's idea?
Article title is 'Soviet Russia' logic
by
The+Monster
·
· Score: 3, Interesting
Or is Debian plainly boycotting
Debian isn't 'boycotting' anything. It didn't even really 'reject' anything. In classic 'Soviet Russia' fashion, the editors got it backwards. It should be more like
Debian Project (recognizes that) Sender-ID Rejects
it
Anyone who can read simple declaratory English sentences can see that the Sender-ID licence terms are incompatible with the GPL. Full stop. Go directly to Jail, do not collect $200. This parrot has ceased to be!
The only way that Debian could accept Sender-ID is to reject the GPL. At that point, having denied its own soul, it would cease to be 'Debian' by any meaningful definition - it would be ex-Debian.
--
[100% ISO 646 Compliant] SVM, ERGO MONSTRO.
Toll-Booth on the Internet quote
by
9mind
·
· Score: 2, Interesting
Am I the only one that remembers this Billy Gates quote? I believe he will make Sender-ID a requirement in Exchange and Outlook... This will force feed it's adoption unless Microsoft continues to lose market share to alternative desktop OSes.
Trying to sneak a pantented standard in, then later charging for it after wide-spread adoption seems more likely, if you do remember that quote.
Perhaps this is where closed source vendors (read: Microsoft) will lead the adoption of Sender-ID.
We have many major players rejecting this proposal in public. Is it enough for critical mass?
Sendmail has a plugin available which allows for Sender ID compliance. Which other GPL software will be modified by third parties? This is the joy of GPL software, of course, to maintain it separately from the core. This is also the Achilles' Heel. If Microsoft wanted to do so it could produce the necessary changes for all of these dissenting software packages itself -- and distribute them itself -- and achieve dominance through this method.
The official group declaration would mean little if the availability of the encumbered proposal is enormous and well known.
Most importantly, why wasn't this type of public condemnation available for the various W3C proposals that had patents attached? We cannot pick and choose the fights we engage in - our opposition to patents and intellectual property in standards must be uniform and universal. Once a single standard is accepted despite being weighed down by IP concerns the floodgates will open.
My reality check bounced.
I'm assuming Microsoft will soon enough have mail servers that support (or worse, require!) sender ID, and will advertize heavily with this as a supposed extra security feature that OS cannot or will not offer. What I'm wondering: is this in any way a threat to OS and the infrastructure of the web?
I've read both statements and, while I agree they can do whatever they want with their software/distributions/etc., I've seen little analysis.
What makes Sender-ID so bad, in comparison to other technologies that both do support (say ASP and SMB). Is it because they reverse-engineered those and MS is trying to release this into the "open"? Are they waiting for a reverse-engineered version?
I know some about coding but little about law. What in particular about this license is causing so much trouble? Could MS change a few lines and it would be accepted?
This should be a concern for all, no matter how you feel about MS, or even if this was another company, like IBM, HP, etc. The standards which hold the Internet together cannot "belong" to one company.
What needs to happen is we need to develop an open Sender-ID format. Of course this would have to be different enough to sneak by the patent office but maybe we can sneak in interoperatability???
"Initial success, or total failure!"
remin8.com
It's sad, but it seems that taking sometimes the most primitive steps to help secure one's mail server is over the heads of mail administrators. Even worse, the amount of resistance to having an MTA have proper reverse is incredible.
A short time ago the company I worked for started refusing inbound connections from MTA's that didn't have proper reverse DNS. By proper reverse dns I mean as per RFC 1912 section 2.1 . While the word must isn't used in the RFC, the word should is used, and the RFC even states "For every IP address, there should be a matching PTR record in the in-addr.arpa domain........Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all."
Imagine when I had to explain what proper reverse DNS was to an MCI "internet engineer" (That was the title in his e-mail). Imagine my suprise at the number of complaints generated - and even greater suprise that people simply REFUSED to fix their problem. Instead, bowing to our own customer pressure, we stopped enforcing the checks. We again became part of the problem, instead of part of the solution.
We did this because we saw lots of spam that came from MTA's with no reverse. Even more telling we found lots of spam that used "spoofed" reverse dns. I.E. the reverse had a pointer to some host like mx4.hotmail.com, when no forward with that IP existed. This is most common from spammers coming out of eastern Europe, and some out of china. By refusing to accept mail from these we lowered the amount of delivered SPAM.
Supposedly, AOL, Road Runner, and AT&T require reverse dns. In actuality they don't. If the community is truly serious about fighting spam then they would follow their own policies, and they would help. If AOL and hotmail alone required valid everse DNS the rest of the world would follow suit in short order. By not enforceing their own published rules, very large providers are part of the problem, and their laziness continues to perpetuate the problem.
Considering their inability to enforce something as simple and as easy as rdns (RFC 1912 published 1996) I see no hope for caller ID, or SPF records. They all sound like great standards - but we can't even enforce the standards we have had for almost 10 years.
Debian is correct to reject the "caller-id" feature. Not for any copyright reason, but because it won't work in the current environment with so many lazy administrators, and the only adoption being the spammers themselves.
cluge
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
It is very likely that Sun, IBM and RedHat will reject Sender-ID as well. Here is a very interesting read on News Forge
This is my sig. There are thousands more, but this one is mine.
You can implement handling the setup of the DNS TXT records without touching anything Microsoft claims ownership of. You can implement the checking of the HELO/EHLO and MAIL FROM via SPF with no patent concerns. Will Apache, Debian, et al dismiss this, simply because the most popular implementations of SPF also support checking the header FROM field, which is supposedly Microsoft's idea?
The only way that Debian could accept Sender-ID is to reject the GPL. At that point, having denied its own soul, it would cease to be 'Debian' by any meaningful definition - it would be ex-Debian.
[100% ISO 646 Compliant]
SVM, ERGO MONSTRO.
Trying to sneak a pantented standard in, then later charging for it after wide-spread adoption seems more likely, if you do remember that quote.