Apache Rejects Sender ID

Hoody Hoo! by CountBrass · 2004-09-02 04:44 · Score: 5, Insightful

Well done Apache! Surely this must be a big stake in the heart of MS email domination plans ?

--
Bad analogies are like waxing a monkey with a rainbow.

Re:Hoody Hoo! by chris_mahan · 2004-09-02 04:52 · Score: 4, Funny

Next time, put the GPL all over it and MS won't join.

You know, you guys could have seen this one coming.

--
"Piter, too, is dead."
Re:Hoody Hoo! by Tracy+Reed · 2004-09-02 05:03 · Score: 5, Insightful

No, it does not hinder SPF. Sender ID is SPF+MS's hacks. You are still free to use SPF by itself.
Re:Hoody Hoo! by DAldredge · 2004-09-02 05:12 · Score: 4, Insightful

It's not 'irrational hatred of Microsoft', it is concern that, in the future, Microsoft will use these patentes to control email on the net. Microsoft just hired a high level exec to over see it's IP portfolio and to increase it's 'value' to Microsoft.
Re:Hoody Hoo! by Abcd1234 · 2004-09-02 05:14 · Score: 5, Insightful

Yup, you're absolutely right! Despite what the ASF said, they're rejecting SenderID because it's *Microsoft*! Yeah! Sure, they *claimed* it was because it was patent encumbered, but you have efficiently seen through their veil of deception.

Don't be a tool. The ASF doesn't gives a damn who created the freakin' standard. The fact is, it's patent encumbered. Period. And, as a result, they refuse to implement it. This shouldn't be at all surprising. Frankly, I think it's down right ridiculous that the IETF is willing to consider a standard that's patent encumbered. But, hey, who wants a free, open Internet?
Re:Hoody Hoo! by killjoe · 2004-09-02 05:24 · Score: 2, Insightful

" It's SOP on /. to instantly hate anything that is 1) MS or MS related or 2) not open source. "

So? Arent there plenty of boards where people

1) Love MS or 2) Hate open source?

The internet is a big place. You could always hang out at gotdotnet or any of the thousands of MS sponsored blogs if you want to be filled with pro MS propaganda.

--
evil is as evil does
Re:Hoody Hoo! by jaaron · 2004-09-02 05:35 · Score: 2, Interesting

In fact, the ASF just rather recently set up SPF filtering on their own internal mail servers.

--
Who said Freedom was Fair?
Re:Hoody Hoo! by nacturation · 2004-09-02 05:58 · Score: 3, Funny

As opposed to anti-Microsoft propaganda? Either way, it's all propaganda.

Some propagandas are more equal than others.

--
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
Re:Hoody Hoo! by _Sprocket_ · 2004-09-02 06:20 · Score: 2, Insightful

It's SOP on /. to instantly hate anything that is 1) MS or MS related or 2) not open source.

You don't suppose that's got anything to do with the behavior of some proprietary vendors, specifically Microsoft?

You'll note that there are numerous other major players in IT who don't get the same kind of attention. Nobody is without criticism, of course. But how much bashing does, for example, Cisco get around here despite their market position in networking gear?

Microsoft reaps what it has sown.
Re:Hoody Hoo! by _Sprocket_ · 2004-09-02 10:24 · Score: 3, Insightful

MS is the biggest OS producer, their founder is the number 1 richest man in the world...they hold a lot of number ones.

This is a common claim directed at Microsoft critics. There is a belief that Microsoft gets attacked because of their position. And I'm sure there is a certain degree of truth to it. However, I often see this as a dismissal to ALL Microsoft criticism - or even criticisms that individuals simply don't agree with. And that, frankly, is bunk.

For example a day or two ago there was /. article about Bill G. talking about Longhorn. He got blasted by some posters saying that he is just doing this for the free press. If this was say the creators of Half - Life 2 giving us an update, we would praise them for coming out.

I'm at a disadvantage here. I didn't read either the linked article nor the /. post. So I don't know the specifics. But keep in mind that commenting on future technology offerings has been used in the past by Microsoft to generate buzz / vapor ware / FUD. I don't wish to imply that this particular instance is such a case. As I said, I don't know. But I'm not surprised to see criticism based on this long-standing history.

That is what I am talking about...when MS does something bad blast them, but when they do something good give them some credit...

I also occasionally disagree with some of the criticisms towards Microsoft that are voiced on Slashdot. However, that doesn't mean that all the criticisms are wrong. Nor does it mean that Microsoft is even unjustly targeted. Microsoft should be criticized for actions that deserve criticism. And there is no short supply of such actions from Microsoft.

Good start... by keiferb · 2004-09-02 04:45 · Score: 5, Insightful

Hopefully this is just the start of a string of rejections. If lots of big names in the OSS community and some of the e-mail superpowers (yahoo, gmail, etc...) jump on the bandwagon, maybe it'll get pushed aside.

Wishful thinking? Probably, but a boy can dream...

Good for them, but not far enough. by Euphonious+Coward · 2004-09-02 04:46 · Score: 4, Interesting

I don't see any reason to use SPF either. It only benefits big ISPs, by keeping spammers from mentioning them in their return addresses. Even then it only works until the spammers hijack the machine of some dumb sap who's a legitimate customer of such an ISP, and send under his name. It does you and me no good at all, either way.

The whole exercise has been a waste of time and attention for all involved, and the sooner it's forgotten, the better.

Re:Good for them, but not far enough. by athakur999 · 2004-09-02 04:53 · Score: 5, Insightful

In the scenario you mentioned, it forces the spammer to use machines that's within the ISP's control. If the spam bearing your domain is originating from some random computer in China, there's not a whole lot you can do. But if the spam has to originate from one of your customer's computers and has to be sent via one of your SMTP servers, then you can look at the logs on your SMTP server, figure out the infected customer, and take appropriate action.

