You know, this sounds like it won't ever make it to the level that CPAN has reached. The reason CPAN works is simple: it's entirely open to anyone to put stuff in there.
In other words, the barrier to entry is incredibly low, and you get free worldwide distribution off the back of it.
Now in spite of this, there are some incredibly high quality pieces of software uploaded to CPAN every week (there's a lot of junk there too). A lot of people complain about the junk and cry for a way to filter it out, but honestly I think it's actually a bonus - the people who write junk today may produce master works tomorrow and we don't want to discourage them (I went through that same process myself with my earlier CPAN efforts).
There's been some pretty good stuff written about the success of CPAN elsewhere. I would urge those working on this project to find those articles and read them.
No, this is the key to pissing people off who never sent you those mails in the first place. You realise these mails go back to forged senders when you bounce them, not the spammers, right?
You can open from the command line with open -a jEdit filename, which of course you can easily turn into a shell script or a bash function.
Re:"no one has..survived a landing without a chute
on
Closer to Human Flight
·
· Score: 4, Interesting
It all comes down to how much you can move an object. When you hit water the object has to move sideways to get out of your way. This is much harder to achieve than moving something down (i.e. by breaking glass) plus the glass will weigh a hell of a lot less than a few hundred meters of water going straight down, so the opposing force is a lot less.
By breaking several layers of glass one by one you slow the body down with a succession of small forces rather than one big one.
I work for an outsourcer (I won't provide the name in case moderators think I'm advertising), and I'm astonished by your story. We've NEVER had that kind of outage. Once we had some of our infrastructure down for about 8 hours while one of our upstreams had big problems, but in 4 years working here that's the only outage we've ever had. We filter mail for some pretty important customers so we just couldn't allow that kind of downtime to happen.
I know that outsourcing involves a lot of trust, but to paint all outsourcing as bad because of one bad experience is a little unfair.
The Sender entry in the headers is often added by MTAs as the value in the SMTP envelope's MAIL field. This is the same value that SPF validates against.
Just because you don't understand SMTP and SPF is written in RFC language does not mean that Caller-ID is better. The XML in DNS TXT records is a big deal. The fact that with Caller-ID you have to validate after DATA is a big deal. But you won't understand these issues if you don't understand SMTP.
It would be impossible because SPF supports more features than Caller-ID.
If you just wanted to do the subset of features that Caller-ID supports then it would be very easy. SPF is trivial to parse. Case in point - the code required to parse Caller-ID is around 1MB (including the XML Parser for perl and expat). The code required to parse SPF is around 50k.
This is a common misconception by geeks who are smug because they didn't get infected with Sobig.
Sobig didn't use any exploits. It was just a plain old.EXE attached to an email. Outlook prompted the user when they tried to run it telling them that exes often contain viruses. But they still ran it.
This behaviour is the same in Thunderbird and other windows mail clients. It's even the same in Apple's Mail.app.
Don't be a bigot and assume you're immune because you don't run Outlook.
Sobig.E came out before the virus scanners had signature updates. When viruses spread so fast these days about all you can do is push your email through MessageLabs who have never let a virus through to a customer due to their custom AV scanner which uses heuristics instead of signatures.
Your point about not relying on any one point of access is well taken though - all entry points need to be protected in one way or another.
When you're sending out a virus, or just writing a mass mailer and letting it spread itself, there is no product to advertise. No product means no link. Think of the virus as the "first stage".
When it comes to doing the spamming itself the spammer is just "innocently" using an open proxy, and while that may be rude it's not considered illegal. It would be very hard to link the spamming and the virus writing in any legal way without access to the machine which created the virus (and finding the source code to it on a spammer's machine), hence the link is purely speculation, but it's based on pretty strong coincidental evidence.
We use Bayes at the ISP level, and it's effective, but nowhere near as effective as when it gets per-user training. Consider that a particular group of people at your ISP may get emails that look like your spam (stock reports, HTML newsletters, asian emails, etc) and you'll see what the problem is.
There are some potential solutions to this (such as ours which is to use bayes merely as part of an overall solution), but most ISPs don't want to be storing 30M of bayes database per user - its just not sensible.
No. False positives are always bad. A false positive means you blocked a legitimate mail. A mail that was not spam. A mail that was not from a spammer, but from a person trying to contact you.
Frankly it's the spammers that should suffer, not the legitimate users. False positives in the fight against spam cause nothing but animosity. We've had DNSBLs for a long time now, and I see nothing but an increase in the level of spam. Are DNSBLs working for you? Maybe. Is the collateral damage model reducing the amount of spam the world sees? Nope. Not remotely.
Time to move on, try something else. Time to stop more spam and hit them in the pocket. We've no evidence that will work either, but at least we're trying something.
Actually it's the other way around. DNSBL's (not RBLs - thats a specific term for MAPS' list) are fine for personal users, and even for some businesses, but generally they have way too high a false positive rate for any kind of generic filtering. The SpamAssassin team has done lots of research into this, see for example the slide at the very end of my talk.
No, for a large scale service you need much lower rates of false positives than any of the DNSBLs provide right now. They're fine as inputs into heuristic or statistical systems, but on their own they are just not accurate enough.
Slashdot Mirror
You know, this sounds like it won't ever make it to the level that CPAN has reached. The reason CPAN works is simple: it's entirely open to anyone to put stuff in there.
In other words, the barrier to entry is incredibly low, and you get free worldwide distribution off the back of it.
Now in spite of this, there are some incredibly high quality pieces of software uploaded to CPAN every week (there's a lot of junk there too). A lot of people complain about the junk and cry for a way to filter it out, but honestly I think it's actually a bonus - the people who write junk today may produce master works tomorrow and we don't want to discourage them (I went through that same process myself with my earlier CPAN efforts).
There's been some pretty good stuff written about the success of CPAN elsewhere. I would urge those working on this project to find those articles and read them.
No, this is the key to pissing people off who never sent you those mails in the first place. You realise these mails go back to forged senders when you bounce them, not the spammers, right?
You can open from the command line with open -a jEdit filename, which of course you can easily turn into a shell script or a bash function.
It all comes down to how much you can move an object. When you hit water the object has to move sideways to get out of your way. This is much harder to achieve than moving something down (i.e. by breaking glass) plus the glass will weigh a hell of a lot less than a few hundred meters of water going straight down, so the opposing force is a lot less.
By breaking several layers of glass one by one you slow the body down with a succession of small forces rather than one big one.
I work for an outsourcer (I won't provide the name in case moderators think I'm advertising), and I'm astonished by your story. We've NEVER had that kind of outage. Once we had some of our infrastructure down for about 8 hours while one of our upstreams had big problems, but in 4 years working here that's the only outage we've ever had. We filter mail for some pretty important customers so we just couldn't allow that kind of downtime to happen.
I know that outsourcing involves a lot of trust, but to paint all outsourcing as bad because of one bad experience is a little unfair.
The Amiga's "DataTypes" system was around before Quicktime.
Umm, DSPAM is in the report. The significant bit you're probably interested in is:
CRM-114 and DSPAM exhibit substantially inferior performance to the other filters, regardless of the threshold setting.
This is not a "data point". You've provided anecdotal evidence at best. You cannot compare this to an 8 month long academic study.
I can guess the first part (identification of potential airports) will use Rendezvous, so that should at least be trivial to emulate.
This is because you don't understand SMTP.
The Sender entry in the headers is often added by MTAs as the value in the SMTP envelope's MAIL field. This is the same value that SPF validates against.
Just because you don't understand SMTP and SPF is written in RFC language does not mean that Caller-ID is better. The XML in DNS TXT records is a big deal. The fact that with Caller-ID you have to validate after DATA is a big deal. But you won't understand these issues if you don't understand SMTP.
It would be impossible because SPF supports more features than Caller-ID.
If you just wanted to do the subset of features that Caller-ID supports then it would be very easy. SPF is trivial to parse. Case in point - the code required to parse Caller-ID is around 1MB (including the XML Parser for perl and expat). The code required to parse SPF is around 50k.
Better still, KDE has kio_fish, which allows you to access any ssh enabled server as a file server. Awesome stuff.
Looks like you've solved the Final Ultimate Solution to the Spam Problem. Congratulations!
That annoying bug is still there.
No. The address book is just one of the places it looks. It also checks the IE cache, and also does a filesystem scan!
This is a common misconception by geeks who are smug because they didn't get infected with Sobig.
.EXE attached to an email. Outlook prompted the user when they tried to run it telling them that exes often contain viruses. But they still ran it.
Sobig didn't use any exploits. It was just a plain old
This behaviour is the same in Thunderbird and other windows mail clients. It's even the same in Apple's Mail.app.
Don't be a bigot and assume you're immune because you don't run Outlook.
Perl has fixed this in the soon-to-be-released perl 5.8.1
Sobig.E came out before the virus scanners had signature updates. When viruses spread so fast these days about all you can do is push your email through MessageLabs who have never let a virus through to a customer due to their custom AV scanner which uses heuristics instead of signatures.
Your point about not relying on any one point of access is well taken though - all entry points need to be protected in one way or another.
When you're sending out a virus, or just writing a mass mailer and letting it spread itself, there is no product to advertise. No product means no link. Think of the virus as the "first stage".
When it comes to doing the spamming itself the spammer is just "innocently" using an open proxy, and while that may be rude it's not considered illegal. It would be very hard to link the spamming and the virus writing in any legal way without access to the machine which created the virus (and finding the source code to it on a spammer's machine), hence the link is purely speculation, but it's based on pretty strong coincidental evidence.
Mailblocks' patent dates from 1997. Unfortunately TMDA wasn't around then.
I'm sure there's other prior art though.
Even social problems require technical solutions to help the system.
Take for example theft. We lock our house doors and our car doors to prevent theft, even though theft is illegal and anti-social.
So the spam problem, while its true that its a social problem, I don't think you have "The" solution. We need technical fixes too, and we always will.
We use Bayes at the ISP level, and it's effective, but nowhere near as effective as when it gets per-user training. Consider that a particular group of people at your ISP may get emails that look like your spam (stock reports, HTML newsletters, asian emails, etc) and you'll see what the problem is.
There are some potential solutions to this (such as ours which is to use bayes merely as part of an overall solution), but most ISPs don't want to be storing 30M of bayes database per user - its just not sensible.
No. False positives are always bad. A false positive means you blocked a legitimate mail. A mail that was not spam. A mail that was not from a spammer, but from a person trying to contact you.
Frankly it's the spammers that should suffer, not the legitimate users. False positives in the fight against spam cause nothing but animosity. We've had DNSBLs for a long time now, and I see nothing but an increase in the level of spam. Are DNSBLs working for you? Maybe. Is the collateral damage model reducing the amount of spam the world sees? Nope. Not remotely.
Time to move on, try something else. Time to stop more spam and hit them in the pocket. We've no evidence that will work either, but at least we're trying something.
Actually it's the other way around. DNSBL's (not RBLs - thats a specific term for MAPS' list) are fine for personal users, and even for some businesses, but generally they have way too high a false positive rate for any kind of generic filtering. The SpamAssassin team has done lots of research into this, see for example the slide at the very end of my talk.
No, for a large scale service you need much lower rates of false positives than any of the DNSBLs provide right now. They're fine as inputs into heuristic or statistical systems, but on their own they are just not accurate enough.