"I can confirm that the... personnel are not participating in customer visits. This is an error in the copy and will be amended in future material on the subject," Alexander claimed.
The "Feet on the Street" are not visiting customers (that is, purchasers of computers), they're visiting the vendors of such systems. This campaign is not aimed at stopping the people buying naked systems, it's about choking off the supply by targetting the sellers.
I put this in the same class of ideas as seatbelt laws
To be fair, seatbelt laws aren't just for the benefit of the seatbelt wearer - in a collision, your two hundred pounds of meat moving at 60mph is just an unsecured load like any other, and presents a danger to others, inside and outside of your vehicle. This is also why rear-seat belts are important - they save the lives of front seat passengers.
This year marks fifty years since Elvis' performance of Heartbreak Hotel was released. It's not like this comes as some sudden surprise, though - recall the dozens of Elvis re-release compilations a few years back? Expect the same treatment for all the sixties classics in the next few years, as every last cent of cash is wrung out of them before they're finally, grudgingly handed over to the public domain.
SPF is a failure. Unlike the submitter, its proponents don't even pretend that it's an anti-spam method (there are more spam messages with SPF than ham), focussing instead on its authentication promise. Now it seems even Meng has abandoned that as being worth anything if the FUSSP is whitelist-only. Imagine that - saving email by destroying it!
Email has been a phenomenal success because it costs close to zero to contact people with whom you otherwise would never easily be able to communicate. UBE is a problem precisely because it costs close to zero to contact people with whom you otherwise would never easily be able to communicate. Any FUSSP that destroys either of those two qualities, cost and ubiquity, is a cure that's worse than the disease.
From what I understand, the RSA patent has expired now.
I well remember the party I attended to celebrate the patent expiry, in September 2000
So, why havent we seen people working on a simple to use way to do encrypted email now that they dont have to pay RSA for the patent?
Ever used Outlook? Or Thunderbird? Those email clients (and many others) do have a simple way to encrypt (and sign) email using S/MIME. The problem never was patent restrictions, rather the difficulties associated with key management (certificate management and PKI never took off the way it was originally hoped, for a number of reasons).
if they start taxing "innocent people" (AKA people who don't watch online content from the BBC), then they are more or less just a thief with government permission.
I don't have children, but they steal money from me to pay for schools. I don't drive, but they steal from me to build roads. I don't read, but they steal from me to build libraries.
The value of the BBC to the nation (indeed the world) is somewhat more than the sum of Eastenders and Porridge.
If fewer people see the spam, it's less profitable and less of it is sent out.
That doesn't follow at all. There's compelling evidence that improved filtering rates act as an incentive for spammers to increase their sending volumes, simply to try and maintain the same return rate.
Not quite dead
on
Spam is Dead
·
· Score: 5, Insightful
You may not be seeing it, but it's still taking up gobs of bandwidth, disk and CPU, and *somebody* has to pay for all that. I think that the costs to transfer, store and process spam outweigh the cost of individuals' time spent reading/deleting it.
Mea culpa
on
Spam is Dead
·
· Score: 2, Insightful
You're totally right, I should have written "piece", not "article".
My work machine and home machine both have better uptimes. And I've seen (laid my hands upon) windows servers with uptimes orders of magnitudes higher.
Better than his Windows uptimes, or his Linux uptimes? Even if it's the latter (and I doubt that, see below), all that says is that you never apply updates to Windows. So you never update, yet you have the temerity to question his "fucking" windows admin skills?
As to "orders of magnitudes" higher uptime, that means at least one hundred times better - I am quite confident neither you nor anybody else has ever seen a Windows server with *tens of thousands* of days of uptime.
Maybe you should change your nick to everphullofshitski ?
Heh, and when the money gets tight, guess who'll be the first to go?
In a sane world, those getting the chop would be the ones whose poor decisions cost the company so much (but I am unable to argue with conviction that we actually live in such a world).
I would like to point out that at Sony's size, the different divisions have little or nothing to do with each other.
So the same people who make decisions for the music products are not the same people who make decisions at the playstation divisions .
From what I hear, there is some pretty intense inside fighting going on between the people who make mop3 players, and the music division.
That sounds to me like more reason to boycott, not less - the impact is not compartmentalised, but spreads across their entire business. It also gives ammunition to those on the inside who are fighting against the shenanigans. Sony need to get the message that their actions don't just do damage to their CD sales business, they also create a serious dent in the Sony "brand" as a whole.
drug manufacturers outlay a truly phenomenal amount of money to develop and test any particular drug
The implication being that this is a huge drain on the pharmcos resources, and they therefore need "special protection". The truth is that whatever the actual R&D budget is, the big pharmcos all spend at least twice as much on marketing.
I moved and did not get a landline phone in my new abode. It's illegal for marketing types to call my cellular phone
If these bottom-feeders manage to get the DNC laws overturned, what makes you think they won't then start whining^Wlobbying about how unfair it is that they can't call cell phones?
I didn't realise when I replied to you earlier that you are not just a regular proponent of SPF, but Wayne* , so of course, you're very familiar indeed with the pros and cons of SPF. My apologies for not recognising you earlier, and for perhaps oversimplifying what I think all sides in the debate will concede is a difficult problem.
* I guess you've been on by Friends list for so many years, I'd long forgotten *why*
Even with throw-away domains, an SPF pass will not help spammers. A domain that has no record of sending significant quantities of email and which has other spam indicators such as who their authoratative name servers are or their whois/registration information can have a negative reputation from the very start.
True iff you're collaboarating with others to build a "reputation score". For an isolated system, this works well if you receive mail from the same senders all the time, but starts to break down if you have to accept mail from people with whom you've never communicated before.
Again, I can understand spammers being stupid enough to think they need to get an SPF pass, but I can't understand MX logic claiming that this is in any way a problem.
The problem may be more one of perception. It's (currently at least) a fact that a message that has SPF is *more likely* to be spam than not (cf the Habeus Corpus stuff - I've never seen those "anti-spam" headers in any messages other than spam). The only way to cut through that is to rely on other measures, reputation, whois lookups etc; but then, why not just do that anyway and forget about SPF?
Meng Wong once used the analogy of "SPF is an anti-spam system like flour is a food." SPF alone doesn't do much for you, but SPF plus reputations systems do stop spam. The "problem" with null envelope-froms is not a problem. SPF falls back to the HELO domain, since it is the MTA at the HELO domain that is generating the bounce.
Nice quote. But null envelope senders *are* a problem for SPF - it simply *can't* deal with them because there is no data to deal with. The other suggested "workaround" for this is parsing the bounce message itself and trying to determine whether the message ID is valid, a recipe for failure if ever I heard one. Falling back to assessing the HELO takes us right back to where we started - the HELO is the single most useless and untrustworthy element in an SMTP transaction. Sad to say, there's plenty of borken email software out there that doesn't HELO properly; rejecting on bad HELO alone will definitely break some legitimate mail. It's a distinct possibility that rising use of SPF will encourage spammers to use null envelope sender more often, and the knock-on consequences of that are potentially quite serious (there are enough brain-dead mail admins out there already who reject the null sender envelope). Quite apart from which, it's trivial for the sender (zombie trojan for example) to generate a perfectly valid HELO for its own IP/hostname.
I can understand the appeal of a method that is an analog of the MX record but for sending rather than receiving. The problems stem from the underlying fact that this conflicts with one of the fundamental design goals of SMTP - that anyone can send email without requiring the permission of anyone else.
MX logic does seem to quite grasp the concept that spammers identifying themselves as the true senders of the spam is a good thing, not a bad thing
Would be a fair point if the "identity" of the spammers was static. But it is not; domain registration is automated and turnover is massive, sites lasting maybe a few hours. It's no coincidence that the biggest take-up of SPF has been amongst spammers.
Quite apart from which, even the proponents of SPF, when tackled head-on with hard questions (eg about how SPF deals with null envelope-sender (bounces)), will tell you that SPF is *not* a spam prevention mechanism. What it might, *might*, help with is reducing the collateral damage and back-scatter effects of joe-jobs, as well as reducing the effectiveness of phishing attacks. Those are mostly othogonal to the spam problem.
You seem to be lumping me in with the extremists like the SPEWS people. I would have thought it was clear from my other postings that far from being dogmatic, I take a balanced approach to RBLs and other anti-spam measures. Nowhere have I said that RBLs are *the* tool for *everybody* in *all circumstances*.
But you know, you can't have it both ways - you say this is destroying email, but then you also object to pressuring ISPs to deal with what you describe as a "minor problem". Well, which is it? Minor problem or the end of email as we know it? Nothing you've written has had the slightest effect on my view, because you're simply never going to convince me that I'm not permitted to choose what traffic I will accept on my own system.
Okay, but I question how you can actually know how much the RBL is costing you.
Millions and millions of rejected messages versus the occasional manual intervention. It's a pretty easy judgement. I can even figure an average spam message size, multiply by the number received, compare that to my ham traffic, weight it against the cost of running my mail service and produce a dollars and cents figure of what RBLs save me (and that's before I factor in the costs associated with users having to deal with those spams if they were delivered). If I'm rejecting two thirds of all delivery attempts at the front door, I don't need to have mail systems that are three times the size and three times the cost.
If an employee sends an email asking for product information from Companies A, B, C, and D, but only gets answers from C and D, is he going to call you up assuming there's a problem or is he going to assume A and B aren't interested?
You seem to be conflating the case where I am using RBLs and the case where someone else is. If my employee attempts to send an email to a system that has us on their blocklist, my employee gets a non-delivery report from my system, advising him that the message was not delivered, including a transcript of the SMTP dialogue ("552 We don't like people with a "K" in their name"). Typically, he would then contact me and ask what was up, and I then deal with it in whatever way is appropriate. In the case where somebody elses employee tries to send to us, and we reject because of a RBL listing, that remote person gets a non-delivery report from their own system, and it is for the remote admin to deal with it as appropriate. I can only take responsibility for my own systems, I can't be postmaster for everybody else.
[...the old "it stops people sending" chestnut again...]
So you believe the onus for ensuring delivery of any particular message lies with the intended recipient, not the sender? I refute that entirely. As long as I own my equipment, then I'll feel no obligation to accept any traffic that I don't want to. And your smokescreen about "third parties" is just that, FUD. By "receiver", I mean the system published as handling the mail for a particular domain, as specified in its MX record. The fact that other stuff may happen internally at the receiver after a message is accepted is irrelevent. Simply, the MX record says "mail for domain example.com is handled by mail.example.com". When a sender connects to that system, responsibilty for that particular message does not pass from sender to receiver until the receiver issues a 250 OK. You seem to want me to take responsibility for *all* messages, not just the ones I've 250'd. That makes no sense, sounds more like a charter for spammers, and it is also completely impractical to try to force that on me.
Let's stop destroying email and let's tackle spam using appropriate, sensible, measures. If it generates false positives, preventing an email, send from one individual addressed to another, that the intended recipient wants to receive from being received, it shouldn't be under consideration.
Firstly, let's not forget who are the real villains here : it is the *spammers* who are damaging the utility of email.
So, you're in the camp who thinks false positives are not acceptable, ever. OK. Your system, your choice. But you have to recognise that this is not a cut & dried decision, and there will always be substantial numbers of others who are quite willing to suffer false positives, provided the rate is low. Hell, SMTP doesn't make any guarantees about delivery, and messages go missing or undelivered all the time, for reasons that have nothing to do with RBLs.
Bottom line is, I'm not going to stop using RBLs until they stop being useful, and I'm far from alone in that. What are you going to do about it? Whine some more?
Slashdot Mirror
The "Feet on the Street" are not visiting customers (that is, purchasers of computers), they're visiting the vendors of such systems. This campaign is not aimed at stopping the people buying naked systems, it's about choking off the supply by targetting the sellers.
To be fair, seatbelt laws aren't just for the benefit of the seatbelt wearer - in a collision, your two hundred pounds of meat moving at 60mph is just an unsecured load like any other, and presents a danger to others, inside and outside of your vehicle. This is also why rear-seat belts are important - they save the lives of front seat passengers.
This year marks fifty years since Elvis' performance of Heartbreak Hotel was released. It's not like this comes as some sudden surprise, though - recall the dozens of Elvis re-release compilations a few years back? Expect the same treatment for all the sixties classics in the next few years, as every last cent of cash is wrung out of them before they're finally, grudgingly handed over to the public domain.
You can get personal certificates free from Thawte. Also, PGP add-ons are widely available, eg for Mozilla/Thunderbird, Enigmail hits the spot.
SPF is a failure. Unlike the submitter, its proponents don't even pretend that it's an anti-spam method (there are more spam messages with SPF than ham), focussing instead on its authentication promise. Now it seems even Meng has abandoned that as being worth anything if the FUSSP is whitelist-only. Imagine that - saving email by destroying it!
Email has been a phenomenal success because it costs close to zero to contact people with whom you otherwise would never easily be able to communicate. UBE is a problem precisely because it costs close to zero to contact people with whom you otherwise would never easily be able to communicate. Any FUSSP that destroys either of those two qualities, cost and ubiquity, is a cure that's worse than the disease.
I well remember the party I attended to celebrate the patent expiry, in September 2000
Ever used Outlook? Or Thunderbird? Those email clients (and many others) do have a simple way to encrypt (and sign) email using S/MIME. The problem never was patent restrictions, rather the difficulties associated with key management (certificate management and PKI never took off the way it was originally hoped, for a number of reasons).
I don't have children, but they steal money from me to pay for schools. I don't drive, but they steal from me to build roads. I don't read, but they steal from me to build libraries.
The value of the BBC to the nation (indeed the world) is somewhat more than the sum of Eastenders and Porridge.
That doesn't follow at all. There's compelling evidence that improved filtering rates act as an incentive for spammers to increase their sending volumes, simply to try and maintain the same return rate.
You may not be seeing it, but it's still taking up gobs of bandwidth, disk and CPU, and *somebody* has to pay for all that. I think that the costs to transfer, store and process spam outweigh the cost of individuals' time spent reading/deleting it.
You're totally right, I should have written "piece", not "article".
/me lashes self
The archive is only available to IP addresses originating from the UK.
Better than his Windows uptimes, or his Linux uptimes? Even if it's the latter (and I doubt that, see below), all that says is that you never apply updates to Windows. So you never update, yet you have the temerity to question his "fucking" windows admin skills?
As to "orders of magnitudes" higher uptime, that means at least one hundred times better - I am quite confident neither you nor anybody else has ever seen a Windows server with *tens of thousands* of days of uptime.
Maybe you should change your nick to everphullofshitski ?
In a sane world, those getting the chop would be the ones whose poor decisions cost the company so much (but I am unable to argue with conviction that we actually live in such a world).
That sounds to me like more reason to boycott, not less - the impact is not compartmentalised, but spreads across their entire business. It also gives ammunition to those on the inside who are fighting against the shenanigans. Sony need to get the message that their actions don't just do damage to their CD sales business, they also create a serious dent in the Sony "brand" as a whole.
The implication being that this is a huge drain on the pharmcos resources, and they therefore need "special protection". The truth is that whatever the actual R&D budget is, the big pharmcos all spend at least twice as much on marketing.
Do you always express yourself in tautologies or is today somehow special?
So : NAFTA, good or bad for trade?
In similar vein, note that you have to fill in your email twice . A classic example of why "double opt-in" is utterly meaningless.
I moved and did not get a landline phone in my new abode. It's illegal for marketing types to call my cellular phone
If these bottom-feeders manage to get the DNC laws overturned, what makes you think they won't then start whining^Wlobbying about how unfair it is that they can't call cell phones?
I didn't realise when I replied to you earlier that you are not just a regular proponent of SPF, but Wayne* , so of course, you're very familiar indeed with the pros and cons of SPF. My apologies for not recognising you earlier, and for perhaps oversimplifying what I think all sides in the debate will concede is a difficult problem.
* I guess you've been on by Friends list for so many years, I'd long forgotten *why*
Even with throw-away domains, an SPF pass will not help spammers. A domain that has no record of sending significant quantities of email and which has other spam indicators such as who their authoratative name servers are or their whois/registration information can have a negative reputation from the very start.
True iff you're collaboarating with others to build a "reputation score". For an isolated system, this works well if you receive mail from the same senders all the time, but starts to break down if you have to accept mail from people with whom you've never communicated before.
Again, I can understand spammers being stupid enough to think they need to get an SPF pass, but I can't understand MX logic claiming that this is in any way a problem.
The problem may be more one of perception. It's (currently at least) a fact that a message that has SPF is *more likely* to be spam than not (cf the Habeus Corpus stuff - I've never seen those "anti-spam" headers in any messages other than spam). The only way to cut through that is to rely on other measures, reputation, whois lookups etc; but then, why not just do that anyway and forget about SPF?
Meng Wong once used the analogy of "SPF is an anti-spam system like flour is a food." SPF alone doesn't do much for you, but SPF plus reputations systems do stop spam. The "problem" with null envelope-froms is not a problem. SPF falls back to the HELO domain, since it is the MTA at the HELO domain that is generating the bounce.
Nice quote. But null envelope senders *are* a problem for SPF - it simply *can't* deal with them because there is no data to deal with. The other suggested "workaround" for this is parsing the bounce message itself and trying to determine whether the message ID is valid, a recipe for failure if ever I heard one. Falling back to assessing the HELO takes us right back to where we started - the HELO is the single most useless and untrustworthy element in an SMTP transaction. Sad to say, there's plenty of borken email software out there that doesn't HELO properly; rejecting on bad HELO alone will definitely break some legitimate mail. It's a distinct possibility that rising use of SPF will encourage spammers to use null envelope sender more often, and the knock-on consequences of that are potentially quite serious (there are enough brain-dead mail admins out there already who reject the null sender envelope). Quite apart from which, it's trivial for the sender (zombie trojan for example) to generate a perfectly valid HELO for its own IP/hostname.
I can understand the appeal of a method that is an analog of the MX record but for sending rather than receiving. The problems stem from the underlying fact that this conflicts with one of the fundamental design goals of SMTP - that anyone can send email without requiring the permission of anyone else.
MX logic does seem to quite grasp the concept that spammers identifying themselves as the true senders of the spam is a good thing, not a bad thing
Would be a fair point if the "identity" of the spammers was static. But it is not; domain registration is automated and turnover is massive, sites lasting maybe a few hours. It's no coincidence that the biggest take-up of SPF has been amongst spammers.
Quite apart from which, even the proponents of SPF, when tackled head-on with hard questions (eg about how SPF deals with null envelope-sender (bounces)), will tell you that SPF is *not* a spam prevention mechanism. What it might, *might*, help with is reducing the collateral damage and back-scatter effects of joe-jobs, as well as reducing the effectiveness of phishing attacks. Those are mostly othogonal to the spam problem.
You seem to be lumping me in with the extremists like the SPEWS people. I would have thought it was clear from my other postings that far from being dogmatic, I take a balanced approach to RBLs and other anti-spam measures. Nowhere have I said that RBLs are *the* tool for *everybody* in *all circumstances*.
But you know, you can't have it both ways - you say this is destroying email, but then you also object to pressuring ISPs to deal with what you describe as a "minor problem". Well, which is it? Minor problem or the end of email as we know it? Nothing you've written has had the slightest effect on my view, because you're simply never going to convince me that I'm not permitted to choose what traffic I will accept on my own system.
Spam is a resolvable issue.
Go ahead Einstein, I'm all ears...?
Okay, but I question how you can actually know how much the RBL is costing you.
Millions and millions of rejected messages versus the occasional manual intervention. It's a pretty easy judgement. I can even figure an average spam message size, multiply by the number received, compare that to my ham traffic, weight it against the cost of running my mail service and produce a dollars and cents figure of what RBLs save me (and that's before I factor in the costs associated with users having to deal with those spams if they were delivered). If I'm rejecting two thirds of all delivery attempts at the front door, I don't need to have mail systems that are three times the size and three times the cost.
If an employee sends an email asking for product information from Companies A, B, C, and D, but only gets answers from C and D, is he going to call you up assuming there's a problem or is he going to assume A and B aren't interested?
You seem to be conflating the case where I am using RBLs and the case where someone else is. If my employee attempts to send an email to a system that has us on their blocklist, my employee gets a non-delivery report from my system, advising him that the message was not delivered, including a transcript of the SMTP dialogue ("552 We don't like people with a "K" in their name"). Typically, he would then contact me and ask what was up, and I then deal with it in whatever way is appropriate. In the case where somebody elses employee tries to send to us, and we reject because of a RBL listing, that remote person gets a non-delivery report from their own system, and it is for the remote admin to deal with it as appropriate. I can only take responsibility for my own systems, I can't be postmaster for everybody else.
Shorts are no place for a hamster.
[...the old "it stops people sending" chestnut again...]
So you believe the onus for ensuring delivery of any particular message lies with the intended recipient, not the sender? I refute that entirely. As long as I own my equipment, then I'll feel no obligation to accept any traffic that I don't want to. And your smokescreen about "third parties" is just that, FUD. By "receiver", I mean the system published as handling the mail for a particular domain, as specified in its MX record. The fact that other stuff may happen internally at the receiver after a message is accepted is irrelevent. Simply, the MX record says "mail for domain example.com is handled by mail.example.com". When a sender connects to that system, responsibilty for that particular message does not pass from sender to receiver until the receiver issues a 250 OK. You seem to want me to take responsibility for *all* messages, not just the ones I've 250'd. That makes no sense, sounds more like a charter for spammers, and it is also completely impractical to try to force that on me.
Let's stop destroying email and let's tackle spam using appropriate, sensible, measures. If it generates false positives, preventing an email, send from one individual addressed to another, that the intended recipient wants to receive from being received, it shouldn't be under consideration.
Firstly, let's not forget who are the real villains here : it is the *spammers* who are damaging the utility of email.
So, you're in the camp who thinks false positives are not acceptable, ever. OK. Your system, your choice. But you have to recognise that this is not a cut & dried decision, and there will always be substantial numbers of others who are quite willing to suffer false positives, provided the rate is low. Hell, SMTP doesn't make any guarantees about delivery, and messages go missing or undelivered all the time, for reasons that have nothing to do with RBLs.
Bottom line is, I'm not going to stop using RBLs until they stop being useful, and I'm far from alone in that. What are you going to do about it? Whine some more?