--
"People that quote themselves in their signatures bother me" - athakur999
Re:Good for them, but not far enough. by Grayputer · 2004-09-02 05:00 · Score: 3, Insightful

OK I'll bite. I fail to see how SPF only helps the big ISPs. Any little guy (running a domain) can publish his own SPF record. Any little guy (running a mail server) can check against existing SPF records. Checking against an SPF record will weed out (or at least certainly reduce) SPAM with forged source addresses (or make it harder to forge an acceptable address). Trackable SPAM is a definite improvement over the current state of affairs.

Obviously you have a beef with SPF. I seem to have missed it. So where's the beef?
Re:Good for them, but not far enough. by DJ+Rubbie · 2004-09-02 05:01 · Score: 4, Insightful

You are horribly wrong, and I will bite. I had my email address 'spoofed' by the W32.Netsky worm a while back, and it was sent from a machine that is not of the domain of my address. An SPF enabled mail server would reject emails with spoofed headers, and so my friends (victims) will not see the infected email with *my* email address. On the other hand, non-SPF enabled mail servers will accept it, and my friends sees it, and accuses me of sending them a 'virus'.

SPF will not only stop spammers, but will stop (or at least prevent) people and worms from spoofing the from address *sent from _everywhere_* to claim to be from a user@domain they do not own. I do not want spammers or anyone to claim to be from my domain (or my legit email address even), and have angry letters accusing me of letters I did not send.

If you have your machine hacked, or running a mail relay by accident, you should have secured those equipments, and if you had anything important on it (eg. financial records), you probably have much bigger concerns, like identity theft.

Yes, I know, we are supposed to check the email headers, but most home users are completely ignorant of those features.

--
Please direct all bug reports to /dev/null
Re:Good for them, but not far enough. by jhunsake · 2004-09-02 05:05 · Score: 2, Interesting

It's an inferior attempt at authentication. Yahoo!'s DomainKeys is superior in every respect.

I was really interested in SPF for a while, but I'm tired of this shit. Like the grandparent says, it's all a big waste of time. I'm going to delete those TXT records right now...
Re:Good for them, but not far enough. by Emrys · 2004-09-02 05:17 · Score: 2, Insightful

SPF doesn't tell admins a damn thing they didn't know before. Admins do not pay attention to header addresses when determining the source of spam, they look at the IP addresses, which are not truly being forged (not in the same sense, anyway).

SPF is only useful to end users who can be fooled by forged text headers. It was created to help stop phishing and provide some kind of reputation protection. It's ridiculous that people who should know better co-opted it as a "spam solution" and are willing to break legitimate uses of SMTP to see it adopted, without seeming to even reale the leverage it hands big ISPs.
Re:Good for them, but not far enough. by Daniel+Boisvert · 2004-09-02 05:25 · Score: 2, Interesting

There's a difference between knowing which IP's in your netblock are allowed to send mail, and which IP's are allowed to send mail from your domain. SPF requires you to know the latter, which is something you really ought to know if you're running a domain.

The former is much harder to know, for a zillion reasons (subnets controlled by downstream entities, legit residential mailservers, etc.).
Re:Good for them, but not far enough. by ajs · 2004-09-02 06:01 · Score: 4, Informative

DomainKeys and SPF fit in differnt spaces for solving different problems.

SPF has a great deal of value. The only problem I see with it is the envelope rewriting schemem (SRS, I think it's called) which is cumbersome. I'm expecting a) someone will fork the SPF standard, since the original introducers got in bed with MSFT and b) they'll want to introduce a transfer-of-authority protocol into SMTP rather than trying to cram everything into the FROM part of the envelope.

After that, SPF is really all you need to stop forged spam.

What a lot of people (including the grandparent) don't get is that SPF isn't designed to stop spam. SPF is designed to stop two things: forgeries and bounces of forgeries. Stopping those two, however, then makes stopping spam a much more manageable problem.

If you're looking for the panacea spam solution, you're doomed. If you're looking for the right tools to eliminate almost all of the problem, SPF should be among your first few (along with a good, flexible, multi-technology server-based filtering tool like SpamAssassin; an extremely well maintained and liberal blacklist like Spamhaus; and an easy-to-use end-user spam filter like Thunderbird's).
Re:Good for them, but not far enough. by Xformer · 2004-09-02 06:04 · Score: 2, Informative

To phrase it similarly, SPF doesn't do a damn thing with email headers. It only pays attention to the envelope sender, which is what is specicied in the SMTP MAIL FROM command, and winds up in the Return-Path header due to actions of the receiving server. It's not designed to stop phishing schemes.

Caller ID, on the other hand, was designed to look at things like the From: header. That was designed to stop phishing more than SPF was.

Sender ID isn't one or the other, but the combination of those and some other weird thing M$ came up with. Sender ID is also what's patented, as far as I know, not SPF.

--
All I want is a kind word, a warm bed and unlimited power.
Re:Good for them, but not far enough. by pjrc · 2004-09-02 06:32 · Score: 2, Interesting

Yahoo!'s DomainKeys is superior in every respect.
Records already published by 70000+ domains, including some very important ones like aol.com.
A way to guess a default record for any domain not yet publishing, that works for most existing mail servers.
Code already under development and in beta testing for all major MTAs.
Algorithm already implemented in upcoming SpamAssassin filter, which is currently in release testing
It's an inferior attempt at authentication.
Yeah, yeah, yeah... it has crypto, so it must be strong.
Like the grandparent says, it's all a big waste of time. I'm going to delete those TXT records right now...
And replace it with a yahoo DomainKey? How are you going to do that? Oh, you're going to go download the reference implementation, compile this alpha-release source code, and run the "dknewkey" to get something like this:
testkey._domainkey IN TXT "k=rsa; p=MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBANazc9du4IFEWnSr idEMAuv9UvCojT8hiTg1L646F6T4dRTsz7MB0WdnG2cF5J6HgA AlvpIB8HN1bh43FBb1MqkCAwEAAQ=="

