decoration decoration
Stories

GROKLAW
When you want to know more... 		decoration
For layout only
Home
Archives
Site Map
Search
About Groklaw
Awards
Legal Research
Timelines
ApplevSamsung
ApplevSamsung p.2
ArchiveExplorer
Autozone
Bilski
Cases
Cast: Lawyers
Comes v. MS
Contracts/Documents
Courts
DRM
Gordon v MS
GPL
Grokdoc
HTML How To
IPI v RH
IV v. Google
Legal Docs
Lodsys
MS Litigations
MSvB&N
News Picks
Novell v. MS
Novell-MS Deal
ODF/OOXML
OOXML Appeals
OraclevGoogle
Patents
ProjectMonterey
Psystar
Quote Database
Red Hat v SCO
Salus Book
SCEA v Hotz
SCO Appeals
SCO Bankruptcy
SCO Financials
SCO Overview
SCO v IBM
SCO v Novell
SCO:Soup2Nuts
SCOsource
Sean Daly
Software Patents
Switch to Linux
Transcripts
Unix Books

Gear

Groklaw Gear

Click here to send an email to the editor of this weblog.

You won't find me on Facebook

Donate

Donate Paypal

No Legal Advice

The information on Groklaw is not intended to constitute legal advice. While Mark is a lawyer and he has asked other lawyers and law students to contribute articles, all of these articles are offered to help educate, not to provide specific legal advice. They are not your lawyers.

Here's Groklaw's comments policy.

What's New

STORIES
No new stories

COMMENTS last 48 hrs
No new comments

Sponsors

Hosting:
hosted by ibiblio

On servers donated to ibiblio by AMD.

Webmaster
Is Sender ID Dead in the Water? - No MARID Working Group Consensus
Wednesday, September 08 2004 @ 08:40 PM EDT

The co-chairs of the MARID Working Group, Andrew Newton and Marshall Rose, have sent an email to the MARID list, stating their opinion that there is no consensus on using Sender ID:

"It is the opinion of the co-chairs at this time (before the end of last call) that the MARID working group has no consensus regarding the deployment of Sender ID. This lack of consensus centers around the IPR associated with the PRA algorithm."

I asked Yakov Shafranovich what it means that they can't reach consensus, and here is his explanation:

"Sender-ID appears to be probably dead in its current form. It remains to be seen whether Microsoft will continue pushing the current form of Sender ID or agree to the compromise proposed by the MARID co-chair."

It appears that Sender-ID cannot be approved because of IPR issues, due to the lack of consensus. Of course, if Microsoft were to change their license, the story could change.

Of course, some say they'll just barrel ahead with their corporate cronies:

"Despite the controversy, the ESPC remains hopeful about Sender ID's fate.

"'The broadest adoption possible and the most consistent standards are in the interests of not just senders, not just ISPs, but of consumers,' said Trevor Hughes, executive director of the ESPC.

"Hughes also points out that even if it doesn't become a standard, Sender ID will still be a factor if the major ISPs adopt it.

"'Where we stand is that Sender ID is going to be a reality for large senders,' he said. 'We don't question the sincerity of the folks who are raising concerns over open source compatibility. We just haven't come up with the same concerns.'"

Hmm. Did he just say the ESPC doesn't care about compatibility in a standard? Yes. I believe he did. And the only consumers that will benefit are those with domains, from what I understand. The ESPC is the EMail Service Providers Coalition. You can see by the list of their members -- like DoubleClick and Real 24/7 Media -- that their concerns are marketing-related, and they probably don't much care what anybody else wants. At least, that's been my experience with DoubleClick. It's not saying much that's good about Microsoft that they intend to do what they do exclusively in their email space, if necessary.

Anyway, the biggest-gorilla-in-the-room response might not work , because Microsoft isn't the biggest gorilla here:

"Open source endorsement is essential for widespread, worldwide adoption of Sender ID. Although major e-mail service providers like Microsoft and AOL say they will be incorporating Sender ID as it stands, and many software vendors are already moving forward with implementations of their own. The vast majority of administrators around the world use open source Message Transfer Agents like Sendmail, QMail, Postfix or Exim.

"Yakov Shafranovich, a former co-chair of the Anti-Spam Research Group (ASRG) and one of the more vocal critics of Microsoft's patent claims, was initially receptive to Newton's proposal, which puts the decision of which extension to use in the hands of network administrators.

"'A proposal that allows Sender ID to be used with multiple identities would sidestep that problem by letting end users pick if they want to use PRA and handle the IPR issues themselves,' he said in an e-mail interview. 'Others are free to choose "mailfrom" or any other extensions that will probably be developed. This way the IETF will sidestep IPR issues and can approve the standard.'"

