Even our best programmers make security bugs when writing in C though (see: Quake I, II, III, Half-Life, Linux Kernel, sshd, ftpd, apache, perl, mozilla, and just about every other software package you think is written by great programmers), so how can we expect the rest of the world to do it?
qmail and djbdns have no security bugs and they are written in C. How do you explain that?
And if you are testing web pages in multiple resolutions, trying out everything from 640x480 up to 1600x1200 on an lcd can be . . . problematic to say the least.
Umm, why are you changing the screen size and not the browser size? Try Mike Lin'sWindowSizer to resize your browser to an exact size.
For those who don't know this already, all that does is validate that there is a user who actively checks/reads that email account. A list of valid email addresses is VERY valuable to other spammers, who eagerly shell out the $$$ so they can send you MORE spam.
No one wants to mail to a remove list. There are plenty of people who will read spam and buy the products. People who want to be removed won't buy anything anyway, so there is no point in mailing them. Additionally, those people are the ones who cause trouble for spammers.
It is simply bad business to mail hostile users.
The real issue is that the minute you submit your email address to a website, it is sold to other people. You can opt out of that site, but you will still get spam from the other ten.
If you don't opt out, don't blame them if they keep mailing you.
Having given it some thought, I just have to wonder why the airline just didn't block the scraper when they came to the site.
Given the nature of the HTTP, doing that would be very difficult. It is not hard to "fake" HTTP requests so that they look like they are coming from a browser. Blocking by IP address could work, but there are many ways around that too.
For example suppose the standard postage amount is a problem which typically requires five seconds of CPU time on modern systems.
What is a ``modern system''? Is it a 400mhz P2 or a 2.4ghz P4? The speed difference there is a factor of at least six. Either one could reasonably be used for a mail server. So now the range is between one and thirty seconds for each piece of email.
What if I run a large mailing list? Do I need to buy more machines simply because I send a lot of messages? What about systems like AOL that send millions or billions of messages a day?
I never said it did not work. I said it may not be written to the proper specs. It may have serious bugs. Many programs have shortcomings, that doesn't make them useless or worthless.
My point, which you obviously missed, is this: The program does not work well enough to pay for it, yet it works well enough for the company to continue to use it. That makes no sense.
The client may have a valid reason not to pay. The software may not be written to the specifications outlined in the contract, the software may have bugs, etc, etc... Again, the courts decide the outcome of a dispute, not one of the parties involved.
Postfix is only slightly more flexible in some ways (for example, the MySQL backend) but those ways aren't difficult to integrate into qmail; it's just that nobody's bothered to do it yet.
vpopmail is a virtual domain manager for qmail. It supports MySQL and a number of other backends. You don't even need to recompile qmail to use it, thanks to qmail's very modular design.
I still have to find *how* does one get secure user accessible (r/w/x) cgi-bin's per virtual host.
We do this using Zeus. Each customer gets his/her own virtual server. Each virtual server is configured to run CGI scripts under a specific uid/gid (that of the customer's account). It works nicely and is very easy to setup.
which creates a whole lot of problems... (SSL, etc..)
Everything supports HTTP/1.1 now days, or sends a Host header with HTTP/1.0. The SSL issue can be solved rather easily by either using wildcard certificates, or running each SSL site on it's own port.
However, I feel that they should not have to. It's not that I think that blocking port 25 won't help stop spam. I just am against ISPs filtering service in any way. Once they start down the slippery slope of filtering, I doubt it will end.
Assuming competence on the part of the ISP, this is a good solution for spam. If customers want to send mail directly to other systems, enable it just for them. The ISP could make the customer sign a contract first, making them explicitly liable for sending spam. Lots of spam is sent from dialup and dynamic broadband accounts. Blocking these by IP (which is the best current reliable method for stopping spam) is difficult.
By forcing all mail to go through the ISP's mail server, that server can at least add a legitimate Received header. It could add an additional header identifying the user, such as AOL's X-Apparently-From. It might also rate limit for each user and automatically track possible abuse. If users want to send email via an authenticating SMTP server, it can be run on a different port (specifying the port of the server is no more difficult than specifying the SMTP authentication info).
This won't stop spam entirely, of course, but it will make it harder on spammers.
I work for a small company that offers web hosting. Along with the web hosting, we give the customer mail accounts, with SMTP, POP and IMAP access. We have had numerous complaints from customers that were unable to connect to the SMTP server because thier ISP blocks port 25. Why shouldn't they be able to connect to any server they like?
There is a more important question: Why can't your customers send email through their ISP's SMTP server?
Because I like to actually be able to change my DNS records after they are published.
In addition, DNS records should not just arbitrarily expire...
They don't arbitrarily expire. They expire when the TTL for the record has been reached.
If a record HAS reached it's "expire", it should still remail valid UNTIL the DNS server has been able to get a valid update.
That would allow an attacker to blind your DNS resolver to DNS changes by keeping it from contacting a remote DNS server. And if the same attacker can poison your cache, the cache will keep the poisoned records forever.
The next is the refresh time which indicates when an entry in a cache should be checked to see if it is still current and is typically about a half a day.
This is only for DNS servers such as BIND that use AXFR to update slaves.
Finally DNS servers can coordinate notification messages, whereby the primary name server for a domain will send a message to any secondaries whenever the data has changed.
Modern DNS servers use better methods such as rsync over SSH or database replication, which provide real security, instant updates and more efficient network usage.
Given that, consider the possibility of the ISP or corporate data center intercepting any queries done (as if the end user were running a recursive DNS server instead of a basic resolver) and handle them through a local cache (within the ISP or corporate data center). It won't break normal use.
Wrong. I run my own local DNS resolver, dnscache. I don't trust my ISP to manage a DNS resolver properly. What if they are running a version of BIND vulnerable to poison or other issues? What if I am testing DNS resolution and need to flush the cache? (I do this routinely.) They also don't need to see every DNS query I make. If they want to sniff and parse packets, fine, but no need to make it any easier on them.
It won't break even if someone is running their own DNS (although they will get a cached response instead of an authoritative one).
That would be possible only if they were in fact intercepting every single DNS packet and rewriting it. It would make it impossible for me to perform diagnostic queries to DNS servers. And unless they were doing some very complex packet rewriting, it would break if an authoritative server was providing different information depending on the IP address that sent the query.
If you can't even get ISPs to perform egress filtering, why would they do something as stupid and broken as this? Egress filtering would do much more to stop these types of attacks.
Besides, how does this stop me if I am the ISP? There are plenty vulnerable machines that are on much better connections than dialup or broadband.
Now, the author seems much more worried about attackts against Top Level Domains, because of reasons related to the nature of the information that TLD servers have, and he suggests a few techniques that they could use. What he doesn't say is what techniques the TLD's are using currently, and how secure they are.
They fail to _gain_ money. Not the same thing at all.
You are right, it is different than if they had to pay out $1.1 billion. But it still impacts their bottom line, probably almost as much. And either way, it's probably a tax write off.
Slashdot Mirror
Even our best programmers make security bugs when writing in C though (see: Quake I, II, III, Half-Life, Linux Kernel, sshd, ftpd, apache, perl, mozilla, and just about every other software package you think is written by great programmers), so how can we expect the rest of the world to do it?
qmail and djbdns have no security bugs and they are written in C. How do you explain that?
This is for consumer protection from retailers that do not allow you to return open music, even if it won't work as advertised.
That's why you buy things with your Visa card. One word: chargeback
And if you are testing web pages in multiple resolutions, trying out everything from 640x480 up to 1600x1200 on an lcd can be . . . problematic to say the least.
Umm, why are you changing the screen size and not the browser size? Try Mike Lin's WindowSizer to resize your browser to an exact size.
For those who don't know this already, all that does is validate that there is a user who actively checks/reads that email account. A list of valid email addresses is VERY valuable to other spammers, who eagerly shell out the $$$ so they can send you MORE spam.
No one wants to mail to a remove list. There are plenty of people who will read spam and buy the products. People who want to be removed won't buy anything anyway, so there is no point in mailing them. Additionally, those people are the ones who cause trouble for spammers.
It is simply bad business to mail hostile users.
The real issue is that the minute you submit your email address to a website, it is sold to other people. You can opt out of that site, but you will still get spam from the other ten.
If you don't opt out, don't blame them if they keep mailing you.
Having given it some thought, I just have to wonder why the airline just didn't block the scraper when they came to the site.
Given the nature of the HTTP, doing that would be very difficult. It is not hard to "fake" HTTP requests so that they look like they are coming from a browser. Blocking by IP address could work, but there are many ways around that too.
For example suppose the standard postage amount is a problem which typically requires five seconds of CPU time on modern systems.
What is a ``modern system''? Is it a 400mhz P2 or a 2.4ghz P4? The speed difference there is a factor of at least six. Either one could reasonably be used for a mail server. So now the range is between one and thirty seconds for each piece of email.
What if I run a large mailing list? Do I need to buy more machines simply because I send a lot of messages? What about systems like AOL that send millions or billions of messages a day?
I never said it did not work. I said it may not be written to the proper specs. It may have serious bugs. Many programs have shortcomings, that doesn't make them useless or worthless.
My point, which you obviously missed, is this: The program does not work well enough to pay for it, yet it works well enough for the company to continue to use it. That makes no sense.
The client may have a valid reason not to pay. The software may not be written to the specifications outlined in the contract, the software may have bugs, etc, etc... Again, the courts decide the outcome of a dispute, not one of the parties involved.
If it doesn't work, then why are they using it?
Also, Wietse Venema is a better human being (aka not a hypocrite) like djb.
Oh? What grounds do you have to call Dan a hypocrite?
Postfix is only slightly more flexible in some ways (for example, the MySQL backend) but those ways aren't difficult to integrate into qmail; it's just that nobody's bothered to do it yet.
vpopmail is a virtual domain manager for qmail. It supports MySQL and a number of other backends. You don't even need to recompile qmail to use it, thanks to qmail's very modular design.
I still have to find *how* does one get secure user accessible (r/w/x) cgi-bin's per virtual host.
We do this using Zeus. Each customer gets his/her own virtual server. Each virtual server is configured to run CGI scripts under a specific uid/gid (that of the customer's account). It works nicely and is very easy to setup.
Try buying a wildcard cert from Verisign
We buy ours from Equifax without trouble. See the certificate for ITmom.com if you don't believe me.
which creates a whole lot of problems ... (SSL, etc ..)
Everything supports HTTP/1.1 now days, or sends a Host header with HTTP/1.0. The SSL issue can be solved rather easily by either using wildcard certificates, or running each SSL site on it's own port.
http://www.angryflower.com/bobsqu.gif
Spiffy.
However, I feel that they should not have to. It's not that I think that blocking port 25 won't help stop spam. I just am against ISPs filtering service in any way. Once they start down the slippery slope of filtering, I doubt it will end.
Assuming competence on the part of the ISP, this is a good solution for spam. If customers want to send mail directly to other systems, enable it just for them. The ISP could make the customer sign a contract first, making them explicitly liable for sending spam. Lots of spam is sent from dialup and dynamic broadband accounts. Blocking these by IP (which is the best current reliable method for stopping spam) is difficult.
By forcing all mail to go through the ISP's mail server, that server can at least add a legitimate Received header. It could add an additional header identifying the user, such as AOL's X-Apparently-From. It might also rate limit for each user and automatically track possible abuse. If users want to send email via an authenticating SMTP server, it can be run on a different port (specifying the port of the server is no more difficult than specifying the SMTP authentication info).
This won't stop spam entirely, of course, but it will make it harder on spammers.
http://cr.yp.to/qmail/antispam.html
Unfortunately, it's only on OpenBSD so far. Can some one please port this to Linux by tomorrow?
http://cr.yp.to/ucspi-tcp/rblsmtpd.html
I work for a small company that offers web hosting. Along with the web hosting, we give the customer mail accounts, with SMTP, POP and IMAP access. We have had numerous complaints from customers that were unable to connect to the SMTP server because thier ISP blocks port 25. Why shouldn't they be able to connect to any server they like?
There is a more important question: Why can't your customers send email through their ISP's SMTP server?
That would be Network Solutions.
I've been able to ping a website that had an IP change, and in IE still pull up the old site.
Almost all web browsers have caches. Usually, they work correctly. Sometimes they don't.
Tools->Internet Options->Settings->Check for newer versions of stored pages: Every visit to the page
Why does a cache have to expire?
Because I like to actually be able to change my DNS records after they are published.
In addition, DNS records should not just arbitrarily expire...
They don't arbitrarily expire. They expire when the TTL for the record has been reached.
If a record HAS reached it's "expire", it should still remail valid UNTIL the DNS server has been able to get a valid update.
That would allow an attacker to blind your DNS resolver to DNS changes by keeping it from contacting a remote DNS server. And if the same attacker can poison your cache, the cache will keep the poisoned records forever.
The next is the refresh time which indicates when an entry in a cache should be checked to see if it is still current and is typically about a half a day.
This is only for DNS servers such as BIND that use AXFR to update slaves.
Finally DNS servers can coordinate notification messages, whereby the primary name server for a domain will send a message to any secondaries whenever the data has changed.
Modern DNS servers use better methods such as rsync over SSH or database replication, which provide real security, instant updates and more efficient network usage.
Given that, consider the possibility of the ISP or corporate data center intercepting any queries done (as if the end user were running a recursive DNS server instead of a basic resolver) and handle them through a local cache (within the ISP or corporate data center). It won't break normal use.
Wrong. I run my own local DNS resolver, dnscache. I don't trust my ISP to manage a DNS resolver properly. What if they are running a version of BIND vulnerable to poison or other issues? What if I am testing DNS resolution and need to flush the cache? (I do this routinely.) They also don't need to see every DNS query I make. If they want to sniff and parse packets, fine, but no need to make it any easier on them.
It won't break even if someone is running their own DNS (although they will get a cached response instead of an authoritative one).
That would be possible only if they were in fact intercepting every single DNS packet and rewriting it. It would make it impossible for me to perform diagnostic queries to DNS servers. And unless they were doing some very complex packet rewriting, it would break if an authoritative server was providing different information depending on the IP address that sent the query.
If you can't even get ISPs to perform egress filtering, why would they do something as stupid and broken as this? Egress filtering would do much more to stop these types of attacks.
Besides, how does this stop me if I am the ISP? There are plenty vulnerable machines that are on much better connections than dialup or broadband.
Now, the author seems much more worried about attackts against Top Level Domains, because of reasons related to the nature of the information that TLD servers have, and he suggests a few techniques that they could use. What he doesn't say is what techniques the TLD's are using currently, and how secure they are.
http://cr.yp.to/djbdns/forgery.html
They fail to _gain_ money. Not the same thing at all.
You are right, it is different than if they had to pay out $1.1 billion. But it still impacts their bottom line, probably almost as much. And either way, it's probably a tax write off.