Then you're going to head over head and grab this while ignoring the advisory section:
THIS IS PRE-RELEASE SOFTWARE, and should not be used in any critical production environments.

For someone highly concerned about what is and is not a waste of time (unlikely, posting to slashdot).... if you already did publish a SPF record, your best course of action is probably to just leave it there.
Certainly, Yahoo's DomainKeys is not yet to a degree of maturity to be actually used for much more than development and alpha testing.
In contrast, SPF is already protecting 70000+ domains and numerous sites are beginning to filter out forged messages pretending to be from those domains.
Very soon, SpamAssassin 3.x will be released (already on second release canidate), with SPF checking built in and turned on by default. Other anti-spam filters will follow.
From a practical point of view for the near future, choosing between installing a TXT record of the form "v=spf1..." or "k=rsa...", it's pretty clear which of these is useful today and which (unless you're a developer working on DomainKeys) is a waste of time.

--
PJRC: Electronic Projects, 8051 Microcontroller Tools
Re:Good for them, but not far enough. by Pasc · 2004-09-02 08:03 · Score: 2, Insightful

I have my own domain and I pay a 3rd party, EasyDNS, to handle my DNS. They support SPF... I just type some info into a textbox in the web-based management console and it works! If your DNS provider doesn't support SPF then they probably aren't very tech savvy... and that isn't an attribute I'd like in a DNS provider.

In case you don't follow M$'s every move like me.. by Emugamer · 2004-09-02 04:47 · Score: 4, Informative

Microsoft Sender ID Framework

The Sender ID Framework is an industry standard created to counter e-mail domain spoofing and to provide greater protection against phishing schemes. This combined specification is the result of Microsoft's Caller ID for E-Mail proposal, Meng Wong's Sender Policy Framework (SPF), and a third specification called the Submitter Optimization. These three draft technical specifications were recently submitted to the Internet Engineering Task Force (IETF) and other industry organizations for review and comment. ... and it goes on and on

Patent encumbered indeed! by Anonymous Coward · 2004-09-02 04:47 · Score: 5, Informative

Is this why the sender ID article on Wikipedia is only a stub?

Please, click "edit this page" and help if you know anything!

MSFT doesn't care about Apache. by garcia · 2004-09-02 04:47 · Score: 3, Interesting

We will not be implementing support for Sender ID until such time as the issues with the license are fixed and acceptable to the Apache James and Apache SpamAssassin Project Management Committees.

It's obvious that Apache's concerns are of the utmost importance to both MSFT and those conducting the discussions. If they were SO concerned this would have been taken care of long ago. MSFT figures that either Apache will kowtow after users get pissed that they cannot send to those behind an MS mail solution or that they will end up having to break down themselves later. It's a lot bigger of a gamble for Apache to ignore MSFT than it is for MSFT to ignore Apache.

As an alternative resolution, we would find it acceptable if the pending patents were granted to a non-profit organization such as ISOC and licensed under sufficiently open
terms.

This, OTOH, is a valid option and should be exercised but I highly doubt it will be for obvious reasons.

Re:MSFT doesn't care about Apache. by millahtime · 2004-09-02 04:51 · Score: 3, Insightful

MSFT does need to care about open source and other mail servers. They are a small fish in a big sea when it comes to mail systems.

--
Evolution or ID?
Re:MSFT doesn't care about Apache. by trifster · 2004-09-02 04:58 · Score: 5, Insightful

Your logic doesn't flow. If that were the case then everyone would have stopped using sendmail and switched to exchange so everyone can send meeting appointments and tasks in addition to email. no, apache is on the right track. open standards (truely open) and protocols will win over closed source solutions. the reason is simple...the desires of the many will trump those of the few or only. so the majority will move on to the open technologies.
Re:MSFT doesn't care about Apache. by mr_z_beeblebrox · 2004-09-02 05:01 · Score: 4, Funny

It's a lot bigger of a gamble for Apache to ignore MSFT than it is for MSFT to ignore Apache.

Good point!!! Because Apache has Billions of dollars invested in their product. Whereas Windows is mainly just a free download.
Re:MSFT doesn't care about Apache. by TheUnFounded · 2004-09-02 05:10 · Score: 2, Insightful

Not only that, but as the world's predominant web server, Apache has a fair bit of clout with the IETF.
Re:MSFT doesn't care about Apache. by macdaddy · 2004-09-02 05:17 · Score: 3, Insightful

It's not Apache HTTP Server that would need the plugin. It's SpamAssassin, the dominant spam fighting tool and now an official Apache Software Foundation project.
And getting a few of the big players onboard with MS isn't going to do jack. The top dozen big ISPs are a drop in the bucket in the email system world-wide. Sure they are the biggest ISPs but that doesn't mean their userbase makes up the majority on the 'Net.
Re:MSFT doesn't care about Apache. by jest3r · 2004-09-02 05:28 · Score: 2, Insightful

It's a lot bigger of a gamble for Apache to ignore MSFT than it is for MSFT to ignore Apache.
There are 56 Million domain names in existence (22 million of them active). 70% of these domain names are hosted with Opensource software and hence use Opensource mailservers (for the most part).
MS needs buy-in from the Opensource community or their market share will continue to slip.

Oh really? by archen · 2004-09-02 04:48 · Score: 4, Insightful

