Icelanders deliberately don't use such networks, because most local ISPs charge seperately for international downloads (we have somewhat limited bandwidth to the rest of the world due to a lack of competition and resources).
Downloads which are local to Iceland are "free" (included in the lease of the ADSL line), but international downloads are rather expensive.
This is exactly why DC++, with it's centralized hub-based architecture was so popular in Iceland. Anybody who understood both technology and copyright law knew better than to connect to them though, for exactly the same reasons.
Yes, the traffic really did drop that much (I live in Iceland). It was very noticable on publicly accessible usage graphs for the largest peering point in Iceland. This graph from the Reykjavík Internet Exchange is very telling.
However, the Register article was slightly misleading in implying that the traffic reduction was directly caused by the raid - it was more likely caused by the media coverage of the raid.
Basically, Joe Sixpacks all over the country read about the raids in their morning papers, paniced and turned off all their P2P apps. This includes the managers of the other DC++ hubs.
Actually, that's only assuming that you have a relatively passive system.
If you actively update the "defense boxes" with all the latest exploits and then configure it to use it's full arsenal to take down any attacking hosts (e.g. by making all exploits simply turn off networking on the target machine), then you'll have a very high success rate indeed. Then only worms exploiting previously unknown holes on otherwise fully patched machines will be able to run unchecked. This raises the bar for worm writers by an order of magnitude... or two.
Note that I'm suggesting that the "counter attack" would be simply disable networking on the infected host. This is easier to get right than any sort of complex cleanup, thus lowering the odds that you'll break the infected machine. Also, a machine which keeps dropping off the network will eventually get attended to by a technician, who will hopefully disinfect and patch it properly.
This would also have the beneficial side-effect that worm authors would be forced to close the holes they exploit in order for their worms to live. This would suddenly mean that worms and viruses would be competing against each other instead of coexisting peacefully.
Frankly I hope someone writes such a thing and a government body or group of white hats simply deploys it. Or both. Then the internet will finally have an immune system.
The above support for AOL's actions is based on the fact that if I recall correctly, there are remotely expoitable problems with the Windows Messenger service. If my memory is playing tricks on me and the ONLY point was to disable annoying popups, then I don't condone this particular hack. But for an equivalent hack to close the Blaster hole or other similar ones, my argument is valid and I stand by it.:-)
Although I understand your general sentiment, I would like to point out that a controlled "hack" like this run from a trusted location by a qualified technician is radically different from a worm or virus.
If something like this backfires, then A) you know who is responsible and B) the responsible person can TURN IT OFF.
For most viruses and worms, neither A) nor B) can be guaranteed, which is why releasing worms into the wild is ALWAYS a bad idea, whether their payload is benign or not.
Proactive "hacking" of machines by ISPs is actually relatively easy to justify from a network-reliability point of view. As a network admin I frankly couldn't care less if you need Windows Messanger - if you're running it unpatched on my network then you're putting the rest of my network and the rest of my users at risk, which is unacceptable.
So, basically, I agree with Russ. Go AOL!
This is what both the Razor and DCC projects are about, although their approaches differ slightly.
This is almost exactly what the DCC does. This strategy works very well for certain types of spam, but it doesn't catch everything and needs manual intervention to allow legitimate mailing list traffic through.
What I generally recommend to ISPs, when given the chance, is that they offer two sorts of subscriptions - the default being a locked down subscription which allocates IP addresses behind ACLs blocking outgoing port 25 and incoming 135-137, along with a few others.
If the technical-minded people can opt out of the firewall then they're generally quite happy. In some cases they're even willing to pay a little bit extra, which is after all justifiable because the risk is higher for the ISP and offering this sort of thing adds complexity.
I realize this isn't technically feasable for all ISPs, but for many it provides an excellent solution.
Yes, this is quite nice. Alot of people have been recommending this sort of thing in the discussion thread already.
The only problem is... you can't be sure that the server trying offering the infected mail isn't just a relay. If it's a relay then you're effectively instructing it to resend the entire message - virus and all - to the sender, which is an innocent thrid party.
This sort of scenario is the most common cause of the complaints about "A/V programs" which resend the entire virus, thus helping it spread.
So you're just passing the buck. It's understandable and I agree that this is a much better approach than most. But the ideal behavior, from a global network point of view, would be to reliably detect the infection as a massmailer (using a good A/V scanner) and/dev/null the message.
Disclaimer: I work for FRISK on e-mail related stuff.:-)
In many countries it is illegal to for a communications carrier to drop messages (e.g. e-mail) without notifying someone. However, you can generally choose between notifing the sender and notifying the recipient.
Notifying the recipient is the only technically "safe" course of action, since everything else may be forged and sending mail to it could be increasing the magnitude of the problem.
If the recipient then requests that you discard all such warning messages for him, then that's probably also legal - so it boils down to how you word the contract with the recipient.
I don't think law is really a practical obstacle in such cases. Additionally, in some countries in Europe (not sure about Germany) ISPs are granted specific permission to take steps to protect the network infrastructure from attacks, and virus outbreaks definately a form of attack.
Disclaimer: I work for FRISK on e-mail filtering, but I'm not a lawyer.:-)
Not true, most worms and viruses have spoofed the From address for quite a long time now.
Autoreplies have always been problematic at best, which anyone who's experienced the annoyance caused by vacation programs on public mailing lists can attest to. Autoreplies to automatically generated traffic have always been a no-no.
Viruses and worms are clearly autogenerated traffic.
Also, although 95% of computer users have never heard of FRISK, Fridrik has been a respected member of the A/V community since it very began and wrote one of the very first virus scanners.
Disclaimer: I work for FRISK, writing said e-mail filter code. But I can tell you with authority that the decision was taken a long time ago.
On the other hand, if you're unlucky enough to be running an MTA other than Sendmail as a mail hub, relaying to sendmails you don't have the access needed to upgrade, then the people you are relaying to are in trouble and you don't have many tools to protect them.
The sendmail patch protects machines relayed to - so people running sendmail on their mail hubs will have far less reason to worry about the machines behind them.;-)
Note that this also applies to ISPs using something other than sendmail - any linux/*bsd user who fetchmails his inbox and then pipes it through sendmail can get rooted that way as well. At the moment, ironically enough, the only umodified MTA which is known to protect the users behind it is: sendmail!
But just in case using a sendmail security bug as a reason for upgrading to sendmail seems distasetful to you, my open source Anomy Sanitizer has had code to prevent attacks like this for quite some time now. Or if you prefer throwing money at the problem, you could sign up for a managed e-mail security service (yes, they pay my salary).
It seems to me that people tend to forget that companies are just groups of people working together to accomplish something (e.g. put bread on the table). Companies aren't inherantly evil. Requesting money for service rendered is perfectly acceptable social behavior.
Giving a company your business or outright donating money to support a company you like are very similar decisions that as consumers we make every day. I avoid McDonald's because I don't like the company - even though I do actually like some of their food. I'm willing to go out of my way and even pay a little bit extra for friendly, polite, quality service. How are these decisions different from making a donation? To me they are the same. If you value service provided, you express your thanks - with cash (or code, or docs, or postcards). The Mandrake donation page makes that easier for people. How is that a problem?
I personally think that soliciting donations in return for providing alot of high quality software for free download is not only acceptable, it is quite commendable. More power to them, I hope the people using their free services have the decency to donate some cash. Those who don't donate are just ungrateful leeches. TAANSTAFL, etc.
It's really a shame that some quite vocal segments of the free software community seem to be a bit confused about things like this. They reflect badly on the rest of us. --
The AMaViS code is pretty messy - it is essentially a shell script, and as such relies
on invoking a great deal of external tools such
as find, file, grep, etc. And of course it needs
lots of disk space for temporary files. For
these reasons I've been very leery of using it
anywhere even a moderate mail load was to be
expected. Also, this may be a cheap shot since
they've fixed the worst problems since I noticed
them (quite a while ago), but there were some pretty bad security issues within AMaViS itself last time I looked.
Inflex is much cleaner, but still has the same
basic (IMO broken) design, and both lack alot of
features I want. For these reasons I started work on my own solution, the Anomy sanitizer.
Follow the link in my signature to check it out,
it's pretty reliable these days.
I'm the author of a free software program called
"the Anomy sanitizer". Click on my signature to
download it or read the readme.
Anomy allows you to define on a mail gateway
(sendmail, qmail or something else - Anomy is
mailer independant) what to do to different sorts of attachments. Options include "drop", "save",
"scan" (with a third party virus scanner), "mangle" (rename to avoid windows extension risks) and "accept".
Anomy is more powerful than Amavis or Inflex, in that it allows you to selectively scan/drop/... only certain types of files for viruses (thus saving CPU cycles when people are just swapping.gifs). So you can taylor it pretty carefully to match the needs of your customer. And Anomy should also be faster, since it doesn't need as many forks or use up temporary disk space for each message. Anomy is also aware of
non-MIME attachments, so all those uuencoded outlook-style attachments will get scanned. The same goes for nested MIME parts. Some of the other solutions get these things wrong, which means that things are likely to slip through.
Another feature Anomy has which the others lack, is a method for cleaning up risky HTML - disabling things like styles, javascript, ActiveX - all of which have had email security
related problems.
I wrote Anomy because I wasn't happy with any of
the other available free solutions, and I've
reached all of my technical goals - so I think it's fair to say that mine is better. It's also been pretty stable for the last few months. Now I just need to write a decent manual...:-)
--
Re:No Security on a Windows Network
on
Microsoft Cracked
·
· Score: 2
In short, I agree with you. But it's not limited
to Windows, even though that is currently the
riskiest platform by far.
As far as I can tell, defining and enforcing a
policy for what is acceptible as email content is
a very, very rare practise. I contend that it
shouldn't be, no matter what OS you are running.
Which is why I hang around on slashdot telling
people to click on my signature - I wrote an
open source filter which allows admins to do
just this.:-)
My program doesn't solve the problem. But it
helps - it allows the admin to make his internal
network immune to whole classes of attacks. That
can really make a difference. --
Email attachments, be they binaries or something
else, are far to valuable and useful to be
eliminated or banned.
Windows programs may be more vulnerable, but that
is largely due to how common they are - finding a
single bug has an impact on a huge number of
users. There have been, and probably still are
just as serious problems with Pine, Mutt and
other open source mailers. Exploiting them just
isn't as much fun...
So while it is true that email programs should be
more careful about their default behaviors, the
biggest problem still lies in the user's ignorance
of what is dangerous and what is not. No matter
how good the mailer is, social engineering can
still make email a security risk.
What has been IMHO lacking is a tool to help
those of us who do know what we are doing protect
the ignorant users from common mistakes and
problems, without making their lives too
difficult. This is more or less what all
firewalls do - and email should be firewalled in
the same way, for the same reasons. It's all
about risk management - the risk cannot be
eliminated.
This is only marginally related to the Microsoft
hack - but it is quite likely that if they had
had such a policy, and had automatically enforced
it wherever possible, then they wouldn't have been
hacked so easily.
There are tools to do this, which were inspired
by the obvious dangers posed by active HTML
content and malicious attachments. Follow the
link in my signature - I wrote one.:-)
--
I just thought I'd point out that those.src.rpm
files that you see on RedHat sites, in the SRPMS
directory, contain all patches that RedHat has
applied to that given package. To access them,
do a "rpm -i" on the source-RPM, and then check/usr/src/redhat/* for interesting stuff.
I've been using RedHat since 3.0, and have even
spent time rolling my own RedHat-based distro.
I also write code and release it as open source.
So I think I know what I'm talking about, when I say that I have yet to see RedHat do anything that is against the spirit of the "open source movement". Go pick on SuSE or Caldera...
Unlike you, I'd like to applaud RedHat for
some of those "pointless changes" that they made
- I love it that there is SSL support in things
like Samba and that they finally dropped inetd
for the vastly superior xinetd. These are genuine steps forward - they may
increase the learning curve for upgrading a bit,
but they have good reasons for doing these things.
I'm not sure I'm happy with the gcc thing, but
I'm not going to let it ruin my opinion of this
excellent company. So what if some of the new
stuff has bugs? They'll get fixed, just like they have in the past.
Unfortunately, no Linux distro has jails... so
I'm installing FreeBSD these days.:-)
I disagree, and my employers do as well (I work for a company which *maintains* software for the air traffic controllers in Iceland. Alot of traffic passes thorugh our air space.). I'm doing Linux stuff.
Having a specialized platform, with specialized features, is all well and good - but 5-10 years down the line it becomes a major liability. Unless your "specialized platform" is widely used and supported, you're going to run into serious trouble when the hardware you were using becomes hard or even impossible to buy, and nobody has created any drivers for the hardware you can buy.
With Linux (or other open source solutions) it seems you can have your cake and eat it too - you can customize and debug and hack it to suit your needs, while still having a huge community that supports and maintains all the commonly used stuff, like ethernet adapters and video hardware.
If people are devoting resources to creating an uncrashable system (which some people do need), then basing it on a widely used, widely supported open source solution makes a lot of sense.
So yes, I'd definately prefer a warship running Linux (or one of the BSDs) than one running its own written-from-scratch OS. The many eyeballs rule applies especially to highly critical systems. That doesn't mean I want the warship designers to cut corners - I want them to spend their time and efforts on the stuff that actually matters for the application, not drudgery like writing a whole new OS from scratch.
She does quite well. She's had Linux for under a week now, but she's already progressed from "how do I hold the mouse?" to sending me email about how much she likes it... that's almost entirely without my help, after showing her the basics once I left town.
It's running RedHat Linux 6.0, updated with KDE 1.1.2, and heavily tweaked by me to make it easier to use. Sure, it took me two days to configure the machine so that I was happy with it - but after I was done the result was really very good. With constantly improving distributions and apps, I expect that next time it won't take me two days to get even better results...
Linux just works. Making it work the way you want it to is getting easier every day - and that includes making it user friendly.
The problem with most usability tests, is people are testing users who already have Windows or Mac experience, and therefore expect certain things from their computers. If Windows users hate using Macs and vice versa, is it fair to expect either to like Linux? A valid test would involve a well configured machine and a complete newbie. I'm getting the distinct impression that Linux can do a pretty good job in that scenario.
For what it's worth, GNOME already uses Corba. They wrote their own (partially compliant?) ORB, named ORBit. KDE 1.x doesn't do Corba yet, but apparently 2.0, which adds this feature, is stabilizing fast.
I'm currently a KDE-user (and contributer...) myself, but I'm not religious about it, and I hate it when people get their facts wrong like that.:-)
As others have said - I just wish, wish, wish the GNOME and KDE people would get their heads out of... whereever it is they keep them, and standardize on a method which would allow their objects to interact seam- lessly. I have yet to see evidence that this is really happening, except in the drag-and-drop area.
The way things are going, this looks like something they'll "kludge together" after the fact, once each group has become firmly entrenched, for better or worse, in their respective architectures. Not being familiar with the Corba technology, I'm not sure whether such a kludge will be ugly or if it's even feasable... but I am a bit worried.
X does add overhead. Some think it is reasonable. I say that if your task involves client/server GUI interaction then great. But myself, and I'm sure many others, just use X for the GUI at the same machine the host is on and don't give a darn for the client/server architecture. Can't this be gutted out? #UNDEF CLIENT_SERVER If I want the taste of an orange, the solution is not to complain about how my apples don't taste like oranges: the solution is to replace the darn apples!
I don't know if it would be possible to create "X light" by removing the client/server stuff, or whether much would be gained by doing so.
But what you propose (a GUI w/o X) could be accomplished by porting e.g. Qt and the KDE libs (or GTK+ and the GNOME libs) to another, simpler platform, e.g. SVGAlib or GGI.
Voila, you'd have consistancy (nothing would run that didn't use those libs!), speed (fewer context switches, no networking slowing you down), etc. etc. But you wouldn't have access to all the good 'ole X apps, which is a serious drawback. So serious that very few developers think it's worth the effort. The ones that do, and care, are probably working on Berlin.
W.r.t. to this whole networking thing - I think it's a grossly underrated feature. I've used it extensively, especially when I'm squeezing the last few ounces of performance out of old hardware, by creating X terminals. Being able to run an app like Netscape 4.5 from a 386 class machine is IMHO not something to be sneered at!
I've also made good use of this feature at work, where my windows-bound co-workers run apps off my machine by using Exceed (a Windows X server).
I'm perfectly happy with the performance of X on all the machines I use (well, the 386s are a bit slow, but that's to be expected), and have repeatedly made good use of X's networking features. Having a powerful, stable, standards-compliant and most of all flexible operating system is what Linux is all about (technically speaking - freedom is also very important). X is IMHO a valuable part of that.
But each to his own - you wait for Berlin (or help them hack it), and I'll continue thinking up new ways to take advantage of the power already on my desktop.
I challenge anyone to complete basic tasks (such as switching applications, accessing menus, etc) faster in X than an experienced user can in Windows; any time a user has to reach for the mouse, there is a significant time wastage.
[snip]
Am I wrong? Why? I'd be happy to accept your challenge - you've described exactly the reason I've stuck with KDE as my X environment. It has lots of friendly, consistent hot-keys which were similaur enough to their Windows counterparts for me to "discover" them without having to read any manuals. Try it, you might like it.
You are guilty of doing the same thing as most of the other people in this thread - confusing X with the GUI. X is NOT a GUI. X is a platform for displaying rectangulaur pictures on your screen, and handling events from input devices. That's it!
X may or may not do a good job with it's designated task, but complaining about it's faults as a GUI is like complaining because your apples don't taste orange enough.
KDE is a GUI. GNOME is a GUI. If you want to complain about GUIs, try them and complain about them - criticism helps them improve. But please, please, please stop confusing the issue by complaining that X lets you use different styles of programs at the same time. If that really is so horrible, then just don't do it! Go without! But don't dis X for giving you the option.
Read the news page before argueing...
on
Some KDE news
·
· Score: 1
According to a post from 22 july, the estimated release date was about 4 weeks from then - unless it gets pushed back again.
Also, according to third-hand reports I've heard, they've decided to release it as 1.2, not 1.1.2. Those reports could be wrong (actually, I hope they are - 1.1.2 isn't radically different from 1.1.1), but who knows.
It is possible to deal with this sort of thing, although neither Linux, NT or any other OS I'm familiar with (which I'll admit aren't very many) implement it.
Check out LOMAC, it's a system that marks connections (and possibly files as well, I forget) as "untrustworthy" if they come from an untrustworthy medium, such as the internet. Untrusted processes can't mess with trusted stuff, no matter whether they are running as root or nobody...
Slashdot Mirror
Yes, it has been confirmed. Read my comment above, follow the links and see for yourself.
Downloads which are local to Iceland are "free" (included in the lease of the ADSL line), but international downloads are rather expensive.
This is exactly why DC++, with it's centralized hub-based architecture was so popular in Iceland. Anybody who understood both technology and copyright law knew better than to connect to them though, for exactly the same reasons.
However, the Register article was slightly misleading in implying that the traffic reduction was directly caused by the raid - it was more likely caused by the media coverage of the raid.
Basically, Joe Sixpacks all over the country read about the raids in their morning papers, paniced and turned off all their P2P apps. This includes the managers of the other DC++ hubs.
Traffic still hasn't returned to "normal".
If you actively update the "defense boxes" with all the latest exploits and then configure it to use it's full arsenal to take down any attacking hosts (e.g. by making all exploits simply turn off networking on the target machine), then you'll have a very high success rate indeed. Then only worms exploiting previously unknown holes on otherwise fully patched machines will be able to run unchecked. This raises the bar for worm writers by an order of magnitude... or two.
Note that I'm suggesting that the "counter attack" would be simply disable networking on the infected host. This is easier to get right than any sort of complex cleanup, thus lowering the odds that you'll break the infected machine. Also, a machine which keeps dropping off the network will eventually get attended to by a technician, who will hopefully disinfect and patch it properly.
This would also have the beneficial side-effect that worm authors would be forced to close the holes they exploit in order for their worms to live. This would suddenly mean that worms and viruses would be competing against each other instead of coexisting peacefully.
Frankly I hope someone writes such a thing and a government body or group of white hats simply deploys it. Or both. Then the internet will finally have an immune system.
The above support for AOL's actions is based on the fact that if I recall correctly, there are remotely expoitable problems with the Windows Messenger service. If my memory is playing tricks on me and the ONLY point was to disable annoying popups, then I don't condone this particular hack. But for an equivalent hack to close the Blaster hole or other similar ones, my argument is valid and I stand by it. :-)
If something like this backfires, then A) you know who is responsible and B) the responsible person can TURN IT OFF.
For most viruses and worms, neither A) nor B) can be guaranteed, which is why releasing worms into the wild is ALWAYS a bad idea, whether their payload is benign or not.
Proactive "hacking" of machines by ISPs is actually relatively easy to justify from a network-reliability point of view. As a network admin I frankly couldn't care less if you need Windows Messanger - if you're running it unpatched on my network then you're putting the rest of my network and the rest of my users at risk, which is unacceptable. So, basically, I agree with Russ. Go AOL!
This is what both the Razor and DCC projects are about, although their approaches differ slightly.
This is almost exactly what the DCC does. This strategy works very well for certain types of spam, but it doesn't catch everything and needs manual intervention to allow legitimate mailing list traffic through.
If the technical-minded people can opt out of the firewall then they're generally quite happy. In some cases they're even willing to pay a little bit extra, which is after all justifiable because the risk is higher for the ISP and offering this sort of thing adds complexity.
I realize this isn't technically feasable for all ISPs, but for many it provides an excellent solution.
Disclaimer: I work for FRISK on e-mail stuff.
The only problem is... you can't be sure that the server trying offering the infected mail isn't just a relay. If it's a relay then you're effectively instructing it to resend the entire message - virus and all - to the sender, which is an innocent thrid party.
This sort of scenario is the most common cause of the complaints about "A/V programs" which resend the entire virus, thus helping it spread.
So you're just passing the buck. It's understandable and I agree that this is a much better approach than most. But the ideal behavior, from a global network point of view, would be to reliably detect the infection as a massmailer (using a good A/V scanner) and /dev/null the message.
Disclaimer: I work for FRISK on e-mail related stuff. :-)
Notifying the recipient is the only technically "safe" course of action, since everything else may be forged and sending mail to it could be increasing the magnitude of the problem.
If the recipient then requests that you discard all such warning messages for him, then that's probably also legal - so it boils down to how you word the contract with the recipient.
I don't think law is really a practical obstacle in such cases. Additionally, in some countries in Europe (not sure about Germany) ISPs are granted specific permission to take steps to protect the network infrastructure from attacks, and virus outbreaks definately a form of attack.
Disclaimer: I work for FRISK on e-mail filtering, but I'm not a lawyer. :-)
Autoreplies have always been problematic at best, which anyone who's experienced the annoyance caused by vacation programs on public mailing lists can attest to. Autoreplies to automatically generated traffic have always been a no-no.
Viruses and worms are clearly autogenerated traffic.
Also, although 95% of computer users have never heard of FRISK, Fridrik has been a respected member of the A/V community since it very began and wrote one of the very first virus scanners.
Disclaimer: I work for FRISK, writing said e-mail filter code. But I can tell you with authority that the decision was taken a long time ago.
The sendmail patch protects machines relayed to - so people running sendmail on their mail hubs will have far less reason to worry about the machines behind them. ;-)
Note that this also applies to ISPs using something other than sendmail - any linux/*bsd user who fetchmails his inbox and then pipes it through sendmail can get rooted that way as well. At the moment, ironically enough, the only umodified MTA which is known to protect the users behind it is: sendmail!
But just in case using a sendmail security bug as a reason for upgrading to sendmail seems distasetful to you, my open source Anomy Sanitizer has had code to prevent attacks like this for quite some time now. Or if you prefer throwing money at the problem, you could sign up for a managed e-mail security service (yes, they pay my salary).
Giving a company your business or outright donating money to support a company you like are very similar decisions that as consumers we make every day. I avoid McDonald's because I don't like the company - even though I do actually like some of their food. I'm willing to go out of my way and even pay a little bit extra for friendly, polite, quality service. How are these decisions different from making a donation? To me they are the same. If you value service provided, you express your thanks - with cash (or code, or docs, or postcards). The Mandrake donation page makes that easier for people. How is that a problem?
I personally think that soliciting donations in return for providing alot of high quality software for free download is not only acceptable, it is quite commendable. More power to them, I hope the people using their free services have the decency to donate some cash. Those who don't donate are just ungrateful leeches. TAANSTAFL, etc.
It's really a shame that some quite vocal segments of the free software community seem to be a bit confused about things like this. They reflect badly on the rest of us.
--
Inflex is much cleaner, but still has the same basic (IMO broken) design, and both lack alot of features I want. For these reasons I started work on my own solution, the Anomy sanitizer. Follow the link in my signature to check it out, it's pretty reliable these days.
--
Anomy allows you to define on a mail gateway (sendmail, qmail or something else - Anomy is mailer independant) what to do to different sorts of attachments. Options include "drop", "save", "scan" (with a third party virus scanner), "mangle" (rename to avoid windows extension risks) and "accept".
Anomy is more powerful than Amavis or Inflex, in that it allows you to selectively scan/drop/... only certain types of files for viruses (thus saving CPU cycles when people are just swapping .gifs). So you can taylor it pretty carefully to match the needs of your customer. And Anomy should also be faster, since it doesn't need as many forks or use up temporary disk space for each message. Anomy is also aware of
non-MIME attachments, so all those uuencoded outlook-style attachments will get scanned. The same goes for nested MIME parts. Some of the other solutions get these things wrong, which means that things are likely to slip through.
Another feature Anomy has which the others lack, is a method for cleaning up risky HTML - disabling things like styles, javascript, ActiveX - all of which have had email security related problems.
I wrote Anomy because I wasn't happy with any of the other available free solutions, and I've reached all of my technical goals - so I think it's fair to say that mine is better. It's also been pretty stable for the last few months. Now I just need to write a decent manual... :-)
--
As far as I can tell, defining and enforcing a policy for what is acceptible as email content is a very, very rare practise. I contend that it shouldn't be, no matter what OS you are running.
Which is why I hang around on slashdot telling people to click on my signature - I wrote an open source filter which allows admins to do just this. :-)
My program doesn't solve the problem. But it helps - it allows the admin to make his internal network immune to whole classes of attacks. That can really make a difference.
--
Windows programs may be more vulnerable, but that is largely due to how common they are - finding a single bug has an impact on a huge number of users. There have been, and probably still are just as serious problems with Pine, Mutt and other open source mailers. Exploiting them just isn't as much fun...
So while it is true that email programs should be more careful about their default behaviors, the biggest problem still lies in the user's ignorance of what is dangerous and what is not. No matter how good the mailer is, social engineering can still make email a security risk.
What has been IMHO lacking is a tool to help those of us who do know what we are doing protect the ignorant users from common mistakes and problems, without making their lives too difficult. This is more or less what all firewalls do - and email should be firewalled in the same way, for the same reasons. It's all about risk management - the risk cannot be eliminated.
This is only marginally related to the Microsoft hack - but it is quite likely that if they had had such a policy, and had automatically enforced it wherever possible, then they wouldn't have been hacked so easily.
There are tools to do this, which were inspired by the obvious dangers posed by active HTML content and malicious attachments. Follow the link in my signature - I wrote one. :-)
--
I've been using RedHat since 3.0, and have even spent time rolling my own RedHat-based distro. I also write code and release it as open source. So I think I know what I'm talking about, when I say that I have yet to see RedHat do anything that is against the spirit of the "open source movement". Go pick on SuSE or Caldera...
Unlike you, I'd like to applaud RedHat for some of those "pointless changes" that they made - I love it that there is SSL support in things like Samba and that they finally dropped inetd for the vastly superior xinetd. These are genuine steps forward - they may increase the learning curve for upgrading a bit, but they have good reasons for doing these things. I'm not sure I'm happy with the gcc thing, but I'm not going to let it ruin my opinion of this excellent company. So what if some of the new stuff has bugs? They'll get fixed, just like they have in the past.
Unfortunately, no Linux distro has jails... so I'm installing FreeBSD these days. :-)
--
Having a specialized platform, with specialized features, is all well and good - but 5-10 years down the line it becomes a major liability. Unless your "specialized platform" is widely used and supported, you're going to run into serious trouble when the hardware you were using becomes hard or even impossible to buy, and nobody has created any drivers for the hardware you can buy.
With Linux (or other open source solutions) it seems you can have your cake and eat it too - you can customize and debug and hack it to suit your needs, while still having a huge community that supports and maintains all the commonly used stuff, like ethernet adapters and video hardware.
If people are devoting resources to creating an uncrashable system (which some people do need), then basing it on a widely used, widely supported open source solution makes a lot of sense.
So yes, I'd definately prefer a warship running Linux (or one of the BSDs) than one running its own written-from-scratch OS. The many eyeballs rule applies especially to highly critical systems. That doesn't mean I want the warship designers to cut corners - I want them to spend their time and efforts on the stuff that actually matters for the application, not drudgery like writing a whole new OS from scratch.
It's running RedHat Linux 6.0, updated with KDE 1.1.2, and heavily tweaked by me to make it easier to use. Sure, it took me two days to configure the machine so that I was happy with it - but after I was done the result was really very good. With constantly improving distributions and apps, I expect that next time it won't take me two days to get even better results...
Linux just works. Making it work the way you want it to is getting easier every day - and that includes making it user friendly.
The problem with most usability tests, is people are testing users who already have Windows or Mac experience, and therefore expect certain things from their computers. If Windows users hate using Macs and vice versa, is it fair to expect either to like Linux? A valid test would involve a well configured machine and a complete newbie. I'm getting the distinct impression that Linux can do a pretty good job in that scenario.
I'm currently a KDE-user (and contributer...) myself, but I'm not religious about it, and I hate it when people get their facts wrong like that. :-)
As others have said - I just wish, wish, wish the GNOME and KDE people would get their heads out of... whereever it is they keep them, and standardize on a method which would allow their objects to interact seam- lessly. I have yet to see evidence that this is really happening, except in the drag-and-drop area.
The way things are going, this looks like something they'll "kludge together" after the fact, once each group has become firmly entrenched, for better or worse, in their respective architectures. Not being familiar with the Corba technology, I'm not sure whether such a kludge will be ugly or if it's even feasable... but I am a bit worried.
I don't know if it would be possible to create "X light" by removing the client/server stuff, or whether much would be gained by doing so.
But what you propose (a GUI w/o X) could be accomplished by porting e.g. Qt and the KDE libs (or GTK+ and the GNOME libs) to another, simpler platform, e.g. SVGAlib or GGI.
Voila, you'd have consistancy (nothing would run that didn't use those libs!), speed (fewer context switches, no networking slowing you down), etc. etc. But you wouldn't have access to all the good 'ole X apps, which is a serious drawback. So serious that very few developers think it's worth the effort. The ones that do, and care, are probably working on Berlin.
W.r.t. to this whole networking thing - I think it's a grossly underrated feature. I've used it extensively, especially when I'm squeezing the last few ounces of performance out of old hardware, by creating X terminals. Being able to run an app like Netscape 4.5 from a 386 class machine is IMHO not something to be sneered at!
I've also made good use of this feature at work, where my windows-bound co-workers run apps off my machine by using Exceed (a Windows X server).
I'm perfectly happy with the performance of X on all the machines I use (well, the 386s are a bit slow, but that's to be expected), and have repeatedly made good use of X's networking features. Having a powerful, stable, standards-compliant and most of all flexible operating system is what Linux is all about (technically speaking - freedom is also very important). X is IMHO a valuable part of that.
But each to his own - you wait for Berlin (or help them hack it), and I'll continue thinking up new ways to take advantage of the power already on my desktop.
[snip]
Am I wrong? Why? I'd be happy to accept your challenge - you've described exactly the reason I've stuck with KDE as my X environment. It has lots of friendly, consistent hot-keys which were similaur enough to their Windows counterparts for me to "discover" them without having to read any manuals. Try it, you might like it.
You are guilty of doing the same thing as most of the other people in this thread - confusing X with the GUI. X is NOT a GUI. X is a platform for displaying rectangulaur pictures on your screen, and handling events from input devices. That's it!
X may or may not do a good job with it's designated task, but complaining about it's faults as a GUI is like complaining because your apples don't taste orange enough.
KDE is a GUI. GNOME is a GUI. If you want to complain about GUIs, try them and complain about them - criticism helps them improve. But please, please, please stop confusing the issue by complaining that X lets you use different styles of programs at the same time. If that really is so horrible, then just don't do it! Go without! But don't dis X for giving you the option.
According to a post from 22 july, the estimated release date was about 4 weeks from then - unless it gets pushed back again.
Also, according to third-hand reports I've heard, they've decided to release it as 1.2, not 1.1.2. Those reports could be wrong (actually, I hope they are - 1.1.2 isn't radically different from 1.1.1), but who knows.
Check out LOMAC, it's a system that marks connections (and possibly files as well, I forget) as "untrustworthy" if they come from an untrustworthy medium, such as the internet. Untrusted processes can't mess with trusted stuff, no matter whether they are running as root or nobody...
I like the idea alot, for a normal workstation.