To me, it did not seem that the term "the leading desktop environment" was used in an exclutinary manner - rather, it seemed that the intention was to explain what KDE is (to the occasional Windows-only user that happens upon/.)
Sort of like Ford, the leading auto maker (even though they are probably not the worlds largest).
-tor
PS. I use Gnome and WindowMaker. KDE is a bit too "all-or-nothing" for me.
Given that so many already have sold this stock short, and will have to buy it back at some point, the stock price will remain high for a while (even after it's blindingly obvious that the company is doomed).
You know, rather than blocking all IP's owned by ComCast, you could filter your mails via the RBL at dynablock.easynet.dl. This lists dynamic IP ranges given out by the likes of Comcast for residential customers. Indeed, ComCast & other ISPs are the ones contributing these address ranges to the maintainers of that RBL.
It sounds like the original poster's ISP is blocking inbound traffic to port 25 on his own server -- that's why he raised the question of SMTP on a different port (which, by the way, is mostly useless).
The updated article, with the bit about Charter blocking direct outbound SMTP connections, should not be much of a problem for the casual home user - even those that wish to run their own inbound SMTP server. Simply set the SMTP server up to use the designated smarthost.
Moreover, many MTAs now reject incoming mails received directly from an ISP's dynamic IP address ranges. For instance, the RBL at dynablock.easynet.nl is being used by a default SpamAssassin configuration (score 2.6 or so). So even if your ISP did not block outbound SMTP, the recipient may never actually get your message if you send it directly from your IP address.
If you are concerned with security (cfr. the reference to SSL), you really ought to encrypt your messages (with PGP or similar).
The ISP is trying to prevent your host from being an open SMTP relay, by shutting down inbound port 25.
Although this helps a little bit in the fight against spam, the effect is not as large as your ISP thinks. Spammer/cracker gangs nowadays use viruses to infect zombie hosts (virii typically use ports 80 to infect IIS, or ports 135-139 to infect the CIFS filesharing). Once on your machine, these virii can easily send out spam on outbound port 25, no matter if your ISP blocks the inbound port or not.
Explain this to them, maybe they'll reconsider... (Yeah,right).
You could add both a "From: " and a "Sender: " header to your usenet/mailing list postings:
From: you@yourdomain
Sender: blockme@yourdomain
You'll gets tons of spam to both addresses (not neccessarily the same spam, unfortunately - that would make filtering real easy). You run SpamAssassin (or similar) to filter mail to your real address, and you run "spamassassin -r" or "razor-report" to handle mails sent to your spamtrap address (making the Razor service, and in turn, SpamAssassin, more efficient at identifying these spams).
Better yet, if your MTA is Exim, use SA-Exim to add teergrubing functionality to SpamAssassin. Oh, the satisfaction!:-)
Sorry for restating the obvious, but it seems that the person already was receiving these calls to his phone (he may not even have a fax machine, for what we know).
I know this problem myself. Periodically I would receive calls with nobody (just dead silence) on the other end. Last year I purchased one of these multi-function devices (printer, fax, scanner, copier..) and, stupidly enough, enabled the fax receiver (It would let me or my answering machine pick up the phone, then if it turned out to be a fax call, take it from there). After a few days, I received my first fax spam, and did not think much of it. But apparently, just like with an e-mail address, once my now fax-enabled number is out, it's hard to contain the calls.
This is about a year ago now. After receiving about 3-4 spam faxes, I figured out what was going on, and turned off the automatic fax receiver feature. Fax calls kept coming for a while (basically just annoying beeps on the phone line to me), and an occasional fax call still comes to this day.
Of course fax spams are illegal according to US code, but I never took the matter up with these senders and/or the legal system. Indeed, I am not even certain if the sender's number (as listed on the top of the page) is reliable, and/or legal evidence.
Bottom line in these days of spams, scams, and such and abundance of dishonest people (combined with underresourced / ineffective government oversight), is that you have to be extremely vigilent to avoid both this type of fax/email/phone solicitations, as well as more serious trouble like ID theft, credit card fraud, etc. That's just the world we have created, with this overemphasis on capitalism & money, and underemhpasis on human values.
Just to play devils advocate here, but this is no different from Linux/OSS/BSD/Apple software. There have been SSH problems surfacing lately, and who knows if there will be say, an exploit to own someone box through apple's mail.app tomorrow.
Although you are philosophically/theoretically correct, this is probably not a good example. The recent OpenSSH (application, not protocol) vulnerabilities are near, if not entirely, non-exploitable - especially compared to the large gaping holes that are still present in M$ {Win*,IE,Office,Outlook*,...}.
It would be even more far-fetched to see this vulnerability provide access to Mail.app, since "Remote Login/SSH" is turned off by default on MacOSX, and because Apple has released a fixed version of OpenSSH via the "Software Update" feature (which is turned on by default on Internet-enabled OSX boxes).
That said, UNIX/Linux certainly have a long history with many very large holes in it. If you put a RedHat 6.2 box on the internet, chances are you'll be r00ted in 15 minutes or less.
No. Exploits are usually released with major operating system upgrades, not patches.
No. Vulnerabilities are usually released with major operating system upgrades, and sometimes with patches.
Exploits (that take advantage of these) are usually released by third parties, usually shortly before or after a patch is released by the OS vendor to fix the vulnerability (and perhaps introduce new ones).
Print to PDF from Mac vs Export from OO
on
OpenOffice.org Hits 1.1
·
· Score: 5, Interesting
You know, in Mac OS X [...] you can export a document from any application to PDF format, as long as that application supports printing.
True, however those PDFs are HUGE compared to those that OpenOffice creates -- with no seeming improvement in quality. Indeed, the OO seems a bit better at detailed pictures etc.
I printed a 3.2MB MS PowerPoint presentation to PDF from a Mac, and the resulting file was 22MB. I exported the same file from OO v1.1 (which, by the way, has been in Debian 'sid' since Sep 25), and the resulting size was 2.3MB.
Indeed, the PDF created from OO seemed smoother (despite having to import a foreign document format) than the one created via the "Print to PDF..." option in the Mac OS X print dialogue.
3) US "H1-B" visas, and related visas, within the US afford much longer than 6 years residency. Our average "H1-B" visa employee has resided in the US for over 14 years. It is very common for "H1-B" visa holders to "reset" their qualification process for "Green Card" application numerous times as they change jobs.
No, the H1-B visa allows for a grand total of 6 years only. (Believe me, I have first-hand experience in almost running into that limit, with no possibility of extension, before the "timely" issue of a green card).
The average person who initially gets employed on a H1-B may well reside in the US for 14 years (your assertion, not mine) - a significant percentage of H1-B visa holders eventually obtain a green card (and/or citizenship).
Personally, I came on a F-1 visa as a student + 1 year on a practial trainee program; 6 years on a H1-B VISA, and now as a permanent resident.
4) Your understanding of how globalized markets work operate is so simplistic that it does not even deserve a USA-Today level of readership. Try applying a little more economic extrapolation to the subject than you learned in freshman economics.
Sure it is simplistic - This is not exactly the type of forum where you go into the lower level details. But the bottom line is exactly as I said - the US has been pushing for free trade (even trade "subsidies" in the form of tax breaks for exporters); it follows that products and services get imported more as well as exported more.
Companies like IBM try (perhaps misguidedly) to maximize their profitablity by outsourcing functions to India, so as not to lose ground against other companies that already operate in, say, India (based there or not).
Since the US is a net-importer, and India enjoys numerous protectionist barriers, there is a net flow of wealth from the US into India whereas global trade and commerce are concerned.
According to the CIA World Fact Book, India (just like the USA) is a net importer.
Inflammatory subject. Here is a reality check.
on
No Americans Need Apply
·
· Score: 5, Informative
The title "No Americans Need Apply" is both incorrect w.r.t. working in India (or other countries) in general, and only serve to rile up the more, ahem, chauvinist elements among the (American) Slashdot readership.
In order to work in India, you need a work permit. Not knowing exactly the procedure for obtaining a work permit in India, I can only speculate that one will normally be issued only for jobs/diciplines for which there is no qualified native applicants.
That's the same way it works in the USA. In order for foreigners to get a work permit (a H1-B visa), the prospective employer must:
Advertise the position publicly for 60 days
Demonstrate that the candidate has unique skills pertaining to the job
Be unable to find qualified candidates that are either citizens or permanent residents.
The H1-B visa is temporary (expires after 3 years, can be renewed for a grand total of 6 years). This is kind of unique - not many other countries have this restriction.
Finally, a H1-B visa is tied to a particular employer (which some other countries do, but not all), so the holder cannot change jobs without going through this process again.
Given these restrictions, only a small percentage of American companies (usually mid-size companies that otherwise have troubles finding qualified personel) are willing to sponsor H1-B visas for foreign workers.
In a country of ~250 million people, an influx of 150-200 thousand legal (H1-B) immigrant workers per year is nothing - indeed, a much lower percentage than other western countries (including my native Norway).
Of course, illegal immigration is much larger, and a different problem alltogether. Too bad some of the less intelligent elements of this society is unable to distinguish the (modest) number of legal immigrants from the (huge) number of illegal immigrants.
The process of getting a permanent residency ("green card") -- remember, the H1-B is only temporary -- is even harder, and many more steps are involved (including INS, the department of labor, and a handful of other agencies -- all of which are understaffed and overwhelmed). I was personally on a H1-B visa for nearly the allowed 6 years -- it took me that long to apply for (and receive) a green card. I am in a field where there is still a lot of demand for labor, and I am from a country for which parts of the application/qualification process goes quicker than for most. (Yes, the processing time of one of the agencies involved in the serialized green card application process depends on where you are from).
Re: Outsourcing to India in general, I can only say: Tough. The USA is getting what it asked for - a more globalized economy. If the US gets easier access to foreign markets, then foreign countries get easier access to the US market as well. Indian-produced goods and services (whether managed by US companies or not) can enter the US market more freely, just like US goods and services have already entered other markets more freely.
The bad news for industrialized countries is that this will level the global playing field w.r.t. salaries, standards of living, etc. The good news for the developing word is the same. All the same, it means further concentration of power an money in the hands of large, multinational corporations, whether they be incorporated in the USA or elsewhere.
The whole reason that I want to use Gentoo is the ease of install & upgrading. I had a few bad problems with RH.
This is actually a very good argument for installing Debian. All the software we have been talking about in this discussion (QMail, Sendmail, Postfix, Exim, Procmail, UW-IMAP, Courier-*, Cyrus,...) are readily installable as Debian packages. Dependency + Conflict resolution is automatic. Updates are a breeze ("apt-get dist-update"). Stability is exceptional (very nicely tailored to production envionments). Compilers (like any other software) are optional.
Debian is (one of?) the largest free software efforts in the world - some 700+ volunteer developers. Various slashdot polls shows it as the #2 distribution in number of users (behind RedHat) among Slashdot readers.
All Debian-packaged software follows a strict policy (on everything from file hierarchy/locations to configurability).
It may not be the quickest/easiest distribution to install (yet!) but once you are done, you won't regret it.
I migrated to Debian (after SLS, Slackware, RedHat, SuSE) some 5+ years ago. I have never since set up a non-Debian Linux system.
All that said, I have never tried Gentoo. However, it sounds (from this and other discussions) as if it is also a very thought-through distribution - I'll perhaps try it out someday.
Cyrus doesn't provide an option to make use of the maildir format even if we wanted to do so
That is correct. If you want to use the Maildir format, you'd want to use the "Courier" suite.
we should try to make use of the Cyrus format, no matter what
Not really. It is the most scalable format of the three, but (again) the problem is that it is unique to Cyrus, and that you need to use the Cyrus tools to access your mails (delivery and reading).
If you don't have such extreme performance/scalability demands, then Maildir is probably quite feasible, and it does have the advantage of being better supported by various mail software (Exim, Postfix, Procmail, Mutt, Courier-IMAP/POP3, QMail, etc..)
Exim & Postfix don't deal with the Cyrus format, natively
This is correct. Basically, you'd configure them to deliver mail via the "cyrdeliver" utility.
Also, are you saying that mutt can actually create a pseudo-IMAP feel when dealing with POP3
That I don't know, but I doubt it. POP3 is a protocol for downloading mail, not for managing it remotely on a server (like IMAP). It also has the limitation of dealing with a single mailbox (your inbox), not multiple folders.
Mutt can of course read mail from any IMAP server (including Cyrus), by using a folder name like "{user@server}mailfolder" ("mailfolder" can be omitted, defaults to INBOX):
mutt -f {user@server}INBOX
I forgot to mention one more advantage that both Courier and Cyrus have over UW-IMAPD (and other BSD-mailbox based servers): The presentation of the IMAP namespace.
With UW-IMAP, "INBOX" is your mail spool file (/var/spool/mail/$USER or similar). The list of other available IMAP folders is collected from every file within your home directory. So, unless you configure your IMAP client (like Outlook Express etc) to look only within the "Mail" subdirectory, then all your files are presented as mailboxes. For instance, you will have an IMAP folder named ".bashrc" if you have such a file. (Of course, it will fail to open this file as a mail folder).
With both Courier and Cyrus, your IMAP folders are presented as sub-folders of "INBOX". So, you may have "INBOX.Sent", "INBOX.Draft", "INBOX.MyMailingList", etc. Naturally, you will only see real mailboxes (for instance, Courier will only look for Maildir-formatted subdirectories inside $HOME/Maildir; Cyrus maintains an index of your mailboxes).
When it comes to IMAP servers, there is a near inverse relationship between setup simplicity vs. the ability to handle large amounts of users and mails.
The simplest IMAP servers (e.g. UW-IMAPD) use the traditional BSD mailbox format (Your INBOX is a single file in/var/spool/mail/$USER, other mailboxes are single files in $HOME/Mail). The most common mail delivery agents (sendmail, exim, postfix, procmail...) all use this format by default.
The problem is that storing all your mail in a single file is not very scalable. Once you have about 1000 messages in a mailbox, that mailbox becomes painfully slow to open. It is also a bit kludgy - basically, if a line in a mail message starts with the word "From ", then that line has to be altered (to e.g. ">From ") so as not to represent a new message.
The next step up in terms of scalabilty is to use the "Maildir" format, invented in QMail and now supported by a number of different MDAs and MUAs. If you use e.g. Exim or Postfix as your MTA/MDA, then a simple configuration change is all that is required to get mail delivered into $HOME/Maildir, using the "Maildir" structure. In this case, you would use the Courier servers (courier-imap, courier-pop3d, courier-imap-ssl, courier-pop3d-ssl) to provide IMAP/POP3 access. Also, MUAs such as "mutt" understand this format natively, so you can access your mail directly on the server without going through IMAP. (Of course, "mutt" can also read mail via IMAP).
Finally, the most complex to set up, but _superscalable_ w.r.t. number of users and mailbox size, are the Cyrus IMAP and POP3 servers. The Cyrus suite uses its own mailbox/folder structure, not compatible by any other software. (Like the Maildir format, each message is stored in a file, organized in subfolders representing the IMAP folder hierarchy. Message header/indexing information, however, is cached in a super-efficient format). One other advantage (that causes some complexity w.r.t setup) is its use of SASL for authentication - so users don't need user accounts on your server.
The trick is to get your MDA to deliver mail into your Cyrus folders. Cyrus provides a utility for this purpose, "cyrdeliver". One thing is to set up your default MDA (e.g. Exim, Postfix) to use "cyrdeliver" - another is to educate everyone who use "procmail" to filter their mail into subfolders in how to write appropriate ".procmailrc" (Procmail Run Control) files.
Personally, I use Cyrus on a Debian system (with a 266MHz National Semiconductor CPU). It opens HUGE mail folders (My "debian-private" mailing list folder contains some 10000+ messages!) within 5 seconds or so. I use Exim as my mail transport agent, mainly due to the sa-exim (SpamAssassin at SMTP connection time) plugin, and its built-in support for mailbox-filtering/forwarding a la procmail. Thus, I had to write some Exim delivery rules to use "cyrdeliver" both for INBOX deliveries, and to support mail sorting/filtering via "cyrdeliver". If you are interested in these modifications, send me an e-mail: "tor" at "slett.net".
Interesting article. It misses a couple of noteworthy points, though, perhaps out of the author's ignorance rather than oversight.
Symantec (and other anti-virus vendors), like now Microsoft, use Akamai to proxy their web site. A DDoS against the main Symantec site will only be so effective; a DDoS attack against Akamai will be severely "washed out" due to the sheer number of Akamai servers out there (some 13,000?)
Similarly, a DDoS against FBI or the "Department of Homeland Defense" will only be able to target their public presence (e.g. the main FBI website), not the thousands of disparate computers used by FBI agents out there. Even if FBI as an organization are served behind a single net.presence (router, dns, etc) (are they?), it would be trivial for agents to temporarily or permanently gain access through other channels (e.g. as individual customers of an ISP).
The article mentions "whois" as a mechanized way of obtaining domain names. However, public WHOIS servers (at least those that are hosted by domain name providers) do not provide a means to obtain a list of domains - only to query for information about a given record (domain name, IP address, contact handle, etc..). In other words, "whois" lookups will not work the way that the author presumes.
The author also mentions open mail relays as a means for the virus [sic -- it would be a worm, not a virus] to propagate itself. This can certainly be done, but for little benefit. Most mail transport agents (MTAs) record the IP address of the connecting client in its Received: header -- by tracing the Received: header trail, one can usually get all the way back to the originating IP. Sure, this IP belongs to an "innocent" third party whose computer is infected, but, unlike the case with spam, relaying the mail through open relays will not help very much in its effort to spread.
The author mentions using P2P network to spread the virus via MP3 files. As far as I know, this is not possible - no MP3 player will execute malicious code given in a filename opened as a music file.
The author mentions putting entries into the [Windows] system registry to make the system appear to have the latest patches, when, in fact, it does not, thus disabling the "Windows Update" application from functioning properly. This will work with the version of Windows Update included in XP and earlier versions, but if the user is actually using the Windows Update application, (s)he will by now have obtained a version for which this exploit does not work.
I'm only on page 3 of 7.. but think I have made enough comments to show that we should take this article with more than a grain of salt. I'm going to read the rest of the article now.
That may sound like religious gospel to some, but people using Windows are just about as insensitive to their peers as people who, say, smoke.
(Bandwidth/Air consumption)
The only problem is that running a more secure operating system is either more expensive (Mac OS X), or more difficult (Linux, *BSD). You are not going to be very popular among, oh, say, MBA or Law students once you mandate this restriction.
(Then again, those are perhaps precisely the type of studends we'd be better off without.. hmmm....)
Tech support services are basically overhead at an ISP (as far as increased service burden, ultimately cost to you). The easier you make the service, and the less dependent on tech support, the better for its consumers.
Indeed, if you call your favorite big ISPs tech support, they are unlikely to provide real help anyway (little technical insight, low pay, high turnover). Adding the extra burden of instructing the user how to un-infect their computer on something mechanical like individual telephone tech support would not help matters.
I favor the idea of cutting off infected customers. But I think the mechanism of getting customers back online should not involve the customer having to figure out that they need to call tech support - at least not first. The better way to support them is to redirect ALL HTTP requests from these customers to a ISP-provided site, which in turn informs the customer that they are seeing this page because their network access has been lost due to a virus problem on their computer.
That's the way that AT&T got customers off their @Home services (e.g. static IP addresses, dns/nntp/pop3/imap server information, etc etc). All HTTP requests went to a canned page. All usenet newsgroups at the old NNTP server contained a single message - one that instructed the customer to reconfigure their NNTP settings. All requests from non-DHCP provided IP addresses were directed to an appropriate placeholder.
Forgive my ignorance but which part of your setup prevents me from sending SPAM through another relay and set my From:, Reply-To:, etc. to tor@slett.net?
Nothing. I guess I forgot to mention the whole point of hosting your own MTA - namely, that:
Your email account will not be suspended by anyone but yourself (as a result of receiving tons of "Message Undeliverable" replies)
By controlling your own spam filtering, you can (temporarily?) weed out such messages.
So, it does not solve the problem with forged e-mail addresses (that's impossible given SMTP as it is defined at present); it merely allows you to do some damage control.
I am nearly in the same situation like you, except that I have complete control of my domain name (slett.net). I run my own DNS, my own SMTP server (Exim with SpamAssassin at SMTP Time), etc.. A nice side benefit is the ability to teergrube spammer hosts.
If you are technically inclined, and you have a broadband connection, this is definitely the best way at present to take control of spam.
Incidentally, I believe the ultimate solution to spam must involve banks and financial institutions - basically, an international mandate for these to not honor payment requests (e.g. credit card payments) to spammers. In the mean time, a mandatory upgrade or replacement to the SMTP protocol, to provide foolproof sender validation (by way of private/public keys or similar), will certainly go a long way towards solving the problem.
I think we (as led by mass media) are missing the point of SCO's venture. SCO's senior management are actually quite smart and cunning, and are getting exactly the results that they want (even if it will cost them the company).
The court date for SCO vs. IBM has been set to sometime in 2005. In the mean time, they have a pretty nifty scheme involving an absurd pending lawsuit, even more absurd press releases to match, Slashdot readers (&al) to provide free publicity, and gullible potential CEOs that are only asking where to send the check (and how much to put on it). 'Course, they'll stifle the use of Linux in some environments too, but hey, those are environments that probably should not be using Linux in the first place.
To put it in simpler terms - the lawsuit has nothing to do with legal issues such as license violations, copyrights etc. It's a ridiculous case that they are bound to lose, and they know it.
They are only trying to boost the stock price of their dying company long enough that their insiders can unload some shares. Sort of a highly publicised pump'n'dump scheme, if you will.
We saw the evidence yesterday, when some execs dumped some stocks (at a price higher than, say, back in May...).
Too bad this scheme is probably a little bit to the side of what the SEC normally would prosecute.
I believe the whole thing behind not using VNC is the network lag. I use VNC at work and it sucks.
Keep in mind that these suggestions were for x2vnc and win2vnc . So instead of running a full VNC client (with the remote desktop displayed back to the controlling computer), you are only sending keyboard/mouse events. This is much faster.
I have a Sun workstation at work, from which I am controlling a Linux box on one side (using x2x) and a Mac OS X box on the other side (using x2vnc). There is no lag whatsoever - the mouse moves smoothly across all my 3 monitors.:-)
(That is, unless the network has the occasional hiccup).
Slashdot Mirror
To me, it did not seem that the term "the leading desktop environment" was used in an exclutinary manner - rather, it seemed that the intention was to explain what KDE is (to the occasional Windows-only user that happens upon /.)
Sort of like Ford, the leading auto maker (even though they are probably not the worlds largest).
-tor
PS. I use Gnome and WindowMaker. KDE is a bit too "all-or-nothing" for me.
Given that so many already have sold this stock short, and will have to buy it back at some point, the stock price will remain high for a while (even after it's blindingly obvious that the company is doomed).
Ce la via.
-tor
You know, rather than blocking all IP's owned by ComCast, you could filter your mails via the RBL at dynablock.easynet.dl. This lists dynamic IP ranges given out by the likes of Comcast for residential customers. Indeed, ComCast & other ISPs are the ones contributing these address ranges to the maintainers of that RBL.
-tor
It sounds like the original poster's ISP is blocking inbound traffic to port 25 on his own server -- that's why he raised the question of SMTP on a different port (which, by the way, is mostly useless).
The updated article, with the bit about Charter blocking direct outbound SMTP connections, should not be much of a problem for the casual home user - even those that wish to run their own inbound SMTP server. Simply set the SMTP server up to use the designated smarthost.
Moreover, many MTAs now reject incoming mails received directly from an ISP's dynamic IP address ranges. For instance, the RBL at dynablock.easynet.nl is being used by a default SpamAssassin configuration (score 2.6 or so). So even if your ISP did not block outbound SMTP, the recipient may never actually get your message if you send it directly from your IP address.
If you are concerned with security (cfr. the reference to SSL), you really ought to encrypt your messages (with PGP or similar).
-tor
The ISP is trying to prevent your host from being an open SMTP relay, by shutting down inbound port 25.
Although this helps a little bit in the fight against spam, the effect is not as large as your ISP thinks. Spammer/cracker gangs nowadays use viruses to infect zombie hosts (virii typically use ports 80 to infect IIS, or ports 135-139 to infect the CIFS filesharing). Once on your machine, these virii can easily send out spam on outbound port 25, no matter if your ISP blocks the inbound port or not.
Explain this to them, maybe they'll reconsider...
(Yeah,right).
Anyone ported this to Saab XP yet?
You could add both a "From: " and a "Sender: " header to your usenet/mailing list postings:
:-)
From: you@yourdomain
Sender: blockme@yourdomain
You'll gets tons of spam to both addresses (not neccessarily the same spam, unfortunately - that would make filtering real easy). You run SpamAssassin (or similar) to filter mail to your real address, and you run "spamassassin -r" or "razor-report" to handle mails sent to your spamtrap address (making the Razor service, and in turn, SpamAssassin, more efficient at identifying these spams).
Better yet, if your MTA is Exim, use SA-Exim to add teergrubing functionality to SpamAssassin. Oh, the satisfaction!
Mac OS X already includes /bin/bash, though not as the default shell. Sure, Fink contains a copy also (perhaps a newer one), but is not required.
/bin/bash.
First thing I do on any new Mac OS X box is to go into the NetInfo manager and change my (and root's) login shell to
Sorry for restating the obvious, but it seems that the person already was receiving these calls to his phone (he may not even have a fax machine, for what we know).
I know this problem myself. Periodically I would receive calls with nobody (just dead silence) on the other end. Last year I purchased one of these multi-function devices (printer, fax, scanner, copier..) and, stupidly enough, enabled the fax receiver (It would let me or my answering machine pick up the phone, then if it turned out to be a fax call, take it from there). After a few days, I received my first fax spam, and did not think much of it. But apparently, just like with an e-mail address, once my now fax-enabled number is out, it's hard to contain the calls.
This is about a year ago now. After receiving about 3-4 spam faxes, I figured out what was going on, and turned off the automatic fax receiver feature. Fax calls kept coming for a while (basically just annoying beeps on the phone line to me), and an occasional fax call still comes to this day.
Of course fax spams are illegal according to US code, but I never took the matter up with these senders and/or the legal system. Indeed, I am not even certain if the sender's number (as listed on the top of the page) is reliable, and/or legal evidence.
Bottom line in these days of spams, scams, and such and abundance of dishonest people (combined with underresourced / ineffective government oversight), is that you have to be extremely vigilent to avoid both this type of fax/email/phone solicitations, as well as more serious trouble like ID theft, credit card fraud, etc. That's just the world we have created, with this overemphasis on capitalism & money, and underemhpasis on human values.
Although you are philosophically/theoretically correct, this is probably not a good example. The recent OpenSSH (application, not protocol) vulnerabilities are near, if not entirely, non-exploitable - especially compared to the large gaping holes that are still present in M$ {Win*,IE,Office,Outlook*,...}.
It would be even more far-fetched to see this vulnerability provide access to Mail.app, since "Remote Login/SSH" is turned off by default on MacOSX, and because Apple has released a fixed version of OpenSSH via the "Software Update" feature (which is turned on by default on Internet-enabled OSX boxes).
That said, UNIX/Linux certainly have a long history with many very large holes in it. If you put a RedHat 6.2 box on the internet, chances are you'll be r00ted in 15 minutes or less.
-tor
No. Vulnerabilities are usually released with major operating system upgrades, and sometimes with patches.
Exploits (that take advantage of these) are usually released by third parties, usually shortly before or after a patch is released by the OS vendor to fix the vulnerability (and perhaps introduce new ones).
True, however those PDFs are HUGE compared to those that OpenOffice creates -- with no seeming improvement in quality. Indeed, the OO seems a bit better at detailed pictures etc.
I printed a 3.2MB MS PowerPoint presentation to PDF from a Mac, and the resulting file was 22MB. I exported the same file from OO v1.1 (which, by the way, has been in Debian 'sid' since Sep 25), and the resulting size was 2.3MB.
Indeed, the PDF created from OO seemed smoother (despite having to import a foreign document format) than the one created via the "Print to PDF..." option in the Mac OS X print dialogue.
-tor
No, the H1-B visa allows for a grand total of 6 years only. (Believe me, I have first-hand experience in almost running into that limit, with no possibility of extension, before the "timely" issue of a green card).
The average person who initially gets employed on a H1-B may well reside in the US for 14 years (your assertion, not mine) - a significant percentage of H1-B visa holders eventually obtain a green card (and/or citizenship).
Personally, I came on a F-1 visa as a student + 1 year on a practial trainee program; 6 years on a H1-B VISA, and now as a permanent resident.
Sure it is simplistic - This is not exactly the type of forum where you go into the lower level details. But the bottom line is exactly as I said - the US has been pushing for free trade (even trade "subsidies" in the form of tax breaks for exporters); it follows that products and services get imported more as well as exported more.
Companies like IBM try (perhaps misguidedly) to maximize their profitablity by outsourcing functions to India, so as not to lose ground against other companies that already operate in, say, India (based there or not).
According to the CIA World Fact Book, India (just like the USA) is a net importer.
In order to work in India, you need a work permit. Not knowing exactly the procedure for obtaining a work permit in India, I can only speculate that one will normally be issued only for jobs/diciplines for which there is no qualified native applicants.
That's the same way it works in the USA. In order for foreigners to get a work permit (a H1-B visa), the prospective employer must:
The H1-B visa is temporary (expires after 3 years, can be renewed for a grand total of 6 years). This is kind of unique - not many other countries have this restriction.
Finally, a H1-B visa is tied to a particular employer (which some other countries do, but not all), so the holder cannot change jobs without going through this process again.
Given these restrictions, only a small percentage of American companies (usually mid-size companies that otherwise have troubles finding qualified personel) are willing to sponsor H1-B visas for foreign workers.
In a country of ~250 million people, an influx of 150-200 thousand legal (H1-B) immigrant workers per year is nothing - indeed, a much lower percentage than other western countries (including my native Norway).
Of course, illegal immigration is much larger, and a different problem alltogether. Too bad some of the less intelligent elements of this society is unable to distinguish the (modest) number of legal immigrants from the (huge) number of illegal immigrants.
The process of getting a permanent residency ("green card") -- remember, the H1-B is only temporary -- is even harder, and many more steps are involved (including INS, the department of labor, and a handful of other agencies -- all of which are understaffed and overwhelmed).
I was personally on a H1-B visa for nearly the allowed 6 years -- it took me that long to apply for (and receive) a green card. I am in a field where there is still a lot of demand for labor, and I am from a country for which parts of the application/qualification process goes quicker than for most. (Yes, the processing time of one of the agencies involved in the serialized green card application process depends on where you are from).
Re: Outsourcing to India in general, I can only say: Tough. The USA is getting what it asked for - a more globalized economy. If the US gets easier access to foreign markets, then foreign countries get easier access to the US market as well. Indian-produced goods and services (whether managed by US companies or not) can enter the US market more freely, just like US goods and services have already entered other markets more freely.
The bad news for industrialized countries is that this will level the global playing field w.r.t. salaries, standards of living, etc. The good news for the developing word is the same. All the same, it means further concentration of power an money in the hands of large, multinational corporations, whether they be incorporated in the USA or elsewhere.
This is actually a very good argument for installing Debian. All the software we have been talking about in this discussion (QMail, Sendmail, Postfix, Exim, Procmail, UW-IMAP, Courier-*, Cyrus,
Debian is (one of?) the largest free software efforts in the world - some 700+ volunteer developers. Various slashdot polls shows it as the #2 distribution in number of users (behind RedHat) among Slashdot readers.
All Debian-packaged software follows a strict policy (on everything from file hierarchy/locations to configurability).
It may not be the quickest/easiest distribution to install (yet!) but once you are done, you won't regret it.
I migrated to Debian (after SLS, Slackware, RedHat, SuSE) some 5+ years ago. I have never since set up a non-Debian Linux system.
All that said, I have never tried Gentoo. However, it sounds (from this and other discussions) as if it is also a very thought-through distribution - I'll perhaps try it out someday.
-tor
That is correct. If you want to use the Maildir format, you'd want to use the "Courier" suite.
we should try to make use of the Cyrus format, no matter what
Not really. It is the most scalable format of the three, but (again) the problem is that it is unique to Cyrus, and that you need to use the Cyrus tools to access your mails (delivery and reading).
If you don't have such extreme performance/scalability demands, then Maildir is probably quite feasible, and it does have the advantage of being better supported by various mail software (Exim, Postfix, Procmail, Mutt, Courier-IMAP/POP3, QMail, etc..)
Exim & Postfix don't deal with the Cyrus format, natively
This is correct. Basically, you'd configure them to deliver mail via the "cyrdeliver" utility.
Also, are you saying that mutt can actually create a pseudo-IMAP feel when dealing with POP3
That I don't know, but I doubt it. POP3 is a protocol for downloading mail, not for managing it remotely on a server (like IMAP). It also has the limitation of dealing with a single mailbox (your inbox), not multiple folders.
Mutt can of course read mail from any IMAP server (including Cyrus), by using a folder name like "{user@server}mailfolder" ("mailfolder" can be omitted, defaults to INBOX):
I forgot to mention one more advantage that both Courier and Cyrus have over UW-IMAPD (and other BSD-mailbox based servers): The presentation of the IMAP namespace.
With UW-IMAP, "INBOX" is your mail spool file (/var/spool/mail/$USER or similar). The list of other available IMAP folders is collected from every file within your home directory. So, unless you configure your IMAP client (like Outlook Express etc) to look only within the "Mail" subdirectory, then all your files are presented as mailboxes. For instance, you will have an IMAP folder named ".bashrc" if you have such a file. (Of course, it will fail to open this file as a mail folder).
With both Courier and Cyrus, your IMAP folders are presented as sub-folders of "INBOX". So, you may have "INBOX.Sent", "INBOX.Draft", "INBOX.MyMailingList", etc. Naturally, you will only see real mailboxes (for instance, Courier will only look for Maildir-formatted subdirectories inside $HOME/Maildir; Cyrus maintains an index of your mailboxes).
Good Luck!
-tor
When it comes to IMAP servers, there is a near inverse relationship between setup simplicity vs. the ability to handle large amounts of users and mails.
/var/spool/mail/$USER, other mailboxes are single files in $HOME/Mail). The most common mail delivery agents (sendmail, exim, postfix, procmail...) all use this format by default.
The simplest IMAP servers (e.g. UW-IMAPD) use the traditional BSD mailbox format (Your INBOX is a single file in
The problem is that storing all your mail in a single file is not very scalable. Once you have about 1000 messages in a mailbox, that mailbox becomes painfully slow to open. It is also a bit kludgy - basically, if a line in a mail message starts with the word "From ", then that line has to be altered (to e.g. ">From ") so as not to represent a new message.
The next step up in terms of scalabilty is to use the "Maildir" format, invented in QMail and now supported by a number of different MDAs and MUAs. If you use e.g. Exim or Postfix as your MTA/MDA, then a simple configuration change is all that is required to get mail delivered into $HOME/Maildir, using the "Maildir" structure. In this case, you would use the Courier servers (courier-imap, courier-pop3d, courier-imap-ssl, courier-pop3d-ssl) to provide IMAP/POP3 access. Also, MUAs such as "mutt" understand this format natively, so you can access your mail directly on the server without going through IMAP. (Of course, "mutt" can also read mail via IMAP).
Finally, the most complex to set up, but _superscalable_ w.r.t. number of users and mailbox size, are the Cyrus IMAP and POP3 servers. The Cyrus suite uses its own mailbox/folder structure, not compatible by any other software. (Like the Maildir format, each message is stored in a file, organized in subfolders representing the IMAP folder hierarchy. Message header/indexing information, however, is cached in a super-efficient format). One other advantage (that causes some complexity w.r.t setup) is its use of SASL for authentication - so users don't need user accounts on your server.
The trick is to get your MDA to deliver mail into your Cyrus folders. Cyrus provides a utility for this purpose, "cyrdeliver". One thing is to set up your default MDA (e.g. Exim, Postfix) to use "cyrdeliver" - another is to educate everyone who use "procmail" to filter their mail into subfolders in how to write appropriate ".procmailrc" (Procmail Run Control) files.
Personally, I use Cyrus on a Debian system (with a 266MHz National Semiconductor CPU). It opens HUGE mail folders (My "debian-private" mailing list folder contains some 10000+ messages!) within 5 seconds or so. I use Exim as my mail transport agent, mainly due to the sa-exim (SpamAssassin at SMTP connection time) plugin, and its built-in support for mailbox-filtering/forwarding a la procmail. Thus, I had to write some Exim delivery rules to use "cyrdeliver" both for INBOX deliveries, and to support mail sorting/filtering via "cyrdeliver". If you are interested in these modifications, send me an e-mail: "tor" at "slett.net".
I'm only on page 3 of 7.. but think I have made enough comments to show that we should take this article with more than a grain of salt. I'm going to read the rest of the article now.
-tor
Yeah!
That may sound like religious gospel to some, but people using Windows are just about as insensitive to their peers as people who, say, smoke.
(Bandwidth/Air consumption)
The only problem is that running a more secure operating system is either more expensive (Mac OS X), or more difficult (Linux, *BSD). You are not going to be very popular among, oh, say, MBA or Law students once you mandate this restriction.
(Then again, those are perhaps precisely the type of studends we'd be better off without.. hmmm....)
Tech support services are basically overhead at an ISP (as far as increased service burden, ultimately cost to you). The easier you make the service, and the less dependent on tech support, the better for its consumers.
Indeed, if you call your favorite big ISPs tech support, they are unlikely to provide real help anyway (little technical insight, low pay, high turnover). Adding the extra burden of instructing the user how to un-infect their computer on something mechanical like individual telephone tech support would not help matters.
I favor the idea of cutting off infected customers. But I think the mechanism of getting customers back online should not involve the customer having to figure out that they need to call tech support - at least not first. The better way to support them is to redirect ALL HTTP requests from these customers to a ISP-provided site, which in turn informs the customer that they are seeing this page because their network access has been lost due to a virus problem on their computer.
That's the way that AT&T got customers off their @Home services (e.g. static IP addresses, dns/nntp/pop3/imap server information, etc etc). All HTTP requests went to a canned page. All usenet newsgroups at the old NNTP server contained a single message - one that instructed the customer to reconfigure their NNTP settings. All requests from non-DHCP provided IP addresses were directed to an appropriate placeholder.
Nothing. I guess I forgot to mention the whole point of hosting your own MTA - namely, that:
So, it does not solve the problem with forged e-mail addresses (that's impossible given SMTP as it is defined at present); it merely allows you to do some damage control.
-tor
I am nearly in the same situation like you, except that I have complete control of my domain name (slett.net). I run my own DNS, my own SMTP server (Exim with SpamAssassin at SMTP Time), etc.. A nice side benefit is the ability to teergrube spammer hosts.
If you are technically inclined, and you have a broadband connection, this is definitely the best way at present to take control of spam.
Incidentally, I believe the ultimate solution to spam must involve banks and financial institutions - basically, an international mandate for these to not honor payment requests (e.g. credit card payments) to spammers. In the mean time, a mandatory upgrade or replacement to the SMTP protocol, to provide foolproof sender validation (by way of private/public keys or similar), will certainly go a long way towards solving the problem.
-tor
I think we (as led by mass media) are missing the point of SCO's venture. SCO's senior management are actually quite smart and cunning, and are getting exactly the results that they want (even if it will cost them the company).
The court date for SCO vs. IBM has been set to sometime in 2005. In the mean time, they have a pretty nifty scheme involving an absurd pending lawsuit, even more absurd press releases to match, Slashdot readers (&al) to provide free publicity, and gullible potential CEOs that are only asking where to send the check (and how much to put on it). 'Course, they'll stifle the use of Linux in some environments too, but hey, those are environments that probably should not be using Linux in the first place.
To put it in simpler terms - the lawsuit has nothing to do with legal issues such as license violations, copyrights etc. It's a ridiculous case that they are bound to lose, and they know it.
They are only trying to boost the stock price of their dying company long enough that their insiders can unload some shares. Sort of a highly publicised pump'n'dump scheme, if you will.
We saw the evidence yesterday, when some execs dumped some stocks (at a price higher than, say, back in May...).
Too bad this scheme is probably a little bit to the side of what the SEC normally would prosecute.
-tor
I believe the whole thing behind not using VNC is the network lag. I use VNC at work and it sucks.
:-)
Keep in mind that these suggestions were for x2vnc and win2vnc . So instead of running a full VNC client (with the remote desktop displayed back to the controlling computer), you are only sending keyboard/mouse events. This is much faster.
I have a Sun workstation at work, from which I am controlling a Linux box on one side (using x2x) and a Mac OS X box on the other side (using x2vnc). There is no lag whatsoever - the mouse moves smoothly across all my 3 monitors.
(That is, unless the network has the occasional hiccup).