This means no Sender ID support for SpamAssassin, Apache JAMES, etc.

Funny, I thought Apache supported these things called modules that allowed you to extend Apache.

Just because it doesn't come from the Apache Foundation doesn't mean it wont happen.

Re:Oh really? by ClosedSource · 2004-09-02 05:07 · Score: 2, Insightful

"Most system administrators also have a strong social conscience."

Some do and some don't just like everybody else. Of course, some people would argue that a strong social conscience has more to do with things like poverty, war and the like than it does with the GPL.
Re:Oh really? by Anonymous Coward · 2004-09-02 05:13 · Score: 2, Informative

You're mixing up the Apache HTTP daemon with other projects under the ASF's umbrella.

Stick with JAMES by Anonymous Coward · 2004-09-02 04:48 · Score: 5, Informative

I use JAMES for my mail transport, and have found it to be fantastic. A single XML file can configure all the services you need (SMTP, POP3, IMAP), with or without TLS. If you want TLS, you just add an entry for it.

Also, it's really easy to write custom programs for mail processing, called "Matchers" or "Mailets" (many already exist), for things like SPAM detection, custom mail delivery, etc. I highly recommend it over sendmail/qmail.

Re:Stick with JAMES by BigGerman · 2004-09-02 05:01 · Score: 4, Informative

James project does not list IMAP in the list of features and the FAQs mention some "experimental" code. Is there something you know and they don't?
Re:Stick with JAMES by mmurphy000 · 2004-09-02 05:28 · Score: 2, Informative

From the James FAQ:

"IMAP development had been stalled, but has recently attracted new activity. IMAP support is scheduled for inclusion in James v3. In the meantime, there is experimental code in the repository. If you are interested in working on or trying the IMAP prototype code, join the james-dev mailing list and let us know."

--
The Busy Coder's Guide to Android Development

I had so much hope by Omega1045 · 2004-09-02 04:51 · Score: 4, Insightful

Having read up on SPF long before MS got involved, I had such hope that this would help to secure email and kill spam. The reliance on a proven system like DNS seemed like an awesome idea. I wonder what parts of SPF can be considered prior art to MS's patent, and how it was licensed before MS came into the picture. Can we use a pure SPF implimentation an avoid the MS crud? If not, can we come up with a similar system? I think this is a concept that we need implimented asap.

With the rejection by Apache, hopefully the rest of the FOSS will follow and then the industry at large.

--

Great ideas often receive violent opposition from mediocre minds. - Albert Einstein

What a suprise! by yoshi_mon · 2004-09-02 04:53 · Score: 4, Insightful

Finally, as developers of open source e-mail technologies, we are concerned that no company should be permitted IP rights over core Internet infrastructure.

Is any really surprised that MS is trying to build it's patent arsenal around such things? And of course they want to do it quickly because it's much easier to get something underhanded accepted quickly. (PATRIOT Act anyone?)

We are also concerned by the rush to adopt this standard in spite of technical concerns, lack of experience in the field, and a lack of consensus in the IETF MARID WG.

I think again Open Source groups show their strength by not allowing such tactics to take place without notice. It also shows that many major groups are very aware of how the game is being played.

--

Really, I know what I'm doing...Ohhhh, look at the shiny buttons!

Go Apache foundation! by Rupan · 2004-09-02 04:53 · Score: 2, Insightful

I'm glad that a major OSS project has seen through the FUD and is speaking out on behalf of the community. I seem to have lost my faith in humanity, but events like this start to restore it.

--
Ads? What ads?

Re:First Post! by Edmund+Blackadder · 2004-09-02 04:55 · Score: 3, Insightful

If you do not like spam, please stop spamming slashdot.

Encumbered Standards by Secrity · 2004-09-02 04:56 · Score: 5, Insightful

I find it pretty amazing that the IETF accepts encumbered "standards". Protocols should either be industry standards or propietary. It could become interesting if an RFC calls for the use of an encumbered standard and half of the Internet chooses to ignore the standard.

Sendmail what is your move now?? by bryam · 2004-09-02 04:56 · Score: 5, Interesting

"Sendmail releases open source milter for Sender ID
August 30, 2004
Today, Sendmail, Inc. is releasing an open source implementation of the IETF's Sender ID specification for testing on the Internet. This implementation utilizes the milter interface to plug directly into the sendmail MTA.

Sender ID is a standards-track proposal that merges Meng Wong's SPF and Microsoft's Caller ID for email. Authorizations records are published in DNS in an SPF-compatible format, and then used to validate user-visible message headers using the Caller ID "Purported Responsible Address". This sid-milter release implements the marid-protocol and marid-core draft standards, leaving the marid-submitter SMTP Extension to be implemented directly by the sendmail MTA.

Downloadable source code for sid-milter can be found at: sendmail.net/sid-milter"

Re:Sendmail what is your move now?? by avida · 2004-09-02 07:00 · Score: 2, Insightful

Sendmail has to make money so supporting Sender ID is a good thing for them. They are packaging it as a seperate download so as to not encumber their main product with Sender ID's problems. This is how real vendors should deal with real problems.

RMS summed it up well by Skiron · 2004-09-02 04:58 · Score: 5, Interesting

RMS E-Mail to IETF MARID WG ML

All listen to the man!

Re:RMS summed it up well by Skiron · 2004-09-02 05:09 · Score: 3, Funny

What's that got to do with the price of beer?

He is spot on about what M$ are up to with this issue.

Re:In case you don't follow M$'s every move like m by sxtxixtxcxh · 2004-09-02 05:04 · Score: 3, Insightful

industry standard?

isn't a bit early to be calling it a standard?
especially if apache is rejecting it.

--
for a minute there, i lost myself...

