Given my knowledge of MS OSes, that's basically 180 days with out a patch. You're asking for it. Or is it a box sitting in the corner, not connected to anything, idling along waiting for heat death of the universe (or hard drive crash).
Is there ANY app churn on this thing? No new apps have required a new MDAC/management hook/OS patch?
In my experience, it is not sitting still spinning electrons that causes MS OSes to crash, it is OS rot caused by churn. Sufficient churn causes OS rot THEN the spinning electrons tend to bump about somewhat. A stable OS install right out of the box that runs for a month straight will likely run for a year straight barring hardware/power issues IF you do not install/change anything. At least that's my experience.
OK you're right, any polluting country should be restricted to polluting only 'their' space.
So nuke plants are out, we'll keep using coal plants and dumping the pollution into 'our' atmosphere.
Re:As a former nuclear navy reactor operator
on
Port-A-Nuke
·
· Score: 2, Funny
----- How much did it cost to operate the nuclear reactor with the (hopefully) strict safety and security measurements and the corresponding training of its crew? ----
Significantly less than it would have to guard an extension cord that long:).
I understand but I disagree. You are correct there will be the little guys that do not publish SPF records and try to send mail. Unfortunately for them, they will be at best second class email citizens and at worse rejected in corporate email networks (once SPF is wide spread). Basically, no SPF record will equal "go to SPAM hell".
Now sales and marketing types aside, if it is an SPF 'spam hell' type of email it does not get to an employee (assume whitelist for customer domains). My filtering burden for non sales staff just got smaller and if Auntie Sue uses a small ISP without SPF then she better send email to your house/hotmail/yahoo/gmail/... not the office.
If large ISPs get many infected clients punching spam through their mailservers, it is in both the Net citizens and the ISPs interest to stop it (loads their servers, network, and business rep). So some level of control will occur at that level. Will it be perfect, not likely. Additionally if the ISP still is a pain and I have no customers using that ISP, see the Aunt Sue comment.
What does this mean to me, the corporate network guy? I drop from several thousands of SPAM mails a day to maybe several hundred for my 30 users. That reduces my disk requirements, my processing/processor requirements, and reduces the amount of time the staff plays whack-a-spam.
Sure the sales/marketing guys may still have an issue as I'm not going to risk potential business but the execs, the developers, and admin staff all get a 'free' reduction in SPAM. And when the execs get a reduction in spam, you can bet some sort of system will happen.
Bayes filtering was the first step, it failed BECAUSE AS YOU SAY the spammer could adapt. The entire point of SPF is the end user can not control the mechanism. No amount of fiddling with the message content (OK, some fake header magic may be possible, but COULD be closed and would be complex) will get it accepted without a good SPF record. Which, as you complain, is likely outside of the spammer's control. If it is not outside of your control (an ISP or large entity that spams), then it is REALLY easy to blacklist your domain. For those employees in sales, marketing, or other external, unsolicited, direct customer contact, we are still stuck with Bayes and friends BUT we have another weighted metric to add to the Bayesian bucket.
This is really a no lose for corporate entities IF they can get SPF records wide spread. As you pointed out, companies that value their rep WILL publish their own SPFs (we already have). So I think we can agree that SOME level of penetration will occur. If nothing else, even a minimal level of penetration could be used to improve/tune bayesian filters (e.g., have SPF start at -5, no SPF start at 0, I believe spamassassin is doing something similar).
The fight over whether this will happen is long over. The current fight is what form it will take, SPF, Sender ID, Hybrid, or some new scheme; and consequently, who will control/own it.
What you are REALLY saying is: SPF works just fine but it raises the bar of basic network administration IF you want to run a mailserver. For the bulk of the Internet 'unwashed masses' this works fine, their ISPs handle it and they send mail through the ISP's mailserver, the world is good. For MOST mailservers handling real traffic (the average home mailserver probably doesn't do much outbound traffic), it also works as those people handle all network admin tasks including DNS.
The gripe appears to be: well I'd like to run a mailserver for my own little domain but then I'd have to learn DNS or figure out another SPF solution in that space.
My response, MAYBE. In the short term that is probably correct but as SPF (or similar) becomes more popular some domain registrars will likely provide the service just like dotearth, godaddy, and friends do for basic mail redirects and web redirects today. They are already handling DNS for the mail and web redirects (typically a DNS CNAME entry), it would be trival for them to add a 'publish spf' checkbox to the mailserver entry (adding a TXT DNS entry for the domain).
SPAM is not magically going to go away without some work. While I can appreciate the fact you'd like to have someone else do the work while you reap the benefit, it is not a 'have your cake and eat it too' world. Small domain owners (like me as well) will have three choices, run DNS, 'pay' someone to run DNS (or may be free if you use registrar XXXXX), or start to get locked out of corporate mailservers.
I'm responsible for a corporate net for about 30 users and we block several THOUSAND spam mails a DAY. Believe me I will be implementing SPF or any and every other mechanism that allows me to better classify spam and keep it from the end users mailbox. The overhead of the users manually sorting all that spam everyday is NOT an option.
OK I'll bite. I fail to see how SPF only helps the big ISPs. Any little guy (running a domain) can publish his own SPF record. Any little guy (running a mail server) can check against existing SPF records. Checking against an SPF record will weed out (or at least certainly reduce) SPAM with forged source addresses (or make it harder to forge an acceptable address). Trackable SPAM is a definite improvement over the current state of affairs.
Obviously you have a beef with SPF. I seem to have missed it. So where's the beef?
No, anyone that sets up a mail gateway needs to know what he/she is doing. A departmental mail server that does not directly access mail from the outside world is not NECESSARILY a critical infrastructure resource/risk. (Note: I'm not recommending this, I don't run my network that way, I'm simply playing Satan's advocate here. Oh, and I've seen it before.)
Scenerio:
The organization has a mail gateway setup and run by people with a clue. Internally mail within the organization is routed to departmental mail servers used to shorten network paths for POP/exchange retrieval. All 'internal mail hosts' receive mail only from the official mail gateway and send all outbound mail through the official mail gateway (which scans/slices/dices/juliennes as it is run by the clued).
Advantages: Distribute mail admin to the departments that MAY be less than stellar in the clue department. Run the correct software as that department/subdivision requires (windows dev uses windows products, Unix departments use Unix based products) or has expertise in to maximize the clue factor. Reduce network paths for mail retrieval. Create buy-in at a lower corporate level than then 'corporate network gods/weenies'). Follow corporate culture that typically delegates to the departmental level.
Disadvantages: Possibility that internally generated 'attacks' can spread internally (soft chewy center security model issue). No single 'standard' mail 'server'. More complex environment.
It REALLY depends on your environment. Security is all about risk. Is the risk of my 'windoze admin' screwing up Linux more or less than my exposure from said admin properly configuring Exchange? (Note: risk is not only a virus getting through, it is also the risk of lost email, misrouted email, ability to correctly apply patches, downtime, whine factor, help desk cost,...).
More importantly, security is all about risk in your particular corporate environment. If your corporate culture is departmental level control, then it is likely that departmental level mail servers are a possibility.
Allowing a departmental level mail server setup that is point, click, and potentially shoot foot MAY be acceptable IF you can minimize damage to the corporate foot at a different level (corporate mail gateway, desktop anti-virus,...).
So IF you have a mixed bag of department skill levels, a corporate culture of departmental control and a need to be secure; don't rule anything out. Your cost structure may be minimized by allowing certain departments with less than stellar admins to run point and click and use that as leverage to lock down the corporate gateways. That combination with additional toys (desktop AV, EMAIL gateway AV, desktop installed 'spybot') deployed and managed by the clued, may provide a better cost/security ratio than force feeding clueless admins and staffing the help desk.
Sometimes you can't just fire the 'grandmother' running the departmental server you need to work with/around them. They don't know the apps, don't want to learn the apps, can't manage/install the apps, and like to whine about the apps in a Linux environment. Forcing them to do it your way is not always the correct choice, it creates political issues, increases cost, and does not necessarily increase security.
And yes I used the Grandmother/Desktop mantra on purpose. I'd hoped the admin set in their ways and the grandmother set in her ways symbolism would shine through without my being so non-PC as to have to point out that some admins (and instance on using some software) are less than stellar, I'll buy a bigger flashlight in the future.:)
Oh and as a side note, we can explore the Linux specific side of the coin: sendmail vs. postfix vs. qmail vs.... OR we can agree that 'it depends on familiarity/environment/staff/culture';).
Actually I was taking exception to the 'anyone can do anything in Linux' mantra that is so often spouted. The grandmother argument seemed the obvious sarcastic approach to the 'problem'. Obviously if you know Linux and sendmail/postfix/qmail/... you are qualified to use it, if you know Exchange, you MIGHT be better using that. The 'you should do it in Linux, because anyone can do anything in Linux because they have the source' mantra is just blowing smoke up people's butts. Not everyone can do everything. Sometimes it is better/safer/more secure to use a tools you know (with limitations you know) that learn a new tool and screw it up.
ANYONE can decide to write a setup program for Sendmail. Full availability of the source makes that possible.
My grandmother can't, my mother can't, and most 10 year olds can't (OK they can DECIDE, but they're usually not so stupid as to reach that far beyond their abilities). There IS a target market for "point, click, and shoot foot", as long as the damage to the foot is minimal. IMO, linux is not there YET, it gets better every day, but not there yet. The main reason is the lack of bundled apps that crowd needs/wants. Yes, open source alternatives exist for some of them, more each month. But it is not always an "easy to find, easy to install" process for that crowd.
Wrong experts, these are hard science types with small budgets. They are not going to waste any cash on that pseudoscience psychobabble crap, nary a psychologist on staff, I'd bet. Hell probably get two good physicists for the cost of one babbler.:-).
I've never forgotten to update serials or had a dot problem. There is a tool called h2n that takes a standard host file and generates all zones needed for bind. I think the discussion misses the point, BIND is the standard, tools exist to generate the zones, it works, it is reasonably bug free given today's definition (low to moderate instances, quick fixes), it is the default install on most *nix, and help/doco is everywhere. Why would the AVERAGE guy change? (Yes, security geeks might, windows guys hate unix tools, newer toys to play with exist, and some people just have to be different, but why would Joe Average?).
Entropy doesn't make it a bad idea. Assume 85% of the energy used is converted to heat, further assume you can reclaim the heat to charge at say 40% (yeah, the numbers are made up, I providing an example, not an engineering spec), then 'charge life' can, in theory, be extended by about 30%. Entropy still exists in this world, I am not claiming to get 100% efficiency. The real world issue is not with the idea but with the term 'effective'.
Because next you'll want a faster way to connect your 8 inch floppies and 9 track tape. Oh yeah, and I bet you need a faster interface between your sound card and your 8-track player.
It also doesn't work for companies that use different inbound and outbound mail gateways. Mail comes in to our inbound mail gateway where it is sanitized (we do things like tarpitting, virus checking, spamassassin, and such). Outbound mail goes out via a different host with virus checking, different internal/intraoffice routing, but no spam assassin and other such. Easier to use two PCs and two IPs than deal with crazy routing and processing requirements. Also different offices may send directly but all inbound mail routes thru a central hub to simplify virus and spam checking.
Re:Port Knocking won't hide your servers from yr I
on
Port Knocking in Action
·
· Score: 0, Flamebait
And what part of 'in operation' did you miss? During an ssh session the fact that ssh is running will certainly show up on a sniffer, if it didn't, there would not be packets and the connection would not exit. I did not see SCAN anywhere in the original post, so if you want to blast someone's post, please at least read the post (yeah I know it breaks slashdot tradition but it DOES improve the signal to noise ratio).
Ahh yes a real world example of the bear joke. For the uninformed:
Two fishermen are suprised by an angry bear in the woods. The first guy looks at the second guy and says, let's run. The second guy says, you can't outrun a bear. The first guy points out, I don't have to outrun a bear, I just have to outrun you.
Problem: for all you know, the 'second guy' has been practicing or eventually all the slow 'second guys' get eaten by bears. Either way, ultimately you too get eaten by a bear. So this is not really a good strategy, IMO.
The mail system has come under virus attack, several accounts including your account have been attacked and have been suspended. We have included a form that you will need to fill out in order to have mail service restored. Since the form includes spaces for a new password and some personal information, it has been encrypted. The password on the form is: xxxxx, please forward the form to supportstaff@yourcompany.com after completion.
Obviously you should NOT include the form password in the return mail or your password and personal information could be compromised again.
-- The support staff
It has all the correct domain names filled in, reasonable to/from headers (the rec'd headers are obviously bad but outlook and several other mailers do not show those without asking and most non techies do not ask), and reasonable generic addresses to forward to (supportstaff@xxx or helpdesk@xxx).
Like I said, pretty good, not perfect but definitely very good luser bait. Unfortunately we DO get encrypted files from off-site so blocking ALL encrypted files is not an option. Guess it's time to build an encrypted file whitelist [sigh].
Actually most virus arrivals now do need a luser. Email gateways are doing more scanning and keeping outlook users from becoming auto-lusers. However, one of the latest/best scams is to zip the virus and password protect it (quasi-encrypted) so the gateway scanner can not scan it. Then include instructions in the email that social engineer some luser into unzipping it with the supplied password and running it. I've seen some pretty good email virus scams recently, the text is REALLY good, definitely luser friendly.
People make incorrect assumptions about brand names all the time, why?
Last time I looked (admittedly awhile back) a lot of the Hondas and Toyotas were made in the USA and may of the popular bottom of the line Fords were made in Mexico. So I'd say thanks for buying American !
--Because we all know Corporations policing is a VERY GOOD THING!tm
OK, corporate policing is a bad thing, so any spammer should be able to get an account on any ISP and send out spam in violation of the AUP agreement and the corporation shouldn't police it. Excellent plan!
Do you work for a spammer? Do you live on planet earth? Do you actually use an email account? Do you resemble the second word of 'knee jerk'?
Yes, arbitrary ISP restrictions suck, justified ISP restrictions do not. Yes, justified is frequently defined by the ISP but it is also policed by the users (via ISP change). Let the free market do the free market thing.
Actually MS bought a company called RAV antivirus. They had a really good Linux product that I used. Since the buy out (several months), the Linux version has been discontinued. If the engine is RAV, it was really good and the staff was good with timely updates.
PLEASE. Let's back up. Science believed (at one point) that the Earth was the center of the universe. Data gathered scientifically is probably correct but conclusions drawn from that data are conclusions not scientific fact. Conclusions are subject to bias. As an example, if I take data from just after the last ice age and measure the climatic change I'm quite sure I'll see 'global warming', scientific fact, the temperature is increasing over time. The conclusion that it is a direct result of the pesty humans and the fires they build in their caves is conclusion. Even if I add several other pieces of evidence to the pot, it is still conclusion. Admittedly as the pieces of evidence accumulate the conclusion becomes more likely (or unlikely) but without a direct chain of uninterpeted data evidence (which almost never occurs) it is never 'sure'. Newtonian physics was a 'sure thing' until quantum mechanics.
Mathematics is about the only 'scientific' field that can claim theories (or theorems) are either provably correct or incorrect and even in math the bulk of the interesting stuff is 'unknown'.
Cool then General Motors can pay a spammer to advertize Ford and let Ford get stuck with the penalty/bill. Great method to allow companies to put their competition out of business.
Slashdot Mirror
Given my knowledge of MS OSes, that's basically 180 days with out a patch. You're asking for it. Or is it a box sitting in the corner, not connected to anything, idling along waiting for heat death of the universe (or hard drive crash).
Is there ANY app churn on this thing? No new apps have required a new MDAC/management hook/OS patch?
In my experience, it is not sitting still spinning electrons that causes MS OSes to crash, it is OS rot caused by churn. Sufficient churn causes OS rot THEN the spinning electrons tend to bump about somewhat. A stable OS install right out of the box that runs for a month straight will likely run for a year straight barring hardware/power issues IF you do not install/change anything. At least that's my experience.
OK you're right, any polluting country should be restricted to polluting only 'their' space.
So nuke plants are out, we'll keep using coal plants and dumping the pollution into 'our' atmosphere.
-----
:).
How much did it cost to operate the nuclear reactor with the (hopefully) strict safety and security measurements and the corresponding training of its crew?
----
Significantly less than it would have to guard an extension cord that long
I understand but I disagree. You are correct there will be the little guys that do not publish SPF records and try to send mail. Unfortunately for them, they will be at best second class email citizens and at worse rejected in corporate email networks (once SPF is wide spread). Basically, no SPF record will equal "go to SPAM hell".
Now sales and marketing types aside, if it is an SPF 'spam hell' type of email it does not get to an employee (assume whitelist for customer domains). My filtering burden for non sales staff just got smaller and if Auntie Sue uses a small ISP without SPF then she better send email to your house/hotmail/yahoo/gmail/... not the office.
If large ISPs get many infected clients punching spam through their mailservers, it is in both the Net citizens and the ISPs interest to stop it (loads their servers, network, and business rep). So some level of control will occur at that level. Will it be perfect, not likely. Additionally if the ISP still is a pain and I have no customers using that ISP, see the Aunt Sue comment.
What does this mean to me, the corporate network guy? I drop from several thousands of SPAM mails a day to maybe several hundred for my 30 users. That reduces my disk requirements, my processing/processor requirements, and reduces the amount of time the staff plays whack-a-spam.
Sure the sales/marketing guys may still have an issue as I'm not going to risk potential business but the execs, the developers, and admin staff all get a 'free' reduction in SPAM. And when the execs get a reduction in spam, you can bet some sort of system will happen.
Bayes filtering was the first step, it failed BECAUSE AS YOU SAY the spammer could adapt. The entire point of SPF is the end user can not control the mechanism. No amount of fiddling with the message content (OK, some fake header magic may be possible, but COULD be closed and would be complex) will get it accepted without a good SPF record. Which, as you complain, is likely outside of the spammer's control. If it is not outside of your control (an ISP or large entity that spams), then it is REALLY easy to blacklist your domain. For those employees in sales, marketing, or other external, unsolicited, direct customer contact, we are still stuck with Bayes and friends BUT we have another weighted metric to add to the Bayesian bucket.
This is really a no lose for corporate entities IF they can get SPF records wide spread. As you pointed out, companies that value their rep WILL publish their own SPFs (we already have). So I think we can agree that SOME level of penetration will occur. If nothing else, even a minimal level of penetration could be used to improve/tune bayesian filters (e.g., have SPF start at -5, no SPF start at 0, I believe spamassassin is doing something similar).
The fight over whether this will happen is long over. The current fight is what form it will take, SPF, Sender ID, Hybrid, or some new scheme; and consequently, who will control/own it.
OK BUT ... (as they say)
What you are REALLY saying is: SPF works just fine but it raises the bar of basic network administration IF you want to run a mailserver. For the bulk of the Internet 'unwashed masses' this works fine, their ISPs handle it and they send mail through the ISP's mailserver, the world is good. For MOST mailservers handling real traffic (the average home mailserver probably doesn't do much outbound traffic), it also works as those people handle all network admin tasks including DNS.
The gripe appears to be: well I'd like to run a mailserver for my own little domain but then I'd have to learn DNS or figure out another SPF solution in that space.
My response, MAYBE. In the short term that is probably correct but as SPF (or similar) becomes more popular some domain registrars will likely provide the service just like dotearth, godaddy, and friends do for basic mail redirects and web redirects today. They are already handling DNS for the mail and web redirects (typically a DNS CNAME entry), it would be trival for them to add a 'publish spf' checkbox to the mailserver entry (adding a TXT DNS entry for the domain).
SPAM is not magically going to go away without some work. While I can appreciate the fact you'd like to have someone else do the work while you reap the benefit, it is not a 'have your cake and eat it too' world. Small domain owners (like me as well) will have three choices, run DNS, 'pay' someone to run DNS (or may be free if you use registrar XXXXX), or start to get locked out of corporate mailservers.
I'm responsible for a corporate net for about 30 users and we block several THOUSAND spam mails a DAY. Believe me I will be implementing SPF or any and every other mechanism that allows me to better classify spam and keep it from the end users mailbox. The overhead of the users manually sorting all that spam everyday is NOT an option.
OK I'll bite. I fail to see how SPF only helps the big ISPs. Any little guy (running a domain) can publish his own SPF record. Any little guy (running a mail server) can check against existing SPF records. Checking against an SPF record will weed out (or at least certainly reduce) SPAM with forged source addresses (or make it harder to forge an acceptable address). Trackable SPAM is a definite improvement over the current state of affairs.
Obviously you have a beef with SPF. I seem to have missed it. So where's the beef?
No, anyone that sets up a mail gateway needs to know what he/she is doing. A departmental mail server that does not directly access mail from the outside world is not NECESSARILY a critical infrastructure resource/risk. (Note: I'm not recommending this, I don't run my network that way, I'm simply playing Satan's advocate here. Oh, and I've seen it before.)
...).
...).
:)
... OR we can agree that 'it depends on familiarity/environment/staff/culture' ;).
Scenerio:
The organization has a mail gateway setup and run by people with a clue. Internally mail within the organization is routed to departmental mail servers used to shorten network paths for POP/exchange retrieval. All 'internal mail hosts' receive mail only from the official mail gateway and send all outbound mail through the official mail gateway (which scans/slices/dices/juliennes as it is run by the clued).
Advantages: Distribute mail admin to the departments that MAY be less than stellar in the clue department. Run the correct software as that department/subdivision requires (windows dev uses windows products, Unix departments use Unix based products) or has expertise in to maximize the clue factor. Reduce network paths for mail retrieval. Create buy-in at a lower corporate level than then 'corporate network gods/weenies'). Follow corporate culture that typically delegates to the departmental level.
Disadvantages: Possibility that internally generated 'attacks' can spread internally (soft chewy center security model issue). No single 'standard' mail 'server'. More complex environment.
It REALLY depends on your environment. Security is all about risk. Is the risk of my 'windoze admin' screwing up Linux more or less than my exposure from said admin properly configuring Exchange? (Note: risk is not only a virus getting through, it is also the risk of lost email, misrouted email, ability to correctly apply patches, downtime, whine factor, help desk cost,
More importantly, security is all about risk in your particular corporate environment. If your corporate culture is departmental level control, then it is likely that departmental level mail servers are a possibility.
Allowing a departmental level mail server setup that is point, click, and potentially shoot foot MAY be acceptable IF you can minimize damage to the corporate foot at a different level (corporate mail gateway, desktop anti-virus,
So IF you have a mixed bag of department skill levels, a corporate culture of departmental control and a need to be secure; don't rule anything out. Your cost structure may be minimized by allowing certain departments with less than stellar admins to run point and click and use that as leverage to lock down the corporate gateways. That combination with additional toys (desktop AV, EMAIL gateway AV, desktop installed 'spybot') deployed and managed by the clued, may provide a better cost/security ratio than force feeding clueless admins and staffing the help desk.
Sometimes you can't just fire the 'grandmother' running the departmental server you need to work with/around them. They don't know the apps, don't want to learn the apps, can't manage/install the apps, and like to whine about the apps in a Linux environment. Forcing them to do it your way is not always the correct choice, it creates political issues, increases cost, and does not necessarily increase security.
And yes I used the Grandmother/Desktop mantra on purpose. I'd hoped the admin set in their ways and the grandmother set in her ways symbolism would shine through without my being so non-PC as to have to point out that some admins (and instance on using some software) are less than stellar, I'll buy a bigger flashlight in the future.
Oh and as a side note, we can explore the Linux specific side of the coin: sendmail vs. postfix vs. qmail vs.
Actually I was taking exception to the 'anyone can do anything in Linux' mantra that is so often spouted. The grandmother argument seemed the obvious sarcastic approach to the 'problem'. Obviously if you know Linux and sendmail/postfix/qmail/... you are qualified to use it, if you know Exchange, you MIGHT be better using that. The 'you should do it in Linux, because anyone can do anything in Linux because they have the source' mantra is just blowing smoke up people's butts. Not everyone can do everything. Sometimes it is better/safer/more secure to use a tools you know (with limitations you know) that learn a new tool and screw it up.
ANYONE can decide to write a setup program for Sendmail. Full availability of the source makes that possible.
My grandmother can't, my mother can't, and most 10 year olds can't (OK they can DECIDE, but they're usually not so stupid as to reach that far beyond their abilities). There IS a target market for "point, click, and shoot foot", as long as the damage to the foot is minimal. IMO, linux is not there YET, it gets better every day, but not there yet. The main reason is the lack of bundled apps that crowd needs/wants. Yes, open source alternatives exist for some of them, more each month. But it is not always an "easy to find, easy to install" process for that crowd.
Wrong experts, these are hard science types with small budgets. They are not going to waste any cash on that pseudoscience psychobabble crap, nary a psychologist on staff, I'd bet. Hell probably get two good physicists for the cost of one babbler. :-).
I've never forgotten to update serials or had a dot problem. There is a tool called h2n that takes a standard host file and generates all zones needed for bind. I think the discussion misses the point, BIND is the standard, tools exist to generate the zones, it works, it is reasonably bug free given today's definition (low to moderate instances, quick fixes), it is the default install on most *nix, and help/doco is everywhere. Why would the AVERAGE guy change? (Yes, security geeks might, windows guys hate unix tools, newer toys to play with exist, and some people just have to be different, but why would Joe Average?).
Cool, I could use a new bike, mine's in the shop. :-)
Entropy doesn't make it a bad idea. Assume 85% of the energy used is converted to heat, further assume you can reclaim the heat to charge at say 40% (yeah, the numbers are made up, I providing an example, not an engineering spec), then 'charge life' can, in theory, be extended by about 30%. Entropy still exists in this world, I am not claiming to get 100% efficiency. The real world issue is not with the idea but with the term 'effective'.
Because next you'll want a faster way to connect your 8 inch floppies and 9 track tape. Oh yeah, and I bet you need a faster interface between your sound card and your 8-track player.
It also doesn't work for companies that use different inbound and outbound mail gateways. Mail comes in to our inbound mail gateway where it is sanitized (we do things like tarpitting, virus checking, spamassassin, and such). Outbound mail goes out via a different host with virus checking, different internal/intraoffice routing, but no spam assassin and other such. Easier to use two PCs and two IPs than deal with crazy routing and processing requirements. Also different offices may send directly but all inbound mail routes thru a central hub to simplify virus and spam checking.
And what part of 'in operation' did you miss? During an ssh session the fact that ssh is running will certainly show up on a sniffer, if it didn't, there would not be packets and the connection would not exit. I did not see SCAN anywhere in the original post, so if you want to blast someone's post, please at least read the post (yeah I know it breaks slashdot tradition but it DOES improve the signal to noise ratio).
Ahh yes a real world example of the bear joke. For the uninformed:
Two fishermen are suprised by an angry bear in the woods. The first guy looks at the second guy and says, let's run. The second guy says, you can't outrun a bear. The first guy points out, I don't have to outrun a bear, I just have to outrun you.
Problem: for all you know, the 'second guy' has been practicing or eventually all the slow 'second guys' get eaten by bears. Either way, ultimately you too get eaten by a bear. So this is not really a good strategy, IMO.
Actually the wording is along the lines of:
The mail system has come under virus attack, several accounts including your account have been attacked and have been suspended. We have included a form that you will need to fill out in order to have mail service restored. Since the form includes spaces for a new password and some personal information, it has been encrypted. The password on the form is: xxxxx, please forward the form to supportstaff@yourcompany.com after completion.
Obviously you should NOT include the form password in the return mail or your password and personal information could be compromised again.
-- The support staff
It has all the correct domain names filled in, reasonable to/from headers (the rec'd headers are obviously bad but outlook and several other mailers do not show those without asking and most non techies do not ask), and reasonable generic addresses to forward to (supportstaff@xxx or helpdesk@xxx).
Like I said, pretty good, not perfect but definitely very good luser bait. Unfortunately we DO get encrypted files from off-site so blocking ALL encrypted files is not an option. Guess it's time to build an encrypted file whitelist [sigh].
Actually most virus arrivals now do need a luser. Email gateways are doing more scanning and keeping outlook users from becoming auto-lusers. However, one of the latest/best scams is to zip the virus and password protect it (quasi-encrypted) so the gateway scanner can not scan it. Then include instructions in the email that social engineer some luser into unzipping it with the supplied password and running it. I've seen some pretty good email virus scams recently, the text is REALLY good, definitely luser friendly.
People make incorrect assumptions about brand names all the time, why?
Last time I looked (admittedly awhile back) a lot of the Hondas and Toyotas were made in the USA and may of the popular bottom of the line Fords were made in Mexico. So I'd say thanks for buying American !
--Because we all know Corporations policing is a VERY GOOD THING!tm
OK, corporate policing is a bad thing, so any spammer should be able to get an account on any ISP and send out spam in violation of the AUP agreement and the corporation shouldn't police it. Excellent plan!
Do you work for a spammer? Do you live on planet earth? Do you actually use an email account? Do you resemble the second word of 'knee jerk'?
Yes, arbitrary ISP restrictions suck, justified ISP restrictions do not. Yes, justified is frequently defined by the ISP but it is also policed by the users (via ISP change). Let the free market do the free market thing.
Since we started using Microsoft software (sorry couldn't resist).
Actually MS bought a company called RAV antivirus. They had a really good Linux product that I used. Since the buy out (several months), the Linux version has been discontinued. If the engine is RAV, it was really good and the staff was good with timely updates.
PLEASE. Let's back up. Science believed (at one point) that the Earth was the center of the universe. Data gathered scientifically is probably correct but conclusions drawn from that data are conclusions not scientific fact. Conclusions are subject to bias. As an example, if I take data from just after the last ice age and measure the climatic change I'm quite sure I'll see 'global warming', scientific fact, the temperature is increasing over time. The conclusion that it is a direct result of the pesty humans and the fires they build in their caves is conclusion. Even if I add several other pieces of evidence to the pot, it is still conclusion. Admittedly as the pieces of evidence accumulate the conclusion becomes more likely (or unlikely) but without a direct chain of uninterpeted data evidence (which almost never occurs) it is never 'sure'. Newtonian physics was a 'sure thing' until quantum mechanics.
Mathematics is about the only 'scientific' field that can claim theories (or theorems) are either provably correct or incorrect and even in math the bulk of the interesting stuff is 'unknown'.
Cool then General Motors can pay a spammer to advertize Ford and let Ford get stuck with the penalty/bill. Great method to allow companies to put their competition out of business.