I think you are looking for a proof of your political convictions where none exists. WTF does the size of government or the viability of the EPA have to do with patents?
Perpetual copyright and the absurd patent system in particular exactly IS the government interferring with corporations and the free market. Patents are not capitalistic, in fact they are the exact opposite. They do nothing but prevent fair competition, and they are all about the government inhibiting companies or even individuals from competing. So despite your flawed argument I very much would like to see less government interference in at least one respect--I don't want the government telling me I can't do something because somebody else vaguely had the same thought. Now, what is your argument again?
As a software programmer who has written IPv6 enabled applications what I'd really like to see is a similar report of the kernel support for IPv6 in addition to common applications, and for multiple operating systems.
For instance I took advantage of the superior multicasting capability of IPv6, but when porting to different Unixes I found varying level of support. Some just didn't do it, while others were missing some important APIs which made it easier. And some just have messed up C header files rather than faulting the kernel. IPv6 is supposed to have a whole new set of APIs which allow your application to do things like enumerate the various network adapters (important to know when multicasting). Name resolution is also done differently, and with more sane APIs.
The IETF IPv6 Working Group has been busy developing a lot of standards, and for the developer the two most important are RFC2553 for the basic sockets API, and RFC3542 for advanced sockets API. But many Unix vendors aren't up to the latest standard and still implement the older RFC's 2133 and 2292 respectively.
Oh, and on the applications side, many network administrative tools are missing from their list. What about netfilter (aka, iptables and iptables6), or tcpdump, nc, ping/ping6, or X Window? Also what about language support for those languages which have "super" libraries. Python's support for IPv6 is getting pretty strong, but I've found Java's support to be superficial (it only exposes say 10% of IPv6 functionality). Not to complain too much though, this as list is the most complete I've seen so far.
Modern C++ is a wonderful language, at least I think so. But it is much different than the "old" C++, almost to the point of being a different language. So if you've had bad experiences with C++ in the past, perhaps you should give it another look. And C++ is not dead, there are a lot of interesting advancements in the language, and more properly how to use it. There are a whole lot of generic programming and template patterns which are comming out which show that C++ has a lot more power than people ever thought.
Of course C++ does tend to have some problems with Open Source projects, which C usually doesn't have. So I certainly don't frown on C development either. And plain old C is usually very easy to integrate into other languages/environments.
C++ compilers are just now catching up to the standard. gcc 3.3 for instance is pretty darn good now, but lots of compilers have lots of problems.
C++ can be very slow to compile (or more technically to link), especially as you use lots of templates.
The binary ABI is not universal. It's hard to write shared libraries in C++, so it's not as useful for components as it is an entire application.
Dynamic linking in of C++ is next to impossible (dynamic linking often uses the dlopen() system calls, and it how most run-time plugin architectures, such as in Apache or Python work).
Although in theory C++ is very portable, in practice that is still difficult (usually a victim of poor linkers). C++ which works fine under Linux may have serious problems under say AIX or HP-UX, unless you test on those platforms.
However, C++ is certainly still alive and very viable on a whole. And O'Reilly just published the new C++ in a Nutshell book which covers the ISO standard C++ very well. Also you should look at the Boost Project if you're looking for more advanced C++ libraries (many of the Boost developers actively participate in the C++ standardaization effort, and Boost is often thought of as the testbed for possible language additions for the next round of standardization).
But I do agree, that you need to pick the language according to the project. There is no one best language. When I look for other open source projects with the intent of being able to take advantage of the openness (i.e., modify the code), I tend to look for projects written in Python. I particularly avoid Perl, becuase it is much harder for me to understand. I also avoid Java because it's a proprietary language with no open source JDE/JDK and I think the language sucks when compared to ISO C++. But again, those are my preferences.
That wouldn't really solve the problem, unless the replacement was effectively to not have worldwide email. It really comes down to a problem of authenticating the source of the mail, and even then you need some way to know if that source is acceptable. Both of those are really tough problems when applied to a worldwide scale.
Think about secure TLS/SSL websites. The authenticity check is dependent upon the trustworthyness of the root CAs. The respectable CAs must do a lot of manual checking of the registrant's identity before signing a certificate. And that costs a lot of time and money and infrastructure. And even then the certificate-based system we have for webpages is not all that great, it's still relatively easy to hijack websites or even run it yourself (who besides me actually bothers to look at the certificate details when they go to a secure site, or even removes some of the root CAs from their browser's builtin list?).
Now, there certainly should be a way to get the domain name registration information as verifyable as certificate registrations; because the whois databases right now are laughably corrupt, not even the most fundamental checks are performed to insure that the data is correct. But even then, that doesn't stop spam, although it may help you track them down better.
And asuming you have perfect authentication, knowing the source is authentic still doesn't determine whether you consider the source to be a spammer or not. A certificate only proves identity, it doesn't say anything about the type of content being sent. You certainly wouldn't be able to know the millions of different potential email sources, nor keep up with the minute-to-minute changes. And if you're a business you can't use a known sender whitelist; or you may never get job resumes, sales inquires, and so forth. So someone would have to build a list of all "good" non-spammer certificates.
But then you're back to the same situation we have now. You'd just be using certificates or something like that instead of IP addresses as the "identity" you'd be matching against some database, like the many blackhole lists. And given how easy it is to hijack insecure computers, there would certainly be holes around that type of system too.
Now true, the insecurity of vanilla SMTP is an issue for confidentiality purposes, but you can't really blame spam on that. And if you use the already standardized SMTP extensions, such as STARTLS or S/MIME, then SMTP can be pretty secure. Spam is a social problem, not a technology problem.
The inherent vice of capitalism is the unequal sharing of the blessings.
I don't care about the unequal sharing of the blessings, that is after all what motivates people to do wonderful things, paid or not. It is the unequal sharing of opportunity that is the problem.
And things like DRM, outrageous copyrights, software patents, and illegal "Redmond" monopolies are fundamentally about eliminating opportunity or unfairly sharing opportunity; preventing people from doing wonderful things even though they have the motivation and possibly even the means. Those are not capitalistic ideas; they are the cancer that is trying to bring the downfall of capitalism.
The word "trust" is pretty much the central idea in formal security. And ultimately is comes down to deciding if one person trusts another person. Of course when you mix in technologies, then that expands into trusting the system components. Do you trust the website is the correct one? Do you trust the CA registrar. Do you trust that the web browser isn't lying to you. Do you trust that your keyboard isn't recording all your keystrokes? Its all about trust, and no secure system can avoid the subject. And no formal security method can avoid it either.
So yes, trusted security is very much alive, or it had better be, or we won't have any security. But the big question is whom or what is being trusted? And the big media companies are trying their best to confuse the issue. It's just like their "secure media". Their concept of trust is that they, the media distributors, want to be able to trust your hardware to not trust you the consumer. They also want to also insure that other consumers will not trust you, or you could otherwise become your own media producer and distributor and compete with them. If DVD players only play content that is digitally signed by the cartel, then you are barred from competing because you can no longer produce your own content that other's hardware will trust. But on the other side I want to trust that my computer is not infected with a virus; I want to trust that my legally copied media is not corrupted by the media police. Trust is the just the tool.
Trusted computed could be a very good thing, but you absolutely must define what you mean by trust before you can begin any discussion or evaluation, or to say whether it it "bad" or "good". From a purely technical and formal perspective trusted computing is the next step forward. From a society's perspective the answer is not so easy.
Unauthorized copying (sometimes called piracy) is not the real threat against the __AA, but it is the easiest to defend. What they really fear is the ability of independents from creating and distributing their own content without their aid. They want to eventually force all technologies to only play content that was blessed by one of their sacred keys. Think about the CSS keys in DVDs...I am unable to produce a DVD containing my own content which is protected by CSS because I don't have access to one of the magic keys. But is my content which I own a copyright on any less deserving of full copyright protection under the law? Well, certainly the DMCA doesn't protect my content because I've been locked out of even using the popular circumvention technologies.
Well, Palladium and the like are the step towards eroding my rights as an independent creator even further. At least with DVDs, I could given enough capitalistic force create my own alternative to CSS with which I could protect my own content. But with an enforced technology, I don't even have that option open to me. Content creators will be forced to publish only through the evil media oligopoly.
BTW, on an unrelated crypto subject. What about an idea of taking advantage of what is traditionally viewed as fair rights. Say it's okay to just extract 3 seconds of media. I can then publish on a P2P network an article which includes an except of seconds 7.2 through 9.8 of a song. If enough different (and independenly-acting) people publish fair-use derived content with different 3-second extracts, one could in theory reproduce the entire original. There are also crypto techniques such as secret splitting, but the simple 3-second method may be more defendable in the interests of expression of fair rights as long as there is no collusion among individuals. Just a thought, not that I condone unauthorized copying.
Yes, that sounds like something that actually could be very useful. Have the keys actually distributed in the DNS RRs, rather than having to rely upon a complex and sometimes untrustable CA network. There would then have to be something in DNS that could state a sender's policy, such as "all mail coming from my domain must be signed by this key -or- must originate from this IP address(es)"
Of course the biggest win for a company signing its email in such a manner is not immediately to reduce its volume of inbound spam...but rather to prevent other spammers from forging mail as having come from that company. Fearing getting blacklisted or getting 100000 bounced emails that you never sent would disappear.
The RMX approach is certainly very interesting. Although not based on DNS I had previously asked an AOL postmaster for similar information about what servers could legitimately send mail from any aol.com domains. That simple step has allowed me to block almost 100% of all spam reporting to come from joerandomuser@aol.com. I've been looking for similar information from the other big ISPs that spammers love to forge but with little luck.
Of course there may be a few things that this breaks (not that they shouldn't be fixed to work a different way). One is email intermediaries. SMTP was originally designed to be store and forward, and it used to be quite common that mail took many sometimes unpredictable hops along its way...direct end-to-end connections were not nearly as unbiqutious as they are now. But there still are cases where an SMTP intermediate hop may exist for legitimate reasons, but which may be unknown to the sender; thus they would not be listed in the RMX access list.
Another "questionable" practice that would be affected are services like monster.com, which send mail (usually resumes) to subscribers (companies hunting employees), but forge the sender address as being the real address of the individual, not of monster.com itself. Thus monster.com forges mail from almost any domain all the time; even though that mail can hardly be described as "spam" since the individual being forged has authorized monster to do it, and the recipient is paying monster to recieve them... But that kind of practice would still be affected without some workaround.
Oh, and if you want end-to-end authentication why don't more SMTP servers use the STARTTLS (aka SSL) mechanism with REAL certificates just like web servers do? If this became standard practice then it would be much easier to do SMTP server authentication with existing technology, and in a way that is completely transparent to the users (MTAs).
Maybe how you count, but most of us don't need v1agra or naked ch33r1eaders, and therefore consider all those messages to be spam!.. actually, on second thought;-)
The obvious question is how much mail do you receive in total, how much non-spam, and how many false-positives go completely unnoticed by you? I've had my email account since the late 1980's and I get over 200 per day. I also run a mail gateway for a medium sized company, and we get over 30,000 per day.
There are in fact two big problems with Bayesian filtering (or any content-based filtering) from the perspective of an ISP or company... 1) one person's spam is another person's necessity (and usually that person is your boss or VP), and 2) you still have to waste your bandwidth and CPU before you reject it. Sure the bulk of it is very obvious, but there is an awfully fuzzy and thick gray line between good and bad. And the spammers are adapting rather quickly too. So Bayesian filters are a good tool of last resort, but there are many other tools that should be used too.
You have to just jump in! I too am already using IPv6 comfortably alongside my routed IPv4 network. I actually forced myself to start using it just 'cause, and it's wonderful. The autoconfiguration features are worth it alone. And I have a mixed network of Linux, AIX, HP-UX, Windows 2000, and Cisco. My bind/DNS is configured for IPv6, my sendmail is configured for IPv6, and so on. But the underlying IPv4 network is still there right along side. There's really no reason to not go ahead and start experimenting with IPv6, to get comfortable with it before you depend on it.
Actually my excuse to start playing with it was I was developing an application which could make use of multicasting. And let me tell you, IPv6 multicasting is a dream come true when compared with IPv4! And the sockets-API is much more sane and complete, after all the IETF learned from the shortcomings of the IPv4 API.
See these wonderful resources and just jump in!
So now that I'm enjoying it, I've been seeking out open source applications that use IPv4 and providing assistance to the developers to get them compatible with IPv6. A lot of the smaller projects in particular could use help, as some of them are unnecessarily tied to the IPv4 stack and probably don't even know it nor know anything about IPv6. I also suggest that anybody with some expertise to lend a hand as well. The open source/free software community can not find itself falling being here.
Most email that appears to come from AOL in fact comes from somewhere else. Same for all the big ISPs like yahoo, msn, hotmail, and so on. Not only do spammers forge the From: headers, they are also forging the SMTP envelope MAIL FROM as well.
Actually we were inadvertently relaying undeliverable spam back to AOL customers and found ourselves blacklisted by AOL until we cleared it up. No, this is not an "open relay" problem; this was an "undeliverable bouncing" problem. But the effect was similar. You really need to be careful because spammers are getting very smart.
What was happening was that mail which got through our SMTP gateway (running sendmail) and into our back end internal email server (running Exchange) was being bounced as being undeliverable because of the made up recipient addresses that spammers use. The problem was Exchange was creating these "bounces" as NEW email messages rather than as an SMTP DSN rejection, mearly prepending "Undeliverable:" to the subject and sending the message to the supposed sender. But those forged senders turned out to be real AOL user accounts, and being AOL users they flagged our bounces as being spam, and poof, after about 15,000 in one day we got blacklisted....actually I can't blame AOL at all.
The AOL postmasters were surprisingly helpful and courteous in helping us resolve this. What I now do is to take the connecting IP address and do a reverse DNS lookup. If it is not from within the aol.com or aol.net domains, it is rejected as being forged (regardless of what the headers or even the envelope say). Likewise I also check the responce on the HELO/EHLO greeting to make sure it is also from aol.com. And just as an extra check, I finally configured our sendmail milter interface to use LDAP to the exchange backend server to reject mail for invalid mailboxes before it is ever passed through to our backend server.
Now if there were reliable was to detect forged mail from the other big ISP players. I can only perform those forgery catching tricks with them because AOL has a policy that ALL outbound mail from AOL will ALWAYS be sent from an SMTP server registered within the aol.com DNS domain. I don't know if that is necessarily true for the other big ISPs.
I too have noticed that the vast majority of spammers now seem to forge the HELO/EHLO greeting. And as most non-spammers don't, this is actually a wonderful way to catch them. I've even seen them send the IP address of my secondary mail gateway in hopes that my primary mail server would fully trust it (obtained probably by looking up my MX records). I run a mail gateway for a corporate domain an get on average 30 to 40 thousand spams per day. Using sendmail with it's milter programming interface I put the HELO greeting though a very strict check. For those contemplating doing the same...
Per
RFC 2821, the HELO greeting string should be either the FQDN of the sending hostname, or the IP address of the sending system in SMTP syntax (e.g., [1.2.3.4] or [IPV6:abcd::1234]
Most spammers don't even bother with a domain name, using a random greeting like "sqss7e". If it doesn't have a domain, throw it away. Same if you see an IP address without the [] brackets; it's another dumb spammer that can't read the RFC's.
Sometimes spammers don't even hide their spammy-sounding names in the HELO greeting even though they go to a lot of trouble to make up legitimate From headers. A good regular expression check for common words like "offers" or "optin" in the HELO greeting can work wonders (but use caution).
When checking if a spammer if forging your own address, be sure to check for ALL hostnames under your domain (say you have acme.com, then check for both "acme.com" and "*.acme.com", and use a case-insensitive comparison). Also check for ALL your possible IP address even if you don't use them all. A remote site using your own IP or hostname is never legitimate.
If you are running a gateway, you need to treat outbound versus inbound messages differently. This can usually be done by checking the connecting IP address to see if it is one of yours. Also be sure to check for 127.*.*.* and::1 (IPv6).
Be aware that some mail clients are broken and don't send conforming HELO greeting; this includes Mozilla
(see Bug 68877). So don't be too agressive with your HELO checks for mail originating from the inside of your organization.
One last note about Forged AOL Spam after talking to one of their postmasters...all their legitimate mail by corporate policy is always sent from within the *.aol.com or *.aol.net domains. This will be in both the HELO as well as a reverse DNS lookup of the connecting IP address. If you don't see this in the HELO and DNS but you see a MAIL FROM for aol.com, it's probably spam.
I wish more big ISPs would provide public information about how to better detect forged mail claiming to come from their sites. For instance if I see a MAIL FROM *@yahoo.com, then should the connecting IP address always be from a *.yahoo.com host? Some ISP's like hotmail seemingly always add in a known predictable header whose absence indicates spam. But I can't reliably make these calls unless the ISPs provide that information. Also, beware that some semi-legitimate sites, like Monster.com forge the sending address on purpose; so if you want to receive resumes you may need to whitelist them.
For those interested in the letter of the law, as published in Federal Register on October 27, 2000 (FR 64556):
[from section III part C] "After reviewing all the comments and testimony of the witnesses who appeared at the hearings, the Register concludes that a case has been made for exemptions relating to two classes of works:
(1) Compilations consisting of lists of websites blocked by filtering software applications; and
(2) Literary works, including computer programs and databases, protected by access control mechanisms that fail to permit access because of malfunction, damage, or obsoleteness."
The above summary is actually codified into law in 17 U.S.C. 702 Sect 201.40, Exemption to prohibition against circumvention, and can be found in the same FR publication on page 64574. The period of the exemption is temporary, it covers the period from October 28, 2000 through October 28, 2003 only. If the copyright office does not renew these this time around those exemptions will expire.
But what's really interesting is that all of the reasons for their decisions as well a a thourough discussion of other possible excemptions which were considered but not selected! Included among these are most of slashdot's favorites, such as DVDs, video games, reverse engineering, research, etc. Yes it's a government document and looks intimidating, but it's well worth a close read by everybody. As noted a new round of hearings is underway; I encourage everybody to read up on why many exemptions failed last time around and what needs to be done to present a better case next time.
Security is only as strong as the weakest part, and I seriously doubt that's with the encryption algorithm here. Remember this system is not designed to protect your computer from outside threats (like SSH, etc), it is to protect the operating system from the user. The threat model and problem being solved are entirely different.
Why attack the encryption algorithm directly? Instead reverse engineer and bypass the parts of the OS that invoke the license checks. Or fool the probes which try to determine your hardware signatures. "Borrow" a key. Or for that matter just be sure to run IIS, as it lets perfect strangers run any applications they want on your computer, it should just as easily let you use your own computer too without any security checks:-)
I do have two important observations though:
I suspect this is one of the reasons MS is pushing so hard for TCPA/Palladium or other Distrustful Restrictions Management (DRM, sic) in hardware. That would finally allow Windows to completely distrust the user with a vengeance, as well as a side effect of preventing other choices in OS (look at the X-Box as their prototype of a hardware-enforced monopoly).
This is actually bad news for Open Source advocates as it widens the distribution and exposure of this product to people who otherwise may never intend or have the $$ to buy it anyway, futhering their illegal monopolistric grip on the modern world. I for one hate it when people pirate Windows or Office or even Windows Plus, that's one more person that doesn't "feel" the heavy price for using MS software and has no desire to look for other choices. Open Source people would love for more so-called piracy of their products! Perhaps GNU/Linux should require an activation key, maybe that would accelerate its adoption (I'm joking here).
Re:Federal Register could use some updating
on
NARA Goes Online
·
· Score: 3, Informative
It is interesting that you link to the GPO website for the FR rather than the NARA site. The official record keeper and editor of the FR is NARA, wheras the GPO is just responsible for the physicial reproduction and publication. Both run websites, but I find the NARA site to be much better. Also don't forget their joint website Regulations.Gov which went online earlier this year to try to better track proposed regulations still in their comment period and keep the US public better informed.
For those who don't know, the Federal Register is perhaps the most important function of the US National Archives, and most relevent to US citizens' day-to-day activities. I especially like the fact the that NARA FR website is updated daily with each new issue, including a very well organized table of contents. Furthermore each "publication" within the FR is available in both text and PDF format (no proprietary MS formats here!).
Perhaps of the few things which I would like to see improved are: (1) online avilability of FR issues prior to 1998, (2) more frequent revision of the CFR, (3) easier cross reference between issues, dates, and page numbers, (4) an RSS feed of the daily table of contents, (5) FTP access to the FR, and (6) digitally signed (GPG?) issues.
As far as the functional duties of the NARA, keeping the Constitution, Bill of Rights, and so forth are incredibly important, but usually don't affect the citizen directly...those historic documents' power really is expressed indirectly by governing what Congress can do and how the Justice department works...they are just the framework on which the bulk of the legislation and regulations hang. Please don't get me wrong, those foundational documents are what defines the US and and our freedoms, and as such are the most important documents we have. But seriously those documents are very stable and unchanging and don't require much action on the part of the NARA to maintain beyond being just a glorified museum.
But the NARA is right at the center of the US government and has duties way more important than playing museum.
The Federal Register is where the many thousands and thousands of highly detailed regulations, notices, presidental orders and so forth are recorded. It is the very presence of these writings in the Federal Register which makes them official and binding on the US citizens. The Federal Register is the primary means by which the government informs the country about what it expects us to do and not do. And it is the NARA which has the ultimately important responsibility of recording what's official and what's not. That's an incredibly powerful position if you think about it.
The second one (without the boy) is obviously faked, and rather poorly. Some obvious indications:
Look at the grassline underneath the tank. See the regular vertical bands on the concrete wall just above the grass and below the tank. Those lines fall in direct line with both the blocky pattern of the grass as well as small brighter higlights on the underneath side of the tank (look closely). Obviously stamping the same pattern across the image, but the stamp includes the grass, the wall, and part of the tank; a dead giveaway.
On the front edge of the tank where the transition is to the underneath side there is a row of attached square reactive plate armor. Notice that above each is what looks like a horizontal hinge. Now on the second image those plates which fall behind where the boy should be have no attachment "hinge". And there are two out of place half-width plates where all other plates are more nearly square. Also the center outer block is missing...it would seem a lot easier to take this out than to put it in.
Now look at the ground which lies behind where the boy's legs would be. There is a very definite line-pattern there that looks sort of like tread marks, but is too regular. It certainly doesn't match the texture of the rest of the dirt. Also at the angle in which the light is shining any horizontal tread marks, if there, should be pratically invisible. And you can also see the same block repeated several times...way to regular to be real.
As for the first image, it's not as clearly a fake as the second. But there are small indications which look like some attempt was made to burn (lighten) parts of the tank underside, perhaps to provide more contrast? As another reader pointed out, the boy's empty hand has an unusual lightness to it as if a brush was swiped across it. Also the darker halo around the boy traces his outline fairly well, but especially under his armpit there is a clear circular curve where you can almost tell the exact brush size that had been used. Of course film optics can also produce this halo-like effect in certain light, so it's not clear cut.
Of course this begs the question (if my analysis is correct), the second image where the boy was removed is definitely unethical for news reports. But is it unethical to do minor corrections such as white balancing, darking or lightening incorrect exposures, etc as maybe was been done to the first?
May work for a small site, but there's a maximum of 32767 processes in most Unixces, and I get that many messages in just one day. And it's not just shared memory, there's also all those thousands of kernel socket structures and packet buffers being consumed for no good reason, not to mention connection state tracking in your firewalls etc. I still think you can never win the resource battle...best to just drop the connections as fast as possible.
"Excessively slow server detection will be a standard feature of all next generation spam software"
Let's hope so. Then I'd just accept all mail slowly and spam would go away!
Seriously there are flaws in this kind of defense. First, I'm already seeing several spammers who already send mail slowly, probably to avoid setting off statistical trappers and to make it harder to scan through log files. Also don't forget that the spammers usually have much more bandwidth than the recipient; you can never win by trying to fight the battle of resources!
BTW, this is NOT very tricky programming to do if you use the Milter programming interface to sendmail...in fact it is quite easy to do. But like I mentioned, you're sort of self defeating, because you burn your own resources by being slow.
If 50% of all mail in the US is spam, then the other 50% must be the bounces for all that undeliverable mail!
I run a mail gateway for a medium sized company, and although not on the scale of a large ISP, I see many of the same problems. Dealing with spam on a gateway level is quite different from dealing with a single personal mailbox. And spam flooding has gotten much worse in the last few months. Getting over a 1000 messages in under a minute can really start to tax your infrastructure. Actually from my own observations, I'd say that at least 75% of all mail is spam, and 80% of that is undeliverable.
Of course one of the big problems as Ramasubramanian points out is that spammers are getting very sophisticated at impersonating other entities. This results in a large number of bounces being directed back to the wrong guy. So not only are you getting spammed, but you are also indirectly spamming the poor guy who is being impersonated with your flood of bounces. And the bounces also cause other problems because it tends to fill up your outbound mail spools, as well as making the required postmaster account near useless sometimes.
One thing I've learned is that a mail administrator must be very careful about constructing blacklists and filters. I use sendmail and make heavy use of it's milter programatic filter interface. It's amazing how being able to analyze the mail at the protocol level (such as the HELO command) helps identify impersonated mail that can't just be done by only looking at mail headers or the message body. It is also possible to help correlate large volumes of nearly identical inbound mail from a large number of different servers, as well as correlate them with large number of undeliverable outbounds.
I'm also very careful to check whois an other registrar databases before adding blacklist entries, to help prevent blacklisting the wrong guy. But I do admit that for a few of the most audacious flood attacks, I actually have to resort to iptables firewall blocks to stop it even before sendmail sees it. I really dislike having to disobey the SMTP standards, but spam floods are IMHO just as destructive as worms and viruses!
The thing I fear most as a mail administrator is not the inbound spam, but that some spammer may start impersonating my company! We'd start getting placed on blacklists and blocked, plus we'd start getting flooded with all those bounce messages (probably an order of magnitude more than direct spam). How can one possibly protect against that?
Designing in explicit incompatibilities and obsolesense is very annoying and a greedy ripoff, but there is nothing leagally wrong with it (except in the EU), as long as reverse engineering is permitted. However as soon as something like the DMCA is invoked by Dell (which Lexmark has
already done), then the real low road will have been discovered.
Imagine what might happen in the future, say with some new kind of organic ink. Well if that ink contains some sort of DNA strand, and you got that patented, and you found a cheap way to put DNA testing chips in the catridges there would be another low milestone.
For me, I'd be glad to pay higher prices for a printer if the cost and hassle of ink/toner replacement were easier. The situation where every new model of printer must have a new unique and incompatible cartidge is beyond silly. This kind of thing happens in other industries too from time to time. Consider battery packs for digital cameras. It seems that the usual way for these things to be sorted back to a reasonable reality is either for the government to step in (say #2 pencils, shoe sizes, gas peddle on the right, etc.) or for the industry to totally collapse or come under the control of a single monopoly.
It's not the bugs that got fixed, it's the ones that haven't been discovered yet.
If I remember right I think Unix and even Linux has a rather long history of security holes. Any large enough program with a long enough history will have a record. That's not easily translated into how secure it is...especially since sendmail has been rewritten a few times (or large portions of it). It's not all 20-year old stale code.
Remember, this bug was fixed before a known exploit was loose. That's a testiment to the amount of source code scrutiny sendmail is getting.....I'm rather comforted by the fact that this was discovered, it means that somebody has been reviewing the code in rather fine-grained detail. I'm always skeptical of any program that claims a clean record; it usually means nobody bothered to look yet or that the hackers are just keeping their exploits secret.
Perhaps you haven't actually looked at sendmail since 1983?
Sendmail certainly does not need to run as root for most of its operations anymore. Read the file "sendmail/SECURITY" in the source code distribution for all the details.
"One way to minimize the possibility
of such problems [root exploits] is to install sendmail without
set-user-ID root, which avoids local exploits.
This configuration, which is the default starting
with 8.12,..."
There are of course a few small things that any mail transport agent will need root access for, primarily for opening port 25., local mail delivery, etc. But the basic quering and mail handling operations don't require root, and neither does sendmail require root for that. Plus sendmail has separated the mail transport function from the local mail delivery/submission function too. And furthermore you can write your own custom sendmail filters (milters) as separate processes from sendmail and can run as any user you like. And if you don't require local delivery, there's no reason you can't chroot jail it either.
It amazes me how often people spout off about their favorite non-sendmail program being ultimately secure and sendmail being ultimately vulnerable to everything. Nothing is that black and white. True sendmail may have a long history, but it has by no means stood still. And furthermore security vunerabilities are possible in every mail program no matter how much it is evangelized as being "secure".
If you don't need the power of sendmail (and most people don't) and it intimidates you then fine use what works for you. That's a legitimate functionaility decision. But just because there is one buffer overflow bug doesn't mean that the whole of sendmail is junk. It got fixed didn't it? There are many things that sendmail does much better than any other alternative out there, especially for very large and complex sites.
Slashdot Mirror
I think you are looking for a proof of your political convictions where none exists. WTF does the size of government or the viability of the EPA have to do with patents?
Perpetual copyright and the absurd patent system in particular exactly IS the government interferring with corporations and the free market. Patents are not capitalistic, in fact they are the exact opposite. They do nothing but prevent fair competition, and they are all about the government inhibiting companies or even individuals from competing. So despite your flawed argument I very much would like to see less government interference in at least one respect--I don't want the government telling me I can't do something because somebody else vaguely had the same thought. Now, what is your argument again?
As a software programmer who has written IPv6 enabled applications what I'd really like to see is a similar report of the kernel support for IPv6 in addition to common applications, and for multiple operating systems.
For instance I took advantage of the superior multicasting capability of IPv6, but when porting to different Unixes I found varying level of support. Some just didn't do it, while others were missing some important APIs which made it easier. And some just have messed up C header files rather than faulting the kernel. IPv6 is supposed to have a whole new set of APIs which allow your application to do things like enumerate the various network adapters (important to know when multicasting). Name resolution is also done differently, and with more sane APIs.
The IETF IPv6 Working Group has been busy developing a lot of standards, and for the developer the two most important are RFC2553 for the basic sockets API, and RFC3542 for advanced sockets API. But many Unix vendors aren't up to the latest standard and still implement the older RFC's 2133 and 2292 respectively.
Oh, and on the applications side, many network administrative tools are missing from their list. What about netfilter (aka, iptables and iptables6), or tcpdump, nc, ping/ping6, or X Window? Also what about language support for those languages which have "super" libraries. Python's support for IPv6 is getting pretty strong, but I've found Java's support to be superficial (it only exposes say 10% of IPv6 functionality). Not to complain too much though, this as list is the most complete I've seen so far.
Okay , you
dont't
have to
like using whitespace
so
others can actually
read your code, but
I like the
way
Python lets me
do the
right
thing.
Have you seen Perl? Or for the old-timers, JCL? Now that's ugly! (but to be fair, both are very powerful).
Modern C++ is a wonderful language, at least I think so. But it is much different than the "old" C++, almost to the point of being a different language. So if you've had bad experiences with C++ in the past, perhaps you should give it another look. And C++ is not dead, there are a lot of interesting advancements in the language, and more properly how to use it. There are a whole lot of generic programming and template patterns which are comming out which show that C++ has a lot more power than people ever thought.
Of course C++ does tend to have some problems with Open Source projects, which C usually doesn't have. So I certainly don't frown on C development either. And plain old C is usually very easy to integrate into other languages/environments.
However, C++ is certainly still alive and very viable on a whole. And O'Reilly just published the new C++ in a Nutshell book which covers the ISO standard C++ very well. Also you should look at the Boost Project if you're looking for more advanced C++ libraries (many of the Boost developers actively participate in the C++ standardaization effort, and Boost is often thought of as the testbed for possible language additions for the next round of standardization).
But I do agree, that you need to pick the language according to the project. There is no one best language. When I look for other open source projects with the intent of being able to take advantage of the openness (i.e., modify the code), I tend to look for projects written in Python. I particularly avoid Perl, becuase it is much harder for me to understand. I also avoid Java because it's a proprietary language with no open source JDE/JDK and I think the language sucks when compared to ISO C++. But again, those are my preferences.
That wouldn't really solve the problem, unless the replacement was effectively to not have worldwide email. It really comes down to a problem of authenticating the source of the mail, and even then you need some way to know if that source is acceptable. Both of those are really tough problems when applied to a worldwide scale.
Think about secure TLS/SSL websites. The authenticity check is dependent upon the trustworthyness of the root CAs. The respectable CAs must do a lot of manual checking of the registrant's identity before signing a certificate. And that costs a lot of time and money and infrastructure. And even then the certificate-based system we have for webpages is not all that great, it's still relatively easy to hijack websites or even run it yourself (who besides me actually bothers to look at the certificate details when they go to a secure site, or even removes some of the root CAs from their browser's builtin list?).
Now, there certainly should be a way to get the domain name registration information as verifyable as certificate registrations; because the whois databases right now are laughably corrupt, not even the most fundamental checks are performed to insure that the data is correct. But even then, that doesn't stop spam, although it may help you track them down better.
And asuming you have perfect authentication, knowing the source is authentic still doesn't determine whether you consider the source to be a spammer or not. A certificate only proves identity, it doesn't say anything about the type of content being sent. You certainly wouldn't be able to know the millions of different potential email sources, nor keep up with the minute-to-minute changes. And if you're a business you can't use a known sender whitelist; or you may never get job resumes, sales inquires, and so forth. So someone would have to build a list of all "good" non-spammer certificates.
But then you're back to the same situation we have now. You'd just be using certificates or something like that instead of IP addresses as the "identity" you'd be matching against some database, like the many blackhole lists. And given how easy it is to hijack insecure computers, there would certainly be holes around that type of system too.
Now true, the insecurity of vanilla SMTP is an issue for confidentiality purposes, but you can't really blame spam on that. And if you use the already standardized SMTP extensions, such as STARTLS or S/MIME, then SMTP can be pretty secure. Spam is a social problem, not a technology problem.
I don't care about the unequal sharing of the blessings, that is after all what motivates people to do wonderful things, paid or not. It is the unequal sharing of opportunity that is the problem.
And things like DRM, outrageous copyrights, software patents, and illegal "Redmond" monopolies are fundamentally about eliminating opportunity or unfairly sharing opportunity; preventing people from doing wonderful things even though they have the motivation and possibly even the means. Those are not capitalistic ideas; they are the cancer that is trying to bring the downfall of capitalism.
The word "trust" is pretty much the central idea in formal security. And ultimately is comes down to deciding if one person trusts another person. Of course when you mix in technologies, then that expands into trusting the system components. Do you trust the website is the correct one? Do you trust the CA registrar. Do you trust that the web browser isn't lying to you. Do you trust that your keyboard isn't recording all your keystrokes? Its all about trust, and no secure system can avoid the subject. And no formal security method can avoid it either.
So yes, trusted security is very much alive, or it had better be, or we won't have any security. But the big question is whom or what is being trusted? And the big media companies are trying their best to confuse the issue. It's just like their "secure media". Their concept of trust is that they, the media distributors, want to be able to trust your hardware to not trust you the consumer. They also want to also insure that other consumers will not trust you, or you could otherwise become your own media producer and distributor and compete with them. If DVD players only play content that is digitally signed by the cartel, then you are barred from competing because you can no longer produce your own content that other's hardware will trust. But on the other side I want to trust that my computer is not infected with a virus; I want to trust that my legally copied media is not corrupted by the media police. Trust is the just the tool.
Trusted computed could be a very good thing, but you absolutely must define what you mean by trust before you can begin any discussion or evaluation, or to say whether it it "bad" or "good". From a purely technical and formal perspective trusted computing is the next step forward. From a society's perspective the answer is not so easy.
Unauthorized copying (sometimes called piracy) is not the real threat against the __AA, but it is the easiest to defend. What they really fear is the ability of independents from creating and distributing their own content without their aid. They want to eventually force all technologies to only play content that was blessed by one of their sacred keys. Think about the CSS keys in DVDs...I am unable to produce a DVD containing my own content which is protected by CSS because I don't have access to one of the magic keys. But is my content which I own a copyright on any less deserving of full copyright protection under the law? Well, certainly the DMCA doesn't protect my content because I've been locked out of even using the popular circumvention technologies.
Well, Palladium and the like are the step towards eroding my rights as an independent creator even further. At least with DVDs, I could given enough capitalistic force create my own alternative to CSS with which I could protect my own content. But with an enforced technology, I don't even have that option open to me. Content creators will be forced to publish only through the evil media oligopoly.
BTW, on an unrelated crypto subject. What about an idea of taking advantage of what is traditionally viewed as fair rights. Say it's okay to just extract 3 seconds of media. I can then publish on a P2P network an article which includes an except of seconds 7.2 through 9.8 of a song. If enough different (and independenly-acting) people publish fair-use derived content with different 3-second extracts, one could in theory reproduce the entire original. There are also crypto techniques such as secret splitting, but the simple 3-second method may be more defendable in the interests of expression of fair rights as long as there is no collusion among individuals. Just a thought, not that I condone unauthorized copying.
Yes, that sounds like something that actually could be very useful. Have the keys actually distributed in the DNS RRs, rather than having to rely upon a complex and sometimes untrustable CA network. There would then have to be something in DNS that could state a sender's policy, such as "all mail coming from my domain must be signed by this key -or- must originate from this IP address(es)"
Of course the biggest win for a company signing its email in such a manner is not immediately to reduce its volume of inbound spam...but rather to prevent other spammers from forging mail as having come from that company. Fearing getting blacklisted or getting 100000 bounced emails that you never sent would disappear.
The RMX approach is certainly very interesting. Although not based on DNS I had previously asked an AOL postmaster for similar information about what servers could legitimately send mail from any aol.com domains. That simple step has allowed me to block almost 100% of all spam reporting to come from joerandomuser@aol.com. I've been looking for similar information from the other big ISPs that spammers love to forge but with little luck.
Of course there may be a few things that this breaks (not that they shouldn't be fixed to work a different way). One is email intermediaries. SMTP was originally designed to be store and forward, and it used to be quite common that mail took many sometimes unpredictable hops along its way...direct end-to-end connections were not nearly as unbiqutious as they are now. But there still are cases where an SMTP intermediate hop may exist for legitimate reasons, but which may be unknown to the sender; thus they would not be listed in the RMX access list.
Another "questionable" practice that would be affected are services like monster.com, which send mail (usually resumes) to subscribers (companies hunting employees), but forge the sender address as being the real address of the individual, not of monster.com itself. Thus monster.com forges mail from almost any domain all the time; even though that mail can hardly be described as "spam" since the individual being forged has authorized monster to do it, and the recipient is paying monster to recieve them... But that kind of practice would still be affected without some workaround.
Oh, and if you want end-to-end authentication why don't more SMTP servers use the STARTTLS (aka SSL) mechanism with REAL certificates just like web servers do? If this became standard practice then it would be much easier to do SMTP server authentication with existing technology, and in a way that is completely transparent to the users (MTAs).Maybe how you count, but most of us don't need v1agra or naked ch33r1eaders, and therefore consider all those messages to be spam! .. actually, on second thought ;-)
The obvious question is how much mail do you receive in total, how much non-spam, and how many false-positives go completely unnoticed by you? I've had my email account since the late 1980's and I get over 200 per day. I also run a mail gateway for a medium sized company, and we get over 30,000 per day.
There are in fact two big problems with Bayesian filtering (or any content-based filtering) from the perspective of an ISP or company... 1) one person's spam is another person's necessity (and usually that person is your boss or VP), and 2) you still have to waste your bandwidth and CPU before you reject it. Sure the bulk of it is very obvious, but there is an awfully fuzzy and thick gray line between good and bad. And the spammers are adapting rather quickly too. So Bayesian filters are a good tool of last resort, but there are many other tools that should be used too.
You have to just jump in! I too am already using IPv6 comfortably alongside my routed IPv4 network. I actually forced myself to start using it just 'cause, and it's wonderful. The autoconfiguration features are worth it alone. And I have a mixed network of Linux, AIX, HP-UX, Windows 2000, and Cisco. My bind/DNS is configured for IPv6, my sendmail is configured for IPv6, and so on. But the underlying IPv4 network is still there right along side. There's really no reason to not go ahead and start experimenting with IPv6, to get comfortable with it before you depend on it.
Actually my excuse to start playing with it was I was developing an application which could make use of multicasting. And let me tell you, IPv6 multicasting is a dream come true when compared with IPv4! And the sockets-API is much more sane and complete, after all the IETF learned from the shortcomings of the IPv4 API. See these wonderful resources and just jump in!
So now that I'm enjoying it, I've been seeking out open source applications that use IPv4 and providing assistance to the developers to get them compatible with IPv6. A lot of the smaller projects in particular could use help, as some of them are unnecessarily tied to the IPv4 stack and probably don't even know it nor know anything about IPv6. I also suggest that anybody with some expertise to lend a hand as well. The open source/free software community can not find itself falling being here.
Most email that appears to come from AOL in fact comes from somewhere else. Same for all the big ISPs like yahoo, msn, hotmail, and so on. Not only do spammers forge the From: headers, they are also forging the SMTP envelope MAIL FROM as well.
Actually we were inadvertently relaying undeliverable spam back to AOL customers and found ourselves blacklisted by AOL until we cleared it up. No, this is not an "open relay" problem; this was an "undeliverable bouncing" problem. But the effect was similar. You really need to be careful because spammers are getting very smart.
What was happening was that mail which got through our SMTP gateway (running sendmail) and into our back end internal email server (running Exchange) was being bounced as being undeliverable because of the made up recipient addresses that spammers use. The problem was Exchange was creating these "bounces" as NEW email messages rather than as an SMTP DSN rejection, mearly prepending "Undeliverable:" to the subject and sending the message to the supposed sender. But those forged senders turned out to be real AOL user accounts, and being AOL users they flagged our bounces as being spam, and poof, after about 15,000 in one day we got blacklisted....actually I can't blame AOL at all.
The AOL postmasters were surprisingly helpful and courteous in helping us resolve this. What I now do is to take the connecting IP address and do a reverse DNS lookup. If it is not from within the aol.com or aol.net domains, it is rejected as being forged (regardless of what the headers or even the envelope say). Likewise I also check the responce on the HELO/EHLO greeting to make sure it is also from aol.com. And just as an extra check, I finally configured our sendmail milter interface to use LDAP to the exchange backend server to reject mail for invalid mailboxes before it is ever passed through to our backend server.
Now if there were reliable was to detect forged mail from the other big ISP players. I can only perform those forgery catching tricks with them because AOL has a policy that ALL outbound mail from AOL will ALWAYS be sent from an SMTP server registered within the aol.com DNS domain. I don't know if that is necessarily true for the other big ISPs.
I too have noticed that the vast majority of spammers now seem to forge the HELO/EHLO greeting. And as most non-spammers don't, this is actually a wonderful way to catch them. I've even seen them send the IP address of my secondary mail gateway in hopes that my primary mail server would fully trust it (obtained probably by looking up my MX records). I run a mail gateway for a corporate domain an get on average 30 to 40 thousand spams per day. Using sendmail with it's milter programming interface I put the HELO greeting though a very strict check. For those contemplating doing the same...
One last note about Forged AOL Spam after talking to one of their postmasters...all their legitimate mail by corporate policy is always sent from within the *.aol.com or *.aol.net domains. This will be in both the HELO as well as a reverse DNS lookup of the connecting IP address. If you don't see this in the HELO and DNS but you see a MAIL FROM for aol.com, it's probably spam.
I wish more big ISPs would provide public information about how to better detect forged mail claiming to come from their sites. For instance if I see a MAIL FROM *@yahoo.com, then should the connecting IP address always be from a *.yahoo.com host? Some ISP's like hotmail seemingly always add in a known predictable header whose absence indicates spam. But I can't reliably make these calls unless the ISPs provide that information. Also, beware that some semi-legitimate sites, like Monster.com forge the sending address on purpose; so if you want to receive resumes you may need to whitelist them.
For those interested in the letter of the law, as published in Federal Register on October 27, 2000 (FR 64556):
The above summary is actually codified into law in 17 U.S.C. 702 Sect 201.40, Exemption to prohibition against circumvention, and can be found in the same FR publication on page 64574. The period of the exemption is temporary, it covers the period from October 28, 2000 through October 28, 2003 only. If the copyright office does not renew these this time around those exemptions will expire.
But what's really interesting is that all of the reasons for their decisions as well a a thourough discussion of other possible excemptions which were considered but not selected! Included among these are most of slashdot's favorites, such as DVDs, video games, reverse engineering, research, etc. Yes it's a government document and looks intimidating, but it's well worth a close read by everybody. As noted a new round of hearings is underway; I encourage everybody to read up on why many exemptions failed last time around and what needs to be done to present a better case next time.
Security is only as strong as the weakest part, and I seriously doubt that's with the encryption algorithm here. Remember this system is not designed to protect your computer from outside threats (like SSH, etc), it is to protect the operating system from the user. The threat model and problem being solved are entirely different.
Why attack the encryption algorithm directly? Instead reverse engineer and bypass the parts of the OS that invoke the license checks. Or fool the probes which try to determine your hardware signatures. "Borrow" a key. Or for that matter just be sure to run IIS, as it lets perfect strangers run any applications they want on your computer, it should just as easily let you use your own computer too without any security checks :-)
I do have two important observations though:
It is interesting that you link to the GPO website for the FR rather than the NARA site. The official record keeper and editor of the FR is NARA, wheras the GPO is just responsible for the physicial reproduction and publication. Both run websites, but I find the NARA site to be much better. Also don't forget their joint website Regulations.Gov which went online earlier this year to try to better track proposed regulations still in their comment period and keep the US public better informed.
For those who don't know, the Federal Register is perhaps the most important function of the US National Archives, and most relevent to US citizens' day-to-day activities. I especially like the fact the that NARA FR website is updated daily with each new issue, including a very well organized table of contents. Furthermore each "publication" within the FR is available in both text and PDF format (no proprietary MS formats here!).
Perhaps of the few things which I would like to see improved are: (1) online avilability of FR issues prior to 1998, (2) more frequent revision of the CFR, (3) easier cross reference between issues, dates, and page numbers, (4) an RSS feed of the daily table of contents, (5) FTP access to the FR, and (6) digitally signed (GPG?) issues.
As far as the functional duties of the NARA, keeping the Constitution, Bill of Rights, and so forth are incredibly important, but usually don't affect the citizen directly...those historic documents' power really is expressed indirectly by governing what Congress can do and how the Justice department works...they are just the framework on which the bulk of the legislation and regulations hang. Please don't get me wrong, those foundational documents are what defines the US and and our freedoms, and as such are the most important documents we have. But seriously those documents are very stable and unchanging and don't require much action on the part of the NARA to maintain beyond being just a glorified museum.
But the NARA is right at the center of the US government and has duties way more important than playing museum.
The Federal Register is where the many thousands and thousands of highly detailed regulations, notices, presidental orders and so forth are recorded. It is the very presence of these writings in the Federal Register which makes them official and binding on the US citizens. The Federal Register is the primary means by which the government informs the country about what it expects us to do and not do. And it is the NARA which has the ultimately important responsibility of recording what's official and what's not. That's an incredibly powerful position if you think about it.
The second one (without the boy) is obviously faked, and rather poorly. Some obvious indications:
Look at the grassline underneath the tank. See the regular vertical bands on the concrete wall just above the grass and below the tank. Those lines fall in direct line with both the blocky pattern of the grass as well as small brighter higlights on the underneath side of the tank (look closely). Obviously stamping the same pattern across the image, but the stamp includes the grass, the wall, and part of the tank; a dead giveaway.
On the front edge of the tank where the transition is to the underneath side there is a row of attached square reactive plate armor. Notice that above each is what looks like a horizontal hinge. Now on the second image those plates which fall behind where the boy should be have no attachment "hinge". And there are two out of place half-width plates where all other plates are more nearly square. Also the center outer block is missing...it would seem a lot easier to take this out than to put it in.
Now look at the ground which lies behind where the boy's legs would be. There is a very definite line-pattern there that looks sort of like tread marks, but is too regular. It certainly doesn't match the texture of the rest of the dirt. Also at the angle in which the light is shining any horizontal tread marks, if there, should be pratically invisible. And you can also see the same block repeated several times...way to regular to be real.
As for the first image, it's not as clearly a fake as the second. But there are small indications which look like some attempt was made to burn (lighten) parts of the tank underside, perhaps to provide more contrast? As another reader pointed out, the boy's empty hand has an unusual lightness to it as if a brush was swiped across it. Also the darker halo around the boy traces his outline fairly well, but especially under his armpit there is a clear circular curve where you can almost tell the exact brush size that had been used. Of course film optics can also produce this halo-like effect in certain light, so it's not clear cut.
Of course this begs the question (if my analysis is correct), the second image where the boy was removed is definitely unethical for news reports. But is it unethical to do minor corrections such as white balancing, darking or lightening incorrect exposures, etc as maybe was been done to the first?
May work for a small site, but there's a maximum of 32767 processes in most Unixces, and I get that many messages in just one day. And it's not just shared memory, there's also all those thousands of kernel socket structures and packet buffers being consumed for no good reason, not to mention connection state tracking in your firewalls etc. I still think you can never win the resource battle...best to just drop the connections as fast as possible.
Let's hope so. Then I'd just accept all mail slowly and spam would go away!
Seriously there are flaws in this kind of defense. First, I'm already seeing several spammers who already send mail slowly, probably to avoid setting off statistical trappers and to make it harder to scan through log files. Also don't forget that the spammers usually have much more bandwidth than the recipient; you can never win by trying to fight the battle of resources!
BTW, this is NOT very tricky programming to do if you use the Milter programming interface to sendmail...in fact it is quite easy to do. But like I mentioned, you're sort of self defeating, because you burn your own resources by being slow.
If 50% of all mail in the US is spam, then the other 50% must be the bounces for all that undeliverable mail!
I run a mail gateway for a medium sized company, and although not on the scale of a large ISP, I see many of the same problems. Dealing with spam on a gateway level is quite different from dealing with a single personal mailbox. And spam flooding has gotten much worse in the last few months. Getting over a 1000 messages in under a minute can really start to tax your infrastructure. Actually from my own observations, I'd say that at least 75% of all mail is spam, and 80% of that is undeliverable.
Of course one of the big problems as Ramasubramanian points out is that spammers are getting very sophisticated at impersonating other entities. This results in a large number of bounces being directed back to the wrong guy. So not only are you getting spammed, but you are also indirectly spamming the poor guy who is being impersonated with your flood of bounces. And the bounces also cause other problems because it tends to fill up your outbound mail spools, as well as making the required postmaster account near useless sometimes.
One thing I've learned is that a mail administrator must be very careful about constructing blacklists and filters. I use sendmail and make heavy use of it's milter programatic filter interface. It's amazing how being able to analyze the mail at the protocol level (such as the HELO command) helps identify impersonated mail that can't just be done by only looking at mail headers or the message body. It is also possible to help correlate large volumes of nearly identical inbound mail from a large number of different servers, as well as correlate them with large number of undeliverable outbounds. I'm also very careful to check whois an other registrar databases before adding blacklist entries, to help prevent blacklisting the wrong guy. But I do admit that for a few of the most audacious flood attacks, I actually have to resort to iptables firewall blocks to stop it even before sendmail sees it. I really dislike having to disobey the SMTP standards, but spam floods are IMHO just as destructive as worms and viruses!
The thing I fear most as a mail administrator is not the inbound spam, but that some spammer may start impersonating my company! We'd start getting placed on blacklists and blocked, plus we'd start getting flooded with all those bounce messages (probably an order of magnitude more than direct spam). How can one possibly protect against that?
Designing in explicit incompatibilities and obsolesense is very annoying and a greedy ripoff, but there is nothing leagally wrong with it (except in the EU), as long as reverse engineering is permitted. However as soon as something like the DMCA is invoked by Dell (which Lexmark has already done), then the real low road will have been discovered.
Imagine what might happen in the future, say with some new kind of organic ink. Well if that ink contains some sort of DNA strand, and you got that patented, and you found a cheap way to put DNA testing chips in the catridges there would be another low milestone.
For me, I'd be glad to pay higher prices for a printer if the cost and hassle of ink/toner replacement were easier. The situation where every new model of printer must have a new unique and incompatible cartidge is beyond silly. This kind of thing happens in other industries too from time to time. Consider battery packs for digital cameras. It seems that the usual way for these things to be sorted back to a reasonable reality is either for the government to step in (say #2 pencils, shoe sizes, gas peddle on the right, etc.) or for the industry to totally collapse or come under the control of a single monopoly.
It's not the bugs that got fixed, it's the ones that haven't been discovered yet.
If I remember right I think Unix and even Linux has a rather long history of security holes. Any large enough program with a long enough history will have a record. That's not easily translated into how secure it is...especially since sendmail has been rewritten a few times (or large portions of it). It's not all 20-year old stale code.
Remember, this bug was fixed before a known exploit was loose. That's a testiment to the amount of source code scrutiny sendmail is getting.....I'm rather comforted by the fact that this was discovered, it means that somebody has been reviewing the code in rather fine-grained detail. I'm always skeptical of any program that claims a clean record; it usually means nobody bothered to look yet or that the hackers are just keeping their exploits secret.
Perhaps you haven't actually looked at sendmail since 1983?
Sendmail certainly does not need to run as root for most of its operations anymore. Read the file "sendmail/SECURITY" in the source code distribution for all the details.
There are of course a few small things that any mail transport agent will need root access for, primarily for opening port 25., local mail delivery, etc. But the basic quering and mail handling operations don't require root, and neither does sendmail require root for that. Plus sendmail has separated the mail transport function from the local mail delivery/submission function too. And furthermore you can write your own custom sendmail filters (milters) as separate processes from sendmail and can run as any user you like. And if you don't require local delivery, there's no reason you can't chroot jail it either.
It amazes me how often people spout off about their favorite non-sendmail program being ultimately secure and sendmail being ultimately vulnerable to everything. Nothing is that black and white. True sendmail may have a long history, but it has by no means stood still. And furthermore security vunerabilities are possible in every mail program no matter how much it is evangelized as being "secure".
If you don't need the power of sendmail (and most people don't) and it intimidates you then fine use what works for you. That's a legitimate functionaility decision. But just because there is one buffer overflow bug doesn't mean that the whole of sendmail is junk. It got fixed didn't it? There are many things that sendmail does much better than any other alternative out there, especially for very large and complex sites.