Re:First Post! by Sebby · 2004-09-02 05:10 · Score: 4, Funny

"and the mailbox was full of spam THE VERY FIRST TIME I checked my email. I hadn't given the new email addy out to anyone yet."

Serves you right for registering 'asdf.com' :)

--

AC comments get piped to /dev/null

Good articles on this by Anonymous Coward · 2004-09-02 05:11 · Score: 5, Informative

A few good articles on sender-ID controversy:

http://www.eweek.com/print_article/0,1761,a=134028 ,00.asp
http://www.circleid.com/article/730_0_1_0_C/
http://www.eweek.com/article2/0,1759,1639880,00.as p
http://www.newsforge.com/article.pl?sid=04/09/01/1 555212
http://trends.newsforge.com/14/04/08/26/1326244.sh tml?tid=137

Also, here are the opinions of Eben Moglen of FSF and Larry Rosen of OSI:
http://www.imc.org/ietf-mxcomp/mail-archive/msg036 78.html

Be original by chamblah · 2004-09-02 05:11 · Score: 2, Insightful

M$

Re:In case you don't follow M$'s every move like m by macdaddy · 2004-09-02 05:13 · Score: 2, Insightful

Correct. It's not a standard at all but a proposal. Hopefully SenderID never becomes a standard. Wong should be slapped shitless for ever agreeing to couple SPF with CallerID. What a stupid move to make.

Re:We've seen this before... by Feyr · 2004-09-02 05:13 · Score: 2, Insightful

i doubt your claim of technically superior. if i remember DomainKeys work on the headers, which means you have to send the whole mail first (thus anihilating any sort of bandwidth reducing abilities, which spf does not suffer from)

Sender-ID may not be MS's IP by scorp1us · 2004-09-02 05:15 · Score: 3, Interesting

According to this article SenderID in the agreed upon form is nothing new. Indeed it seems that MS has embeaced and extended someone else's IP and put their own claim to it.

Therefore, Apache maybe abandoning something that it needs not to abandon.

--
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.

Look at it another way? by ImaLamer · 2004-09-02 05:22 · Score: 4, Insightful

Apache will kowtow after users get pissed that they cannot send to those behind an MS mail solution

What about us users who are behind the MS mail solutions? I have addresses on both sides of the coin and to think the Microsoft won't let me get mail because someone didn't use their patented technology is crazy....

I know they are trying to ram it through committee, but have they really thought about this? It's crazy. They already put most of my mail in the "Bulk" folder with hotmail, even if it is sent from a friend. And technology is slow to adapt, yet they've already made the announcement that they will not take mail without Sender ID after October 1st (I believe). Who here still uses HTML tags like

<FONT SIZE>

We were supposed to drop that years ago. It still renders though.

We all hate spam but a "magic bullet" will only kill e-mail altogether IMHO. I've missed out on money actually because something gets marked as spam but I needed it for "business". Let me setup my own spam filters or let me weed through it.

Either way, I resent corporations like Microsoft and even Yahoo getting into the mix and removing me from the situation.

It's easy, don't give out your address. Don't click on links in e-mail that are so long they look like encryption keys. Don't allow images to load (easy with Thunderbird + Sygate Personal Firewall in XP and most webmail). Don't sign up for a freeipod (I want to post my referral link, so bad too.)

--
Get your Unix fortune now!

Media issues by r.jimenezz · 2004-09-02 05:27 · Score: 4, Insightful

I hope the OSS community can follow up in the ensuing media war that MS may unleash. It will be relatively easy for them to say "see, we had a solution for this but those non-IPR respecting open source zealots boycott it". Especially if (God forbid!) the rest of the "big companies" do not line up with Apache.

Firm positions like this must be applauded and upheld, but once again we also need other professionals to help get the voice out about the truth. We shall not be fanatical, but I humbly believe it is clear Microsoft is not being transparent in this and that does not bode well for the Internet as we've come to know it.

--
The revolution will not be televised.

More about power and negotiating than technology by Ridgelift · 2004-09-02 05:31 · Score: 4, Interesting

I think this is the first time I've seen a situation where Microsoft is unable to dictate to others on "how things are going to be". The question I have now is "what will Microsoft do next?". Are they willing to be directed by an Open Source project, or will they go their own route to stave off the perception that Microsoft isn't as omnipotent as they want everyone to believe?

Fascinating. Absolutely fascinating.

--
Ruby on Rails Screencast

Re:I don't see the problem.. by macdaddy · 2004-09-02 05:34 · Score: 4, Insightful

You obivously haven't got a clue what we're all talking about or SenderID in general. Microsoft requires a license for SenderID and all covered implementations to issue at their discretion. Apache Software Foundation also didn't say it wasn't going to support IETF standards. It said it opposed Microsoft's SenderID *proposal* which IS NOT A STANDARD. Contradicting one's self is not nearly as bad as talking out one's ass, wouldn't you say?

Just the logical outcome of the RAND debate by sphealey · 2004-09-02 05:46 · Score: 4, Interesting

This is just the logical outcome of the RAND debate.

I hope Apache wins the day here. However, the entire reason for the RAND proposal in the first place was to allow commerical interest to capture open Internet standards. I don't think they will be easily deflected.

sPh

what about home email servers ? by Anonymous Coward · 2004-09-02 05:49 · Score: 4, Interesting

i have a small email server at home that i use for website signups & imdb movie queries, i have a domain name pointing at it but the reverse dns of my IP gives me not my domain name but my ISP's name of my machine as i dont control the dns for that, so how can i use these email certification systems ? i have complete and correct mail headers and am willing to verify who iam but iam a bit pissed at being denied the use of smtp, whats next ? SSH or [insert port here]

