If RPM weren't such a mess, it might be more convenient to make RPMs of the packages you build from source but want to install the same exact binary on all the other machines. I just make Slackware style tarballs, so it's real easy; no spec file needed.
What? And let someone take over my browser? How do I know there isn't some Javascript code to do something else nasty?
Actually, I already have the DNS setup to block several domains for things like this. It was trivial to add one more. No need to have to remember to turn Javascript on (which I wouldn't do, anyway).
zone "aens.net" {
type master;
file "disabled-zone.db";
allow-transfer { none; };
};
where "disabled-zone.db" is a zone file that has a wildcard record to give a local IP address for all name queries, for a web server that always delivers my own little 1x1 transparent GIF.
When I signed up my phone number, and the number of several friends who asked me to do so for them, I used a unique email address for each one, never used before, never used since. If they get spammed, I'll definitely know. So far they have not.
Certainly some ISPs are doing all that they can. Most are not. For example, those that do not block incoming connections to known proxy ports are not doing all that they can. So when I get spam from a particular ISP, this spam is very often because the ISP is not doing certain things it could do to prevent or at least significantly reduce spam. Another thing they can do is to block both inbound and outbount SMTP (except to the ISP's own mail servers or own network) to customers that don't ask for an exemption (spammers might do that, but most of the problem is from people who wouldn't know what SMTP is). This would prevent connections that bypass the ISP mail servers. Then by adding throttling to the mail server that limits numbers of outgoing mail from a single customer, they can reduce the problem in cases where the spammer directs it through the ISP mail server.
I do block the generic (e.g. DHCP, dialup, etc) addresses of ISP customers. This does, unfortunately, affect smarter people with better managed home (or business) mail servers. If the ISP were to allow them to have valid reverse DNS on their static IPs, my blocking, which is based on domain name, would not affect them. And if the ISP were to NOT put their own domain on reverse DNS of any customer with SMTP enabled, and such a customer spammed, I could block that customer by their domain name instead of the ISP.
But too few ISPs are clued in about all the steps they could do to prevent spam, reduce spam, and make it easy for others to prevent spam. That, or their PHB bosses wear too much clue-teflon.
HashCash has some limitations that make it unworkable in the wild. The one I noted is that it is necessary for the recipient (e.g. the one who is trying to cut back on the costs imposed by spammers) to keep track of the stamps that have been spent, up to the expiration period. Further, the costs imposed by spammers are still imposed anyway, if the server is not the one verifying the stamps (and thus also keeping a database of spent stamps for every user it serves).
HashCash would also be a burden on legitimate mailing lists. Of course, to solve that problem, whitelisting of the mailing list would be used. But it tends to be inconvenient to whitelist during subscription. This could be solved by using the HashCash only on the initial signup confirmation, and whitelist thereafter for the bulk mailings. But this still has a problem. I get lots of spam already that mimics mailing lists I am on, using the mailing list itself as the sender, and my tagged email which I signed up with as the recipient. So having whitelisted it lets the spam in, and spammers will make more use of this technique by including such details in their spam lists.
If HashCash could be modified to also include information only the real sender can prove she has, without revealing it in the ability to verify it (e.g. PKC), that might help.
Did he have THAT many domain names to put in the reverse DNS? You did check each of those names in forward DNS to see if the address record matches the connection, right? Can you extract a list of those domain names from your logs?
I hear those words about spam and proposed solutions all the time. But the fact is, and will always remain so, that you cannot get absolutely everyone to do so (whatever that might be).
Consider the first possibility: "if everyone would just stop sending spam". Most of the spam comes from about 200 or so different spam gangs. Most of the rest comes from a few thousand naive victims that try it once or twice, get cut off, and never do it again (and thus losing their investment into the spamware and "list of millions" they paid some spamgang for). Already, 99.999% of internet users do not send spam. A solution that requires getting so close to a percet 100% just isn't possible.
Now for the second possibility: "if everyone would just stop reading the spam and buying from spammers". Spam works because the costs to spam senders is so utterly low, that even sending to every internet user is a lower cost than trying to trim the list down to those few people that really want what the spammers are peddling. This goes along with "just press delete". But it doesn't take much in response for the spammers to actually make a profit from their spam runs. And spammer's for hire are making money even if their clients lose money, so as long as there is a supply of naive vendors who are willing to part with their money to get a spam run in their name, spammers profit. Again, this is a case where closing the gap between 99.99% of people who don't even read the spam and the 100% needed to make spammers and their clients go away, is just not going to happen.
But there is a third possibility: "if everyone would stop using ISPs that permit spam". If even so much as 50% of users who are using ISPs that permit spamming were to cancel and switch to a better ISP that doesn't, that would definitely have a substantial effect on that ISP. I bet even 10% would get noticed, although I think a bit more, like 25%, might be needed to get some of the worst ISPs to act. Of course many people do whine about things like "there is only one ISP here" (not anywhere near 50% face this problem) and "it costs me money to switch" (it costs the victims of spammers even more money for you to continue to support an ISP that is able to give you a discount by accepting pink money from spammers). If we were to simply identify the top 10 worst ISPs for permitting spam to come from or through their network, and get a whopping 25% to 50% of their customers to leave (preferring to go to the top 10 best ISPs for not permitting any spam in or out), this would make a substantial impact and cause some CFOs to panic. And this doesn't require anywhere near 99% to be a successful anti-spam campaign.
The above campaign can also be pushed harder if many of us refused to accept email from those ISPs (and thus anyone in their network) as a sort of boycott against spam support. Of course there will be whiners here, too saying "You have no right to block my email since I don't send spam" (but if they are supporting a spammer anyway, guess what).
My whole point is that we need to avoid any "solutions" that make it necessary for absolutely everyone to do something. There will be plenty of people that won't. Instead, the solutions we need are the ones which only require a practical number of people to take that action. If you don't like the ones I propose, then propose your own and say how many people would have to act to make it work.
Taking apart the bounce message and extracting the original message? That requires going ahead and accepting the DATA transmission. This is not an acceptable solution. While SPF might cut spam in half, I have to double my costs to do it? That puts things back to as bad as they are already. I'll wait until this thing gets re-designed. The idea in principle is interesting. But it needs some work.
Spammers can use this SPF vulnerability. The way SPF works when the sender address is empty, that is, <>, which normally is used for bounce messages, the receiving client that is using SPF checking will use the HELO/EHLO name instead of the SENDER domain name. If the spammer is making the connection, including through an open proxy, he controls the HELO/EHLO name. The problem is that the HELO/EHLO name lookup involves the name of the mail server, and uses a different hierarchy of the domain owner's name space. The spammer can forge any name the owner has not configured. For example he can make the HELO name be "fantastic-offers-just-for-you.aol.com" and the SPF-aware server receiving the mail will look up "xxx.xxx.xxx.xxx.in-addr._smtp_client.fantastic-of fers-just-for-you.aol.com" [warning: slashdot will insert a space in that long string to avoid messed up formatting] for the TXT record. The wildcard deny at "*._smtp_client.aol.com" won't match the query because that's a different branch in the hierarchy. And any wildcards for real existing mail servers at aol.com won't have this spammer name, and they, too, won't match. There being no TXT record answered, your server then has to take the default action, which will usually be to go ahead and accept the mail since it might have been coming from a domain that doesn't implement SPF (yet).
If you choose to block sender <> in your mail server to avoid this kind of spam tactic, you also break the ability to receive bounce messages.
There needs to be some way to indicate at the principle domain level, e.g. at "aol.com" in the examples shown, without the "_smtp_client" subdomain, that SPF is indeed implemented. But adding a wildcard record there messes up lots of stuff. One way around this would be for SPF-aware mail servers receiving mail to perform the SPF lookup on every parent level of the domain involved (especially the HELO/EHLO one) to see if there is a TXT record with an SPF setting present. That would mean lots of extra DNS queries.
Hello and welcome to Charter Communications' legal support department. Your call is very important to us. Please listen to this menu carefully since options have changed. If you are calling about your lawsuit against us because your cable bill is too high, please press 1 now. If you are calling about your lawsuit against us because we double billed you, please press 2 now. If you are calling about your lawsuit against us because we have not paid your program provider fees, please press 3 now. If you are calling about your subpoena to divulge the names and credit card payment records of customers that are sharing music online please press 4 now. If you are calling about our violations of local....
*** beep *** (pressed 4)
[click] [click] [pause] [click] [click]
Hello and welcome to Charter Communications' copyright enforcement department. Your call is very important to us. Please listen to this menu carefully since options have changed. If you are calling about your neighbor recording premium movies, please press 1 now. If you are calling about our customers that are downloading music on the internet, please press 2 now. If you are....
*** beep *** (pressed 2)
[pause] [click] [click] [pause]
Hello and welcome to Charter Communications' music piracy department. Your call is very important to us. Please listen to this menu carefully since options have changed. If you are calling about a subpoena you have already sent to us, please have your subpoena registration number handy and press 1 now. If you are calling to register a new subpoena with use, please have the account number of the customer this subpoena refers to handy and press 2 now. If you are calling to obtain a customer account number, please have the name of the customer handy and press 3 now. If you are calling to obtain the name of a customer please have the IP address and time handy, and press 4 now. If you are....
*** beep *** (pressed 4)
[pause] [click] [pause] [click] [pause]
Hello and welcome to the Charter Communications' online customer identification system. Please have the IP address and time the customer was online handy. If you already have an identification system authorization number, please press 1 now. If you do not already have an identification system authorization number, and wish to register to obtain one, please press 2 now. To repeat this...
*** beep *** (pressed 2)
[pause] [click]
Hello and welcome to the Charter Communications' online customer identification system user authorization registration system. Please listen to this menu carefully since options have changed. If you are already a Charter Communications home cable customer, please press 1 now. If you are already a Charter Communications business internet customer, please press 2 now. If you are not a Charter Communications customer and would like to sign up for Charter Communications' cable service in your home or business today, please press 3 now. If you are not a Charter Communications customer and do not wish to sign up for cable service at this time, please press 4 now. To repeat....
*** beep *** (pressed 4)
[click] [click]
Hello and welcome to Charter Communications' business relations department. Your call is very important to us. Please listen to this menu carefully since options have changed. If you are calling about an existing business relation that is satisfactory to you, please press 1 now. If you are calling about an existing business relation that is unsatisfactory to you, please press 2 now. If you are calling to establish a new business relationship, please have your business name and taxpayer identification number handy, and press 3 now. To repeat this....
One thing that would be important with this is to ensure that the traffic is not only encrypted, but also that the nature of it (that a given session is voice traffic) is hidden. So other kinds of traffic need to be using the same thing. With TLS/SSL, the port number used is still in the clear, so the type of traffic can be inferred. While it would still be possible to do something else of that encrypted path, what is really needed is that the standard allow the end point only to know anything about what services are involved in the traffic. If encrypted tunnels are used for everything, that can help. Better be sure the peer is authenticated to avoid man in the middle interception.
The breakup of AT&T back in the 1980's was done all wrong. They broke things between local phone service and long distance service. The whole thing came about because of competition in long distance. Now we have competition in local calling, plus internet and VoIP. The one thing that remains a monopoly is the physical infrastructure. Had the breakup been done so that one well-regulated company owns and manages the physical infrastructure, and all the rest get to complete (with regulation gradually stepping in as monopolies emerge, to provide a resistance to that), then we wouldn't have all this fuss over so many regulatory and competitive issues as we have now. The one thing is that the company that owns the physical infrastructure has to stay out of the other markets (this isn't a business for the greedy), and needs to have capitalization to keep the infrastructure up to date with technological changes. What we really need right now is a "fiber everywhere" infrastructure that can carry everything. We could move to the model of having the one regulated infrastructure monopoly by creating it to build that fiber infrastucture, and phase out the existing infrastucture.
Once there is enough high speed IP deployed, we can bypass the traditional voice phone network entirely, and run voice over encrypted end to end IP connections. Imagine "dialing" in the form of domain names. The only reason the regulators are getting into this is because VoIP services are interfacing with the existing voice network. More work needs to be done to phase that voice network out of existance (which will be a long slow thing).
I've been working on getting Mozilla Firebird working on my system for a few days now. So far one remaining show-stopper glitch. And the support forum on the Mozilla website is too inconvenient to use (their design just doesn't support the volume of posts they get without taking enourmous amounts of my time manually checking for stuff, so I had to just quit using it after a few hours of getting nowhere). Are you an expert in Mozilla Firebird? Or do you know someone who is? The problem I am running into is that when I try to set up a dynamic userid so that Firebird starts up without prompting for a user profile every time, it can't find the directory for the default profile. It seems to have some registry in binary format that isn't working very well to handle directory changes. If they had coded that in XML like good little programmers (aren't these the guys who are saying "XML everywhere"?), this would have actually worked on my system (it is a multidesktop virtual user system, which works fine with NS3 and NS4, but breaks with Mozilla and now Firebird). What I need to do is dynamically create the "appreg" file correctly. If you or they know where the document that describes this file (please don't ask me to download the source on my 28.8k modem, Firebird is way to big for that... I already considered that) format, I'd sure like to know where that is.
Your backup should be two more 200 GB hard drives. If one of the original drives dies, restoring your data is quite fast. I do something like this, although with only a 120 GB and 80 GB drive. But one difference is I have a 2nd computer. The first few partitions on the 80 GB drives are my Slackware Linux system. The rest of the 80 GB drive and the entire 120 GB drive are all my data. Except for the root partition, I regularly rsync one machine to the other. Once every 2 or 3 months, I bring the backup machine up in full desktop mode just to be sure I haven't broken something. Otherwise it gets powered up every 2-3 days in server mode to accept the rsync connection and re-syncronize.
And this is why many people/networks will choose to block an entire ISP, after some reasonable time in which that ISP fails to terminate the spammer (which they would not do in most pink contract situations). Remember, the costs incurred by the spammer continuing to attempt to send spam even though mail servers will refuse it, is as great as, and maybe even greater than, the cost of "just hit delete". The only way to get rid of these costs (which are many many times what it costs the spammer to attempt to send it) is to get the spammer shut down. Those who blacklist ISPs like that are there trying to pressure them to drop pink contracts, and drop spammers. It works for some ISPs but not others. Those who use those pink ISPs and whine about not being able to send mail are indirectly helping the spammers.
If 99.99 percent of the people who receive spam refuse to buy anything from it, then the spammer will... hit an economic bonanza from all the orders coming in to him, or his client, from that 0.01 percent that do. That would be an immensely successful campaign. The problem isn't that some people part with their money for spammers; it's that it takes only a very tiny fraction of people to do so for the spammer to have tremendous success. This is because the economy of scale in spamming is so huge for the sender. The recipient who deletes a piece of spam even before reading it, based on the subject line or for whatever reason, has already incurred the cost through his ISP. Most of the cost of spam is at the receiving end. When a spammer does a ten million address run, he doesn't put ten million copies of mail in the sendmail queue. Yet ISPs such as AOL, which would likely be the target of a few million of those addresses, has to queue a separate copy for each and every one (or else apply some filtering to each and every one to get rid of it). Even when filtering out the spam in the simplest of ways, the costs at the receiving end will be greater than the costs at the sending end. Spammers have absolutely no economic incentive to trim their lists down to the tiny fraction of a percentage of people who do want that crap; it would cost all their profits to do that work. It used to be when direct marketing was expensive, having lists of people who genuinely wanted it was a great value. But today, the cost of preparing such a list is many times greater than just hitting every known email address... hence the term spam.
The problem with trying to take the approach of getting everyone to stop accepting spam really won't work just because there will always be some tiny portion we cannot convince. So, go smack your "friend" a 2nd time for me. But I don't think it will do any good. Convincing 99% of the ISPs to stop letting spam come from their network (and there are ways to do this quite effectively) will have much much more effect on reducing spam (it's then practical to just block all of the remaining 1%) than trying to convince 99.999% of people to stop reading spam and financing the spammers by buying things from them or their clients.
Ironically, BSD systems don't generally have runlevels. Still, I find them very clear and easy to understand. But I also find they are not essential, either. I did include runlevels when I rewrote my own init system a few years ago. What I didn't include was all the symlinks in separate directories, using instead a script naming scheme that included the runlevels that script is to run in. A dependency based system might be interesting, but I don't want to be forced into a GUI to use it (e.g. its entire state should also be clearly manipulatable in some combination of file names, symlinks, and editable text files). Then if you put a GUI on top of that for those that prefer GUI, that's OK.
The whole runlevels concept is confusing and cumbersome, even for most (not all, but most) sysadmins.
Could someone, preferrably someone who is a sysadmin, and preferrably someone who is confused, and most preferrably someone who is both a sysadmin and confused, please explain why this is confusing, to one of those "not all" sysadmins who is not confused by runlevels at all?
My goal is not to merely have content in the older browsers. Instead, it is to have the content presented as well as that browser can present it using the standard elements (not necessarily extensions) it supports, which were in effect at the time that browser was last improved on. That might mean HTML 3.2 for some, or even earlier. My goal is that the experience on that browser should not diminish until a suitable replacement browser is available. I absolutely do not subscribe to the "graceful degradation" philosophy. Content is not about text alone; presentation itself can have meaning and enhance the readability of content, particularly when it is part of the organization of that content.
I don't have to have it look the same on NS3 as on NS4 and as on Konq or IE or whatever. What it does need to do is still look the same on NS3 as it did on NS3 before I added the new abilities that make it show better on Konq or Moz or whatsever. It's called compatibility.
I do know about, and support, advanced web design standards. But it's time has not come for 100% of the web pages out there. Just what percentage it has come for depends on the goals of those sites. Commercial sites, which do dominate the net, don't usually consider people with limited means in their audience, so for them, disregarding the low end of browsers is fine. My biggest worry is government sites or any other where the goal is, or should be, to serve everyone. And I don't consider them to be served if a decision is made to back down on the quality of that service just to increase the quality to people on the higher end. Certain exceptions would exist. For example the FCC site area used to interact with broadcasters, not the general public, only needs to concern itself with the capabilities of the broadcasters to access it (and we can assume a broadcaster can afford at least one state of the art computer and a decent internet connection). But web areas intended for the general population do need to serve everyone, and really shouldn't be trying to favor the services to higher means people.
This situation exists because browser developers are not making an effort to have improved browser capabilities in a lean form. Instead, they are focusing on making the browser with the greatest number of bells and whistles. It's much like the computer game industry. Of course, no one is required to develop to certain platforms, so its their right to make that choice.
Slashdot Mirror
If RPM weren't such a mess, it might be more convenient to make RPMs of the packages you build from source but want to install the same exact binary on all the other machines. I just make Slackware style tarballs, so it's real easy; no spec file needed.
What? And let someone take over my browser? How do I know there isn't some Javascript code to do something else nasty?
Actually, I already have the DNS setup to block several domains for things like this. It was trivial to add one more. No need to have to remember to turn Javascript on (which I wouldn't do, anyway).
From the article:
Actually, the code I found is:
Anyway, here is my responding code:
where "disabled-zone.db" is a zone file that has a wildcard record to give a local IP address for all name queries, for a web server that always delivers my own little 1x1 transparent GIF.
When I signed up my phone number, and the number of several friends who asked me to do so for them, I used a unique email address for each one, never used before, never used since. If they get spammed, I'll definitely know. So far they have not.
Prison is also for thieves, pick-pockets, shop-lifters, burglars, and the like.
Certainly some ISPs are doing all that they can. Most are not. For example, those that do not block incoming connections to known proxy ports are not doing all that they can. So when I get spam from a particular ISP, this spam is very often because the ISP is not doing certain things it could do to prevent or at least significantly reduce spam. Another thing they can do is to block both inbound and outbount SMTP (except to the ISP's own mail servers or own network) to customers that don't ask for an exemption (spammers might do that, but most of the problem is from people who wouldn't know what SMTP is). This would prevent connections that bypass the ISP mail servers. Then by adding throttling to the mail server that limits numbers of outgoing mail from a single customer, they can reduce the problem in cases where the spammer directs it through the ISP mail server.
I do block the generic (e.g. DHCP, dialup, etc) addresses of ISP customers. This does, unfortunately, affect smarter people with better managed home (or business) mail servers. If the ISP were to allow them to have valid reverse DNS on their static IPs, my blocking, which is based on domain name, would not affect them. And if the ISP were to NOT put their own domain on reverse DNS of any customer with SMTP enabled, and such a customer spammed, I could block that customer by their domain name instead of the ISP.
But too few ISPs are clued in about all the steps they could do to prevent spam, reduce spam, and make it easy for others to prevent spam. That, or their PHB bosses wear too much clue-teflon.
HashCash has some limitations that make it unworkable in the wild. The one I noted is that it is necessary for the recipient (e.g. the one who is trying to cut back on the costs imposed by spammers) to keep track of the stamps that have been spent, up to the expiration period. Further, the costs imposed by spammers are still imposed anyway, if the server is not the one verifying the stamps (and thus also keeping a database of spent stamps for every user it serves).
HashCash would also be a burden on legitimate mailing lists. Of course, to solve that problem, whitelisting of the mailing list would be used. But it tends to be inconvenient to whitelist during subscription. This could be solved by using the HashCash only on the initial signup confirmation, and whitelist thereafter for the bulk mailings. But this still has a problem. I get lots of spam already that mimics mailing lists I am on, using the mailing list itself as the sender, and my tagged email which I signed up with as the recipient. So having whitelisted it lets the spam in, and spammers will make more use of this technique by including such details in their spam lists.
If HashCash could be modified to also include information only the real sender can prove she has, without revealing it in the ability to verify it (e.g. PKC), that might help.
Did he have THAT many domain names to put in the reverse DNS? You did check each of those names in forward DNS to see if the address record matches the connection, right? Can you extract a list of those domain names from your logs?
"If everyone would just ..."
I hear those words about spam and proposed solutions all the time. But the fact is, and will always remain so, that you cannot get absolutely everyone to do so (whatever that might be).
Consider the first possibility: "if everyone would just stop sending spam". Most of the spam comes from about 200 or so different spam gangs. Most of the rest comes from a few thousand naive victims that try it once or twice, get cut off, and never do it again (and thus losing their investment into the spamware and "list of millions" they paid some spamgang for). Already, 99.999% of internet users do not send spam. A solution that requires getting so close to a percet 100% just isn't possible.
Now for the second possibility: "if everyone would just stop reading the spam and buying from spammers". Spam works because the costs to spam senders is so utterly low, that even sending to every internet user is a lower cost than trying to trim the list down to those few people that really want what the spammers are peddling. This goes along with "just press delete". But it doesn't take much in response for the spammers to actually make a profit from their spam runs. And spammer's for hire are making money even if their clients lose money, so as long as there is a supply of naive vendors who are willing to part with their money to get a spam run in their name, spammers profit. Again, this is a case where closing the gap between 99.99% of people who don't even read the spam and the 100% needed to make spammers and their clients go away, is just not going to happen.
But there is a third possibility: "if everyone would stop using ISPs that permit spam". If even so much as 50% of users who are using ISPs that permit spamming were to cancel and switch to a better ISP that doesn't, that would definitely have a substantial effect on that ISP. I bet even 10% would get noticed, although I think a bit more, like 25%, might be needed to get some of the worst ISPs to act. Of course many people do whine about things like "there is only one ISP here" (not anywhere near 50% face this problem) and "it costs me money to switch" (it costs the victims of spammers even more money for you to continue to support an ISP that is able to give you a discount by accepting pink money from spammers). If we were to simply identify the top 10 worst ISPs for permitting spam to come from or through their network, and get a whopping 25% to 50% of their customers to leave (preferring to go to the top 10 best ISPs for not permitting any spam in or out), this would make a substantial impact and cause some CFOs to panic. And this doesn't require anywhere near 99% to be a successful anti-spam campaign.
The above campaign can also be pushed harder if many of us refused to accept email from those ISPs (and thus anyone in their network) as a sort of boycott against spam support. Of course there will be whiners here, too saying "You have no right to block my email since I don't send spam" (but if they are supporting a spammer anyway, guess what).
My whole point is that we need to avoid any "solutions" that make it necessary for absolutely everyone to do something. There will be plenty of people that won't. Instead, the solutions we need are the ones which only require a practical number of people to take that action. If you don't like the ones I propose, then propose your own and say how many people would have to act to make it work.
Taking apart the bounce message and extracting the original message? That requires going ahead and accepting the DATA transmission. This is not an acceptable solution. While SPF might cut spam in half, I have to double my costs to do it? That puts things back to as bad as they are already. I'll wait until this thing gets re-designed. The idea in principle is interesting. But it needs some work.
The decision to accept or refuse the mail is made BEFORE the bounce message is transmitted. Try again.
Spammers can use this SPF vulnerability. The way SPF works when the sender address is empty, that is, <>, which normally is used for bounce messages, the receiving client that is using SPF checking will use the HELO/EHLO name instead of the SENDER domain name. If the spammer is making the connection, including through an open proxy, he controls the HELO/EHLO name. The problem is that the HELO/EHLO name lookup involves the name of the mail server, and uses a different hierarchy of the domain owner's name space. The spammer can forge any name the owner has not configured. For example he can make the HELO name be "fantastic-offers-just-for-you.aol.com" and the SPF-aware server receiving the mail will look up "xxx.xxx.xxx.xxx.in-addr._smtp_client.fantastic-of fers-just-for-you.aol.com" [warning: slashdot will insert a space in that long string to avoid messed up formatting] for the TXT record. The wildcard deny at "*._smtp_client.aol.com" won't match the query because that's a different branch in the hierarchy. And any wildcards for real existing mail servers at aol.com won't have this spammer name, and they, too, won't match. There being no TXT record answered, your server then has to take the default action, which will usually be to go ahead and accept the mail since it might have been coming from a domain that doesn't implement SPF (yet).
If you choose to block sender <> in your mail server to avoid this kind of spam tactic, you also break the ability to receive bounce messages.
There needs to be some way to indicate at the principle domain level, e.g. at "aol.com" in the examples shown, without the "_smtp_client" subdomain, that SPF is indeed implemented. But adding a wildcard record there messes up lots of stuff. One way around this would be for SPF-aware mail servers receiving mail to perform the SPF lookup on every parent level of the domain involved (especially the HELO/EHLO one) to see if there is a TXT record with an SPF setting present. That would mean lots of extra DNS queries.
Hello and welcome to Charter Communications' legal support department. Your call is very important to us. Please listen to this menu carefully since options have changed. If you are calling about your lawsuit against us because your cable bill is too high, please press 1 now. If you are calling about your lawsuit against us because we double billed you, please press 2 now. If you are calling about your lawsuit against us because we have not paid your program provider fees, please press 3 now. If you are calling about your subpoena to divulge the names and credit card payment records of customers that are sharing music online please press 4 now. If you are calling about our violations of local ....
*** beep *** (pressed 4)
[click] [click] [pause] [click] [click]
Hello and welcome to Charter Communications' copyright enforcement department. Your call is very important to us. Please listen to this menu carefully since options have changed. If you are calling about your neighbor recording premium movies, please press 1 now. If you are calling about our customers that are downloading music on the internet, please press 2 now. If you are ....
*** beep *** (pressed 2)
[pause] [click] [click] [pause]
Hello and welcome to Charter Communications' music piracy department. Your call is very important to us. Please listen to this menu carefully since options have changed. If you are calling about a subpoena you have already sent to us, please have your subpoena registration number handy and press 1 now. If you are calling to register a new subpoena with use, please have the account number of the customer this subpoena refers to handy and press 2 now. If you are calling to obtain a customer account number, please have the name of the customer handy and press 3 now. If you are calling to obtain the name of a customer please have the IP address and time handy, and press 4 now. If you are ....
*** beep *** (pressed 4)
[pause] [click] [pause] [click] [pause]
Hello and welcome to the Charter Communications' online customer identification system. Please have the IP address and time the customer was online handy. If you already have an identification system authorization number, please press 1 now. If you do not already have an identification system authorization number, and wish to register to obtain one, please press 2 now. To repeat this ...
*** beep *** (pressed 2)
[pause] [click]
Hello and welcome to the Charter Communications' online customer identification system user authorization registration system. Please listen to this menu carefully since options have changed. If you are already a Charter Communications home cable customer, please press 1 now. If you are already a Charter Communications business internet customer, please press 2 now. If you are not a Charter Communications customer and would like to sign up for Charter Communications' cable service in your home or business today, please press 3 now. If you are not a Charter Communications customer and do not wish to sign up for cable service at this time, please press 4 now. To repeat ....
*** beep *** (pressed 4)
[click] [click]
Hello and welcome to Charter Communications' business relations department. Your call is very important to us. Please listen to this menu carefully since options have changed. If you are calling about an existing business relation that is satisfactory to you, please press 1 now. If you are calling about an existing business relation that is unsatisfactory to you, please press 2 now. If you are calling to establish a new business relationship, please have your business name and taxpayer identification number handy, and press 3 now. To repeat this ....
*** beep *** (pressed 3)
[pause] [click] [pause] [click] [pause] [click] [pause]
Hello and welcome to Charter Communications' business rel
One thing that would be important with this is to ensure that the traffic is not only encrypted, but also that the nature of it (that a given session is voice traffic) is hidden. So other kinds of traffic need to be using the same thing. With TLS/SSL, the port number used is still in the clear, so the type of traffic can be inferred. While it would still be possible to do something else of that encrypted path, what is really needed is that the standard allow the end point only to know anything about what services are involved in the traffic. If encrypted tunnels are used for everything, that can help. Better be sure the peer is authenticated to avoid man in the middle interception.
The breakup of AT&T back in the 1980's was done all wrong. They broke things between local phone service and long distance service. The whole thing came about because of competition in long distance. Now we have competition in local calling, plus internet and VoIP. The one thing that remains a monopoly is the physical infrastructure. Had the breakup been done so that one well-regulated company owns and manages the physical infrastructure, and all the rest get to complete (with regulation gradually stepping in as monopolies emerge, to provide a resistance to that), then we wouldn't have all this fuss over so many regulatory and competitive issues as we have now. The one thing is that the company that owns the physical infrastructure has to stay out of the other markets (this isn't a business for the greedy), and needs to have capitalization to keep the infrastructure up to date with technological changes. What we really need right now is a "fiber everywhere" infrastructure that can carry everything. We could move to the model of having the one regulated infrastructure monopoly by creating it to build that fiber infrastucture, and phase out the existing infrastucture.
Once there is enough high speed IP deployed, we can bypass the traditional voice phone network entirely, and run voice over encrypted end to end IP connections. Imagine "dialing" in the form of domain names. The only reason the regulators are getting into this is because VoIP services are interfacing with the existing voice network. More work needs to be done to phase that voice network out of existance (which will be a long slow thing).
I've been working on getting Mozilla Firebird working on my system for a few days now. So far one remaining show-stopper glitch. And the support forum on the Mozilla website is too inconvenient to use (their design just doesn't support the volume of posts they get without taking enourmous amounts of my time manually checking for stuff, so I had to just quit using it after a few hours of getting nowhere). Are you an expert in Mozilla Firebird? Or do you know someone who is? The problem I am running into is that when I try to set up a dynamic userid so that Firebird starts up without prompting for a user profile every time, it can't find the directory for the default profile. It seems to have some registry in binary format that isn't working very well to handle directory changes. If they had coded that in XML like good little programmers (aren't these the guys who are saying "XML everywhere"?), this would have actually worked on my system (it is a multidesktop virtual user system, which works fine with NS3 and NS4, but breaks with Mozilla and now Firebird). What I need to do is dynamically create the "appreg" file correctly. If you or they know where the document that describes this file (please don't ask me to download the source on my 28.8k modem, Firebird is way to big for that ... I already considered that) format, I'd sure like to know where that is.
The next challenge is to make a Linux distribution like Knoppix big enough to use that whole DVD.
Your backup should be two more 200 GB hard drives. If one of the original drives dies, restoring your data is quite fast. I do something like this, although with only a 120 GB and 80 GB drive. But one difference is I have a 2nd computer. The first few partitions on the 80 GB drives are my Slackware Linux system. The rest of the 80 GB drive and the entire 120 GB drive are all my data. Except for the root partition, I regularly rsync one machine to the other. Once every 2 or 3 months, I bring the backup machine up in full desktop mode just to be sure I haven't broken something. Otherwise it gets powered up every 2-3 days in server mode to accept the rsync connection and re-syncronize.
What operating systems/machines does Icarus run? Will it work on my Sun Sparc machine running NetBSD?
And this is why many people/networks will choose to block an entire ISP, after some reasonable time in which that ISP fails to terminate the spammer (which they would not do in most pink contract situations). Remember, the costs incurred by the spammer continuing to attempt to send spam even though mail servers will refuse it, is as great as, and maybe even greater than, the cost of "just hit delete". The only way to get rid of these costs (which are many many times what it costs the spammer to attempt to send it) is to get the spammer shut down. Those who blacklist ISPs like that are there trying to pressure them to drop pink contracts, and drop spammers. It works for some ISPs but not others. Those who use those pink ISPs and whine about not being able to send mail are indirectly helping the spammers.
If 99.99 percent of the people who receive spam refuse to buy anything from it, then the spammer will ... hit an economic bonanza from all the orders coming in to him, or his client, from that 0.01 percent that do. That would be an immensely successful campaign. The problem isn't that some people part with their money for spammers; it's that it takes only a very tiny fraction of people to do so for the spammer to have tremendous success. This is because the economy of scale in spamming is so huge for the sender. The recipient who deletes a piece of spam even before reading it, based on the subject line or for whatever reason, has already incurred the cost through his ISP. Most of the cost of spam is at the receiving end. When a spammer does a ten million address run, he doesn't put ten million copies of mail in the sendmail queue. Yet ISPs such as AOL, which would likely be the target of a few million of those addresses, has to queue a separate copy for each and every one (or else apply some filtering to each and every one to get rid of it). Even when filtering out the spam in the simplest of ways, the costs at the receiving end will be greater than the costs at the sending end. Spammers have absolutely no economic incentive to trim their lists down to the tiny fraction of a percentage of people who do want that crap; it would cost all their profits to do that work. It used to be when direct marketing was expensive, having lists of people who genuinely wanted it was a great value. But today, the cost of preparing such a list is many times greater than just hitting every known email address ... hence the term spam.
The problem with trying to take the approach of getting everyone to stop accepting spam really won't work just because there will always be some tiny portion we cannot convince. So, go smack your "friend" a 2nd time for me. But I don't think it will do any good. Convincing 99% of the ISPs to stop letting spam come from their network (and there are ways to do this quite effectively) will have much much more effect on reducing spam (it's then practical to just block all of the remaining 1%) than trying to convince 99.999% of people to stop reading spam and financing the spammers by buying things from them or their clients.
Ironically, BSD systems don't generally have runlevels. Still, I find them very clear and easy to understand. But I also find they are not essential, either. I did include runlevels when I rewrote my own init system a few years ago. What I didn't include was all the symlinks in separate directories, using instead a script naming scheme that included the runlevels that script is to run in. A dependency based system might be interesting, but I don't want to be forced into a GUI to use it (e.g. its entire state should also be clearly manipulatable in some combination of file names, symlinks, and editable text files). Then if you put a GUI on top of that for those that prefer GUI, that's OK.
From the OSnews article:
Could someone, preferrably someone who is a sysadmin, and preferrably someone who is confused, and most preferrably someone who is both a sysadmin and confused, please explain why this is confusing, to one of those "not all" sysadmins who is not confused by runlevels at all?
My goal is not to merely have content in the older browsers. Instead, it is to have the content presented as well as that browser can present it using the standard elements (not necessarily extensions) it supports, which were in effect at the time that browser was last improved on. That might mean HTML 3.2 for some, or even earlier. My goal is that the experience on that browser should not diminish until a suitable replacement browser is available. I absolutely do not subscribe to the "graceful degradation" philosophy. Content is not about text alone; presentation itself can have meaning and enhance the readability of content, particularly when it is part of the organization of that content.
I don't have to have it look the same on NS3 as on NS4 and as on Konq or IE or whatever. What it does need to do is still look the same on NS3 as it did on NS3 before I added the new abilities that make it show better on Konq or Moz or whatsever. It's called compatibility.
I do know about, and support, advanced web design standards. But it's time has not come for 100% of the web pages out there. Just what percentage it has come for depends on the goals of those sites. Commercial sites, which do dominate the net, don't usually consider people with limited means in their audience, so for them, disregarding the low end of browsers is fine. My biggest worry is government sites or any other where the goal is, or should be, to serve everyone. And I don't consider them to be served if a decision is made to back down on the quality of that service just to increase the quality to people on the higher end. Certain exceptions would exist. For example the FCC site area used to interact with broadcasters, not the general public, only needs to concern itself with the capabilities of the broadcasters to access it (and we can assume a broadcaster can afford at least one state of the art computer and a decent internet connection). But web areas intended for the general population do need to serve everyone, and really shouldn't be trying to favor the services to higher means people.
This situation exists because browser developers are not making an effort to have improved browser capabilities in a lean form. Instead, they are focusing on making the browser with the greatest number of bells and whistles. It's much like the computer game industry. Of course, no one is required to develop to certain platforms, so its their right to make that choice.