The city itself shouldn't be talking about forming a monopoly, supporting a monopoly or operating a utility. Instead the city should be doing what it needs to do to facilitate the creation of city-wide mesh networks by private providers.
If you RTFA, you would find this quote:
Who says the government is going to be the ISP or build the network? What about the old public-private partnership models? Maybe--just maybe--they should see what the City of Philadelphia is proposing before they attack.
So, yeah, I think this is a good idea. Create a market, not a monopoly.
Latency is the problem - getting down to the ideal of about 70ms regardless of where in the world you are going is key.
You aren't going to be able to reach the 70ms latency from any where in the world to anywhere in the world.
The speed of light is about 299,792km/s. The cicumference of the earth is about 40,000 km, so the time it takes light to go half way around the world is about 65ms.
Electrons in a wire and photons in fiber don't travel as fast as light in a vacuum and wires/fiber aren't layed in a straight line anyway. Add in encoding/decoding times, and delays caused by going through routers, and you are going to be lucky to reach 100ms.
Moria wasn't really a first person shooter game. Yeah, you ran around in a maze with a first person perspective, but you never saw anything other than the walls. Once you "encountered" some monsters, you would go into a more traditional nethack-type battle. (Yeah, it preceeded nethack, people are more familiar with nethack.)
I also thought that Moria wasn't created until the late 70s, and there there were more traditional nethack-like games before then. I used MinnA instead of Cerl, so maybe it just took a long time to make it over there.
Plato was a really cool system. Back in the 70s and 80s, it was more like the modern Internet than the Internet was back then.
One of the things that publishing SPF records does is that it creates a public statement about which email servers are authorized by you to use your domain name and which aren't.
This is somewhat like posting a "no trespassing" sign, and a chain link fence around your property. It doesn't prevent the people from cutting through the fence and getting hurt on your property, but it lets you show to the courts that you took reasonable steps to prevent it.
This is also a good reason to check SPF records. If your company or ISP lets child porn email go through that the domain owner explicitly said should not be allowed, you may have to show why you aren't contributing to the libelling of the domain owner and why you didn't protect your employees/customers from preventable child porn.
Yeah, at this instant, SPF is not enough of a standard to give you strong protection, but in 5-10 years, I think that will change.
The war, of course, is not over. The IETF (Ted, and maybe the former
co-chairs?), Meng, and MS (Harry, Jim, Bob, et al) appear to have
learned nothing from what has happened. They have done an end-run
around the working group last call by closing down the working group,
but they are still pushing ahead with the PRA under the current
license. Apparently, they think that when the "individual" I-Ds are
submitted to the IESG and there is an IETF-wide last-call, things will
go better. I don't see it.
One definition of insanity is doing the same thing again and again and
expecting different results. Under this definition, Ted, Meng, Harry,
Jim, et al, are acting quite insane.
I see four choices:
1) Forget about getting a de-jure standard.
2) Drop the PRA.
3) Change the PRA license to be compatible with F/OSS MTAs.
4) Find one or more widely accepted alternative to the PRA that covers
the 2822.From: identity so that people can reasonably choose
between the PRA and the alternatives.
Ted, Meng, Harry, Jim et al: PLEASE! Wake up and smell the coffee!
We need a anti-forgery system that protects the 2822.From: identity,
we don't need another two-week blowup when the IESG last-call happens.
It appears that my predictions are coming true. Meng, MS and the IETF
shut down the MARID WG so that they could more easily push the patent
encumbered SenderID through. They no longer have to deal with a WG
last call.
Expect more steps to happen after IETF-61 when the individual drafts
will be "reviewed".
I'm on the (not yet IETF) MASS mailing list, the DomainKeys mailing list, and I've read the DomainKey's spec a couple of months ago, but I can't say I'm an expert on all things domainkeys.
SPF verifies that the IP address of the mail server sending you the email is authorized by the domain to do so. This causes problems when email is forwarded, such as via pobox.com. It requires all email to be sent through "authorized" servers, which can cause problems when people are working from home and want to send email, or when you are in a cyber cafe. It also causes problems when email is generated on greeting-card/news-story websites.
DomainKeys creates a hash of the email body and some of the headers and uses public key technology to sign it. This causes problems when email is sent to a mailing list and the mailing list mangles it or when it is sent through things like MS Exchange servers. There are also problems with being able to replay the message. Like SPF, there are problems people are working from home and want to send email, or when you are in a cyber cafe. Also like SPF, also causes problems when email is generated on greeting-card/news-story websites.
Using DomainKeys, a spammer can send an email from a throw-away gmail account to another email account, pick up a copy of the spam with the correct domainkeys signatures, and then blast it out to everyone. I can't see any way to prevent this with domainkeys.
Many mailing lists add stuff at the end, either unsubscribe/archive info, or outright ads. In order to make DomainKey signatures survive being sent through mailing lists, the email body is converted to a "canonical form", which allows this extra text to be ignored.
The problem is that a spammer can subscribe to a mailing list, watch for emails without much text, then add their own ads (spam) onto the end and send it out.
I think domainkeys is an interesting idea, but as of right now, I can't see how it is ever going to work or be useful.
Anyone who attended or watched the videos of last year's FTC anti-spam conference will know that the FTC very much has a clue about the spam problem. They showed far more clue than even the average slashdotter, let alone the general public.
Not only do I expect many F/OSS people to be allowed in, I expect the concerns of deploying anti-spam solutions in F/OSS mail servers to be front and center. I also expect there to be people who don't give a flip about F/OSS to be there too, along with a bunch of spammers^Wethikal bidnizmen.
Actually, I have a list of around 650,000 domains in.COM,.NET and.ORG that have SPF records. These should show up in the SPF Adoption Roll Real Soon Now. Surveys of the.DE and.FR TLDs have also been done, but I don't have the results of those.
I'd like to know how many of those domaines actually are applying effective policies.
In the survey of the.COM domains, I found the top ten SPF records to be:
As you can see, it is very common to define strict SPF record with the "-all" at the end. Those domains that use the softfail option of "~all" are somewhat more lax, but still moving in the right direction.
The complete survey results are available to people who follow the IETF MARID list and/or the SPF discuss list. I'm not going to post a link to them here 'cause I don't want to be slashdotted.
I really wish this was a case of the world having a moment of clarity and deciding that MS won't get their way. Unfortunately, nothing could be further from the truth.
First off, the co-chairs message is so murky and confusing that about a half dozen of us have asked for clarifications about what the heck they are saying.
Far from ruling against MS, it appears to me that the co-chairs have give the green light to advance the patent encumbered PRA algorithm and they are saying that the IETF working group will not consider any replacement for the PRA since it might infringe on MS's patent.
Within a matter of seconds after Chuck first posted this story, I told him I thought he had gotten it totally wrong. Chuck agreed that the jig many not be up, reworded the very end of the story (RTFA) and sent email to the co-chairs. To the best of my knowledge, the co-chairs have not responded to any of us who have asked for clarification.
Dan Quinlan (of Spamassassin/ironport) has been working with Larry Rosen (a lawyer for OSI) and Eben Moglen (a lawyer for FSF) for months now. *VERY* little progress has been made, even when it was clear that SenderID would be at risk of not being advanced by the IETF to RFC status. I have *VERY* little hope that Microsoft will make the required changes to their license to be compatible with Free/open source software.
Insight into the current situation can be found in a post by Matt Sergeant (Spamassassin/messagelabs):
I pressed [Craig Spietzle of Microsoft]: "Will you fix the
license?". I never really got a confirmed yes or no, but my feeling
was "no" when we ended the conversation. I suggested that they give
their IP to the IETF (such as I believe there is precedence of - I
know that IBM has committed patents to the public domain before in a
similar act of openness), to which I was told that Craig believed
this was a reasonable idea, but that Bill Gates himself had vetoed
that idea because of the current focus on patent gathering and IPR
issues at Microsoft.
Here are parts of the email I sent Eric last week about the fetchmail vs SenderID patent.
Yakov Shafranovich (the former chair of the IRTF's ASRG) did some
digging for prior art and turned up quite a bit. One of the examples
that he gave was fetchmail.
I just realized that another way to look at this is not that fetchmail
is prior art, but that if the MS patent goes through, fetchmail will
be infringing on MS's patent and you will need to get a license from
MS to continue to distribute fetchmail.
Mind you, lawyers from places like the OSI, FSF and the Apache
Software Foundation have found MS's SenderID license to be
incompatbile with various F/OSS licenses, including the GPL. So, if
you don't want to run the risk of MS sueing you, you will not only
have to get a license from them, but you will need to change your
license.
Yeah, there *is* a chance that the USPT might reject MS's license
because of the prior art, but, gee, we both know what the chances of
that happen are.
In <20040903064727.GE4436@thyrsus.com> "Eric S. Raymond" [snip] writes:
> wayne <wayne@midwestcs.com>:
>> Yakov Shafranovich (the former chair of the IRTF's ASRG) did some
>> digging for prior art [on PRA] and turned up quite a bit. One of the examples
>> that he gave was fetchmail.
>
> Oh, that *is* interesting. So why back down? Let's fight Microsoft on this.
Oh, I just realized. If MS's patent goes through, you (and all
distributors of fetchmail) will not be able to get a SenderID license
from Microsoft to keep you from risking being sued by MS.
Not only does fetchmail not implement all required aspects of SenderID
(a requirement of the license), but fetchmail's use of header checking
appears to be used for different purposes than implementing SenderID.
MS's license only covers SenderID usage. You will have to negotiate
directly with MS to see if they will permit you, and all users of
fetchmail, to continue using the functionality that you have had for
years.
And, in one more followup, I mentioned:
I had missed interesting detail when I first read the following post
by Matt Sergeant:
I pressed [Craig Spietzle of Microsoft]: "Will you fix the
license?". I never really got a confirmed yes or no, but my feeling
was "no" when we ended the conversation. I suggested that they give
their IP to the IETF (such as I believe there is precedence of - I
know that IBM has committed patents to the public domain before in a
similar act of openness), to which I was told that Craig believed
this was a reasonable idea, but that Bill Gates himself had vetoed
that idea because of the current focus on patent gathering and IPR
issues at Microsoft.
RMS has made no attempt to talk to anyone in the group to find out the real situation.
I'm not sure how you know this. Apparently he was communicating with Michel Bouissou.
We asked Harry and Jim to take up the licensing issue with their lawyers about a week ago. They are meant to come back with a reply before we have the MARID meeting at the San Diego IETF the week after next.
For those who aren't in on who's-who on the IETF MARID working group, Harry and Jim are two of the folks from Microsoft who are working on the SenderID proposal.
However, I know that I have been asking for resolution for this licensing issue on the working group for much more than a week. This is not a new issue.
Now less than 24 hours after Microsoft go off to talk with their lawyers people start campaigning to take the Microsoft technology out using the licensing issue as an excuse. This came mainly from a group of tourists who had had nothing to do with the group previously. It is very obviously a campaign by people whose priority is not getting the best MARID spec we can.
This is almost completely not true. Microsoft lawyers have been in discussions over the license issue since early June (6 weeks ago). While there were indeed some luckers who posted first about the license issue, many of the active participants in the working group started the license discussion. People who object to the current SenderID license for MS do want the best proposal possible. If no one objected to the license, we would have a bad proposal.
Now could someone please translate this acronym-laden message for those of us who do not happen to have spent their entire lives following this particular mailing list?
I've been very active in the SPF project for a long time and have been very active in the IETF MARID working group that is standardizing the merged SPF and Caller-ID spect. In particular, I have been a very vocal critic of the MS license have have tried to work both within the IETF working group and outside to make the license compatible with all major mail servers (MTAs) and other packages, such as spam filters.
I have personally met several of the Microsoft employees who are doing the work on Sender-ID. I have ever reason to beleive that they are working in good faith to try and make sure this technology can be deployed by everyone, including GPLed software. The problem is that Microsoft is a huge company and things like the licensing issue are handled by Microsoft lawyers, not the people directly involved in SenderID.
I know that the SenderID MS folks are working with MS lawyers, and the MS lawyers are working with lawyers from the FSF, Open Source Initiative (OSI), and IBM (for postfix). The IETF working group co-chair has given MS until early August to get this problem resolved.
Personally, I'm going to give Microsoft lawyers a little more time before I try to outright kill the SenderID RFC.
The reference implementation of the SPF validator includes code to validate using Microsoft CallerID records as well. That means that the XML parser needs to be present on the server.
The checking of Caller-ID records in the perl reference implementation has always been optional. I know of only one other SPF implementation that even has Caller-ID support as an option. With the push by Microsoft to use Sender ID (which doesn't use XML) instead of Caller ID (which uses XML), I expect these optional XML checks to be eliminated.
I ran a study of 1.3 million email domains and found only a couple dozen domains that published Caller ID (XML) records, but not SPF records. (Details of this study were posted to the IETF MARID mailing list.) There simply is no good reason to enable these optional Caller ID checks.
I am unconvinced this scheme will make much of a difference in the spam epidemic.
Spam, like other forms of theft, will never be eliminated. SPF/Sender-ID helps solve one portion of the damage done by spammers and it allows you to safely whitelist domains.
And ultimately, it would only stop spam if every system on the planet adopted it. Otherwise a spammer will simply operate from a host that isn't SPF-compliant.
According to spamhaus.org, there are only a few hundred spamming organizations that account for the vast majority of spam. We don't need everyone in the world to adopt SPF, we only need enough to convince these few people to switch from forging legitimate domain names to using their own. Once that happens, the vast majority of bogus bounces will be eliminated.
Ultimately, this is bad. It makes the largest ISPs, who can afford to offer SMTP and all other services, easier to work with, and the smaller guys have more of an administrative overhead to keep up with DNS management.
I disagree. Most of the people involved in the SPF project are not major ISPs. Most of us think it is a good thing for everyone who uses email.
The modifications to SPF made by Microsoft and the IETF when creating Sender ID will not make it proprietary. Since Microsoft does not control the standard nor the software, they can not easily "embrace and extend" it.
The primary difference between SPF and Sender ID is that Sender ID also has the ablility to check the RFC2822 From: email header in addition to the RFC2821 envelope from value. This is something that most of the people in the SPF community wanted to do all along, but it would require changes in end-user mail systems, such as outlook, to do right. Without the support from MicroSoft, this couldn't really be done.
Okay, all I know is that SPF is a good deal simpler than SenderID and much more popular, due to the simple text format verses the use of XML.
XML was dropped from the Sender ID spec by the IETF last month.
The primary difference between SPF and Sender ID is that Sender ID also has the ablility to check the RFC2822 From: email header in addition to the RFC2821 envelope from value. This is something that most of the people in the SPF community wanted to do all along, but it would require changes in end-user mail systems, such as outlook, to do right. Without the support from MicroSoft, this couldn't really be done.
MicroSoft supporting SPF records is a really smart move. Last week, I posted results of a survey of 1.3 million email domain names to the IETF MARID mailing list. Now that I'm back from the MARID meeting, I just finished a survey of Caller-ID records. There appears to be about a factor of 500-1000 more domains that have published SPF exclusively than Caller-ID exclusively and only a tiny fraction of the 1.3 million domains have published Caller-ID records. In short, MicroSoft isn't changing to support SPF records because they are better (I think they are), but because it is an acknowledgement that MicroSoft's Caller-ID hasn't caught on.
Meng Weng Wong (the SPF author) and MicroSoft are still discussing how exactly this merger will work on. I personally don't see any reason to support XML right away. MicroSoft has not come out with a single concrete extention that can't be done with SPF already.
I also think that there are alternatives to the complex Caller-ID algorithm and that doesn't require every Ezmlm and other mailing lists to upgrade their software. From the research that I've done (and yes, this is something I have really researched), there appears to be far more mailing lists broken by MS's Caller-ID system than email forwarders broken by SPF.
Sorry to give you one less reason to hate MS, but they are taking the money as a BOND, not as payment. MS only gets the money if the spammers don't follow their rules.
MicroSoft doesn't get the bond, bondedsender gets the bond. Bondedsender has an incentive to whack spammers quickly so as to get the bond money. This discourages spammers from using bondedsender, which encourages ISPs like MSN/Hotmail to use them.
If you get a spam from somone on the bondedsender program, just report it via spamcop.net. The report automatically goes to bondedsender. If you are not sure if the spam came from someone using bondedsender, just report it via spamcop.net and let them figure it out.
MicroSoft isn't selling anything, they are using the services of another company, namely bondedsender.com.
Who are bondedsender? They are part of ironport systems, who also own spamcop.net. Spam reported to spamcop.net automatically gets reported to bondedsender.com and the spammer gets whacked.
This is really good news because spamcop.net/ironport were recently sued by the spammer snotty scott richter. This means that ironport will have more income to not only fight the spam lawsuit but fight spam in general.
Remeber that the You-Can-Spam act has penalties that are so small that only cost effective for the largest ISPs to can bring claims against spammers. So, only the largest ISPs can really decide which spam gets eliminated. Remember also that you can't bring any claims at all if you are not an ISP.
There is a HUGE potential market out there for "good" bulk advertising out there, if only all the pr0n and scams can be eliminated. These large ISPs have an "existing business relationship" with all their customers, and maybe arguably with those that send email through their servers. Just think of how much these ISPs could make by sending "good" spam from Ford, Pepsi, Pfizer, or PlayBoy.
Cellphone blocking should be automated
on
Cell-Phone Wars
·
· Score: 2, Insightful
I think that being able to create a "no cell-phone zone" is A Good Thing and should be legalized and automated.
Instead of sending out signals that distrupt cell phones, you should be able to buy a device that sends out a message that says "block incoming calls", "block outgoing calls", or "both". The cell phones should be able to override this information, but by default it should be respected. The message should include a GPS location signal, a serial/registration number of the device, and a text description of the location of the device. Local laws should dictate when and were it would be legal to use these devices. (I suspect it would be "private property only", with a few exceptions.)
Face it, most people really want to respect the no-cell phone requests for places that it isn't appropriate, but when you have a hundred people in a room, someone is sure to forget to turn off their phone. They are also going to forget to turn it back on after they leave.
A legalized "no cell phone zone" device would not stop assholes from overriding the request, but it would make life much easier for everyone else.
Slashdot Mirror
If you RTFA, you would find this quote:
So, yeah, I think this is a good idea. Create a market, not a monopoly.
You aren't going to be able to reach the 70ms latency from any where in the world to anywhere in the world.
The speed of light is about 299,792km/s. The cicumference of the earth is about 40,000 km, so the time it takes light to go half way around the world is about 65ms.
Electrons in a wire and photons in fiber don't travel as fast as light in a vacuum and wires/fiber aren't layed in a straight line anyway. Add in encoding/decoding times, and delays caused by going through routers, and you are going to be lucky to reach 100ms.
Moore's law doesn't trump laws of physics.
I also thought that Moria wasn't created until the late 70s, and there there were more traditional nethack-like games before then. I used MinnA instead of Cerl, so maybe it just took a long time to make it over there.
Plato was a really cool system. Back in the 70s and 80s, it was more like the modern Internet than the Internet was back then.
A good overview of Plato can be found at www.platopeople.com There is also a group of people trying to preserve the original plato system.
This is somewhat like posting a "no trespassing" sign, and a chain link fence around your property. It doesn't prevent the people from cutting through the fence and getting hurt on your property, but it lets you show to the courts that you took reasonable steps to prevent it.
This is also a good reason to check SPF records. If your company or ISP lets child porn email go through that the domain owner explicitly said should not be allowed, you may have to show why you aren't contributing to the libelling of the domain owner and why you didn't protect your employees/customers from preventable child porn.
Yeah, at this instant, SPF is not enough of a standard to give you strong protection, but in 5-10 years, I think that will change.
http://www.imc.org/ietf-mxcomp/mail-archive/msg051 35.html
It appears that my predictions are coming true. Meng, MS and the IETF shut down the MARID WG so that they could more easily push the patent encumbered SenderID through. They no longer have to deal with a WG last call.
Expect more steps to happen after IETF-61 when the individual drafts will be "reviewed".
SPF verifies that the IP address of the mail server sending you the email is authorized by the domain to do so. This causes problems when email is forwarded, such as via pobox.com. It requires all email to be sent through "authorized" servers, which can cause problems when people are working from home and want to send email, or when you are in a cyber cafe. It also causes problems when email is generated on greeting-card/news-story websites.
DomainKeys creates a hash of the email body and some of the headers and uses public key technology to sign it. This causes problems when email is sent to a mailing list and the mailing list mangles it or when it is sent through things like MS Exchange servers. There are also problems with being able to replay the message. Like SPF, there are problems people are working from home and want to send email, or when you are in a cyber cafe. Also like SPF, also causes problems when email is generated on greeting-card/news-story websites.
Using DomainKeys, a spammer can send an email from a throw-away gmail account to another email account, pick up a copy of the spam with the correct domainkeys signatures, and then blast it out to everyone. I can't see any way to prevent this with domainkeys.
Many mailing lists add stuff at the end, either unsubscribe/archive info, or outright ads. In order to make DomainKey signatures survive being sent through mailing lists, the email body is converted to a "canonical form", which allows this extra text to be ignored.
The problem is that a spammer can subscribe to a mailing list, watch for emails without much text, then add their own ads (spam) onto the end and send it out.
I think domainkeys is an interesting idea, but as of right now, I can't see how it is ever going to work or be useful.
Not only do I expect many F/OSS people to be allowed in, I expect the concerns of deploying anti-spam solutions in F/OSS mail servers to be front and center. I also expect there to be people who don't give a flip about F/OSS to be there too, along with a bunch of spammers^Wethikal bidnizmen.
I'd like to know how many of those domaines actually are applying effective policies.
In the survey of the .COM domains, I found the top ten SPF records to be:
159416 "v=spf1 mx -all"
147883 "v=spf1 -all"
51245 "v=spf1 ip4:10.0.0.0/24 ip4:10.0.0.0/24 ?all"
28206 "v=spf1 a:smtp.example.net -all"
21437 "v=spf1 mx ip4:10.0.0.0/19 ~all" ""
19733 "v=spf1 mx ~all"
15245 "v=spf1 a:smtp.example.com ~all"
9488 "v=spf1 ip4:10.0.0.0/24 mx -all"
6371 "v=spf1 ip:10.0.0.0/24 ip:10.0.0.0/27 ip:10.0.0.0/24 ip:10.0.0.0/27 ip:10.0.0.0/27 ip:10.0.0.0/27 ip:10.0.0.0/27 ip:10.0.0.0/27 ?all"
5842 "v=spf1 ip4:10.0.0.0/24 -all"
(I have munged the domain names and IP addresses for privacy reasons.)
As you can see, it is very common to define strict SPF record with the "-all" at the end. Those domains that use the softfail option of "~all" are somewhat more lax, but still moving in the right direction.
The complete survey results are available to people who follow the IETF MARID list and/or the SPF discuss list. I'm not going to post a link to them here 'cause I don't want to be slashdotted.
First off, the co-chairs message is so murky and confusing that about a half dozen of us have asked for clarifications about what the heck they are saying.
Far from ruling against MS, it appears to me that the co-chairs have give the green light to advance the patent encumbered PRA algorithm and they are saying that the IETF working group will not consider any replacement for the PRA since it might infringe on MS's patent.
Within a matter of seconds after Chuck first posted this story, I told him I thought he had gotten it totally wrong. Chuck agreed that the jig many not be up, reworded the very end of the story (RTFA) and sent email to the co-chairs. To the best of my knowledge, the co-chairs have not responded to any of us who have asked for clarification.
Insight into the current situation can be found in a post by Matt Sergeant (Spamassassin/messagelabs):
http://www.imc.org/ietf-mxcomp/mail-archive/msg040 45.html
First Atomic Clock Wristwatch
RMS has made no attempt to talk to anyone in the group to find out the real situation.
I'm not sure how you know this. Apparently he was communicating with Michel Bouissou.
We asked Harry and Jim to take up the licensing issue with their lawyers about a week ago. They are meant to come back with a reply before we have the MARID meeting at the San Diego IETF the week after next.
For those who aren't in on who's-who on the IETF MARID working group, Harry and Jim are two of the folks from Microsoft who are working on the SenderID proposal.
However, I know that I have been asking for resolution for this licensing issue on the working group for much more than a week. This is not a new issue.
Now less than 24 hours after Microsoft go off to talk with their lawyers people start campaigning to take the Microsoft technology out using the licensing issue as an excuse. This came mainly from a group of tourists who had had nothing to do with the group previously. It is very obviously a campaign by people whose priority is not getting the best MARID spec we can.
This is almost completely not true. Microsoft lawyers have been in discussions over the license issue since early June (6 weeks ago). While there were indeed some luckers who posted first about the license issue, many of the active participants in the working group started the license discussion. People who object to the current SenderID license for MS do want the best proposal possible. If no one objected to the license, we would have a bad proposal.
Yes! Someone HAS created such a web page. See: http://www.technoids.org/maridterms.html
I have personally met several of the Microsoft employees who are doing the work on Sender-ID. I have ever reason to beleive that they are working in good faith to try and make sure this technology can be deployed by everyone, including GPLed software. The problem is that Microsoft is a huge company and things like the licensing issue are handled by Microsoft lawyers, not the people directly involved in SenderID.
I know that the SenderID MS folks are working with MS lawyers, and the MS lawyers are working with lawyers from the FSF, Open Source Initiative (OSI), and IBM (for postfix). The IETF working group co-chair has given MS until early August to get this problem resolved.
Personally, I'm going to give Microsoft lawyers a little more time before I try to outright kill the SenderID RFC.
The checking of Caller-ID records in the perl reference implementation has always been optional. I know of only one other SPF implementation that even has Caller-ID support as an option. With the push by Microsoft to use Sender ID (which doesn't use XML) instead of Caller ID (which uses XML), I expect these optional XML checks to be eliminated.
I ran a study of 1.3 million email domains and found only a couple dozen domains that published Caller ID (XML) records, but not SPF records. (Details of this study were posted to the IETF MARID mailing list.) There simply is no good reason to enable these optional Caller ID checks.
Spam, like other forms of theft, will never be eliminated. SPF/Sender-ID helps solve one portion of the damage done by spammers and it allows you to safely whitelist domains.
And ultimately, it would only stop spam if every system on the planet adopted it. Otherwise a spammer will simply operate from a host that isn't SPF-compliant.
According to spamhaus.org, there are only a few hundred spamming organizations that account for the vast majority of spam. We don't need everyone in the world to adopt SPF, we only need enough to convince these few people to switch from forging legitimate domain names to using their own. Once that happens, the vast majority of bogus bounces will be eliminated.
Ultimately, this is bad. It makes the largest ISPs, who can afford to offer SMTP and all other services, easier to work with, and the smaller guys have more of an administrative overhead to keep up with DNS management.
I disagree. Most of the people involved in the SPF project are not major ISPs. Most of us think it is a good thing for everyone who uses email.
The primary difference between SPF and Sender ID is that Sender ID also has the ablility to check the RFC2822 From: email header in addition to the RFC2821 envelope from value. This is something that most of the people in the SPF community wanted to do all along, but it would require changes in end-user mail systems, such as outlook, to do right. Without the support from MicroSoft, this couldn't really be done.
(Yes, I posted this once but it appears to need repeating.)
XML was dropped from the Sender ID spec by the IETF last month.
The primary difference between SPF and Sender ID is that Sender ID also has the ablility to check the RFC2822 From: email header in addition to the RFC2821 envelope from value. This is something that most of the people in the SPF community wanted to do all along, but it would require changes in end-user mail systems, such as outlook, to do right. Without the support from MicroSoft, this couldn't really be done.
No one suggested that Don Knuth can't do, only those that can't do teach.
The MicroSoft Caller-ID/SPF merger proposals say that SPF records will be honored, so you can publish them without fear of losing support.
So, go ahead and publish SPF records.
MicroSoft supporting SPF records is a really smart move. Last week, I posted results of a survey of 1.3 million email domain names to the IETF MARID mailing list. Now that I'm back from the MARID meeting, I just finished a survey of Caller-ID records. There appears to be about a factor of 500-1000 more domains that have published SPF exclusively than Caller-ID exclusively and only a tiny fraction of the 1.3 million domains have published Caller-ID records. In short, MicroSoft isn't changing to support SPF records because they are better (I think they are), but because it is an acknowledgement that MicroSoft's Caller-ID hasn't caught on.
Meng Weng Wong (the SPF author) and MicroSoft are still discussing how exactly this merger will work on. I personally don't see any reason to support XML right away. MicroSoft has not come out with a single concrete extention that can't be done with SPF already.
I also think that there are alternatives to the complex Caller-ID algorithm and that doesn't require every Ezmlm and other mailing lists to upgrade their software. From the research that I've done (and yes, this is something I have really researched), there appears to be far more mailing lists broken by MS's Caller-ID system than email forwarders broken by SPF.
(I'm the author of libspf-alt and the maintainer of the trusted-forwarder global whitelist. So, now you know why I have researched this stuff so much.)
MicroSoft doesn't get the bond, bondedsender gets the bond. Bondedsender has an incentive to whack spammers quickly so as to get the bond money. This discourages spammers from using bondedsender, which encourages ISPs like MSN/Hotmail to use them.
If you get a spam from somone on the bondedsender program, just report it via spamcop.net. The report automatically goes to bondedsender. If you are not sure if the spam came from someone using bondedsender, just report it via spamcop.net and let them figure it out.
MicroSoft isn't selling anything, they are using the services of another company, namely bondedsender.com.
Who are bondedsender? They are part of ironport systems, who also own spamcop.net. Spam reported to spamcop.net automatically gets reported to bondedsender.com and the spammer gets whacked.
This is really good news because spamcop.net/ironport were recently sued by the spammer snotty scott richter. This means that ironport will have more income to not only fight the spam lawsuit but fight spam in general.
There is a HUGE potential market out there for "good" bulk advertising out there, if only all the pr0n and scams can be eliminated. These large ISPs have an "existing business relationship" with all their customers, and maybe arguably with those that send email through their servers. Just think of how much these ISPs could make by sending "good" spam from Ford, Pepsi, Pfizer, or PlayBoy.
Instead of sending out signals that distrupt cell phones, you should be able to buy a device that sends out a message that says "block incoming calls", "block outgoing calls", or "both". The cell phones should be able to override this information, but by default it should be respected. The message should include a GPS location signal, a serial/registration number of the device, and a text description of the location of the device. Local laws should dictate when and were it would be legal to use these devices. (I suspect it would be "private property only", with a few exceptions.)
Face it, most people really want to respect the no-cell phone requests for places that it isn't appropriate, but when you have a hundred people in a room, someone is sure to forget to turn off their phone. They are also going to forget to turn it back on after they leave.
A legalized "no cell phone zone" device would not stop assholes from overriding the request, but it would make life much easier for everyone else.