so how will these email schemes protect me ? or is this a case of screw the honest geek on a cable modem and render being in control of my own email useless, forcing me to use "approved server$" from [insert large corp name and another fee here]

Re:what about home email servers ? by SmurfButcher+Bob · 2004-09-02 07:26 · Score: 2, Informative

"Home email servers" are exactly what these concepts are trying to kill... every DHCP typhoid zombie box out there that sources this spam-trash is a "home email server." From the outside looking in, your machine will be no different from them unless you take a few steps.

With that said, all isn't lost - you simply need to set up a legit domain to host your SPF records / etc. It won't be incredibly trivial, but then it isn't supposed to be - otherwise, some spammer could simply do it also, and we're back to square one.

--

help me i've cloned myself and can't remember which one I am

Re:I don't see the problem.. by Anonymous Coward · 2004-09-02 05:50 · Score: 3, Insightful

Isn't Microsoft providing a royalty-free license for everyone to use this patent?

Lawrence Rosen had this to say:

the 'nontransferable, non-sublicenseable' language in their reciprocal patent license imposes an impossible administrative burden on the open-source development community and, in essence, creates additional downstream patent licenses that will be incompatible with the AFL/OSL and similar open-source licenses, and with the open-source development process.

In other words, Microsoft's license is not compatible with Open Source. Open source projects are not allowed to re-distribute the license to end users, unless they obtain a special license from Microsoft. If Apache did this, then you downloaded the Apache product and gave a copy to a friend, you would be infringing on Microsoft's patent because you don't have permission from Microsoft to sublicense their patent. Clearly this creates a completely unworkable situation with respect to Open Source software. Only authorized sites (authorized by Microsoft) would be allowed to distribute software which includes this IP. But, you are correct -- the license is 'royalty-free'. Just understand what strings are attached, and under which circumstances you may end up in jail, or paying huge fines...

This puts way too much power in the hands of a single company, given that email is a piece of core internet infrastructure. This isn't even proven technology yet, but for some reason there is this rush to get this through the IETF.

Why does this matter? by argent · 2004-09-02 06:27 · Score: 4, Insightful

Sender-ID, and in fact any other technology that tries to "fight spam" by restricting some particular technique that spammers are using, is going to be a purely short-term solution... and not much of a solution at all.

Spam is a social problem, and the behaviour that needs to be attacked is the broadcast unsolicited messaging process itself. Any bulk or broadcast communication that the recipient is not in control of (they didn't directly solicit it, or it's not relevant mail from someone they have an ongoing and clear relationship with) has to be explicitly illegal.

Mandate Sender-ID or SPF, and spammers will sign up and continue to spam. Mandate tagging, and spammers will tag and spam *and* people who aren't spammers will be unsure and tag as well... and their mail will be filtered out.

This is already happening, in both cases.

So, it doesn't matter whether anyone implements this technology or not, it's irrelevant to the problem people are hoping it will solve.

Please mod parent back up by ites · 2004-09-02 06:39 · Score: 4, Insightful

RMS's comments to the MARID list are very pertinent and to accuse him of "politics" is to make the mistake (deliberate or otherwise) of relativism. Open source/free software is not a subjective political opinion. The effects of adopting a petent-encumbered standard go far beyond mere politics. They affect the quality and cost of what issues.

RMS is entirely accurate when he says that Microsoft's is probably aiming to control anti-spam tools by controlling who can develop to the standards.

You may or may not support Microsoft's right to attempt to control a market. What you should not do is ignore the impact such control would have.

Open source and free software has proven to be a significant balancing force in the push for better and cheaper IT. Microsoft have done an excellent job in lowering the cost of certain kinds of software, mainly the user front-ends. Open source and free software have handled the back-ends - the servers - better than anything produced by any company, anywhere.

Spam is not a front-end issue. Locking anti-spam standards into a Microsoft-dominated front-end will make much money for some people but will ultimately end in a monopoly control of email, almost certainly built to the usual Microsoft standards: pretty, charming, and totally insecure.

The IETF is composed of individuals, each with their agendas. Many IETF members work from principle, but many others are paid for their work, and paid by companies with serious commercial interests in the outcome.

It's easy to mock RMS: he is sincere and outspoken. But it is misplaced. RMS is a prophet in the true sense of the word: he has had a vision of the way software should be made, and he has defined a way for this to happen.

Naturally some commercial interests detest him. But it's wrong: cheaper software means opportunity for everyone, especially commercial software firms. The world has an endless appetite for pretty, seductive front-ends.

They just should not be doing anything really, vitally important.

And that includes filtering spam.

--
Sig for sale or rent. One previous user. Inquire within.

SenderID and Patent Issues by sakeneko · 2004-09-02 06:39 · Score: 3, Interesting

After reading the statement on the ASF web sit, I reluctantly had to agree with the Apache Software Foundation on the issue of Sender ID. The "free license" offered to those that support SenderID in open-source software packages has too many pitfalls, too many places where it could encumber open source projects. The SpamBouncer will therefore not support SenderID either until there are fundamental changes in the license.

This is a shame. Meng Weng Wong's original idea for SPF was quite good, and I was planning to support it.

--

Catherine

nothing worse then a hypocrite by neoThoth · 2004-09-02 06:42 · Score: 4, Informative