Here is the complete email.

-------- Original Message --------

Subject: consensus call on pra/mailfrom deployment and versioning/scope
Date: Wed, 8 Sep 2004 09:37:18 -0400
From: Andrew Newton
To: IETF MARID WG

It is the opinion of the co-chairs at this time (before the end of last call) that the MARID working group has no consensus regarding the deployment of Sender ID. This lack of consensus centers around the IPR associated with the PRA algorithm. Since predicting deployment is a subjective matter and not strictly a technical concern, we would like to offer the working group a proposal for modifying Sender ID that would take the issue of deployment out of the hands of the IETF and place it in the hands of the ultimate decision-makers, the systems and network administrators of the Internet. We feel that this is where decisions of deployment should really be made.

It is also the opinion of the co-chairs that many in the working group are willing to deploy MAIL FROM checking as specified in draft-mengwong-spf. Therefore, we ask for consideration of the following proposal:

The ABNF in -protocol 3.4.1 is (mostly from a post by Wayne)

version = "spf2." ver-minor "/" ver-scope *( "," ver-scope )
ver-minor = 1*DIGIT
ver-scope = "pra" / "mailfrom" / name
name = alpha *( alpha / digit / "-" / "_" / "." )

And the following stipulations:

1) "mailfrom" checking will be defined in a new draft
2) multiple records are allowed
3) a scope (e.g. "pra") can only appear in one record of one type for validity purposes

The question before the working group: assuming no technical errors with the above, is there anybody who vehemently objects with this proposal?

-andy

  


Is Sender ID Dead in the Water? - No MARID Working Group Consensus | 323 comments | Create New Account
Comments belong to whoever posts them. Please notify us of inappropriate comments.
Errors etc.
Authored by: Darkside on Wednesday, September 08 2004 @ 08:45 PM EDT
So that PJ can find them.

