Slashdot Mirror
Debian Project Rejects Sender-ID
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."
← Back to Stories (view on slashdot.org)
← Back to Stories (view on slashdot.org)
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.
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.