Claim: 2 million jobs in the "telemarketing industry" are supposedly going to be lost by the Do Not Call registry, which is expected to reach 60 million numbers.
So does that mean that 2 million telemarkets are responsible for calling 60 million numbers, or does each telemarketer call just 30 numbers repetitively? Ok, maybe 50% of telemarketing jobs are overhead (seems high), giving each telemarketer who's job is in jeopardy an average target of 60 numbers?
That would explain the high volume of calls... but if a call lasts 30 seconds on average, and each employee works 8 hours (960 calls/shift), that means each of those 60 million numbers would receive an average of 16 calls each day (960 calls/day 60 calls/employee).
Hmm, 16 calls is a bit high... but many households do receive a good number of calls each day (likely 'cause they're saying "take me off your list" rather than "put me on your do not call list").
Ok, maybe it does add up and a couple million people will be looking for new jobs....
One big advantage of this approach [at.allow, at.deny in/usr/lib/cron (posix) rather than/etc (lsb)] would be for a large number of systems, that NFS mount/usr. Now, in order to update the program, or to adjust it's settings, you change one set of files, and it is automatically replicated, throught the NFS mounts.
Many environments would want to allow certain users to run jobs automatically on their machines, without globally granting them that privledge on every other machine in the company, department, university, etc.
Continuing quoting...
If the configureation was seprate, then a new version that required a change in configuration files would result in having to change the file on all the machines, or some ugly hack invloving lot's of symlinks in/etc. And hope that you never have to add a new program to/usr, or it's time to go around all the boxes manually again.
Many solutions exist for administrating/etc files, to merge a global configuration with per-machine specific settings.
Sure, as an administrator, maybe the world revolves around making your job as easy as possible. I know it's hard to think of the bigger picture, especially for some heavily overworked admins, but computers don't exist and we don't all use them to cater to the whims of admins.
Computers are tools that are used to get real work done (well, some people also play games or entertain themselves, but rarely are admins paid to support those activities).
What matters is a useful configuration that facilitates real people using their computers to do real work, which ultimately furthers the mission of the company/organization paying for the computers and system admin(s).
In this case, the LSB decision allows a read-only global NFS mount of/usr and avoids placing configuration files there that will likely need to be different amoung different machines.
I know of this page because of a recent email (that presumably went to all customers), so it's not like they just put it up in an obscure location and didn't tell anyone.
Quoting the parent post, who was quoting Jim Gray...
At current and near-future access speeds, searching a 20-terabyte disk might take a year.
Today's drives run about 20 to 50 Mbyte/sec from the platter. You can get 133 Mbyte/sec from the tiny buffer, of course, but for a whole-drive search, let's assume you're going to read 20 terabytes at 30 megabytes/sec. My calculator says that's 666667 seconds, or 7.7 days. Yes, a long time to wait, but 7.7 days is a long way from "might take a year". Even if you get only 10 Mbyte/sec, which is much slower than the drive's benchmark'd transfer speed but might happen with operating system and other other overhead, you're still at one month, not one year. To take an entire year reading 20 TB, you'd need to sustain only 634 kbyte/sec transfer. Hard drives haven't been that slow for a very, very long time.
I'll be Jim Gray (head of Microsoft's Bay Area Research Center) believes what we all need is to dump FAT32, NTFS (ext2, ext3, JFS, Reiser, XFS, etc) and go to whatever database oriented filesystem Microsoft is cooking up for 2005 in "longhorn"... or whatever they're naming it nowadays. The sad part is that it'll require faster CPU and hard drive to achieve the same performance of older MS system, assuming they continue the long running trend of "innovation".
Your power utility company also lets you install whatever appliances you like on those 120 volt and 240 volt sockets throughout your home.
But that doesn't make those wires safe to touch, does it?
Likewise to the FCC's Part 68 rules, the Underwriters Labortories does not allow manufacturers to sell products that expose you to those power lines, do they?
I should have mentioned that the reason for the FCC's open-circuit failure requirement is because in the event that a high voltage power line or lightning strike hits the phone line, hundreds or even thousands of telephones will be destroyed. When the carrier attempts to restore service, if a significant portion of those damaged phones are conducting (equivilant to you answering the phone and leaving off the hook), they will tie up all the available circuits and service can't be restrored to that area without physically removing all those damaged phones.
The key point is that those tiny, seemingly harmless little telephone wires actually run out of your building and (often times) directly into large bundles strung on telephone polls underneath high voltage power lines. It is not safe to allow consumers to come into contact with those wires. It is also not legal, which is why Sony is recalling.
Of course Sony's going to downplay the seriousness of the problem with a lengthy description that makes it sound like the problem is so rare all the stars have to line up just right for it to occur. But they're recalling for a reason!
The key part is that you can get a shock when the phone rings. Very bad. That means the user is exposed to a low impedance connection to the phone line, which is illegal (FCC part 68). Sure, to feel the shock you need to have a return path to earth ground... and the circumstances spelled out make it seem highly improbably.
But consider that those 2 wires from the phone line are supposed to be galvanically isolated, via a transformer, optocoupler, high-voltage low-value capacitors, or some other safe barrier. Consumers are never supposed to be exposed to those bare telephone wires, which run on telephone poles with high voltage power lines overhead.
Sure, the 50 to 100 volt ring signal can give you a bit of a shock. But the real danger is that those telephone lines are not safe if there is a failure like a tree falls onto the lines or they're hit by lightning. That's why all telephones are required by the FCC to isolate those wires from the user.
The FCC also has strict requirements that all telephone equipment fail as an open circuit (equivilant to not taking the phone off the hook), even if the lines are hit with extreemly high voltage such as 12,000 volt power lines coming into contact with the phone line momentarily.
Before you contact Adobe and "make a serious stink"....
Consider the irony that you will be complaining about how Adobe is authenticating the trustworthiness of plugins, based on misleading information in an angry rant from a very untrustworthy Russian company with a history discovering Adobe's vulnerabilities and then selling (for profit) exploit tools that exploit those vulnerabilities.
What were you going to complain about again to Adobe's senior management... oh yes, it was "their stupidity and callousness".
Naturally, you'll complain that they did release a fix in version 6 in March 2003 for the vulnerability CERT published in January 2003... which Elcom reported to CERT in September 2002, only after years of promoting selling a commercial exploit tool and ultimately having to pull it from the market based on the high profile Dmitry case.
You'll complain it was "stupid" that their fix still has a more obscure weakness (not actually mentioned in the CERT advisory), and when they don't repond you'll call them "callous".
Also, as long as Elcom is thowing stones of "Adobe is slow, unresponsive" and still has a weakness after their attempt to fix the problem, consider Elcom's standard of professional conduct:
Discover weakness in Acrobat Reader
Create exploit tool and sell it commercially
Announce the exploit at Defcon and distribute some free copies of the polished, for-profit exploit
Dmitry gets arrested, infamous DMCA case...
Eventually report the bug to CERT, after Dmitry case resolved
Adobe reworks plugin authentication/signing in next major release, but a flaw still remains where unsigned plugins can patch Acrobat's in-memory image and obtain unathorized privs (CERT avdisory only covers signing weakness)
Elcom complains that Adobe has ignored problem and done nothing.
The DMCA sucks, Adobe is unresponsive, and Dmitry shoulda been released promptly.... but regardless of all that, everybody should remember that we're dealing with a for-profit company that discovered weaknesses and first created and SOLD for-profit exploits and went on a campaign to promote it... and only reported to CERT after a legal battle that forced them to pull their commercial exploit product from the market.
Clearly, Elcom is attempting to characterize Adobe as having utterly ignored this problem. It does appear that they have been slow and unresponsive to input. But this message reads as a smear campaign against Adobe, attempting to distort the facts by mixing a new security advisory with a rant about how slow and unresponsive they have been.
They characterize a new bug (oversight in the fix, see below) as having done absolutely nothing. Not very honest...
I'm pretty impressed that slashdot didn't post the inaccurate "no improvements for 2 years" title, when it is clearly a fact (based on the text of the article) that Adobe added a new, stronger signing method in version 6, as a good-faith attempt to solve this problem. Yes, "2 years" appears to be true, but that's not the 2 years from July 2001 to July 2003 (today).
Likewise, the statement at the top: "oftware released in 2003 contains vulnerabilities disclosured in 2001" gives the impression that the new version contains the exact same vulnerability, rather than an oversight in a major rework of the security mechanism that was intended to fix the bug.
It sounds like Adobe really did try to fix the problem. They implemented a new, strong signing method. They even adandoned backwards compatibility and refuse to load the old, easily forged plugins when in certified mode. As Elcom's message explains, Acrobat 6 only allows "certified" mode if all the plugins have the new, strong signatures, or if all the plugins if finds have these signatures it automatically goes into certified mode.
The real complaint appears to be an oversight that some undocument function, which is callable in uncertified mode by an unsigned plugin (or one of the legacy weakly authenticated plugins) can call this undocumented function and cause Acrobat to switch into certified mode. Quoting from the Elcom message:
Therefore, if plug-in with "forged" certificate is loaded, it can
patch the code of CTIsCertifiedMode function in memory, and so force
Acrobat to believe that it works in "Certified" mode.
So there you have it, a secutity real announcement, burried after a lengthy rant about how slow and unresponsive Adobe has been.
Yes, Adobe has a bad attitude. Yes, they fscked up and their attempt to fix the problem still has an exploitable weakness. Ok, I can buy that Adode has a bad attitude.
Elcom (or specifically, Vladimir Katalov) doesn't impress me much either, when it comes to attitude and standards of professional conduct. This angry rant attempts to paint a picture of Adobe has having still done utterly nothing to fix this problem... including a very misleading tital and summary.
Katalov sinks to the tactic of use a embedded an advisory of a weakness to attract attention to an angry rant about his frustrations with Adobe's unresponsive history.
... pines for the next "killer app" that will bring a segment of the computing industry back to previous glory days of rapid growth.
You'd think after about 10 years of Macintosh enthusiast columnists pining for Apple's sucessor to "desktop publishing" this sort of uninspired writing would end..... but saddly this drivel is too easy to write, especially when 4th-of-july barbeque is what's really on his mind and something/anything needs to get knockout out quickly to meet a publish deadline.
I've always thought that a creed of Linux was to do more with less. It's the continual bloat added to Windows that drives the need for new hardware. Linux development strives for more efficiency.
In the kernel, perhaps...
But give Mozilla a try for bloat. Or launch a gnome-terminal and time how long the first one takes to come up... or worse yet type "ls -l/usr/bin" and see how slowly all those pretty anti-aliased fonts take to scroll.
I wonder how Neilson reconciles today's "Small is Beautiful (and Profitable) on the Web" with his constant theme of 1997's
Advertising Doesn't Work on the Web (which he links to in many articles, as recently as just last month). How can he write:
A site on growing blueberries can be a must-read service for people who farm them, and thus of immense value as a place to
promote blueberry-farming equipment.
Diversity is power on the Web. Big sites may be bigger, but smaller sites will keep scoring higher for specialized topics, both in terms of their connections with users and in terms of each visit's commercial value.
People get their spam an hour after you initiate sending. BFD..... RIGHT NOW, this will stop spam cold. In six months, it will be useless.
No. If it's widely deployed and if spammers adapt, in six months spammers will be forced to maintain the same IP number for 1 hour to get messages delivered (very difficult for the ones who compromise hosts) AND not have that IP number end up in blacklists during that 1 hour AND not have newer spam-pattern detection filters identify that IP number as spewing spam AND not have message digest filters (vipul's razor) list a fuzzy match of whatever they're bulk transmitting within that hour.
All first-contact email conversations will be delayed by 1 hour and that really sucks. But spammers will be hurt, because 1 hour is a very long time in the anti-spam detection world and many conventional filtering techniques will be able to recognize the second attempt an hour later for the spam it is.
Saddly, you have missed the central point about the necessity of timeliness of email delivery and instead focused on using FTP rather than attachments.
Even if FTP were a solution, it does nothing to answer a new customer who says "I just heard about you and I'm excited about your products. Wanted to call and ask you some questions. I sent an email about 10 minutes ago with an outline of the project we're doing were you guys could really help out, have you had a chance to look it over yet".
There's a limitless number of these important common customer relationship scenarios, where the expectation of all parties involved is that email is delivered in under 1 minute and typically 5-10 seconds. And there are an infinite number of scenarios other than sales and customer service/relations where people quite reasonably expect email to be delivered in seconds.
Focusing on using FTP isn't just the wrong answer, it's not even an answer at all to the problem of email delivery taking an order of magnitude longer than users expect and depend upon.
But as others have pointed out, most users don't have access to FTP servers to receive files. Most corporate firewalls would prohibit users from setting up a FTP server. I would guess that almost any employee behind a corporate firewall wanting to somehow receive a file from a new customer via FTP who attempted to ask a sysadmin would get the answer "just have them send it as an attachment". FTP is simply not a viable protocol for customers and salespeople (or most others) to use to pass files back and forth.
Aside from not solving the unacceptable delay and the inappropriateness of using FTP, there is the problem of bad attitude. Specifically:
Explain this to your
user. You can just tell them that... [snip]
Where did "new customer" turn into "user". The word "user" in this context is often spoken in the tone of an overworked, grumpy sysadmin who's personal view of his priorities are decoupled from the larger organization's mission (usually taking care of customers, selling products, operating efficiently, and so on).
In this particular example, what is important is that the new customer whats to talk with someone about solving his problems. That someone is me, and I want to impress him, sell him something that will truely meet his needs, and hopefully turn him from "new customer" into "repeat customer" or even "loyal customer". THAT is what is important, and getting the customer's file quickly and easily with minimal hassle is merely a tool that enables the truely important work to happen.
Not having the email for 1 hour means I'll either have to call him back in an hour, while he probably calls some competitors and shops around. Often times people will buy from the first friendly, knowledgable person who goes to some effort to help them.... searching until they find that person/company. Delaying response to a new customer by 1 hours would put me at a competitive disadvantage.
Or we'll have to proceed without it (FTP is not an option), leading to frustration as he explains material that would have been much better delivered as a file. Maybe it would go ok, maybe not. But it's starting the whole process "on the wrong foot".
Then again, if your business is being a grumpy sysadmin where you have (captive) "users" rather than "customers", maybe delaying new email conversations is a big advantage which is not offset by any impact in "responsiveness" because it's already intentionally low.
Here are answers to these "+5 Insightful" questions. Please notice that I am not the source of these answers. I'm merely going to quote from the paper that slashdot linked to:
It delays all incoming emails for a certain amount of time. Unfortunate side effect of the algorithm. Can anyone tell me what the average extra time is?
Quoting from the paper:
Initial delay of a previously unknown triplet: 1 Hour
At least you discovered that it delays incoming email... better than a lot of comments where the poster didn't read any of the paper!
I am not convinced that most of the spam comes from specialized email applications that can be fooled with a temporarily failure. Can anyone provide numbers on this?
Quoting from the paper:
Unique triplets seen: 346968
Unique triplets that passed email: 8950
Effectiveness (based on triplets): 97.4%
How does the algorithm adapt when aforementioned email applications adapt to 'greylisting'?
Quoting from the paper:
Greylisting as proposed is fairly immune to possible routes of adaptation by spammers to get around the blocking. The possible methods of adaptation may make Greylisting by itself less effective, but the ways of getting around it will only make other spamblocking methods more effective.
The normal spammer behavior is to change IP's when normal IP blacklists have listed their current IP. Unfortunately for the spammers, changing their IP does not help with our delaying method, as every mail (and it's delay) is tied to the IP address of the sending relay. If the IP address changes, it effectively "resets" the timer on the delay, even if the envelope sender and recipient addresses stay exactly the same.
[snip... read the paper (if you haven't already got that impression thus far) for discussion of relays]
I see a lot of spam that was probably produced by applications that use an automated signup to yahoo/hotmail/etc. to obtain a temporary email address and leave the actual emailing to those services which will circumvent 'greylisting'.
This actually isn't answered in the paper, because the vast majority of those emails weren't actually sent from yahoo and hotmail. The "from" says it was, but in fact those are just fraudulent names.
How much of the total internet traffic is made up of email? What happends of we all install 'greylisting' filters and each email has to be resent several times? Is doubling/tripling the amount of email traffic going to be noticable?
Quoting from the paper:
Now let's see what effect greylisting would have on network bandwidth, based on some general averages.
Average size of spam emails: 5000 bytes
Average SMTP delivery attempt overhead: 500 bytes
These numbers are based on spam collected via various methods before the testing period. We picked these as nice round numbers that are pretty closely in line with analysis of previously seen spam. As for the SMTP overhead, in most cases it was less than 500 bytes, but we decided to err on the conservative side.
From this, it follows that for every spam blocked using Greylisting, we save enough bandwidth to "pay" for 10 deferred delivery attempts. If we total that up to give a real-world number (using the unadjusted numbers to give a worst case picture):
338018 (# spams) x 5000 bytes = 1.69 Gbytes of bandwidth saved
33586 (# blocks) x 500 bytes = 16.7 Mbytes of bandwidth wasted
This gives us a net gain of over 1.67 Gbytes of traffic that was saved by implementing Greylisting in our tests. And that's just on a fairly small site.
It could be closed source, and would still fail because the basic premise is so simple - it relies on spammers sending spam to your inbox and not bothering to resend it if an error code is returned. So all a spammer has to do is just resend the message a couple of times to get around the spam 'filter'.
Quite a number of people have this misunderstanding (perhaps from reading only the first part of the paper).
All retrys are blocked for 1 hour, so the spammer must retry again from the same IP number 1 hour later... hopefully by then the ISP will have shut them down, or that IP number will be blacklisted so conventional filtering can block the retried message, or other existing anti-spam techniques can be given time to be effective at identifying it as spam.
No, simply sending the message twice does not defeat it. Retries are rejected for 1 hour (default setting). The paper specifically talks about how 1 minute will block virtually all spam today, but such a short timeout will allow spammers to defeat greylisting exactly as you have described.
Quoting from the paper:
The initial delay of 1 hour was picked for several reasons:
An hour is short enough that in most cases, users will not notice the delay.
It is long enough to give time for administrators on a possibly compromised or abused mail server to discover the problem and hopefully correct it, before any of the offending email is able to be delivered.
It is long enough to provide a good chance that if the sending host is in fact a spammer, they will be listed in other IP-based blacklists that may be used in conjunction with Greylisting, so that even if a spamming relay later attempts a redelivery that would no longer be delayed by Greylisting, it may still be blocked by other methods.
It is also long enough that other types of traffic analysis could be designed and implemented such that spamming IP's could be easily identified and blocked by other methods, in such a way that even the first recipients (before a spamming pattern starts to emerge) would still not be bothered by the spam email.
The data collected during testing showed that more than 99% of the mail that was blocked with the tested setting of 1 hour would still have been blocked with a delay setting of only 1 minute. However, it is expected that as spammers become aware of this blocking method, they will change their software to retry failed deliveries. At that point, having a larger initial delay will definitely help, as it gives time for other blocking methods to act. For this reason, it is suggested that at least a one hour delay value be kept as a default, since spammers will start adapting as soon as this method becomes known and starts being used.
Personally, I disagree with item #1. A one hour delay in first-contact email is not acceptable... at least for me.
An hour is short enough that in most cases, users will not notice the delay.
I'm wondering how I'm going to explain that to a new customer over the phone who says "I'll just email that file right now so we can go over it together".
Slashdot Mirror
Do you really believe SCO's pump-n-dump scam can last 5 years?
That wouldn't have done squat to their stock price, allowing McBride and others to cash out those sub-$1 options at over $12.
There would then be legal precedent for their claims...
Obviously that is not their concern. Think short term!
So does that mean that 2 million telemarkets are responsible for calling 60 million numbers, or does each telemarketer call just 30 numbers repetitively? Ok, maybe 50% of telemarketing jobs are overhead (seems high), giving each telemarketer who's job is in jeopardy an average target of 60 numbers?
That would explain the high volume of calls... but if a call lasts 30 seconds on average, and each employee works 8 hours (960 calls/shift), that means each of those 60 million numbers would receive an average of 16 calls each day (960 calls/day 60 calls/employee).
Hmm, 16 calls is a bit high... but many households do receive a good number of calls each day (likely 'cause they're saying "take me off your list" rather than "put me on your do not call list").
Ok, maybe it does add up and a couple million people will be looking for new jobs....
One big advantage of this approach [at.allow, at.deny in /usr/lib/cron (posix) rather than /etc (lsb)] would be for a large number of systems, that NFS mount /usr. Now, in order to update the program, or to adjust it's settings, you change one set of files, and it is automatically replicated, throught the NFS mounts.
Many environments would want to allow certain users to run jobs automatically on their machines, without globally granting them that privledge on every other machine in the company, department, university, etc.
Continuing quoting...
If the configureation was seprate, then a new version that required a change in configuration files would result in having to change the file on all the machines, or some ugly hack invloving lot's of symlinks in /etc. And hope that you never have to add a new program to /usr, or it's time to go around all the boxes manually again.
Many solutions exist for administrating /etc files, to merge a global configuration with per-machine specific settings.
Sure, as an administrator, maybe the world revolves around making your job as easy as possible. I know it's hard to think of the bigger picture, especially for some heavily overworked admins, but computers don't exist and we don't all use them to cater to the whims of admins.
Computers are tools that are used to get real work done (well, some people also play games or entertain themselves, but rarely are admins paid to support those activities).
What matters is a useful configuration that facilitates real people using their computers to do real work, which ultimately furthers the mission of the company/organization paying for the computers and system admin(s).
In this case, the LSB decision allows a read-only global NFS mount of /usr and avoids placing configuration files there that will likely need to be different amoung different machines.
That would be a first. So far, nobody's held Gartner liable for the loads of wrong advise they've issued over the years.
http://www.redhat.com/advice/speaks_rhletter2.html
I know of this page because of a recent email (that presumably went to all customers), so it's not like they just put it up in an obscure location and didn't tell anyone.
At current and near-future access speeds, searching a 20-terabyte disk might take a year.
Today's drives run about 20 to 50 Mbyte/sec from the platter. You can get 133 Mbyte/sec from the tiny buffer, of course, but for a whole-drive search, let's assume you're going to read 20 terabytes at 30 megabytes/sec. My calculator says that's 666667 seconds, or 7.7 days. Yes, a long time to wait, but 7.7 days is a long way from "might take a year". Even if you get only 10 Mbyte/sec, which is much slower than the drive's benchmark'd transfer speed but might happen with operating system and other other overhead, you're still at one month, not one year. To take an entire year reading 20 TB, you'd need to sustain only 634 kbyte/sec transfer. Hard drives haven't been that slow for a very, very long time.
I'll be Jim Gray (head of Microsoft's Bay Area Research Center) believes what we all need is to dump FAT32, NTFS (ext2, ext3, JFS, Reiser, XFS, etc) and go to whatever database oriented filesystem Microsoft is cooking up for 2005 in "longhorn"... or whatever they're naming it nowadays. The sad part is that it'll require faster CPU and hard drive to achieve the same performance of older MS system, assuming they continue the long running trend of "innovation".
But that doesn't make those wires safe to touch, does it?
Likewise to the FCC's Part 68 rules, the Underwriters Labortories does not allow manufacturers to sell products that expose you to those power lines, do they?
The key point is that those tiny, seemingly harmless little telephone wires actually run out of your building and (often times) directly into large bundles strung on telephone polls underneath high voltage power lines. It is not safe to allow consumers to come into contact with those wires. It is also not legal, which is why Sony is recalling.
The key part is that you can get a shock when the phone rings. Very bad. That means the user is exposed to a low impedance connection to the phone line, which is illegal (FCC part 68). Sure, to feel the shock you need to have a return path to earth ground... and the circumstances spelled out make it seem highly improbably.
But consider that those 2 wires from the phone line are supposed to be galvanically isolated, via a transformer, optocoupler, high-voltage low-value capacitors, or some other safe barrier. Consumers are never supposed to be exposed to those bare telephone wires, which run on telephone poles with high voltage power lines overhead.
Sure, the 50 to 100 volt ring signal can give you a bit of a shock. But the real danger is that those telephone lines are not safe if there is a failure like a tree falls onto the lines or they're hit by lightning. That's why all telephones are required by the FCC to isolate those wires from the user.
The FCC also has strict requirements that all telephone equipment fail as an open circuit (equivilant to not taking the phone off the hook), even if the lines are hit with extreemly high voltage such as 12,000 volt power lines coming into contact with the phone line momentarily.
Consider the irony that you will be complaining about how Adobe is authenticating the trustworthiness of plugins, based on misleading information in an angry rant from a very untrustworthy Russian company with a history discovering Adobe's vulnerabilities and then selling (for profit) exploit tools that exploit those vulnerabilities.
What were you going to complain about again to Adobe's senior management... oh yes, it was "their stupidity and callousness".
Naturally, you'll complain that they did release a fix in version 6 in March 2003 for the vulnerability CERT published in January 2003... which Elcom reported to CERT in September 2002, only after years of promoting selling a commercial exploit tool and ultimately having to pull it from the market based on the high profile Dmitry case.
You'll complain it was "stupid" that their fix still has a more obscure weakness (not actually mentioned in the CERT advisory), and when they don't repond you'll call them "callous".
Sounds like quite a serious stink to me.
The DMCA sucks, Adobe is unresponsive, and Dmitry shoulda been released promptly.... but regardless of all that, everybody should remember that we're dealing with a for-profit company that discovered weaknesses and first created and SOLD for-profit exploits and went on a campaign to promote it... and only reported to CERT after a legal battle that forced them to pull their commercial exploit product from the market.
They characterize a new bug (oversight in the fix, see below) as having done absolutely nothing. Not very honest...
I'm pretty impressed that slashdot didn't post the inaccurate "no improvements for 2 years" title, when it is clearly a fact (based on the text of the article) that Adobe added a new, stronger signing method in version 6, as a good-faith attempt to solve this problem. Yes, "2 years" appears to be true, but that's not the 2 years from July 2001 to July 2003 (today).
Likewise, the statement at the top: "oftware released in 2003 contains vulnerabilities disclosured in 2001" gives the impression that the new version contains the exact same vulnerability, rather than an oversight in a major rework of the security mechanism that was intended to fix the bug.
It sounds like Adobe really did try to fix the problem. They implemented a new, strong signing method. They even adandoned backwards compatibility and refuse to load the old, easily forged plugins when in certified mode. As Elcom's message explains, Acrobat 6 only allows "certified" mode if all the plugins have the new, strong signatures, or if all the plugins if finds have these signatures it automatically goes into certified mode.
The real complaint appears to be an oversight that some undocument function, which is callable in uncertified mode by an unsigned plugin (or one of the legacy weakly authenticated plugins) can call this undocumented function and cause Acrobat to switch into certified mode. Quoting from the Elcom message:
So there you have it, a secutity real announcement, burried after a lengthy rant about how slow and unresponsive Adobe has been.
Yes, Adobe has a bad attitude. Yes, they fscked up and their attempt to fix the problem still has an exploitable weakness. Ok, I can buy that Adode has a bad attitude.
Elcom (or specifically, Vladimir Katalov) doesn't impress me much either, when it comes to attitude and standards of professional conduct. This angry rant attempts to paint a picture of Adobe has having still done utterly nothing to fix this problem... including a very misleading tital and summary.
Katalov sinks to the tactic of use a embedded an advisory of a weakness to attract attention to an angry rant about his frustrations with Adobe's unresponsive history.
Leaving plenty of time for posting on slashdot!
You'd think after about 10 years of Macintosh enthusiast columnists pining for Apple's sucessor to "desktop publishing" this sort of uninspired writing would end..... but saddly this drivel is too easy to write, especially when 4th-of-july barbeque is what's really on his mind and something/anything needs to get knockout out quickly to meet a publish deadline.
In the kernel, perhaps...
But give Mozilla a try for bloat. Or launch a gnome-terminal and time how long the first one takes to come up... or worse yet type "ls -l /usr/bin" and see how slowly all those pretty anti-aliased fonts take to scroll.
There's plenty of bloat to go around.
And how do you "get support" for a Microsoft system, even if you have paid full price?
Oh, I'm sure you just call that toll-free number printed on the cdrom and they just help you out at no extra charge, don't they?
There are approximately 40 million websites on the internet. Maybe a billion individual pages, but not nearly that many sites.
No. If it's widely deployed and if spammers adapt, in six months spammers will be forced to maintain the same IP number for 1 hour to get messages delivered (very difficult for the ones who compromise hosts) AND not have that IP number end up in blacklists during that 1 hour AND not have newer spam-pattern detection filters identify that IP number as spewing spam AND not have message digest filters (vipul's razor) list a fuzzy match of whatever they're bulk transmitting within that hour.
All first-contact email conversations will be delayed by 1 hour and that really sucks. But spammers will be hurt, because 1 hour is a very long time in the anti-spam detection world and many conventional filtering techniques will be able to recognize the second attempt an hour later for the spam it is.
Even if FTP were a solution, it does nothing to answer a new customer who says "I just heard about you and I'm excited about your products. Wanted to call and ask you some questions. I sent an email about 10 minutes ago with an outline of the project we're doing were you guys could really help out, have you had a chance to look it over yet".
There's a limitless number of these important common customer relationship scenarios, where the expectation of all parties involved is that email is delivered in under 1 minute and typically 5-10 seconds. And there are an infinite number of scenarios other than sales and customer service/relations where people quite reasonably expect email to be delivered in seconds.
Focusing on using FTP isn't just the wrong answer, it's not even an answer at all to the problem of email delivery taking an order of magnitude longer than users expect and depend upon.
But as others have pointed out, most users don't have access to FTP servers to receive files. Most corporate firewalls would prohibit users from setting up a FTP server. I would guess that almost any employee behind a corporate firewall wanting to somehow receive a file from a new customer via FTP who attempted to ask a sysadmin would get the answer "just have them send it as an attachment". FTP is simply not a viable protocol for customers and salespeople (or most others) to use to pass files back and forth.
Aside from not solving the unacceptable delay and the inappropriateness of using FTP, there is the problem of bad attitude. Specifically:
Where did "new customer" turn into "user". The word "user" in this context is often spoken in the tone of an overworked, grumpy sysadmin who's personal view of his priorities are decoupled from the larger organization's mission (usually taking care of customers, selling products, operating efficiently, and so on).
In this particular example, what is important is that the new customer whats to talk with someone about solving his problems. That someone is me, and I want to impress him, sell him something that will truely meet his needs, and hopefully turn him from "new customer" into "repeat customer" or even "loyal customer". THAT is what is important, and getting the customer's file quickly and easily with minimal hassle is merely a tool that enables the truely important work to happen.
Not having the email for 1 hour means I'll either have to call him back in an hour, while he probably calls some competitors and shops around. Often times people will buy from the first friendly, knowledgable person who goes to some effort to help them.... searching until they find that person/company. Delaying response to a new customer by 1 hours would put me at a competitive disadvantage.
Or we'll have to proceed without it (FTP is not an option), leading to frustration as he explains material that would have been much better delivered as a file. Maybe it would go ok, maybe not. But it's starting the whole process "on the wrong foot".
Then again, if your business is being a grumpy sysadmin where you have (captive) "users" rather than "customers", maybe delaying new email conversations is a big advantage which is not offset by any impact in "responsiveness" because it's already intentionally low.
Here are answers to these "+5 Insightful" questions. Please notice that I am not the source of these answers. I'm merely going to quote from the paper that slashdot linked to:
It delays all incoming emails for a certain amount of time. Unfortunate side effect of the algorithm. Can anyone tell me what the average extra time is?
Quoting from the paper:
At least you discovered that it delays incoming email... better than a lot of comments where the poster didn't read any of the paper!
I am not convinced that most of the spam comes from specialized email applications that can be fooled with a temporarily failure. Can anyone provide numbers on this?
Quoting from the paper:
How does the algorithm adapt when aforementioned email applications adapt to 'greylisting'?
Quoting from the paper:
I see a lot of spam that was probably produced by applications that use an automated signup to yahoo/hotmail/etc. to obtain a temporary email address and leave the actual emailing to those services which will circumvent 'greylisting'.
This actually isn't answered in the paper, because the vast majority of those emails weren't actually sent from yahoo and hotmail. The "from" says it was, but in fact those are just fraudulent names.
How much of the total internet traffic is made up of email? What happends of we all install 'greylisting' filters and each email has to be resent several times? Is doubling/tripling the amount of email traffic going to be noticable?
Quoting from the paper:
It could be closed source, and would still fail because the basic premise is so simple - it relies on spammers sending spam to your inbox and not bothering to resend it if an error code is returned. So all a spammer has to do is just resend the message a couple of times to get around the spam 'filter'.
Quite a number of people have this misunderstanding (perhaps from reading only the first part of the paper).
All retrys are blocked for 1 hour, so the spammer must retry again from the same IP number 1 hour later... hopefully by then the ISP will have shut them down, or that IP number will be blacklisted so conventional filtering can block the retried message, or other existing anti-spam techniques can be given time to be effective at identifying it as spam.
Quoting from the paper:
Personally, I disagree with item #1. A one hour delay in first-contact email is not acceptable... at least for me.
I'm wondering how I'm going to explain that to a new customer over the phone who says "I'll just email that file right now so we can go over it together".