[source:http://www.anti-spamtools.org/SenderIDEmai lPolicyTool/Default.aspx]
No SPF Record has been found for the domain microsoft.com. However, MX and/or A records currently exist for this domain.
The domain's MX and A records contain the following information:
Addresses Listed in A Records
207.46.130.108
207.46.250.119
Mail Servers Listed in MX Records
maila.microsoft.com 131.107.3.124
131.107.3.125
mailb.microsoft.com 131.107.3.122
131.107.3.123
mailc.microsoft.com 131.107.3.121
131.107.3.126

I think the industry term is "eat your own dog food". thanks for the recommendation MS, let me know when you start using your own bloody system.

Microsoft Patents by SiliconEntity · 2004-09-02 06:58 · Score: 4, Interesting

I think we are missing the real danger here. There was never all that much difference between SPF and Microsoft's Caller ID. The differences were in the details of how they were put into the DNS, the use of XML vs text formats, and maybe some issues about exactly which mail headers were checked. But the basic idea was almost identical.

This means that Microsoft's forthcoming Caller ID patents probably cover SPF. That's the real problem here.

We can't just tell Microsoft to get stuffed and then go ahead and use SPF. There's too much risk that Microsoft will surface with a patent in three or four years that covers a technology which is by then widely used on the net.

I think this decision kills SPF and everything along those lines. Some may cheer and some may be upset, but that is the reality we face. Going forward with SPF under these circumstances is far too risky. Microsoft has warned us about the patent applications and we can't ignore them.

We Need An Open Source Solution To A Closed Source by Long-EZ · 2004-09-02 07:18 · Score: 3, Insightful

The majority of spam is now sent by zombied Windows PCs. Windows insecurity is now a large part of the spam problem.

It sure looks like Microsoft sold PC users the problem, and now they want to sell us the solution. Should we really encourage OS insecurity by paying for the fix to a problem that never should have been?

--
>> My ultraviolent Linux switch video.

SPF is teh win by photon317 · 2004-09-02 07:27 · Score: 2, Insightful

Everyone's just gonna dump Sender-ID and implement classic SPF records. This whole marid/sender-id thing is ridiculuous, and smart reasonable people know that classic SPF is unencumbered, extremely simple, and does the job just fine. This popular opinion is evidenced by how quick and widespread the adoption of classic SPF has been to date. I suspect eventually we'll see dns servers implementing a custom record type for SPF to replace the current TXT records, but other than that, you don't really need anything else.

Classic SPF = no forgeries. As it's use becomes more widespread, eventually there will come a breaking point in time where "everyone" knows that when they set up an email server and make theri MX record, they better make an SPF record while they're at it too - and most people will reject email that hasn't passed SPF checks.

It doesn't directly stop spam, but it makes spam accountable, which is a large step in the right direction.

--
11*43+456^2

Re:SPF is teh win by hal200 · 2004-09-02 09:30 · Score: 2, Informative

FWIW, EasyDNS has supported adding TXT records to your DNS entry for a few months now.

They're a little more expensive than the other DNS service providers out there, but they provide backup MX servers, and I haven't had a single problem with them in 2 years.

And no, I don't work for them, nor am I a member of their affiliate program.

--
I just want to take over the world...Why does that automatically make me EVIL?

Sender-ID was never about stopping spam by dreamer-of-rules · 2004-09-02 08:14 · Score: 2, Insightful

Sender-ID/SPF was never about stopping spam. Repeat this to yourself until you actually hear it. People hear "spam" and "stop" and tend to jump to the wrong conclusion.

This is all about stopping forgery of the From: for domains that have registered their Sender-ID or SPF records. Spammers can still register a domain with authorization for any or all mail servers that they want, and continue sending out spam from zombied systems to their blackened and smoking hearts' content. They can continue to send spam for any other domains that allow forgery, like for alumni accounts or other drop box domains.

Sender-ID is only designed to stop phish-ing emails. So if you get an email from citibank.com, you can be reasonably sure it came from somebody at citibank.com, and not some guy's home pc, as long as citibank.com set up their records appropriately. That's all.

BTW, the reason the IETF is considering Sender-ID over SPF, is because it is highly probable that Microsoft can sue SPF out of existence.

This isn't meant to stop spam. This has nothing to do with stopping spam.

--
Everyone is entitled to his own opinions, but not his own facts.

Re:Sender-ID was never about stopping spam by sff0ghead · 2004-09-02 11:58 · Score: 3, Insightful

The main point in the above is correct: Sender-ID/Caller-ID/SPF
is about forgery. Forged spam is a use case, but there never was an illusion that this would stop spam--a spammer can simply buy a $9 domain, enter a record, and send the mail. The spammer just can't send it as user@protected.example.net
any more.

But the "Microsoft can sue SPF out of existence" piece is not correct (sorry, dude!). SPF protects part of the envelope:
the bounce address coded in the RFC 2821 MAIL-FROM;
Caller-ID/Sender-ID protect the headers in the RFC 2822
message (From:, Resent-From:, and the like). They do different
things. The working group discussed which one to prioritize
and picked the latter after Meng Wong and Mark Lentczner
(SPF authors) met with the Microsoft authors (Harry Katz and
Jim Lyons); this was discussed at the MARID
Campbell interim meeting.

Both are still interesting, but killing Sender-ID in favor of
SPF, as many are now advocating means you're changing
strategy; you're fundamentally changing what you're protecting.

To go back to the main point, neither will stop spam.
Write that down. .

What this means for the standard by cerberusti · 2004-09-02 08:15 · Score: 5, Informative

In less than a week, IETF Last Call for this standard will be over. As of the moment, there is no consensus on the Microsoft patent issue. This will almost certainly prevent the standard from moving forward. The IETF is too divided on this issue for the standard to progress as it is.

Also, a clarification of how the IETF handles patent claims seems to be in order.

Patents are allowed in IETF standards under any terms that the working group feels are acceptable. In most cases, since the goal is to produce a standard which is useful to the largest group possible, patented methods are only used if the patent holder is willing to grant a very permissive license.

For example: The latest working group I was part of was SEND (SEcure Neighbor Discovery), a part of IPv6. SEND makes use of Cryptographically Generated Addresses, which are patented by Erricson. Erricson agreed to license the patent on the terms below:

In addition, for the CGA submission, if said submission is included in the IETF SEND standard and Ericsson has patents that are essential to the implementation of such included submission in said standard, Ericsson shall not assert any such patent against any company or legal entity using said patents in the IETF SEND standard. The Ericsson non-assertion is conditional upon such company or legal entity not asserting any patents within the IETF SEND standard against Ericsson. For all other purposes Ericsson's general patent license statement as referred to above, shall apply.

This is a fairly normal license for the IETF and was found to be acceptable. In almost every case where a patent is relevant to one of our standards, a licence statement such as this one is provided.

The Microsoft license is different, and has sparked quite a bit of discussion. Since this standard has a very large intended audience and there is significant concern over the terms of the license, unless Microsoft changes the terms of their license, this will stop the standard from progressing as is. Either the standard will be restructured to avoid using the methods claimed in the Microsoft patent, or the working group will terminate without a standard.

A lot of people are irritated about this.

--
I'm a signature virus. Please copy me to your signature so I can replicate.

Why does the IETF need to be told this? by hopethishelps · 2004-09-02 08:15 · Score: 2, Insightful

From Apache's open letter:

Finally, as developers of open source e-mail technologies, we are concerned that no company should be permitted IP rights over core Internet infrastructure. We believe the IETF needs to revamp its IPR policies to ensure that the core Internet infrastructure remain unencumbered.

Amen to that. But why did the IETF open the door to patent-encumbered, proprietary material in Internet standards in the first place? Sounds to me as though the current IETF needs to be largely replaced.

a few apache subdomains have txt records by ger · 2004-09-02 08:21 · Score: 2, Informative

some apache.org subdomains have txt records:

$ host -t txt xml.apache.org
xml.apache.org TXT "v=spf1 mx -all"

w3.org started rejecting forgeries based on SPF records about a week ago, and has been rejecting about 10000 forgeries/day since then, including:

52 jakarta.apache.org
18 xml.apache.org

a few other domains that have been forged and rejected according to their SPF records:

1628 amazon.com
222 gmail.com
175 redhat.com
129 lists.sourceforge.net
17 sourceforge.net

(numbers above are # of rejections in the first week)

Re:IETF and patents by figlet · 2004-09-02 09:13 · Score: 2, Informative

Although the W3C has made great efforts to avoid "submarine patents", its Patent Policy does not stop patent encumbered W3C recommendations from being created. Simply put, participants in the working group of the recommendation must license any patents they hold which is implicated in a Royalty-free and Non-Discriminatory (RAND) fashion to anyone implementing the recommendation (other details in the policy...).

This does not stop recommendations which are encumbered by patents possessed by non-working group memebers of the W3C and non-W3C members to be ratified.

It's not what I would have wanted, but it ended up a big compromise (some would argue that the policy using RAND was the W3C caving...) ...See here for some of the goings-on concerning this policy...

Sorry... :-(

Forking the SPF standard by Alan+Cox · 2004-09-02 10:16 · Score: 2, Interesting

Nobody can fork the standard. The patent "grant" is for compliant implementations only. So its microsofts document, microsoft controlled and thats the end of it.

SPF also has another deeply fundamental flaw - it requires the ISP to be vaguely competent. That alone is fatal for many of ISPs.

What is this? Crazy Town? by evilviper · 2004-09-02 10:33 · Score: 3, Funny

What in the world?

Apache... criticizing a bad open source license... Whaaaaaa?

For those with no idea what I'm talking about: http://www.undeadly.org/cgi?action=article&sid=200 40220085910 http://yro.slashdot.org/yro/04/02/18/215242.shtml http://www.apache.org/licenses/GPL-compatibility

On a different note, it's rather funny... In another few years, the OpenBSD guys will be maintaining their own forks of every open source project out there. :-)

--
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant

Courier MTA rejects Sender ID too by lanner · 2004-09-02 14:43 · Score: 4, Informative

On the 27th of last month, the author of the Courier mail system, Sam Varshavchik, announced that Sender ID would not be supported by his MTA software due to the Microsoft patent problems, but that SPF would be. The following is a copy of that eMail.

--

The purpose of this message is to clarify my plans for any deployment of the Sender-ID specification in Courier (http://www.courier-mta.org).

Microsoft has made certain patent claims on the Sender-ID specification. Microsoft has issued the IPR disclosures and royalty free license required by the IETF. It appears that IETF's contemporary policies do not prevent the sponsor/advocates from including patented IP material into standards-track specifications, without even requiring the sponsor to actually enumerate and identify their intellectual property; a mere claim of the existence of some nebulous IP rights is sufficient, which can be revealed at any point in the future, at the sponsor's discretion.

The current development version of Courier implements the original SPF-classic specification, that predates Sender-ID. This will be rolled into a forthcoming release. I'm quite pleased with the results so far -- there are a lot of classic SPF records in existence, as witnessed by my mail logs :-)

It will not be possible for me to implement Sender ID in Courier. Courier is licensed under the GPL. The FSF already flatly stated that Microsoft's IP license is not GPL compatible. I reviewed the most recent version of Microsoft's proposed IP license, and I've reached the same conclusion. For this reason Sender ID cannot be implemented in Courier; Courier's implementation will be limited to the unencumbered SPF-classic.

--
Sam Varshavchik
http://www.courier-mta.org

Re:cool by little_fluffy_clouds · 2004-09-02 15:31 · Score: 3, Informative

grep -c helps avoid unnecessary use of wc -l ;)

--
What were the skies like when you were young?

79 of 351 comments (clear)