The robots.txt shown in the post I replied to is invalid because this syntax is incorrect:
User-agent : * Disallow:/
Allow is indeed a problem due to "headers" not being defined. With your interpretation the file http://adwords.google.co.uk/robots.txt is valid and means exactly the same thing as
Actually, spiders would be perfectly justified in ignoring that robots.txt file, since it does not follow the format in the robot exclusion standard. There's no agreement about what a search engine spider is supposed to do when it encounters an invalid robots.txt such as this.
Finally! Looks like there are a lot of bug fixes in this one.
I hope the big memory leak I've been seeing with 2.6.10 have been fixed in 2.6.11. I had to disable HIGHMEM just to keep the machine running more than a few days, and that unfortunately means it's limited to 896MB LOWMEM.
The timeout is in dig, not in tinydns. This is the way it's supposed to work; tinydns doesn't answer queries for which it has no authoritative data and after a while dig stops waiting for an answer.
You can simulate the BIND behavior by adding the corresponding records to your data file, but there's no point in doing so - you would be encouraging lame delegation.
The difference is that virtually no one uses the.museum TLD. There have been complaints about the wildcards used for.cc,.nu and other TLDs. But it's only when they start playing games with.com and.net that people notice, because this affects everyone.
SPEWS is NOT dead. The osirusoft.com mirror of the SPEWS list is dead. The DDOS of the SPEWS web site does not matter (much); the SPEWS list is still being updated, distributed and used.
An updated version, OpenSSH 3.6.1, has just been released. Apparantly, the 'kex guesses' bugfix from OpenSSH 3.6 triggers a bug in a few other SSH v2 implementations and causes connections to stall. OpenSSH 3.6.1 disables this bugfix when interoperating with these implementations.
I don't know about 5-6 times longer compile times, but ICC (7.0) takes considerably longer time to compile my projects than MSVC (7.0 aka.NET) does. I've never benchmarked them, but ICC sure is slow enough that I prefer MSVC for Windows development whenever I can stand working with the C++ subset supported by MSVC.
While I fully agree spam is a serious problem - is it really that bad? I don't know what you are doing with your addresses to attract spammers, but at least for me, the DNS-based blacklists are still effective enough. Whitelists wouldn't make my life any easier, and they would surely complicate things for those who want to send me mail.
I get less than one actual spam message per day, and most of those are to the (unfiltered, as per RFC recommendations) postmaster@ address on my domain. All other addresses use blacklists only for spam prevention; there's a fair amount of spam blocked and very few legitimate messages are blocked - it has happened to me exactly once, even though I use somewhat aggressive blacklists. My main address have been in use for several years and I can't say I've been careful about revealing it - it has been used on mailing lists, various sign up forms, it's published on a number of web pages, etc.
Content filtering (Bayesian or whatever) seems to be popular among slashdotters. With an IP blacklist, erroneously blocked mail will bounce, making the sender aware of the problem. A content filter, on the other had, usually can't bounce so the message will be sent to/dev/null or stuffed in a trash folder together with other spam - the message is effectively lost. Sure, the filters may be good, but they still do make some mistakes and the cost of those mistakes are higher than it is for blacklists.
So I still prefer blacklists, despite their shortcomings (politics for one). They may be out of fashion, but the fact that messages are blocked before being accepted by the mail server feels right on principle - the spam never gets to waste my bandwidth or disk space.
host -t mx ixxnet.net
ixxnet.net. mail is handled by 5 mail.ixxnet.net.
ixxnet.net. mail is handled by 4 66.25.224.10.
MX must be a host name; an IP address is not acceptable. There are other suspect things about their DNS configuration, but that's probably what the Usenet post was hinting at.
Slashdot Mirror
The robots.txt shown in the post I replied to is invalid because this syntax is incorrect:
Allow is indeed a problem due to "headers" not being defined. With your interpretation the file http://adwords.google.co.uk/robots.txt is valid and means exactly the same thing as
Actually, spiders would be perfectly justified in ignoring that robots.txt file, since it does not follow the format in the robot exclusion standard. There's no agreement about what a search engine spider is supposed to do when it encounters an invalid robots.txt such as this.
Finally! Looks like there are a lot of bug fixes in this one.
I hope the big memory leak I've been seeing with 2.6.10 have been fixed in 2.6.11. I had to disable HIGHMEM just to keep the machine running more than a few days, and that unfortunately means it's limited to 896MB LOWMEM.
The exploit did work on my FireFox 1.0, and I have always had all those checkboxes except "Change Images" disabled.
I would like to disable JavaScript entirely, but unfortunately that breaks too many pages.
The timeout is in dig, not in tinydns. This is the way it's supposed to work; tinydns doesn't answer queries for which it has no authoritative data and after a while dig stops waiting for an answer.
You can simulate the BIND behavior by adding the corresponding records to your data file, but there's no point in doing so - you would be encouraging lame delegation.
The difference is that virtually no one uses the .museum TLD. There have been complaints about the wildcards used for .cc, .nu and other TLDs. But it's only when they start playing games with .com and .net that people notice, because this affects everyone.
No, Intels new naming strategy clearly dictates that the next form factor should be BTX II.
An OpenSSH Security Advisory was just posted about this.
SPEWS is NOT dead. The osirusoft.com mirror of the SPEWS list is dead. The DDOS of the SPEWS web site does not matter (much); the SPEWS list is still being updated, distributed and used.
An updated version, OpenSSH 3.6.1, has just been released. Apparantly, the 'kex guesses' bugfix from OpenSSH 3.6 triggers a bug in a few other SSH v2 implementations and causes connections to stall. OpenSSH 3.6.1 disables this bugfix when interoperating with these implementations.
I don't know about 5-6 times longer compile times, but ICC (7.0) takes considerably longer time to compile my projects than MSVC (7.0 aka .NET) does. I've never benchmarked them, but ICC sure is slow enough that I prefer MSVC for Windows development whenever I can stand working with the C++ subset supported by MSVC.
While I fully agree spam is a serious problem - is it really that bad? I don't know what you are doing with your addresses to attract spammers, but at least for me, the DNS-based blacklists are still effective enough. Whitelists wouldn't make my life any easier, and they would surely complicate things for those who want to send me mail.
I get less than one actual spam message per day, and most of those are to the (unfiltered, as per RFC recommendations) postmaster@ address on my domain. All other addresses use blacklists only for spam prevention; there's a fair amount of spam blocked and very few legitimate messages are blocked - it has happened to me exactly once, even though I use somewhat aggressive blacklists. My main address have been in use for several years and I can't say I've been careful about revealing it - it has been used on mailing lists, various sign up forms, it's published on a number of web pages, etc.
Content filtering (Bayesian or whatever) seems to be popular among slashdotters. With an IP blacklist, erroneously blocked mail will bounce, making the sender aware of the problem. A content filter, on the other had, usually can't bounce so the message will be sent to /dev/null or stuffed in a trash folder together with other spam - the message is effectively lost. Sure, the filters may be good, but they still do make some mistakes and the cost of those mistakes are higher than it is for blacklists.
So I still prefer blacklists, despite their shortcomings (politics for one). They may be out of fashion, but the fact that messages are blocked before being accepted by the mail server feels right on principle - the spam never gets to waste my bandwidth or disk space.
host -t mx ixxnet.net
ixxnet.net. mail is handled by 5 mail.ixxnet.net.
ixxnet.net. mail is handled by 4 66.25.224.10.
MX must be a host name; an IP address is not acceptable. There are other suspect things about their DNS configuration, but that's probably what the Usenet post was hinting at.