[ Reply to This | # ]

Links etc. (NT)
Authored by: Darkside on Wednesday, September 08 2004 @ 08:48 PM EDT
What you looking at?

[ Reply to This | # ]

IETF/IESG have limited weight.
Authored by: iMeowbot on Wednesday, September 08 2004 @ 08:54 PM EDT
It's worth remembering that MS are still free to forge ahead with their proposal
even if there isn't an RFC attached to it. They have other levers, like
millions of MSN/Hotmail users, to use in other efforts to get their own way.

On the flip side, even if they do eventually manage to get an RFC published,
there really isn't any sort of enforcement mechanism attached to them. Bad
ideas published on the standards track get ignored all the time.

[ Reply to This | # ]

Is Sender ID Dead in the Water? - No MARID Working Group Consensus
Authored by: Nick on Wednesday, September 08 2004 @ 08:57 PM EDT
Well done -- so far, at least. It is significant that Microsoft is not the
biggest
gorilla in the room when it comes to the Net. Open Source is. It's how the
Net grew, and it was in place long before Microsoft woke up and realized the
Net was a big deal. So it only seems fair that if you want your product or
service or standard to become a part of the Net standard, you have to fit
around the existing rules, not bend the rules to fit your marketing
requirements.

In other words, there is absolutely no reason why a Sender ID type of solution
cannot be made that is compatible with the GPL. If you want a Net standard,
you have to conform to Net standards. And Open Source is it.

Now if you want to play in your own little corporate sandbox, that's fine. Go
right ahead, nobody will stop you. But try to force everyone else to play the
game they invented by your new rules, well, that isn't a recipe for success. It

doesn't work on the playground, and it won't work on the Net.

[ Reply to This | # ]

Is Sender ID Dead in the Water? - No MARID Working Group Consensus
Authored by: Gerry on Wednesday, September 08 2004 @ 08:58 PM EDT
See ARID Floats Sender ID Compromise for a possible update to this.

[ Reply to This | # ]

OT, Trolls, Jokes here, please
Authored by: DaveF on Wednesday, September 08 2004 @ 08:58 PM EDT
and anything else whose utility as a contribution to the discussion is not
immediately obvious.

---
Imbibio, ergo sum

[ Reply to This | # ]

Cue the lobbyists...
Authored by: Jude on Wednesday, September 08 2004 @ 09:13 PM EDT
I think this is when MS sends a bunch of lobbyists to whine to congress about
how the evil open-source commies are preventing adoption of MS's wonderful
anti-spam technology.

It'll probably work, too. Congress knows all about free (as in beer), and cares
nothing about free (as in speech).

[ Reply to This | # ]

MY secure, spoof proof email scheme:
Authored by: Daddio on Wednesday, September 08 2004 @ 09:14 PM EDT
Of course this is just 1st degree vapourware as I haven't (yet) the IP knowhow
to implement it, or any idea if it would work

I Call it 'certified' mail after a service provided by the US Postal service
wherein the Postman (or woman) delivers only a slip of paper that says
essentially "Hey there's a parcel or letter for you waiting at the Post
office". You then trudge down to the post office, sign for your letter,
and trudge home with it.

My 'certified' email would work similarly.

The sender's server sends out an IP packet to the recipients server. The mail
file sits on the senders server
The recipient receives only a notice:

you have an email addressed from yadda@yaddayadda.org waiting for you at 1.2.3.4
(cmail.disreputable.vendor.com)

If the user wants to get it, the users email program then opens a connection
from their own machine and fetchs the mail file directly from the sender's
server

The benefits are two sided.

The recipient knows where it came from.
The sender knows where(if anywhere) it ended up.

downsides:
totally incompatible with current email systems
The sender knows where it ended up

---
Joshua A Clayton
~Salt Lake City UT

[ Reply to This | # ]

Darn...
Authored by: Anonymous on Wednesday, September 08 2004 @ 09:29 PM EDT

You mean, once Microsoft forges ahead with this patent-locked proposal and implements it on Microsoft's own systems, my e-mail won't be able to interoperate with Microsoft's systems? That's a shame. A cryin' shame. Whatever will I do without access to Hotmail accounts, MSN accounts, and microsoft.com?

[ Reply to This | # ]

Is Sender ID Dead in the Water? - No MARID Working Group Consensus
Authored by: jim Reiter on Wednesday, September 08 2004 @ 09:47 PM EDT
Doing business with M$ is stupid. M$ screws everybody they (M$) can. Apple
tried doing business with M$. What else needs to be said.

[ Reply to This | # ]

Is M$ Sender ID Dead? One can hope.
Authored by: digger53 on Wednesday, September 08 2004 @ 10:26 PM EDT
M$: "O.K all you [*&@#!] penguins, eat the nice [poisoned]
apple."

Apache: "No thanks."

Debian: "No."

Chorus: "Sit on it & rotate, M$."

M$: "Grrrrr" [Picks up apple, slouches away]

Any "gift" from M$ is bound to have strings, and is
probably poisoned to boot, as this one is with the
anti-GPL requirements. Hurrah for Apache, Debian & all
others who rejected the poisoned apple!

If my ISP decides to implement MS Sender-ID, I'll have to
look for another. It's just that simple.


---
When all else fails, follow directions.

[ Reply to This | # ]

OT : Vintela a Canopy company?
Authored by: swelling on Wednesday, September 08 2004 @ 10:27 PM EDT
I recently attended a MS users group where they were going to talk about
Unix/Linux integration. The speaker was from Vintela, which I thought was a
Canopy company. I asked about their connection to SCO and whether you have to
sign an SCOsource license to purchase their products. He said that Canopy is
only a minor shareholder, that they were not affiliated with SCO, and that they
do not sell SCOsource licenses, though their HQ was next to SCO's HQ. Does
anyone have any information about a Vintela/Canopy/SCO connection and any
real-world experience with Vintela's products.

(This is my first post, but I have been addicted to Groklaw for over a year.)

[ Reply to This | # ]

Sender ID will fly like a lead balloon
Authored by: grayhawk on Wednesday, September 08 2004 @ 10:50 PM EDT
MS may push it through in the US of A but unfortunately the web is (World Wide
Web). Many countries will not adopt it because it is a Microsoft Monopoly
Product/Idea or because it is American and Yankee rules are not well received in
other large economies like Europe, China, Japan, etc.

These days the business market is the world and if you want to do business you
play by rules of everyone else in the world market which means you better be
interoperable with everyone else out there. Open source is capturing foreign
markets at an alarming rate which effectively will isolate the U.S. if they
don't adopt standards that are non-proprietary. So if you want to sell your
product; and export to foreign countries is the mainstay to American businesses;
then survival in the global economy is dependant on American companies having
standards in which everyone else deals. There are plenty of foreign competitors
that will step in using global standards thereby making it trouble free when
communicating an interest in doing business with them. It is the consumer that
ultimately drives the standards these days and not companies like MS.

Microsoft is not a world dominating firm and is only an American powerhouse.
They may dictate American adoption of their standards but outside of the US
borders they are toast. The European Union, the Far Eastern Countries will have
little to do with that company since both Europe and the Far East are moving
towards a made at home solution through the use of open source.

---
All ships are safe in a harbour but that is not where they were meant to be.

[ Reply to This | # ]

Is Sender ID Dead in the Water? - No MARID Working Group Consensus
Authored by: Anonymous on Wednesday, September 08 2004 @ 11:06 PM EDT
I'm sure the chairs of THIS group are honorable, but I have to wonder about the
cost-effectiveness of bribing other standards committees in situations where
some company might stand to profit greatly. Profit, after all, is their
fiduciary duty, and there are always ways to bribe that are not bribes, in the
legal sense.
Is it even possible to guard against this possibility?

[ Reply to This | # ]

Biggest gorilla in the room
Authored by: sgarcia on Wednesday, September 08 2004 @ 11:11 PM EDT
Microsoft is not the biggest gorilla in the room.

Who is? In email space it's sendmail. Sendmail doesn't dominate email like it
once did, but I'd guess there are still more sendmail implementations than any
other single MTA, maybe more than the rest of them together.

And the last story on Groklaw seemed to indicate that sendmail was going to be
going along with SenderID. They didn't seem to have a big problem with the
license.

I'd like to think that SenderID really was dead in the water, but I wouldn't get
too comfortable. We're not out of the woods.

[ Reply to This | # ]

Showstopper problems with Sender ID licence
Authored by: Walter Dnes on Thursday, September 09 2004 @ 12:28 AM EDT
Microsoft's Sender-ID licence can be downloaded as a PDF file at...

http://download.microsoft.com/download/b/d/3/bd3b5463-c461-409c-b29f-512218d3f3e
6/senderid_license.pdf

A quick reading raises the following concerns on my part...

1) Privacy and Industrial Espionage; anybody who runs their own mailserver might
have to register with Microsoft. This requires you to submit your name and
address to Microsoft. Given that they have lists of paid-up customers,
non-customers can expect to get sales-calls from Microsoft. And is it *REALLY*
good for the people at sendmail.com that MS will now know who is using non-MS
products like sendmail?

2) Other uses of the IP. When DNS was first invented as a protocol for
converting names to IP addresses, nobody imagined novel uses like DNSbls, of
which there are many today. Paragraph 2.1 of the licence says that that you may
use their IP "...solely for the purpose of conforming with the Sender ID
Specification.". So let's say that someone comes up with a cute hack like
a DNSbl blocklist consisting of Sender ID records. Is this allowed? Could MS
demand royalties from such blocklists? That is only one possibility. Given how
"stuff happens", we don't know what's down the road for internet
standards. Whatever it is, I don't want it encumbered with MS patents, for
which they could demand royalties.

3) Remember the masochistic NDA that SCO required of anybody who wanted to view
their "millions of lines of Unix code in linux"? Well, just take a
look at paragraph 6.4 of the licence. "You consent to exclusive
juridiction and venue.." under either federal or state court in King
County, Washington.
Furthermore "You waive all defenses of lack of personal jurisdiction and
forum nonconveniens". So if you are ignorant enough to sign this licence,
and MS can come up with the slightest nitpicky "problem", you would be
required to travel from wherever you may be on the planet to King County,
Washington. You're stuck with travel and hotel bills.

[ Reply to This | # ]

Is Sender ID Dead in the Water? - No MARID Working Group Consensus
Authored by: Anonymous on Thursday, September 09 2004 @ 02:46 AM EDT
I hate it when these kinds of ugly hacks are called technology. Like they got
some holy grail or something.
For the most part it's a patch that everybody must agree on so that Microsoft's
own broken netapps can be just that little more safe. And they have the guts to
pull this ?. I don't think so.

They can keep there obvious piece of workaround code.
Safe communication in not there domain, Let them stay out.

Retep Vosnul.

[ Reply to This | # ]

Sender ID (and SPF, for that matter) is the wrong answer
Authored by: Anonymous on Thursday, September 09 2004 @ 02:53 AM EDT

It is hard to understand why so many people are obsessed with "SenderID", or SPF as its foundation, as an inhibotor to spam when a) it has already been proven ineffective for this purpose and b) for the problem it _may_ help to solve (e-mail identity spoofing) there is already an absolutely perfect and adequate solution that addresses the problem much more effectively: digital signatures.

Moreover SenderID (as well as SPF) is a provider-side measure, so it probably comes as no surprise that "big" mail providers are willing to adopt this approach as it may strengthen their role in the overall balance -- just imagine what an SenderID-whitelist approach would mean for the "big" providers: smaller providers (or individuals like me who are using their own domain to route their mail) will have to negotiate mutual agreements with the providers, which likely will mean money.

It is interesting to note that considerably better measures consistenly fail to be mentioned in such discussions; I will mention one (that does not solve the problem completely but) that I consider very interesting for two reasons: a) it addresses the fundamental underlying problem of electronic mail leading to spam and b) it is a peer-to-peer measure that requires *zero* provider support (probably for this reason alone it is ignored by big providers).

The fundamental problem is that sending an electronic mail to a recipient is cost-free: assuming that delivering a message would cost, say, 1 cent per recipient would immediately end the spam problem. Now there is a "currency" that does not really cost the sender much but is prohibitively expensive for spammers: CPU power.

Assume for a moment that sending a mail would cost 100ms of CPU power *per* *recipient*, and the verification that the sender spent this amount of CPU time is essentially cost-free for the receiver. Normal electronic mail operation would be completely unaffected (no one would even notice the 100ms delay when sending a message), but sending mass mails to millions of recipients causes a significant problem: The sender has to allocate sufficient CPU resources. Though it may still possible to abuse networks of compromised zombie machines to do the computation, draining significant resources from the machines will at the very least increase the risk of discovery.

How can this be achieved? It's called "hashcash", and the idea is outlined here.

Disclaimer: I am not affilliated with the above site, I simply consider the method promising and hope to bring it to a wider attention, for reasons some of which I have brought forth above. Excuse my bad english.

[ Reply to This | # ]

Is Sender ID Dead in the Water? - No MARID Working Group Consensus
Authored by: Anonymous on Thursday, September 09 2004 @ 04:02 AM EDT
90% of the computers on the net? nah, I only require email access to mail
servers, which is where senderID or whatever comes into play ... and 80% of them
are some form of Unix/BSD/Linux ... and certainly all the big players are on
*nix ... so all though M$ have around 20% of the server market in terms of
numbers, they probably are not the ones anyone cares about. In short, they are
not the biggest gorrilla in the room, not by a long shot.

It may of course be true that M$ can claim to be behind 90% of the email
actually sent on the 'net, but thats because their buggy 0wn3ed boxes spray the
stuff around like a tom-cat in an alley.

[ Reply to This | # ]

Is Sender ID Dead in the Water? - No MARID Working Group Consensus
Authored by: Anonymous on Thursday, September 09 2004 @ 06:01 AM EDT
As I understand it:

The proposal is to allow the sender to publish DNS records with either SPF, PRA,
or SPF and PRA.

The problem is that:
- closed-source MTAs will be able work with PRA or SPF.
- open-source MTAs will only work with SPF.

Either PRA is useful or it isn't.
- If it is useful, then open-source MTAs will be unable to implement, leading to
compatibility problems. This will obviously harm those open-source MTAs, and
help to promote closed-source solutions.
- If it isn't useful then why is PRA going to be standardized?

This proposal is crazy :(.

[ Reply to This | # ]

Windows habit - just one more fix!
Authored by: Anonymous on Thursday, September 09 2004 @ 06:12 AM EDT
Much of this wouldn't be necessary if it wasn't for Microsoft's lousy operating system(s). It doesn't help matters when the source of these problems is *prevalently* installed on most PC's shipped today by companies such as IBM, Dell, HP, Gateway, blah, blah. It's as if Windows was a heroin fix; they know it's not good, but can't seem to break free of it.

If there was a serious interest in solving this SPAM problem, all the aforementioned manufacturers would have switched to Linux without hesitation, and dumped Windows entirely. For the benefit of their customers, and the benefit of the general public.

So who is most to blame for this continuing lunacy? Michael Dell? Carly Fiorina? Sam Palmisano?

They all get my vote. Yes, even Sam. They are all asleep at the wheel. By not stamping out the last of the smouldering coals now, they will face devastating future wildfires (i.e., virii attacks).

Heavens... silly me!!!... why didn't I see it???!!

Wildfires = profit!

Forgive me folks... I had a moment of clarity there. It won't happen again.

[ Reply to This | # ]

Is Sender ID Dead in the Water? - No MARID Working Group Consensus
Authored by: muswell100 on Thursday, September 09 2004 @ 06:39 AM EDT
If most companies are like ours, we don't have MS machines (mailservers or
otherwise) operating anywhere near the perimeter. We have a Unix-based firewall
which relays mail in/out and which also handles the majority of the spam we get.
What it may miss is then checked by a mailsweeper internally which then relays
all 'clean' messages to the mailserver. Assuming MS are the only ones to support
Sender ID, this initiative will prove pretty useless unless the majority of
companies decide to make their Exchange mailserver the first point of contact
for any relay hosts on the Internet - which you'd have to be pretty
[stupid/crazy/incompetent: tick one] to do. Or - presumably - decide to put an
MS firewall in place, which given their security record would not be my own
personal choice.

Summary: If MS are the only ones to employ Sender ID it will be dead before it
even gets to the starting post.

[ Reply to This | # ]

Escape Clause (the user decide to use "pra") as proposed by Newton don't work
Authored by: Anonymous on Thursday, September 09 2004 @ 06:49 AM EDT
Newsforge' Joe Barr got it right:

SenderID == Kerboros all over again. For those who don't know, MS used an
"implementation specific" toggle in Keboros to impose their own closed
algorithm.

While understanding Newton's dilemma, his proposal goes beyond Kerboros: He
essentially blessed MS PRA as a loophole.

[ Reply to This | # ]

I removed all my SPF TXT records
Authored by: Turin on Thursday, September 09 2004 @ 09:19 AM EDT
When I heard Microsoft was getting involved. I had SPF records set up for about
3 months, from around Christmas last year until March or so.

This cannot be good for me and my nine piddling domains, despite the spam
benefits.

I won't be implementing SPF or SenderID until i'm convinced that it isn't some
part of Microsoft's compulsion to buy their products. I don't want their
products and will go very far to avoid them. The standards bodies have a
responsibility to provide assurance that the standards used are unencumbered or
they are going to find compliance is very spotty.

[ Reply to This | # ]

Sender ID is Useless
Authored by: Anonymous on Thursday, September 09 2004 @ 09:38 AM EDT
If you examine it, SenderID is a way to make certain that the sending domains
adhering to it and the receiving domains using it have a way of verifying that
the email actually DOES come from where it says it does.

That is done by lifting the IP and the domain name from the email and checking
it against a server running a dns like system to validate the IP and domaine
name.

This "standard" actually ONLY works if a very very large majority of
all the domains in the internet adhere to it. Since most open source groups have
just turned it down, we already know this wont happen. So it leaves all the non
adhering domains open to the spammers to spoof therefore making this standard
virtually useless.

Further more, more and more domains are closing off their outbound port 25 to
keep ANY mail from coming out without going thrue their own smtp servers. In a
lot of cases, it greatly reduces any possibility of spam coming out from that
domain(using any domain name), but I have a bunch of clients who have to send
business emails from home or when traveling thrue their ISP's smtp servers
instead of their company's because of this. With SenderID, every single one of
these emails will get tagged as spam. NOT good at all. You'll end up with a
whole bunch of traveling execs sending emails that will be tagged and they won't
like it.

We already know sendmail, postfix and exim will not implement this standard. So
right there, you have most of the mail servers on the planet not using it.
Unless the admins manually install a patch (in some cases) and my guess is, if
you're an admin who supports OSS, you won't be very inclined to change your open
source system to add an M$ proprietary feature giving mediocre results at best.

Better just stick to spamassassin and good dnsbl's instead.
SenderID is doomed.

my own opinion

[ Reply to This | # ]

why microsoft?
Authored by: jig on Thursday, September 09 2004 @ 09:46 AM EDT
what i still don't understand is why microsoft?

why did they get to even propose a kind of solution that has gotten so much a
head of steam?

where was the open source community in the standards making, and why didn't they
have a separate solution well before microdoft came up with one?

why don't they have a solid alternative now?

it just seems silly to sit back and allow a corporation like MS to beat what has
always been touted as a solid army of coders to a standards implementation,
ESPECIALLY one as important as anything to do with email, and ESPECIALLY because
the standard is attempting to fix a well recognized problem that has been around
for quite a long time..


stuff like this should never be decided on 'who's the biggest gorilla' terms, it
should always be on 'who's got the better technology'. code darwinism. yes, i
see that MARID has proposed a workaround, but what i see so far is the open
source community playing catch up with a very slow hand delt by MS.

so who was it that was too busy reading groklaw to get around to offering a
standard that was better and more timely than MS's?

there should be a .org somewhere that keeps tabs on standards in infrastucture
code. the same group should at least be able to give warnings about what is
being missed, and in a perfect world be able to assign volunteers to the
problems just like kernel work is done.

wake-up-microsoft-is-peeing-in-our-pool.org

[ Reply to This | # ]

How M$ won Newham.
Authored by: Anonymous on Thursday, September 09 2004 @ 09:50 AM EDT
Link

[ Reply to This | # ]

Sender-ID quick primer
Authored by: turambar386 on Thursday, September 09 2004 @ 11:20 AM EDT
Here's a very quick primer on Sender-ID. First, the history:

A bunch of different people at different times were working on this, but Meng
Weng Wong was the first to really get the ball rolling with SPF, which was and
still is an open community based solution. A bit later on, Microsoft started
struggling with their own solution which they called Caller-ID. MS approached
Meng and they agreed to work on a combined effort to be known as Sender-ID and
which would be submitted to the IETF.

As everyone knows, MS has since applied for a patent on their peice of the
puzzle and has offered the onerous "royalty-free" license.

How it works in a nutshell: Domain owners publish records in their DNS which
recieving MTAs can look up. The records say which hosts are allowed to send
email on the domain's behalf.

Now here is why Microsoft is in a whole world of hurt:

Sender-ID specification says that if a domain has NOT published any Sender-ID
records in their DNS, the recieving MTA must accept the incoming email. This
means that Sender-ID is only useful if a large majority of domains publish these
records. It doesn't matter one whit if Hotmail uses Sender-ID if there are no
records to check for incoming email. Without the support of the OSS community,
which runs most of the MTAs and DNS servers on the net, Sender-ID is going
nowhere. MS simply cannot go it alone.

[ Reply to This | # ]

OT: Tavery v United States
Authored by: Anonymous on Thursday, September 09 2004 @ 02:23 PM EDT
Here are some cases citing Tavery v United States (which IBM cites in IBM-247 it's memo to strike materials that SCO submitted in opposition to IBM's PSJ on CC 10)

Wilson v. County of Bernalillo
In opposing summary judgment, "the nonmoving party need not produce evidence in a form that would be admissible at trial, but the content or substance of the evidence must be admissible." Thomas v. IBM, 48 F.3d 478, 485 (10th Cir. 1995) (quotation and citation omitted). In its summary judgment reply brief in the district court, the County requested that Wilson's declaration be stricken on the basis that it was speculative and conclusory and was largely just his opinion. Although the district court did not refer to the information contained in the declaration in granting summary judgment, it is not clear whether it granted the County's request. In its response brief on appeal, the County reasserts its contention that the declaration should not be considered because it does not contain admissible evidence.

"Under Fed. R. Civ. P. 56(e), only statements 'made on personal knowledge' will support [an opposition to] a motion for summary judgment; statements of mere belief must be disregarded." Tavery v. United States, 32 F.3d 1423, 1426 n.4 (10th Cir. 1994). Conclusory and self-serving statements are similarly disregarded. See Murray v. City of Sapulpa, 45 F.3d 1417, 1422 (10th Cir. 1995) ("To survive summary judgment, nonmovant's affidavits must be based upon personal knowledge and set forth facts that would be admissible in evidence; conclusory and self-serving affidavits are not sufficient.") (quotation omitted). We agree that most of the information in the declaration, and deposition as well, on which Wilson relies to try to create an issue of fact is inadmissible and therefore ineffective for summary judgment purposes.

..

Although Wilson contends in his reply brief on appeal that the declaration is based on personal knowledge, the declaration itself does not say that, nor is there other indication that it is based on anything more than his belief or opinion. His argument quoted above is based on the following statements from the declaration:


Pace v. Capobianco
The Rules are clear: "Supporting and opposing affidavits shall be made on personal knowledge." Fed. R. Civ. P. 56(e) (emphasis added). Rule 56(e)'s personal knowledge requirement prevents statements in affidavits that are based, in part, "upon information and belief" -- instead of only knowledge -- from raising genuine issues of fact sufficient to defeat summary judgment. See Stewart v. Booker T. Washington Ins., 232 F.3d 844, 851 (11th Cir. 2000) ("upon information and belief" insufficient); Fowler v. Southern Bell Tel. and Tel. Co., 343 F.2d 150, 154 (5th Cir.1965) ("knowledge, information and belief" insufficientLikewise, an affidavit stating only that the affiant "believes" a certain fact exists is insufficient to defeat summary judgment by creating a genuine issue of fact about the existence of that certain fact. Jameson v. Jameson, 176 F.2d 58, 60 (D.C. Cir. 1949) ("Belief, no matter how sincere, is not equivalent to knowledge."); see also Tavery v. United States, 32 F.3d 1423, 1426 n. 4 (10th Cir. 1994); Hansen v. Prentice-Hall, Inc., 788 F.2d 892, 894 (2d Cir. 1986). Even if the affidavit is otherwise based upon personal knowledge (that is, includes a blanket statement within the first few paragraphs to the effect that the affiant has "personal knowledge of the facts set forth in th[e] affidavit"), a statement that the affiant believes something is not in accordance with the Rule. See Cermetek, Inc. v. Butler Avpak, Inc., 573 F.2d 1370, 1377 (9th Cir. 1978) (equating "I understand" statement in affidavit to inadmissible "I believe" statements and concluding that statement is inadmissible despite general averment to personal knowledge at beginning of affidavit). The district court's treatment of the "believe" portion of Hedge's statement in his affidavit -- that Hedge "observed motion in the red car which I believe was [Davis] raising his hands towards the roof of his car in an attempt to surrender" -- as sufficient to create a fact issue about raised hands was error.

Quatermass
IANAL IMHO etc

[ Reply to This | # ]

Dangerous precedent on Washington Post.com
Authored by: Anonymous on Thursday, September 09 2004 @ 02:40 PM EDT
Looks like Hatch and his cohorts in crime are at it again.

Now they're trying to change copyright law to make copyright violation a
*criminal* offense, not civil (and since it involves the works of single
authors, it most certainly belongs on the civil side). The article shows a
connection between RIAA and the Judiciary Committee, and their wrong headed
attempt to practically rewrite copyright law. RIAA and MPAA are getting close
to the "success" point in their buyout of the US Congress. Foreign
governments considering "free trade" agreements with copyright and
patent strings attached, beware. Your citizens will be the next to get pulled
into a comfy US prison cell, compliments of senators who have no damn business
rewriting the constitution.

Quatermas, I know you think there isn't much stock in the "SCOG wishes
copyrights said X" argument, but if Hatch keeps this up you may have to eat
your words. Criminalization to protect a single industry, one that long ago
proved it can't compete? One that believe it has a RIGHT to sue 12 year old
kids? AW COME ON, HATCH, GET A BRAIN!

Where's my rope?

[ Reply to This | # ]

OT Autozone
Authored by: Anonymous on Thursday, September 09 2004 @ 03:34 PM EDT
SCOX oard on Yahoo is reporting lots and lots of blood on the SCO side at their
hearing with Autozone... Anyone hear anything about this?

[ Reply to This | # ]

  • OT Autozone - Authored by: Anonymous on Thursday, September 09 2004 @ 03:49 PM EDT
    • Me too - Authored by: Anonymous on Thursday, September 09 2004 @ 05:15 PM EDT
  • OT Autozone - Authored by: Anonymous on Thursday, September 09 2004 @ 05:04 PM EDT
  • OT Autozone - Authored by: Anonymous on Thursday, September 09 2004 @ 05:24 PM EDT
Warning!! Contains bias.
Authored by: Anonymous on Thursday, September 09 2004 @ 03:56 PM EDT
Link

[ Reply to This | # ]

Going price for network of zombie PCs: $2,000-$3,000
Authored by: paul_cooke on Thursday, September 09 2004 @ 04:31 PM EDT
Just to back up a post I made earlier on about where the vast majority of spam is coming from:

USATODAY are running this :

Zombie networks can be sophisticated. Last fall, a small Internet service provider asked cybersleuth Don Bowman to find out which of its 70,000 subscribers were broadcasting spam. Its network was generating so much spam, other ISPs threatened to blacklist it.

Bowman discovered that e-mail would blast from 20 PCs for a brief period. After a pause, another fire-hydrant-like surge gushed from a different group of 20 PCs. On average, each machine disgorged 630 pieces of e-mail an hour. "It wasn't natural," says Bowman, chief software architect for security firm Sandvine. "No one can type that fast."

His conclusion: An intruder was deploying squads of zombies in rotating waves. Why? Probably so the unwitting zombie owner would tolerate performance slowdowns that came and went ? and investigate no further.

---
Use Linux - Computer power for the people: Down with cybercrud...

[ Reply to This | # ]

Is Sender ID Dead in the Water? - No MARID Working Group Consensus
Authored by: Anonymous on Thursday, September 09 2004 @ 06:17 PM EDT
I am not sure that Sender ID is patentable in many contry including Canada,
Mexico, EU and others.

Like the RSA algorithme before, Sender ID can probably go forward in these
country... But US users and compagny will be at a big disavantage.

If that was to be the case, well,the patent system will have play trick on
American citizen.


[ Reply to This | # ]

Spammers love Sender ID
Authored by: Anonymous on Friday, September 10 2004 @ 02:15 PM EDT
http://story.news.yahoo.com/news?tmpl=story&ncid=1817&e=1&u=/cmp/200
40910/tc_cmp/47102042&sid=96120750

Like most Microsoft technologies, this one is also being proven inferior even
before its release.

[ Reply to This | # ]

Bullies and wedgies
Authored by: Stumbles on Friday, September 10 2004 @ 07:23 PM EDT
I could go on and on about reasons why Microsoft should not be trusted. But I won't. The link below pretty much sumarizes my thoughts on this whole matter about SPF and SenderID.

http://moongroup.com/index.php?option=content&task=view&id=23&Itemi d=2

---
You can tuna piano but you can't tuna fish.

[ Reply to This | # ]
Groklaw © Copyright 2003-2013 Pamela Jones.
All trademarks and copyrights on this page are owned by their respective owners.
Comments are owned by the individual posters.

PJ's articles are licensed under a Creative Commons License. ( Details ) 		Site layout based on Woodlands theme by Bryan Bell.
Groklaw logo by John Crowley.
News Picks logo by Ted Thompson.
Powered By GeekLog
Created this page in 0.06 seconds