I believe what you are proposing is similar to something called "MTA mark" or something like that.
SPF, DomainKeys, and "MTA mark" are more sophisticated versions of today's distributed (usually via DNS) blocklists.
As such, they have similar advantages and disadvantages. They are not "solutions" to spam; they do represent steps in the general direction of requiring some combination of authentication and a reputation-management system.
Authentication in your proposal is fundamentally based on IP addresses and domain names. In some ways that's reasonably strong (compared to most forms of analysis of the content of the email or the behavior of the SMTP client, anyway). Weaknesses on the IP-address side include the store-and-forward nature of SMTP (how do you handle an intermediate MTA innocently relaying an evil payload -- can you trust the MTA's claim regarding the IP address from which it received the message?) and NAT (put simply, having many potential SMTP clients on the same IP address). IPv6 probably makes some of this worse, in that the address space becomes vastly larger.
Weaknesses on the domain-name side of things include the practically infinite search space which, combined with the "trustable-parent?" problem (can you trust the entity that delegated the domain name to its owner? how about that entity's delegatee?), presents a significant whack-a-mole problem.
General weaknesses include the fact that all of these systems rely on a reliable distributed third-party data base (usually DNS). When that data base is corrupted or unavailable, the system breaks down.
And since that data base is presently implemented such that it cannot guarantee low fixed-time lookups to all its readers, any system that automatically consults it using keys provided by an untrusted source is prone to exploitation as a means to attack the data base, possibly in order to dDOS the data base itself.
In the short term, as any of these solutions (IP blacklists; SPF, which can be used to blacklist based on envelope senders; DomainKeys, which can be used to blacklist source domains; and MTAmark, which can be used to blacklist MTAs) are implemented, they appear to work fairly well in detecting a substantial percentage of unwanted email -- or, more precisely, email that is "known" to be from an untrusted (or "broken") source or perhaps known to have been transmitted via an untrusted third party, which is orthagonal to whether the content of the email is "unwanted". (My server sends plenty of "wanted" email to sites that reject it as "untrusted" because it uses a "dynamic IP" address -- which hasn't changed in well over a year, though it is always possible it might someday be reassigned to some 0wn3d Win98 box.)
However, as spammers adapt (and they can easily do so, given their incentive and financing), all of these measures are ultimately worked around and attacked.
Therefore, in each case, the rest of us end up expending substantial resources designing and adapting to the "solution" (including adapting to the fact that our own legit outgoing email is falsely tagged as "spam" thanks to these "solutions"), only to find that it wasn't worthwhile in the long run.
In particular, once the "solution" has had the #!@#%@ kicked out of it by spammers and virus authors, not only is it no longer of much use, but we are stuck with maintaining it for many years after its deployment.
There are better ways, or at least ways that rely much less on external, trustable entities such as data bases. But they are much less "impressive", and have their own disadvantages.
power-hungry people get involved twist the religion for their own purposes.
True, even if you replace "religion" with "government", "corporation", "charity", "FOSS project", etc.!
I no longer believe it's the "religion" part of "organized religion" that's the problem.
It's the "organized" aspect of things.
Human nature seems to be ripe for exploitation by others, and any form of organization offers much more opportunity for such exploitation than does reliance on individual initiative.
(I guess that's not too surprising when one considers the most "sacred" form of human organization -- marriage -- and the problems it has presented over the millenia.)
What's cool, to me, about Linux and other FOSS projects is that the low barrier to entry is accompanied by a low barrier to exit, making it difficult for "power-hungry people" to long succeed at twisting such projects to their own purposes.
And Linus, for the most part, continues to "run" Linux in ways that suggest, to me as a fairly "distant" observer anyway, that he is aware of many of the pitfalls, as well as the advantages, of organized FOSS development.
I believe I've said this before, but I do wish I'd had his example to work from back when I started work on my own FOSS project. I took the "cathedral" approach instead, which wasn't surprising given my more-corporate background, and it didn't work out as well as I now think it could have (though at least I did finally "ship" something that sorta kinda worked).
Interestingly, Mary Baker Eddy wrote, over 100 years ago, "Organization and time have nothing to do with Life", and she uses "Life" (capitalized) as a synonym for "God".
Having been raised a Christian Scientist (the religion Eddy "discovered" and "founded"), I often found myself wondering what in the world she meant by that...it makes more sense to me now.
I bathed a cat[...]and have the scars to support it.
I've never understood this problem people have with bathing cats, "scars", and what-not.
When I was a kid, we had a lot of cats at our farm house. One of my "chores" was to clean the cats (which was easier than taking care of the horses; that was my sister's job).
Most of the time, bathing a cat was actually fairly pleasant. I enjoyed it; the cat seemed to enjoy it.
Only problem was the fur would stick to my tongue.
Other than that, it wasn't bad work, and it prepared me in several important ways for real life.
costs up to ten times as much to fix an error by the time it hits the market as it would to catch it during the design.
I don't disagree that it *would be nice* to catch all the bugs before launch but saying that it is cheaper is a false start. Delaying time to market is also extremely expensive in the face of competitors.
I think you're both right.
It is definitely less expensive to ship software without a bug than to ship it with that bug, deal with bug reports from the field, diagnose the bug, fix the bug, risk regressions, and send out patches or new versions.
For highly buggy software, then, the question becomes, what percentage of actual bugs (in shipped software) will actually go through that cycle?
Let's assume 10% of the actual bugs result in user complaints. Right there, that means the extra expense dealing with incoming bug reports would have to be at least 10 times what it would have cost to not ship the bug in the first place for the extra attention to correctness to pay off.
Then, of user complaints, only a certain percentage of bug reports are actually investigated. (Usually, they're prioritized, and the highest-priority ones get investigated first; so, lower-priority bugs might never even be investigated during the product's lifecycle.)
Investigation costs more, but, typically, a lower percentage of overall bugs will be investigated than will be reported.
Repeat this analysis for fixing bugs (which includes providing workarounds, such as "don't use this feature anymore" warnings in documentation) and shipping new software...
...and you end up with the cost-benefit model for Microsoft and its ilk, as well as most FOSS (including Linux, GCC, Emacs) and its ilk.
That is, with most of that software, the actual bug count is assumed to be too high to ever have to worry that all those bugs will come home to roost during the product's lifecycle.
There are exceptions, such as djb's software, including qmail, which (compared to other MTAs) has few features out of the box but has been nearly bug-free (and rock-solid in terms of security) since the 1.03 release many years ago.
But qmail actually highlights the problem: to get almost any feature most Internet sites need for an MTA, third-party patches have to be applied, leading, in many cases, to bugs, even security holes.
IMO the best approach is to decide, for a given product, what sorts of bugs are acceptable and what aren't. For an MTA or anything open to the outside world and especially running as "root", the djb approach of making security a #1 concern seems best, so choose a design that makes it hard for security flaws to exist, especially to propagate among components.
For any software in which a human being composes something online -- this would include text processors, word processors, drawing and painting programs, audio manipulation and music composition programs -- IMO the #1 priority is to NEVER LOSE THE USER'S DATA.
So the language chosen, the coding style, etc. should all be designed to allow the program to crash anytime without losing more than, say, the preceding 1 second of user input, and, ideally, saving (journaling) the user's work in an industry-standard form so the user always has the option of switching over to another product to complete the work.
For a compiler, IMO the #1 priority is to NEVER GENERATE BAD CODE.
Here, the cost of bugs that generate bad code is extremely high. So the design should make it hard for coding errors within the compiler to lead to incorrect code being generated -- better for the compiler to crash and burn than for it to add even more bugs to a program it's generating.
In all these cases, there are eminently practical ways to architect, design, and implement programs accord
I once had to fix a system with a broken/dev/null. I was rather perplexed as to how somebody broke it.
I once broke/dev/null on a whole bunch of machines all over the Internet.
Did it by adding a feature to GNU Fortran 77 (g77), such that when you did "g77 -v" to get version info, it printed info for the libg77 (aka libf2c) libraries as well, by linking up a dummy program via "ld -v -o/dev/null..." or similar.
Turned out, GNU ld (maybe others) first unlink()'s the executable before creating the new one, rather than just opening it for writing.
So, if you did "g77 -v" while root, viola, you ended up with a non-null/dev/null.
Took a little while for people to notice what was happening. Can't recall offhand who noticed first -- me (since I usually did everything as root back then;-) or someone else! But I'm pretty sure I did a release of g77 with that bug, probably during its "alpha test" period.
[...] constant threat of being accused of being unpatriotic if you question the Bush administration.
I keep reading and hearing such complaints, but have little or no experience with any legitimate examples.
Personally, I've criticized the Bush administration's handling of many issues since not long after his inauguration. I've done this mostly verbally, among social contacts, not online. But I've never been accused of being "unpatriotic" as a result.
On the other hand, I've been repeatedly accused of being "inhumane", "uncompassionate", "mentally deficient", and similar by friends and the media simply because I lean and/or vote Republican and/or Libertarian.
(E.g. I recall the Christian Science Monitor editorializing, shortly after the 1994 Congressional elections that brought the Republicans into power, that voters had "turned their backs on the homeless and the poor" or some such thing. This from a paper whose motto includes the notion "to injure no man".)
It gets pretty annoying to have to listen to people like Barbra Streisand complain about how "repressive" whatever Republican regime is in power has been (or was), claiming they're somehow preventing true "art" being made or published, while also having to deal with being associated with a drive to (echoing the words of Democratic candidates and their spokespeople) "put granny out of her home", "keep blacks from voting", "starve children", or whatever vile nonsense the left spouts from moment to moment.
I learned long ago to listen critically to the media from a variety of angles. Yes, I can identify presumptive right-wing bias from Rush Limbaugh, Sean Hannity, and Fox News. But the presumptive left-wing bias (relative to US politics and its sociopolitical center, of course) of most of the media is blatantly obvious and much more insidious, in my opinion. (And, yes, I think things have improved a lot lately.)
So, please, do yourself a favor, suck it up, and deal with the fact that "unpatriotic" is a much more subjective and less personal term to have thrown at you than what anyone not slavishly parroting the left-wing party line regularly gets thrown at them.
I think you mean Sun RPC, as there are several other RPC systems floating around
I assume y'all are talking about RPC on Unix (and workalike systems), correct?
Because, if you mean the general concept of RPC, PRIMOS had it as early as 1981 or so (I wrote code using it around that time) and I'm pretty sure Pr1me just lifted the concept from Multics.
(No, I never particularly cared for it myself.)
PRIMOS also had transparent remote file access a la NFS, though I think it was more truly transparent than NFS, as early as 1979, maybe even earlier, though they transitioned the implementation of their remote file access to use RPC around 1981 or 1982, IIRC.
impuning one "McBride" with another's bad reputation is something of an ethnic slur
So true. I remember Monica Lewinsky's father complaining about how his name became associated with a certain act because of his daughter's interactions with then-President Clinton in the Oval Office.
In fact, I believe his exact words were:
Republican attack dogs are using my surname to defame my entire family. Why, it's McCarthyism at its worst!
An extreme majority of message boxes are dismissed within 1 second
That's because such boxes present themselves as "here's what you have to click [usually OK] to continue getting useful work done", and too many times they're presented more for the convenience of the software designers, authors, etc. than based on the actual needs of the end users.
So, users come to believe that they're more productive when they treat such message boxes as interruptions to be dismissed ASAP.
It's not unlike the "chicken little" or "boy who cried wolf" syndromes.
If I ever design a UI, every time I'm tempted to throw up a message box for the end user to deal with, I promise myself I'll instead ask "exactly why does my software need to know the answer to that question right at that moment? can the decision be deferred? can the information be presented in a less intrusive way?".
And if the answers are "no, no, and no", then I'll try to design the message box so the responses required of the user reflect the implicit requirement that the user actually reads and understands what's going on.
That hardly ever would mean having the user just click OK or CANCEL or PROCEED.
You're essentially arguing in favor of additional gratuitous points of failure by claiming there's little or no reason for well-connected end users of ISPs to run their own mailservers.
From a reliability point of view, I believe the opposite is true: that it's actually better for end users to exchange mail messages (and other higher-level communications) directly, on an end-to-end basis, with as little interference from, and dependency on, intermediaries, beyond their use as necessary low-level transport agents.
After all, those intermediaries are, like any component in a well-engineered system, better designed and used for a small number of tasks -- in the case of upstream ISPs, interconnecting portions of the Internet and transferring packets among them should be their main focus, not running mail servers, HTTP proxies, and so on.
Practically speaking, yes, I can have my domain registrar do email forwarding for me. But you know what? They have an email size limit that is substantially lower than the occasional legitimate email I send or receive.
And why shouldn't they have such a limit, since they're in the business of registering domain names, not serving as an email forwarder, which is just a convenient add-on service?
And, yes, I can sign my outgoing emails with GPG, so while they're sitting on my upstream ISP's server, they can't be read...but that does nothing for my incoming email, and if you think it's just as easy for an corrupt employee at an ISP to scan packets in transit to port 25 on my system as it is for her to start the 3rd shift by searching all pending emails on the server for any destined for my system, I'd like to know why you don't go into the spammer-catching business, since it has some of the very same problems.
The fact that you ask if the OP heard of fetchmail illustrates the problem regarding multiple points of failure. fetchmail has had its share of bugs, so why require its use for a large class of users that would otherwise not need it to get useful work done?
I use fetchmail to pull mail down from my upstream ISP, which gives me essentially no opportunity to reject (or especially tarpit) known spam or sources of spam as the spam is injected into "my" mailbox (in the extended sense of including my upstream POP3 mailbox), meaning that, with fetchmail, I have to wait for a 10MB message that ends up being detected as spam by my local software to be downloaded before I get the 2K legitimate message I really need.
Whereas, with direct injection into my system (which is what happens for my four "vanity" domain names), those two hypothetical messages are handled asynchronously, as designed by the SMTP protocol, and possibly even while I'm doing something else, so I don't have to wait for fetchmail to run. (Or I can have fetchmail run automatically every minute or so, which adds a whole 'nother set of problems, among them performance problems. Sometimes my fetchmail runs have simply not worked because my old dialup ISP's POP3 server was having problems -- thank goodness most of my important email comes directly into my system!)
And, yes, it's nice if your upstream ISP is nearly 100% reliable, but, again, you clearly cannot have TCP+SMTP reliability exceed that of TCP-only reliability for a given upstream ISP.
Depend on your ISP to store-and-forward your outgoing and incoming email as well as push packets around, and you're guaranteed to lose a bit of reliability right there.
And, unless you've got another "path" to your ISP and its mail server than your home computer, it really doesn't matter much that its reliability exceeds that of your computer, does it?
I mean, other than the convenience of having all pending emails already on your ISP's mail server when your power and/or local network comes back up, either way, you can't send or receive email while your home computer is down.
There are definite advantages to letting your upstream ISP handle your mail service -- I'm not arguing
my point was that people on slashdot aren't looking for anything that isn't going to go there way.
Never underestimate your opponent.
Wise advice generally, but I take issue (as a member of "people on slashdot") with your first statement, and suggest that's where you're running into trouble with others here.
There's a fundamental difference between underestimating an opponent and estimating that an opponent is much weaker.
Consider a football game that's coming up. If you just watch the pep rally, the cheerleaders, and so on, on one side, you might come to the conclusion that that side'll win, for all the enthusiasm they display.
But they might have little or no knowledge of the actual opponent -- the football team that they, themselves, aren't going to play.
In that case, they might be underestimating the opponent. Not necessarily -- they're really just cheerleading -- but they might be.
Where true underestimation happens, in terms of being pertinent, is among the coaching staff and team members themselves. If they underestimate their opponent, they might well do a poor job of preparing themselves mentally, physically, and spiritually for the game.
As a result, they might lose.
But there are no such "pertinent people" here on slashdot. The top corporate officers at SCO and IBM, the lawyers conducting the case, and the handful of relevant others are, basically, not contributing to, and probably only rarely reading, discussions of the case on slashdot.
So here's where the reality differs tremendously from your analysis in my hypothetical example: a coaching staff and team members might be properly estimating an opponent's capabilities, based on thorough research.
As a result of that estimation and study, they might well conclude that they have a very high probability of beating that opponent -- possibly shortly after the coin toss, especially if they discover the opposing team's coach doesn't seem to understand the concept of "toin coss", suggesting he has a poor grasp of the rules of the game his team's about to play.
Having reported that information to friends and confidants, it inevitably leaks out to the team cheerleaders, supporters, and assorted other hangers-on, and general pre-victory celebration results.
Again, if you show up just in time to view that celebration, you might be tempted to say "wow, they're underestimating their opponents".
But you'd be basing that on your own underestimation of the thoroughness and accuracy of the analysis already performed.
(A more reasonable analysis might, in that case, be "wow, they're underestimating the ability of the opponents to buy off the officials for the game", but that doesn't seem to be what you're saying here.)
Yes, in worthwhile mythologies and stories of all sorts, the hare gets overconfident as a result of reasonable pre-contest analysis, goofs off, and the turtle wins. It's a good reminder. Do you have any evidence that the IBM/Linux/GPL coaching staff and team members -- as distinct from its cheerleaders on/. -- are behaving like the hare?
I've seen plenty of personal and corporate arrogance cause the "strong" to lose to the "weak", but I've also seen plenty of situations where a noisy, chest-thumping, weakling foolishly takes on a quiet, serious, but incredibly strong opponent, with little or no understanding of that opponent's strengths or resolve.
The results are rarely pretty, but they are instructive.
And, in this case, when it comes to the coaching staff and team members, in my estimation, it is SCO who is doing the chest-thumping, making the noise, egging on its cheerleaders, while the IBM/Linux/GPL side is, largely, observing, preparing, assessing, and behaving, frankly, as if it has little or no concern whatsoever beyond curiousity as to exactly w
MS is indeed proposing to artificially induce inefficiency
Most worthwhile anti-spam/anti-vermin solutions have to introduce inefficiency. MS is hardly doing anything new in that sense -- looks like they've just got a particularly interesting approach for it.
Introducing inefficiency in SMTP is a specific form of the more general need to incorporate inefficiency in any exchange that has long-term consequences, in terms of resource usage or other commitments, for one of the parties to the exchange.
(Consider how inefficient procreation is, especially how it becomes more "artificially inefficient" over a progression from simple, low-level organisms such as amoeba up through highly complex organisms such as mammals, primates, and so on. The inefficiency is artificial in the sense that, in all cases, all it really takes, at most, is for a single cell from a male to contact a single cell from a female; yet all sorts of mechanisms exist, in both creatures -- especially the females of most species -- to make such contact highly unlikely.)
At present, SMTP servers (which represent the "female" side of the equation, in that they accept incoming payloads and must expend potentially substantial resources to hold them, deliver them, or bounce them back to the supposed sender) expend a much larger portion of the resources needed to deliver a particular email than do SMTP clients. (SMTP relays are servers when they receive an email, clients when they forward it, in case you were wondering.)
For example, a typical lightweight SMTP client need only have enough resources to discover the IP address for the destination email addresses' hostname; to open a connection to the SMTP server at that address; to transmit the few commands necessary to deliver the email; and to close the connection.
Spamware typically goes super-minimal, in that it doesn't bother checking return codes, doesn't queue the email in case of failure (as a "proper" SMTP client might), and so on.
SMTP servers, "improved" to cope with the resulting deluge of resource-intensive emails (most of which might be spam and/or vermin), typically expend even more resources than strictly necessary to store, then forward and/or deliver or bounce, an email.
For examples, they might pass an email through one or more filters (Bayesian); do reverse DNS lookups on incoming connections to discover "real" host names; do one or more DNS lookups on RBL sites to discover whether the source is a known or likely spammer/vermin source; consult local data bases to determine whether the envelope sender and/or recipient fit various profiles (Challenge-Response systems have to do this); and so on.
So, in order to accept an incoming email, which requires going through some kind of decision process, an SMTP server's costs include the inherent costs of processing email plus the costs of that decision process.
But most of those costs are never seen, or experienced as minor inconveniences (e.g. short delays, disconnections, outright rejections), by SMTP clients.
And as long as illegitimate SMTP clients are given this "free ride", they have the advantage.
So pretty much any worthwhile anti-spam/anti-vermin proposal must shift the burden of resource utilization from SMTP servers to SMTP clients, somehow.
Some proposals do this in ways inherent to the transmission mechanism. E.g. Dan Bernstein's im2000 proposal requires clients to store message bodies themselves, leaving servers to deal only with accepting the "envelopes" for messages, forwarding them along, then relying on sufficiently fast and reliable network connections to support dynamically retrieving the message bodies when the user finally decides to look at the content of a particular message. (This is a very simple summary of the "default" mode for sending message in im2000.)
While we're dealing with SMTP, though, which requires message bodies to be transmitted along with message envelopes, it
Slashdot Mirror
Hmm -- tempting, but, no thanks. No evidence of privacy policy, no information on what makes the platform "spam, spoof, and phish free", and so on.
Just not clear enough what it is all about. Sorry!
SPF, DomainKeys, and "MTA mark" are more sophisticated versions of today's distributed (usually via DNS) blocklists.
As such, they have similar advantages and disadvantages. They are not "solutions" to spam; they do represent steps in the general direction of requiring some combination of authentication and a reputation-management system.
Authentication in your proposal is fundamentally based on IP addresses and domain names. In some ways that's reasonably strong (compared to most forms of analysis of the content of the email or the behavior of the SMTP client, anyway). Weaknesses on the IP-address side include the store-and-forward nature of SMTP (how do you handle an intermediate MTA innocently relaying an evil payload -- can you trust the MTA's claim regarding the IP address from which it received the message?) and NAT (put simply, having many potential SMTP clients on the same IP address). IPv6 probably makes some of this worse, in that the address space becomes vastly larger.
Weaknesses on the domain-name side of things include the practically infinite search space which, combined with the "trustable-parent?" problem (can you trust the entity that delegated the domain name to its owner? how about that entity's delegatee?), presents a significant whack-a-mole problem.
General weaknesses include the fact that all of these systems rely on a reliable distributed third-party data base (usually DNS). When that data base is corrupted or unavailable, the system breaks down.
And since that data base is presently implemented such that it cannot guarantee low fixed-time lookups to all its readers, any system that automatically consults it using keys provided by an untrusted source is prone to exploitation as a means to attack the data base, possibly in order to dDOS the data base itself.
In the short term, as any of these solutions (IP blacklists; SPF, which can be used to blacklist based on envelope senders; DomainKeys, which can be used to blacklist source domains; and MTAmark, which can be used to blacklist MTAs) are implemented, they appear to work fairly well in detecting a substantial percentage of unwanted email -- or, more precisely, email that is "known" to be from an untrusted (or "broken") source or perhaps known to have been transmitted via an untrusted third party, which is orthagonal to whether the content of the email is "unwanted". (My server sends plenty of "wanted" email to sites that reject it as "untrusted" because it uses a "dynamic IP" address -- which hasn't changed in well over a year, though it is always possible it might someday be reassigned to some 0wn3d Win98 box.)
However, as spammers adapt (and they can easily do so, given their incentive and financing), all of these measures are ultimately worked around and attacked.
Therefore, in each case, the rest of us end up expending substantial resources designing and adapting to the "solution" (including adapting to the fact that our own legit outgoing email is falsely tagged as "spam" thanks to these "solutions"), only to find that it wasn't worthwhile in the long run.
In particular, once the "solution" has had the #!@#%@ kicked out of it by spammers and virus authors, not only is it no longer of much use, but we are stuck with maintaining it for many years after its deployment.
There are better ways, or at least ways that rely much less on external, trustable entities such as data bases. But they are much less "impressive", and have their own disadvantages.
If there was a big fence to be built around Texas, I might decide to move back!
True, even if you replace "religion" with "government", "corporation", "charity", "FOSS project", etc.!
I no longer believe it's the "religion" part of "organized religion" that's the problem.
It's the "organized" aspect of things.
Human nature seems to be ripe for exploitation by others, and any form of organization offers much more opportunity for such exploitation than does reliance on individual initiative.
(I guess that's not too surprising when one considers the most "sacred" form of human organization -- marriage -- and the problems it has presented over the millenia.)
What's cool, to me, about Linux and other FOSS projects is that the low barrier to entry is accompanied by a low barrier to exit, making it difficult for "power-hungry people" to long succeed at twisting such projects to their own purposes.
And Linus, for the most part, continues to "run" Linux in ways that suggest, to me as a fairly "distant" observer anyway, that he is aware of many of the pitfalls, as well as the advantages, of organized FOSS development.
I believe I've said this before, but I do wish I'd had his example to work from back when I started work on my own FOSS project. I took the "cathedral" approach instead, which wasn't surprising given my more-corporate background, and it didn't work out as well as I now think it could have (though at least I did finally "ship" something that sorta kinda worked).
Interestingly, Mary Baker Eddy wrote, over 100 years ago, "Organization and time have nothing to do with Life", and she uses "Life" (capitalized) as a synonym for "God".
Having been raised a Christian Scientist (the religion Eddy "discovered" and "founded"), I often found myself wondering what in the world she meant by that...it makes more sense to me now.
I've never understood this problem people have with bathing cats, "scars", and what-not.
When I was a kid, we had a lot of cats at our farm house. One of my "chores" was to clean the cats (which was easier than taking care of the horses; that was my sister's job).
Most of the time, bathing a cat was actually fairly pleasant. I enjoyed it; the cat seemed to enjoy it.
Only problem was the fur would stick to my tongue.
Other than that, it wasn't bad work, and it prepared me in several important ways for real life.
Shout-out to Steve Martin! ;-)
Is that you, Bill?!
And that's why computing now sounds harsh and brittle, instead of warm and smooth like it used to.
How about Mike Wallace, Morely Safer, and Andy Rooney...wearing hats!!.
People who believe in karma get what they deserve.
I think you're both right.
It is definitely less expensive to ship software without a bug than to ship it with that bug, deal with bug reports from the field, diagnose the bug, fix the bug, risk regressions, and send out patches or new versions.
For highly buggy software, then, the question becomes, what percentage of actual bugs (in shipped software) will actually go through that cycle?
Let's assume 10% of the actual bugs result in user complaints. Right there, that means the extra expense dealing with incoming bug reports would have to be at least 10 times what it would have cost to not ship the bug in the first place for the extra attention to correctness to pay off.
Then, of user complaints, only a certain percentage of bug reports are actually investigated. (Usually, they're prioritized, and the highest-priority ones get investigated first; so, lower-priority bugs might never even be investigated during the product's lifecycle.)
Investigation costs more, but, typically, a lower percentage of overall bugs will be investigated than will be reported.
Repeat this analysis for fixing bugs (which includes providing workarounds, such as "don't use this feature anymore" warnings in documentation) and shipping new software...
That is, with most of that software, the actual bug count is assumed to be too high to ever have to worry that all those bugs will come home to roost during the product's lifecycle.
There are exceptions, such as djb's software, including qmail, which (compared to other MTAs) has few features out of the box but has been nearly bug-free (and rock-solid in terms of security) since the 1.03 release many years ago.
But qmail actually highlights the problem: to get almost any feature most Internet sites need for an MTA, third-party patches have to be applied, leading, in many cases, to bugs, even security holes.
IMO the best approach is to decide, for a given product, what sorts of bugs are acceptable and what aren't. For an MTA or anything open to the outside world and especially running as "root", the djb approach of making security a #1 concern seems best, so choose a design that makes it hard for security flaws to exist, especially to propagate among components.
For any software in which a human being composes something online -- this would include text processors, word processors, drawing and painting programs, audio manipulation and music composition programs -- IMO the #1 priority is to NEVER LOSE THE USER'S DATA.
So the language chosen, the coding style, etc. should all be designed to allow the program to crash anytime without losing more than, say, the preceding 1 second of user input, and, ideally, saving (journaling) the user's work in an industry-standard form so the user always has the option of switching over to another product to complete the work.
For a compiler, IMO the #1 priority is to NEVER GENERATE BAD CODE.
Here, the cost of bugs that generate bad code is extremely high. So the design should make it hard for coding errors within the compiler to lead to incorrect code being generated -- better for the compiler to crash and burn than for it to add even more bugs to a program it's generating.
In all these cases, there are eminently practical ways to architect, design, and implement programs accord
But the proof adds 1 to the product of all known primes.
E.g. 2 * 3 + 1 => 7, which is a prime.
2 * 3 * 5 + 1 => 31, which is a prime.
2 * 3 * 5 * 7 + 1 => 211, which is either a prime or a product of primes larger than 7.
And so on.
I once broke /dev/null on a whole bunch of machines all over the Internet.
Did it by adding a feature to GNU Fortran 77 (g77), such that when you did "g77 -v" to get version info, it printed info for the libg77 (aka libf2c) libraries as well, by linking up a dummy program via "ld -v -o /dev/null ..." or similar.
Turned out, GNU ld (maybe others) first unlink()'s the executable before creating the new one, rather than just opening it for writing.
So, if you did "g77 -v" while root, viola, you ended up with a non-null /dev/null.
Took a little while for people to notice what was happening. Can't recall offhand who noticed first -- me (since I usually did everything as root back then ;-) or someone else! But I'm pretty sure I did a release of g77 with that bug, probably during its "alpha test" period.
A hole is someone you want to a void, but not the other way a round.
"congugation"? Do you, by any chance, work for cingular?
I keep reading and hearing such complaints, but have little or no experience with any legitimate examples.
Personally, I've criticized the Bush administration's handling of many issues since not long after his inauguration. I've done this mostly verbally, among social contacts, not online. But I've never been accused of being "unpatriotic" as a result.
On the other hand, I've been repeatedly accused of being "inhumane", "uncompassionate", "mentally deficient", and similar by friends and the media simply because I lean and/or vote Republican and/or Libertarian.
(E.g. I recall the Christian Science Monitor editorializing, shortly after the 1994 Congressional elections that brought the Republicans into power, that voters had "turned their backs on the homeless and the poor" or some such thing. This from a paper whose motto includes the notion "to injure no man".)
It gets pretty annoying to have to listen to people like Barbra Streisand complain about how "repressive" whatever Republican regime is in power has been (or was), claiming they're somehow preventing true "art" being made or published, while also having to deal with being associated with a drive to (echoing the words of Democratic candidates and their spokespeople) "put granny out of her home", "keep blacks from voting", "starve children", or whatever vile nonsense the left spouts from moment to moment.
I learned long ago to listen critically to the media from a variety of angles. Yes, I can identify presumptive right-wing bias from Rush Limbaugh, Sean Hannity, and Fox News. But the presumptive left-wing bias (relative to US politics and its sociopolitical center, of course) of most of the media is blatantly obvious and much more insidious, in my opinion. (And, yes, I think things have improved a lot lately.)
So, please, do yourself a favor, suck it up, and deal with the fact that "unpatriotic" is a much more subjective and less personal term to have thrown at you than what anyone not slavishly parroting the left-wing party line regularly gets thrown at them.
I assume y'all are talking about RPC on Unix (and workalike systems), correct?
Because, if you mean the general concept of RPC, PRIMOS had it as early as 1981 or so (I wrote code using it around that time) and I'm pretty sure Pr1me just lifted the concept from Multics.
(No, I never particularly cared for it myself.)
PRIMOS also had transparent remote file access a la NFS, though I think it was more truly transparent than NFS, as early as 1979, maybe even earlier, though they transitioned the implementation of their remote file access to use RPC around 1981 or 1982, IIRC.
That's nice of you, but when I first read this, I thought you'd said "I donated a little monkey earlier today".
No wonder she's too busy to turn on moderation!
What's your point?
Can you explain why to me? Maybe there's a cultural reference I'm missing; to me, it's just kinda funny.
So true. I remember Monica Lewinsky's father complaining about how his name became associated with a certain act because of his daughter's interactions with then-President Clinton in the Oval Office.
In fact, I believe his exact words were:
That's because such boxes present themselves as "here's what you have to click [usually OK] to continue getting useful work done", and too many times they're presented more for the convenience of the software designers, authors, etc. than based on the actual needs of the end users.
So, users come to believe that they're more productive when they treat such message boxes as interruptions to be dismissed ASAP.
It's not unlike the "chicken little" or "boy who cried wolf" syndromes.
If I ever design a UI, every time I'm tempted to throw up a message box for the end user to deal with, I promise myself I'll instead ask "exactly why does my software need to know the answer to that question right at that moment? can the decision be deferred? can the information be presented in a less intrusive way?".
And if the answers are "no, no, and no", then I'll try to design the message box so the responses required of the user reflect the implicit requirement that the user actually reads and understands what's going on.
That hardly ever would mean having the user just click OK or CANCEL or PROCEED.
From a reliability point of view, I believe the opposite is true: that it's actually better for end users to exchange mail messages (and other higher-level communications) directly, on an end-to-end basis, with as little interference from, and dependency on, intermediaries, beyond their use as necessary low-level transport agents.
After all, those intermediaries are, like any component in a well-engineered system, better designed and used for a small number of tasks -- in the case of upstream ISPs, interconnecting portions of the Internet and transferring packets among them should be their main focus, not running mail servers, HTTP proxies, and so on.
Practically speaking, yes, I can have my domain registrar do email forwarding for me. But you know what? They have an email size limit that is substantially lower than the occasional legitimate email I send or receive.
And why shouldn't they have such a limit, since they're in the business of registering domain names, not serving as an email forwarder, which is just a convenient add-on service?
And, yes, I can sign my outgoing emails with GPG, so while they're sitting on my upstream ISP's server, they can't be read...but that does nothing for my incoming email, and if you think it's just as easy for an corrupt employee at an ISP to scan packets in transit to port 25 on my system as it is for her to start the 3rd shift by searching all pending emails on the server for any destined for my system, I'd like to know why you don't go into the spammer-catching business, since it has some of the very same problems.
The fact that you ask if the OP heard of fetchmail illustrates the problem regarding multiple points of failure. fetchmail has had its share of bugs, so why require its use for a large class of users that would otherwise not need it to get useful work done?
I use fetchmail to pull mail down from my upstream ISP, which gives me essentially no opportunity to reject (or especially tarpit) known spam or sources of spam as the spam is injected into "my" mailbox (in the extended sense of including my upstream POP3 mailbox), meaning that, with fetchmail, I have to wait for a 10MB message that ends up being detected as spam by my local software to be downloaded before I get the 2K legitimate message I really need.
Whereas, with direct injection into my system (which is what happens for my four "vanity" domain names), those two hypothetical messages are handled asynchronously, as designed by the SMTP protocol, and possibly even while I'm doing something else, so I don't have to wait for fetchmail to run. (Or I can have fetchmail run automatically every minute or so, which adds a whole 'nother set of problems, among them performance problems. Sometimes my fetchmail runs have simply not worked because my old dialup ISP's POP3 server was having problems -- thank goodness most of my important email comes directly into my system!)
And, yes, it's nice if your upstream ISP is nearly 100% reliable, but, again, you clearly cannot have TCP+SMTP reliability exceed that of TCP-only reliability for a given upstream ISP.
Depend on your ISP to store-and-forward your outgoing and incoming email as well as push packets around, and you're guaranteed to lose a bit of reliability right there.
And, unless you've got another "path" to your ISP and its mail server than your home computer, it really doesn't matter much that its reliability exceeds that of your computer, does it?
I mean, other than the convenience of having all pending emails already on your ISP's mail server when your power and/or local network comes back up, either way, you can't send or receive email while your home computer is down.
There are definite advantages to letting your upstream ISP handle your mail service -- I'm not arguing
Wise advice generally, but I take issue (as a member of "people on slashdot") with your first statement, and suggest that's where you're running into trouble with others here.
There's a fundamental difference between underestimating an opponent and estimating that an opponent is much weaker.
Consider a football game that's coming up. If you just watch the pep rally, the cheerleaders, and so on, on one side, you might come to the conclusion that that side'll win, for all the enthusiasm they display.
But they might have little or no knowledge of the actual opponent -- the football team that they, themselves, aren't going to play.
In that case, they might be underestimating the opponent. Not necessarily -- they're really just cheerleading -- but they might be.
Where true underestimation happens, in terms of being pertinent, is among the coaching staff and team members themselves. If they underestimate their opponent, they might well do a poor job of preparing themselves mentally, physically, and spiritually for the game.
As a result, they might lose.
But there are no such "pertinent people" here on slashdot. The top corporate officers at SCO and IBM, the lawyers conducting the case, and the handful of relevant others are, basically, not contributing to, and probably only rarely reading, discussions of the case on slashdot.
So here's where the reality differs tremendously from your analysis in my hypothetical example: a coaching staff and team members might be properly estimating an opponent's capabilities, based on thorough research.
As a result of that estimation and study, they might well conclude that they have a very high probability of beating that opponent -- possibly shortly after the coin toss, especially if they discover the opposing team's coach doesn't seem to understand the concept of "toin coss", suggesting he has a poor grasp of the rules of the game his team's about to play.
Having reported that information to friends and confidants, it inevitably leaks out to the team cheerleaders, supporters, and assorted other hangers-on, and general pre-victory celebration results.
Again, if you show up just in time to view that celebration, you might be tempted to say "wow, they're underestimating their opponents".
But you'd be basing that on your own underestimation of the thoroughness and accuracy of the analysis already performed.
(A more reasonable analysis might, in that case, be "wow, they're underestimating the ability of the opponents to buy off the officials for the game", but that doesn't seem to be what you're saying here.)
Yes, in worthwhile mythologies and stories of all sorts, the hare gets overconfident as a result of reasonable pre-contest analysis, goofs off, and the turtle wins. It's a good reminder. Do you have any evidence that the IBM/Linux/GPL coaching staff and team members -- as distinct from its cheerleaders on /. -- are behaving like the hare?
I've seen plenty of personal and corporate arrogance cause the "strong" to lose to the "weak", but I've also seen plenty of situations where a noisy, chest-thumping, weakling foolishly takes on a quiet, serious, but incredibly strong opponent, with little or no understanding of that opponent's strengths or resolve.
The results are rarely pretty, but they are instructive.
And, in this case, when it comes to the coaching staff and team members, in my estimation, it is SCO who is doing the chest-thumping, making the noise, egging on its cheerleaders, while the IBM/Linux/GPL side is, largely, observing, preparing, assessing, and behaving, frankly, as if it has little or no concern whatsoever beyond curiousity as to exactly w
Most worthwhile anti-spam/anti-vermin solutions have to introduce inefficiency. MS is hardly doing anything new in that sense -- looks like they've just got a particularly interesting approach for it.
Introducing inefficiency in SMTP is a specific form of the more general need to incorporate inefficiency in any exchange that has long-term consequences, in terms of resource usage or other commitments, for one of the parties to the exchange.
(Consider how inefficient procreation is, especially how it becomes more "artificially inefficient" over a progression from simple, low-level organisms such as amoeba up through highly complex organisms such as mammals, primates, and so on. The inefficiency is artificial in the sense that, in all cases, all it really takes, at most, is for a single cell from a male to contact a single cell from a female; yet all sorts of mechanisms exist, in both creatures -- especially the females of most species -- to make such contact highly unlikely.)
At present, SMTP servers (which represent the "female" side of the equation, in that they accept incoming payloads and must expend potentially substantial resources to hold them, deliver them, or bounce them back to the supposed sender) expend a much larger portion of the resources needed to deliver a particular email than do SMTP clients. (SMTP relays are servers when they receive an email, clients when they forward it, in case you were wondering.)
For example, a typical lightweight SMTP client need only have enough resources to discover the IP address for the destination email addresses' hostname; to open a connection to the SMTP server at that address; to transmit the few commands necessary to deliver the email; and to close the connection.
Spamware typically goes super-minimal, in that it doesn't bother checking return codes, doesn't queue the email in case of failure (as a "proper" SMTP client might), and so on.
SMTP servers, "improved" to cope with the resulting deluge of resource-intensive emails (most of which might be spam and/or vermin), typically expend even more resources than strictly necessary to store, then forward and/or deliver or bounce, an email.
For examples, they might pass an email through one or more filters (Bayesian); do reverse DNS lookups on incoming connections to discover "real" host names; do one or more DNS lookups on RBL sites to discover whether the source is a known or likely spammer/vermin source; consult local data bases to determine whether the envelope sender and/or recipient fit various profiles (Challenge-Response systems have to do this); and so on.
So, in order to accept an incoming email, which requires going through some kind of decision process, an SMTP server's costs include the inherent costs of processing email plus the costs of that decision process.
But most of those costs are never seen, or experienced as minor inconveniences (e.g. short delays, disconnections, outright rejections), by SMTP clients. And as long as illegitimate SMTP clients are given this "free ride", they have the advantage.
So pretty much any worthwhile anti-spam/anti-vermin proposal must shift the burden of resource utilization from SMTP servers to SMTP clients, somehow.
Some proposals do this in ways inherent to the transmission mechanism. E.g. Dan Bernstein's im2000 proposal requires clients to store message bodies themselves, leaving servers to deal only with accepting the "envelopes" for messages, forwarding them along, then relying on sufficiently fast and reliable network connections to support dynamically retrieving the message bodies when the user finally decides to look at the content of a particular message. (This is a very simple summary of the "default" mode for sending message in im2000.)
While we're dealing with SMTP, though, which requires message bodies to be transmitted along with message envelopes, it
Ah, okay, I see what you mean. I run qmail, myself, and haven't put up a nameserver yet (but when I do, it'll be djbdns, not BIND).