Ah, that explains it. So tinydns just drops the request without telling the requestor that it isn't going to answer the query. That is fair enough, since we are talking about a query that should have never happened in the first place.
With djbdns you typically run tinydns (the authoritative dns server) on 127.0.0.1, and dnscache (the recursive resolver) on your public IP, configured to look for your authoritative records at localhost. This configuration is extremely stable and very fast.
I actually use the reverse of this. I use a dnscache on localhost so that my server can resolve anything it needs without depending on an external DNS server. And I run a publically accessible authoritative dns server to publish my own zones. I don't see the need in letting the public at large use my DNS server to resolve the IP address for yahoo.com. They can use yahoo's dns servers for that.
Of course your configuration makes much more sense in a protected network, like an office setting.
One thing I have wondered about tinydns, is why does it have a long timeout when trying to resolve a record that it is not authorative for? ie if I do dig www.yahoo.com @my.tinydns.server it doesn't return immediately? Is this a config problem with my setup? It is not a big deal, since no one should every query the server with non-authorative queries but still...
True, this solution won't stop spam on it's own. You will still need a system that tries to figure out whether it is spam or legitimate.
But the beauty of the system is that they can not spoof the from address, which opens lots of new options for filtering: - blacklist the from address if you recieve spam from it - blacklist the entire domain if you recieve multiple spams - blacklist all domains that have been registered by the same organization or individual if they are presistent spammers (check whois for this info)
Also, if a spam gets sent out, there is a good chance that the RBLs will find out about it very quickly (that is what the 'Realtime' part is for). Your mail reader could be intelligent enough to check the spam status just before you go to download the message to see if the from address has appeared on any blacklists since you received the message notification.
But the biggest benefit is that the spammers will have to pay for the bandwidth for each and every email that is collected... Imagine they send out 10 million messages with a 10K message. That is potentially 100G of traffic. It would be easy to configure the email clients to download the message and dump it if it is spam. This would kill their already small margin of profit...
Again, this method isn't a solution in and of itself, but it opens up many more avenues to make life difficult for the spammers.
The only problem with it that I can see is that because it involves a response, the spammer knows that the account is active and that they picked up the spam. Right now, spam is a very shot-in-the-dark type thing.
I would not consider that a drawback, but a benefit. I WANT the spammer to know that I don't read their messages. This system will allow them to get very accurate statistics on who is reading their messages, and hence they can target those 'idiots' instead of wasting their time with me.
If a spammer sends 500 spams to me and they know for certain that I have not read one of them, then they might realize that they are wasting their time and money. With current methods, they can't be certain whether or not I have read the message, so it is easier to just keep sending them.
Right now, there is no way for me to let the spammer know that I have not read their any of their spams and that they are wasting their time (and mine)...
Good point, but if it is signed, then it is not anonymous is it. But you are correct that this would be much harder to DDOS if signed files were released in this way.
By the way, I don't have any beef with RBL lists. But I have a big problem with ISPs using these lists to reject mail. They should be used by end users, or perhaps by a mailadmin to reject mail to an entire domain. Or they should be used to mark mail as possibly being spam.
ISPs that use these lists to reject mail are being irresponsible, and are most likely doing it without the knowledge of their users. One false positive that gets dropped is one too many when your users don't know it is happening.
You are joking right! Who is going to run this system? The government (US?). Microsoft? A new org like ICANN!!!!!
The reason the internet works is because it is open. Closing it off will just destroy it...
Perhaps a better idea would be to use a system like Internet Mail 2000 proposed by DJB
This systems reverses email by storing the message on the senders mail server, and a notification is sent to the receiver. A sender will not be able to hide by spoofing, since the message needs to be stored on their server. It would be much easier to block SPAM with a system like this, plus it would reduce bandwith requirements.
It's probably not perfect either, but it would be beter that regulating email...
And you would trust this file enough to block email based on it's contents??? Accountability is the biggest problem with RBLs, and moving it to a completely anonymous system would loose the last level of trust that they currently have...
I remember trying to get an early version of Slackware running on a 386SX16 with 2Mb of RAM. I let it boot for 2 days while it was thrashing the disks, before I killed it. With 4Mb it ran like a dream.
I can't remember what version of Slackware it was, but I still have a bunch of the disks lying around. The odd times when I need a blank floppy and dig through my floppies to grab an old one I am always hesitant to grab one labeled A1 or N3... Instead I grab the 'Win95 boot disk' instead:)
I bet you it's those guys from SPEWS doing it! This way they can get all these innocent bystanders to bitch to their hosting provider and get SCO booted of the internet...
Here again is another move that shows how responsible these idiots really are. To notify people to stop using their blacklist, they decide to blacklist the world. What a brilliant idea. After all email isn't really that important.
Email used to be one of the most reliable means of communicating on the net. You were always guaranteed that your message would either arrive, or you would hear about it (bounce). But with all of the email worms Microsoft has written (you have to admit these email worms/viruses practically write themselves), and the idiotic attempts at stopping the SPAM problem, email is becoming practically useless. mail admins are using blacklists and just dropping mail, which is effectively breaking the mail system. SPAMers may be the cause, but what is the point in destroying email all together. I would rather receive 100 SPAMs a day that loose one legitimate email that was intended for me. Sort of the same reason I am against the death penalty.
As blacklists go, SPEWS is the worst of them. They block entire netblocks so that innocent bystanders will fight their fight for them. If my IP gets blocked even though I haven't sent any SPAM, I am expected to bitch to my ISP and/or move to another ISP, and then maybe in a couple of months my IP might get removed from the list.
Reminds me of the way things work in the middle east. Pick either side, and they are using the same tactics. The Palestinians are blowing up civilians in the hope that the civilians left alive will do something about their problems. And the Israelli government is firing missiles into crowded cities to kill some suspected criminals and anyone else who happens to be within 100 meters of these guys...
Guerilla tactics like SPEWS employ won't work in the long run, and I am happy that SPEWS is getting hit hard.
SPEWS is claiming that the SPAMers are hitting them with this DDos, but I wouldn't be surpirsed if it was some disgruntled and innocent bystanders who were hit by the SPEWS "Collateral Damage" misile.
And how is this a responsible way of alerting people they should stop using the blacklist???? Anyone using there blacklist will automatically start bouncing all incoming mail based on the fact that every mail server is listed in the blacklist...
This means even more legitimate mail is being bounced or dropped than normally is by mail servers stupid enough to use SPEWS. SPEWS sucks and needs to disappear.
Although I don't agree with the tactics of a DDos, I am happy they are getting a taste of their own medicine.
SPEWS is all about getting other people to fight their battles for them. The are a bunch of fanatics that don't care who they stomp on and anyone who trusts their services should have their head examined.
My pet peeve is the syntax tar -cvf foo.tar foo, in contrast to the way every other Unix command puts the created file at the end.
Actually, the file at the end of the command is usually the file that gets acted upon. In this case it is the file that you want to add to a tape archive. The tar file is provided as an output file, and it is actually optional. If you don't provide an output file, then it should just print the results to STDOUT, which is exactly what tar does.
Also if you placed the tar file to be created at the end, then how would you provide multiple filenames to be added to the tar file?
That wasn't my point though. You control all of those hops... How many 'unknown' servers does the mail pass through? Usually only the SMTP server that the originating sender uses (ie their ISP), or an open relay.
If someone is trying to spoof the origin of the message, they can still only force it to take one hop away from your servers. They can't force it to bounce around the internet like a ping pong ball (only one open relay can be used since it will send the message directly to the recipient).
Now they may add a bunch of bogus Received: headers, but they are easy to spot...
How many hops does the average email message take anyway? Usually one hop from the originating ISP directly to the recieving mail server. It's not like it bounces from machine to machine like a TCP packet...
If there is a hop in between, then one of 2 things have occurred:
1. The recieving mail server has multiple MX records, and the primary server was unavailable at the time the message was sent, so it went to a secondary mail server. In this case, the recieving mail server trusts (and probably controls) all secondary servers in question.
2. The message came through an open relay, in which case you don't trust that mail server at all. And since you used TLS to authenticate, you have a way of finding the entity that controls this machine if you choose to track them down and notify them.
Perhaps what should be done is to test the sending mail server to see if it is an open relay before the message is delivered. The server could keep a list of servers it has checked, so when a mail comes in, it checks this list and decides if the message should be delivered. If it doesn't know, then it accepts the message and sticks it in a queue while it tests the sending mail server to see if it is an open relay. The message gets delivered or bounced (or blackholed) once an answer has been found. Any other messages from that server will be refused for a period of time.
I know that there are ORB lists all over the place, but I don't like trusting my mail systems to third parties that don't really account for their own actions. In my opinion ORB lists are using vigilante style blacklisting that does a lot of harm as well as doing a lot of good.
This method will not stop all spam of course, but it will most likely tell you that the server that sent the spam was a willing participant. And with TLS support that can be a useful bit of info...
It's interesting to see that we look at the amount of money a company has in order to figure out who is most likely to come out on top when it comes to litigation.
I started running the 2.4.0 pre release kernels on my desktop as soon as they were available and never had a problem.
I started running the 2.4 kernel on some production boxes around 2.4.6 and never had a problem.
Yes there will be some problems with the code, but unless you use every single feature in the kernel, chances are it will not bite you... I can't remember the last time I had a kernel panic (besides me mis-compiling modules) on a running box. Probably not since the 2.0 days for me.
There is some pretty funny stuff out there, if you browse long enough to stumble across it. I came across this site the other day and thought there were some pretty funny panel comics there.
A protocol or file format doesn't have to be good to be open. The point is to allow interoperability and hence competition in the marketplace. As long as the protocols and formats are published and publicly accessible (without NDAs and license restrictions), they should be considered open.
But using taxes and regulations to push people toward Linux...
I think the intent is to move proprietary software away from non-standard file formats and protocols, not to move people towards open source software. There is an important distinction there.
It is vendor-lock-in that should be avoided, and I think governments are right to support this.
It would take a whole lot of perl code to achieve the same functionality that can be accomplished in 200 well-written php code. (Depending on what it did - it's based off my personal experiences).
If that is a challenge, then I accept. I can guarantee you that for every command in PHP, there is an equivalent command (or module) in Perl. Hence you should be able to write this imaginary program in exactly the same number of lines...
Although perl and cgi scripts can be ran from the command line, they can't have (X)HTML mixed in quite as easily.
Have a look at Embperl, HTML::Mason, Apache::ASP for a couple of examples of how to do this. Most people who knock perl have never discovered the right tools. Personally I would never use those tools, because I am a strong believer in the separation of Code and HTML. I use a templating system for all my projects, and you will never see one HTML tag in my code. Once you work with a team of developers and a separate team of designers you will understand the need for this separation.
PHP is a great tool! I have used it for several applications in the past (6 or 7 years ago). But if you think that PHP can do more than perl can then you are mistaken...
Perl has its roots as a tool combining the virtues of sed and awk, and was started mainly as a text parsing/processing language. This is one of the many reasons why it is so good as a web development language.
What seems to scare people about perl is that there as so many different ways that you can tackle a job like building dynamic web sites. Perl on it's own doesn't forcefeed anything to you, it lets you find your own style. Many people who start with perl will try to do everything from scratch instead of finding one of the many development environments that simplify things for you a clean framework for developing web applications. Some examples are Axkit, HTML::Mason, Template Toolkit, Embperl, Apache::ASP, CGI::Application, Apache::PageKit, and many more.
Anyway, this article is about PHP, and I won't knock it just because I'm a perl developer. I actually used PHP quite heavily back in 96 when version 2 was just coming out. It was a fantastic tool (even back then) and really let me cut my teeth on dynamic web development. However, I have wandered over to the perl camp, because it is a better tool for me.
Slashdot Mirror
Ah, that explains it. So tinydns just drops the request without telling the requestor that it isn't going to answer the query. That is fair enough, since we are talking about a query that should have never happened in the first place.
Thanks for the answer...
I actually use the reverse of this. I use a dnscache on localhost so that my server can resolve anything it needs without depending on an external DNS server. And I run a publically accessible authoritative dns server to publish my own zones. I don't see the need in letting the public at large use my DNS server to resolve the IP address for yahoo.com. They can use yahoo's dns servers for that.
Of course your configuration makes much more sense in a protected network, like an office setting.
One thing I have wondered about tinydns, is why does it have a long timeout when trying to resolve a record that it is not authorative for? ie if I do dig www.yahoo.com @my.tinydns.server it doesn't return immediately? Is this a config problem with my setup? It is not a big deal, since no one should every query the server with non-authorative queries but still...
True, this solution won't stop spam on it's own. You will still need a system that tries to figure out whether it is spam or legitimate.
But the beauty of the system is that they can not spoof the from address, which opens lots of new options for filtering:
- blacklist the from address if you recieve spam from it
- blacklist the entire domain if you recieve multiple spams
- blacklist all domains that have been registered by the same organization or individual if they are presistent spammers (check whois for this info)
Also, if a spam gets sent out, there is a good chance that the RBLs will find out about it very quickly (that is what the 'Realtime' part is for). Your mail reader could be intelligent enough to check the spam status just before you go to download the message to see if the from address has appeared on any blacklists since you received the message notification.
But the biggest benefit is that the spammers will have to pay for the bandwidth for each and every email that is collected... Imagine they send out 10 million messages with a 10K message. That is potentially 100G of traffic. It would be easy to configure the email clients to download the message and dump it if it is spam. This would kill their already small margin of profit...
Again, this method isn't a solution in and of itself, but it opens up many more avenues to make life difficult for the spammers.
I would not consider that a drawback, but a benefit. I WANT the spammer to know that I don't read their messages. This system will allow them to get very accurate statistics on who is reading their messages, and hence they can target those 'idiots' instead of wasting their time with me.
If a spammer sends 500 spams to me and they know for certain that I have not read one of them, then they might realize that they are wasting their time and money. With current methods, they can't be certain whether or not I have read the message, so it is easier to just keep sending them.
Right now, there is no way for me to let the spammer know that I have not read their any of their spams and that they are wasting their time (and mine)...
Good point, but if it is signed, then it is not anonymous is it. But you are correct that this would be much harder to DDOS if signed files were released in this way.
By the way, I don't have any beef with RBL lists. But I have a big problem with ISPs using these lists to reject mail. They should be used by end users, or perhaps by a mailadmin to reject mail to an entire domain. Or they should be used to mark mail as possibly being spam.
ISPs that use these lists to reject mail are being irresponsible, and are most likely doing it without the knowledge of their users. One false positive that gets dropped is one too many when your users don't know it is happening.
You are joking right! Who is going to run this system? The government (US?). Microsoft? A new org like ICANN!!!!!
The reason the internet works is because it is open. Closing it off will just destroy it...
Perhaps a better idea would be to use a system like Internet Mail 2000 proposed by DJB
This systems reverses email by storing the message on the senders mail server, and a notification is sent to the receiver. A sender will not be able to hide by spoofing, since the message needs to be stored on their server. It would be much easier to block SPAM with a system like this, plus it would reduce bandwith requirements.
It's probably not perfect either, but it would be beter that regulating email...
And you would trust this file enough to block email based on it's contents??? Accountability is the biggest problem with RBLs, and moving it to a completely anonymous system would loose the last level of trust that they currently have...
I remember trying to get an early version of Slackware running on a 386SX16 with 2Mb of RAM. I let it boot for 2 days while it was thrashing the disks, before I killed it. With 4Mb it ran like a dream.
:)
I can't remember what version of Slackware it was, but I still have a bunch of the disks lying around. The odd times when I need a blank floppy and dig through my floppies to grab an old one I am always hesitant to grab one labeled A1 or N3... Instead I grab the 'Win95 boot disk' instead
I bet you it's those guys from SPEWS doing it! This way they can get all these innocent bystanders to bitch to their hosting provider and get SCO booted of the internet...
Blacklisting at the mail server doesn't help the end user - their legitimate emails have already been dropped.
I love these people who assume that the problem can be solved if all ISPs just used blacklists like SPEWS.
Here again is another move that shows how responsible these idiots really are. To notify people to stop using their blacklist, they decide to blacklist the world. What a brilliant idea. After all email isn't really that important.
Email used to be one of the most reliable means of communicating on the net. You were always guaranteed that your message would either arrive, or you would hear about it (bounce). But with all of the email worms Microsoft has written (you have to admit these email worms/viruses practically write themselves), and the idiotic attempts at stopping the SPAM problem, email is becoming practically useless. mail admins are using blacklists and just dropping mail, which is effectively breaking the mail system. SPAMers may be the cause, but what is the point in destroying email all together. I would rather receive 100 SPAMs a day that loose one legitimate email that was intended for me. Sort of the same reason I am against the death penalty.
As blacklists go, SPEWS is the worst of them. They block entire netblocks so that innocent bystanders will fight their fight for them. If my IP gets blocked even though I haven't sent any SPAM, I am expected to bitch to my ISP and/or move to another ISP, and then maybe in a couple of months my IP might get removed from the list.
Reminds me of the way things work in the middle east. Pick either side, and they are using the same tactics. The Palestinians are blowing up civilians in the hope that the civilians left alive will do something about their problems. And the Israelli government is firing missiles into crowded cities to kill some suspected criminals and anyone else who happens to be within 100 meters of these guys...
Guerilla tactics like SPEWS employ won't work in the long run, and I am happy that SPEWS is getting hit hard.
SPEWS is claiming that the SPAMers are hitting them with this DDos, but I wouldn't be surpirsed if it was some disgruntled and innocent bystanders who were hit by the SPEWS "Collateral Damage" misile.
And how is this a responsible way of alerting people they should stop using the blacklist???? Anyone using there blacklist will automatically start bouncing all incoming mail based on the fact that every mail server is listed in the blacklist...
This means even more legitimate mail is being bounced or dropped than normally is by mail servers stupid enough to use SPEWS. SPEWS sucks and needs to disappear.
Although I don't agree with the tactics of a DDos, I am happy they are getting a taste of their own medicine.
SPEWS is all about getting other people to fight their battles for them. The are a bunch of fanatics that don't care who they stomp on and anyone who trusts their services should have their head examined.
Good riddance...
If Didio did not sign the NDA, and they showed her the code, can they still claim the code as a trade secret????
I thought that was one of the big arguements they used for not allowing anyone to see any code without an NDA!!
Actually, the file at the end of the command is usually the file that gets acted upon. In this case it is the file that you want to add to a tape archive. The tar file is provided as an output file, and it is actually optional. If you don't provide an output file, then it should just print the results to STDOUT, which is exactly what tar does.
Also if you placed the tar file to be created at the end, then how would you provide multiple filenames to be added to the tar file?
tar cf outfile.tar file1 file2 file3 dir1 dir2
This really is the best way to do it (IMHO)...
That wasn't my point though. You control all of those hops... How many 'unknown' servers does the mail pass through? Usually only the SMTP server that the originating sender uses (ie their ISP), or an open relay.
If someone is trying to spoof the origin of the message, they can still only force it to take one hop away from your servers. They can't force it to bounce around the internet like a ping pong ball (only one open relay can be used since it will send the message directly to the recipient).
Now they may add a bunch of bogus Received: headers, but they are easy to spot...
Does it include removing the Ethernet card from the system???
How many hops does the average email message take anyway? Usually one hop from the originating ISP directly to the recieving mail server. It's not like it bounces from machine to machine like a TCP packet...
If there is a hop in between, then one of 2 things have occurred:
1. The recieving mail server has multiple MX records, and the primary server was unavailable at the time the message was sent, so it went to a secondary mail server. In this case, the recieving mail server trusts (and probably controls) all secondary servers in question.
2. The message came through an open relay, in which case you don't trust that mail server at all. And since you used TLS to authenticate, you have a way of finding the entity that controls this machine if you choose to track them down and notify them.
Perhaps what should be done is to test the sending mail server to see if it is an open relay before the message is delivered. The server could keep a list of servers it has checked, so when a mail comes in, it checks this list and decides if the message should be delivered. If it doesn't know, then it accepts the message and sticks it in a queue while it tests the sending mail server to see if it is an open relay. The message gets delivered or bounced (or blackholed) once an answer has been found. Any other messages from that server will be refused for a period of time.
I know that there are ORB lists all over the place, but I don't like trusting my mail systems to third parties that don't really account for their own actions. In my opinion ORB lists are using vigilante style blacklisting that does a lot of harm as well as doing a lot of good.
This method will not stop all spam of course, but it will most likely tell you that the server that sent the spam was a willing participant. And with TLS support that can be a useful bit of info...
It's interesting to see that we look at the amount of money a company has in order to figure out who is most likely to come out on top when it comes to litigation.
I started running the 2.4.0 pre release kernels on my desktop as soon as they were available and never had a problem.
I started running the 2.4 kernel on some production boxes around 2.4.6 and never had a problem.
Yes there will be some problems with the code, but unless you use every single feature in the kernel, chances are it will not bite you... I can't remember the last time I had a kernel panic (besides me mis-compiling modules) on a running box. Probably not since the 2.0 days for me.
If they are truly artists, then they shouldn't complain about people NOT buying their 'art'.
If it was about the 'art' then why not drop the price on their albums, so more people can enjoy their 'art'?
If it is about the 'art', then why allow radio stations to play individual songs instead of forcing them to play the entire album?
In my opinion it is all about maximizing profits... Art left the mix once they signed that record contract!
There is some pretty funny stuff out there, if you browse long enough to stumble across it. I came across this site the other day and thought there were some pretty funny panel comics there.
Check it out while it lasts...
A protocol or file format doesn't have to be good to be open. The point is to allow interoperability and hence competition in the marketplace. As long as the protocols and formats are published and publicly accessible (without NDAs and license restrictions), they should be considered open.
I think the intent is to move proprietary software away from non-standard file formats and protocols, not to move people towards open source software. There is an important distinction there.
It is vendor-lock-in that should be avoided, and I think governments are right to support this.
If that is a challenge, then I accept. I can guarantee you that for every command in PHP, there is an equivalent command (or module) in Perl. Hence you should be able to write this imaginary program in exactly the same number of lines...
Have a look at Embperl, HTML::Mason, Apache::ASP for a couple of examples of how to do this. Most people who knock perl have never discovered the right tools. Personally I would never use those tools, because I am a strong believer in the separation of Code and HTML. I use a templating system for all my projects, and you will never see one HTML tag in my code. Once you work with a team of developers and a separate team of designers you will understand the need for this separation.
PHP is a great tool! I have used it for several applications in the past (6 or 7 years ago). But if you think that PHP can do more than perl can then you are mistaken...
Perl has its roots as a tool combining the virtues of sed and awk, and was started mainly as a text parsing/processing language. This is one of the many reasons why it is so good as a web development language.
What seems to scare people about perl is that there as so many different ways that you can tackle a job like building dynamic web sites. Perl on it's own doesn't forcefeed anything to you, it lets you find your own style. Many people who start with perl will try to do everything from scratch instead of finding one of the many development environments that simplify things for you a clean framework for developing web applications. Some examples are Axkit, HTML::Mason, Template Toolkit, Embperl, Apache::ASP, CGI::Application, Apache::PageKit, and many more.
Anyway, this article is about PHP, and I won't knock it just because I'm a perl developer. I actually used PHP quite heavily back in 96 when version 2 was just coming out. It was a fantastic tool (even back then) and really let me cut my teeth on dynamic web development. However, I have wandered over to the perl camp, because it is a better tool for me.