Unfortunately, plenty of small businesses *do* include such foolish links. And many graphically based web clients auto-underline plain text links and auto-render HTML, which makes it very difficult to make people cut and paste them rather than simply clicking on them for more safety.
For the foreseeable future, not having SPF simply means you haven't set a policy for mail from your domain, and email claiming to be from your domain should be filtered however you normally filter email. Please read the documentation before making this kind of claim: you'll create resentment that's simply not appropriate.
It's extremely fast: it's the DNS records for the domain from whom the email is allegedly sent, which get looked up by many mail clients anyway to check the hostname and reverse DNS record.
Add one lookup for the TXT record, process it, and you have some extremely fast and lightweight filtering going on before the email message ever enters your local mail queue and has to be touched by your other filters.
True, but it doesn't mean they'er filtering incoming mail to GMail yet using SPF. Publishing an SPF record is different than actually filtering with yours and other people's SPF records.
You are mistaking the "From:" address in your email with the "FROM" address from your SMTP client. But in most cases, universities do not *want* you to be able to send email pretending to be from the university itself from any IP address on the planet, they really want it to go through their servers for social and legal reasons.
So you have to send your email from your local ISP, but put in a "Reply-to:" line to make clear the email is being sent from offsite but involves your Reply-to: address at the university.
It helps against the email worms blasting mail servers into unconsciousness, and against spam forged to look like it's from your own domain. It's an incremental step, not a magic bullet.
Using one company for SMTP and another for DNS is no problem. Simply set up SPF to permit email that is actually from the SMTP server's IP address or MX records to pretend that it is from your domain.
Calm down. SPF will not, for the foreseeable future, block your email *unless* you publish an SPF record that says "accept email only from these locations". If you don't publish SPF records, your email will not be blocked.
Now, you probably *want* to publish SPF records, but you can set them to be "advisory" meaning "anything other than these machines sending email from my domain is questionable, but I don't want you to block it".
Setting up the DNS TXT records for your domain is trivial with the wizard at spf.pobox.com.
Bingo: the "FROM" used by SPF is in the original SMTP connection, which has your IP address right there in the network connection to examine and look up information for. This way, if your SMTP client is not authorized to send email from whatever domain your email claims to be from in the "FROM" line, the recipient can simply drop the connection immediately and move on to more important matters.
It's extremely useful for blocking the forged hotmail.com, aol.com, and other popular domain email whom most ISP's dare not filter out in their email blacklists, and who cannot be reasonably covered in an IP based blacklist because they change so quickly.
Microsoft is paying them: the money they burned on lawyers last year is more than made up for by the business Microsoft has been shoveling their way to re-inforce the claims of legitimacy of new Microsoft UNIX compatibility tools, and to absolutely avoid using any GPL or other open source code.
They're not so ahead: but people have standardized, because the users' hands and reflexed have learned specific patterns. That set of reflexes runs fairly deep: the price of entry into computer game mastery is steep enough without learning yet another set of reflexes for every game.
So, they've standardized on a control set that is tolerable, if not optimal. That's something we as designers have to learn to accept and not keep trying to re-educate the users.
You are absolutely correct. It therefore falls to the authors of new interfaces to find the nearest non-geek and ask *them* to test the interface, just as it befalls the developer to have someone not involved in the project development review the documentation.
It also falls to the authors of interfaces to be consistent. X Windows, for example, had all these bits of interface whackiness depending on the author's whim and on the particular manager. Bad, bad, bad, bad, bad, not because it does not grant freedome, but because it badly breaks consistence between similar programs written by the same author in subtlely different environments.
I see a lot of alphabetically generated spam. I'd actually use the invalidly addressed mail to create an email blacklist for those IP addresses that send it, a blacklist with an expiration to allow misaddressed email to eventually be re-addressed and later go through.
Let's be very clear on SCO's motives. They're being a puppet to cast FUD on Linux while getting money from Microsoft to stay afloat. In the meantime, their executives are trying to rape the company for golden parachutes, salary, and sales of stock options.
Extending the lawsuits is *good* for SCO, because the purpose of the lawsuits at this point is not to win: the grounds of their lawsuits are frankly too weak to actually win in court. Failing in any way that discredits the suits or reduces the cost or risk of the lawsuits to their chosen targets is *BAD* for SCO, because it reduces the effectiveness of their lawsuits and reduces the likelihood of an out of court settlement and reduces Microsoft's willingness to continue funding them.
RedHat (it's wone word, with no space in it!), is a useful set of tools, but has become too tied to industry partnerships to be an undisputed leader. Debian, SuSE, TurboLinux, Gentoo, Mandrake, PLD, the various BSD flavors, etc. etc., etc. all have feature sets and development models that are in some ways different and for some uses superior to RedHat.
Don't worry about that possibility. Worry about Novell wasting marketplace time with an old closed standard, such as happened with Netware, and bleeding off "anti-Microsoft" energies and "don't single source stuff" energies from the purely open source world.
And don't forget handling an alternative user mailbox directory, the "~/mail" setting necessary to make IMAP play nice with pine run locally on the IMAP server.
The installation CD's for various distributions and the gentoo CD's make excellent starting points for CD distribution firewalls, system recovery tools after someone has hand-edited/etc/passwd and accidentally corrupted the "root" entry, scrubbing Windows and other machines before they leave the building, and probing new hardware configurations with a known kernel before you try to actually install the darned OS.
*Good* perl is your friend. Bad perl is an abomination of S7t7n, written by n00bs to task those who actually have learned to check error results and learned that recursion is not your friend, documentation is for when you are actually writing the code, and one letter variable names are for consultants who want to guarantee a return call to fix what doesn't work anymore and can't be read by anyone else.
Twin infants are interesting in development. They are usually much less tiring than one would expect, because they play with and entertain and comfort each other, which is why their parents don't put them in a blender after a month or two.
And some infants take a lot more support than others: I've met some beautiful meatloafs you couldn't disturb from their naps with a two-by-four, and other delightful infants of pure evil who'd wake up shrieking from Brownian motion bouncing air molecules off their faces, preferably just when you finally got your own eyes closed.
Ahh, yes, you are proof of the dregs of the American school system at work. Don't learn your own language: don't bother to proofread, clearly your self-esteem has been developed by school to the point where such tawdry factors are unnecessary in the glare of the brilliance of your critical observations of *someone else's* writing.
No wonder your job has been outsourced: at least the overseas helpdesks bothered to learn the language ('Ð('re writing and speaking in.
Don't believe that source code theft is a small problem. As others have described here, some folks think it's OK to keep personal copies of everything they ever worked on, so they can use chunks of it later on, and never actually bother to notify their new employers that they do so.
This is why I vastly prefer to write my code under GPL, and grab new tools that are clearly open source: it's available for other people, and it's available for *me* to work with later, so I don't have to just throw away months of my work when I encounter a similar problem in a new place.
Hmm. Thank you for the expanded search terms, they lead to enlightening reading. The articles and analyses I was reading made reference to PRISM as the porting of VMS, not the underlying hardware. You've pointed me to interesting stuff.
I will plead unclear source information, in that the web references I found without the MICA search term are far less clear and the former DEC employees I know never made that distinction clear. I shall chastise them and myself over beer the next time we go out, and thank you again for the pointers.
That is a fair point. But note that they didn't actually break the compatibility, or not very successfully: they simply got the startup tools to print lots of warnings if it detected the os of anything other than *their* version of MS-DOS.
I do a lot of work in both the command line level and the GUI levels of a lot of different OS's, and have watched the development of GUI environments for a lot of them. I can accept that Win3.11 added a lot onto DOS, and that Win9x is a mature version of Win3.11, but don't see why you see Win9x as fundamentally distinct from the DOS underpinnings. It's like saying that X windows is the OS on a UNIX machine: most of the kernel limitations and the hardware handling is still there, even if you've added new layers of complexity for video and mouse handling.
Ahh. I see where I might be confusing. I did not mean to intimate that Mr. Cutler was told, by Microsoft, "bring the source code from the locked cabinat". Like the concerns about the person from Altavista whose behavior started this article, and in Mr. Cutler's case confirmed by the guts of Windows NT itself compared to the guts of VMS and by the DEC lawsuits of the time, I claim that Mr. Cutler stole plenty of trade secrets and code from DEC.
Whether he did so under orders from Microsoft before he left DEC is, frankly, irrelevant. I don't have the intimate knowledge of Mr. Cutler's life to hazard a good guess. But it's relevant to Microsoft's continuing behavior of theft. They don't *have* to give orders to steal trade secrets or orders from employee's old companies: it's profitable and effective to allow their new employees to do it themselves to save time on their new work assignments and never censure or punish them for it. Microsoft development teams get funding and resources based, not on cleanness or proper implementation or stability or security of code: they get approval from their management on the basis of sale-able features added. This makes code theft even tougher to detect.
The money made by capitalizing on such theft to add value to your well-funded monopoly and compete against the original developers is easily turned to legal fees to protect against any potential lawsuits. Fighting Microsoft in court tends to bankrupt companies. I'll leave the extensive analyses of the FUD and delay tactics of Microsoft's legal teams to other discussions. But it's clear that whether or not it is ever absolutely stated, they have little problem with such theft as a corporate policy.
Slashdot Mirror
Unfortunately, plenty of small businesses *do* include such foolish links. And many graphically based web clients auto-underline plain text links and auto-render HTML, which makes it very difficult to make people cut and paste them rather than simply clicking on them for more safety.
For the foreseeable future, not having SPF simply means you haven't set a policy for mail from your domain, and email claiming to be from your domain should be filtered however you normally filter email. Please read the documentation before making this kind of claim: you'll create resentment that's simply not appropriate.
It's extremely fast: it's the DNS records for the domain from whom the email is allegedly sent, which get looked up by many mail clients anyway to check the hostname and reverse DNS record. Add one lookup for the TXT record, process it, and you have some extremely fast and lightweight filtering going on before the email message ever enters your local mail queue and has to be touched by your other filters.
True, but it doesn't mean they'er filtering incoming mail to GMail yet using SPF. Publishing an SPF record is different than actually filtering with yours and other people's SPF records.
You are mistaking the "From:" address in your email with the "FROM" address from your SMTP client. But in most cases, universities do not *want* you to be able to send email pretending to be from the university itself from any IP address on the planet, they really want it to go through their servers for social and legal reasons. So you have to send your email from your local ISP, but put in a "Reply-to:" line to make clear the email is being sent from offsite but involves your Reply-to: address at the university.
It helps against the email worms blasting mail servers into unconsciousness, and against spam forged to look like it's from your own domain. It's an incremental step, not a magic bullet. Using one company for SMTP and another for DNS is no problem. Simply set up SPF to permit email that is actually from the SMTP server's IP address or MX records to pretend that it is from your domain.
Calm down. SPF will not, for the foreseeable future, block your email *unless* you publish an SPF record that says "accept email only from these locations". If you don't publish SPF records, your email will not be blocked. Now, you probably *want* to publish SPF records, but you can set them to be "advisory" meaning "anything other than these machines sending email from my domain is questionable, but I don't want you to block it". Setting up the DNS TXT records for your domain is trivial with the wizard at spf.pobox.com.
Bingo: the "FROM" used by SPF is in the original SMTP connection, which has your IP address right there in the network connection to examine and look up information for. This way, if your SMTP client is not authorized to send email from whatever domain your email claims to be from in the "FROM" line, the recipient can simply drop the connection immediately and move on to more important matters.
It's extremely useful for blocking the forged hotmail.com, aol.com, and other popular domain email whom most ISP's dare not filter out in their email blacklists, and who cannot be reasonably covered in an IP based blacklist because they change so quickly.
Microsoft is paying them: the money they burned on lawyers last year is more than made up for by the business Microsoft has been shoveling their way to re-inforce the claims of legitimacy of new Microsoft UNIX compatibility tools, and to absolutely avoid using any GPL or other open source code.
They're not so ahead: but people have standardized, because the users' hands and reflexed have learned specific patterns. That set of reflexes runs fairly deep: the price of entry into computer game mastery is steep enough without learning yet another set of reflexes for every game. So, they've standardized on a control set that is tolerable, if not optimal. That's something we as designers have to learn to accept and not keep trying to re-educate the users.
You are absolutely correct. It therefore falls to the authors of new interfaces to find the nearest non-geek and ask *them* to test the interface, just as it befalls the developer to have someone not involved in the project development review the documentation.
It also falls to the authors of interfaces to be consistent. X Windows, for example, had all these bits of interface whackiness depending on the author's whim and on the particular manager. Bad, bad, bad, bad, bad, not because it does not grant freedome, but because it badly breaks consistence between similar programs written by the same author in subtlely different environments.
No, no, it's 30 minutes guaranteed delivery time, like all the Greek-owned delivery places.
I see a lot of alphabetically generated spam. I'd actually use the invalidly addressed mail to create an email blacklist for those IP addresses that send it, a blacklist with an expiration to allow misaddressed email to eventually be re-addressed and later go through.
Let's be very clear on SCO's motives. They're being a puppet to cast FUD on Linux while getting money from Microsoft to stay afloat. In the meantime, their executives are trying to rape the company for golden parachutes, salary, and sales of stock options. Extending the lawsuits is *good* for SCO, because the purpose of the lawsuits at this point is not to win: the grounds of their lawsuits are frankly too weak to actually win in court. Failing in any way that discredits the suits or reduces the cost or risk of the lawsuits to their chosen targets is *BAD* for SCO, because it reduces the effectiveness of their lawsuits and reduces the likelihood of an out of court settlement and reduces Microsoft's willingness to continue funding them.
They changed it again? Man, that's what I get for blinking!
RedHat (it's wone word, with no space in it!), is a useful set of tools, but has become too tied to industry partnerships to be an undisputed leader. Debian, SuSE, TurboLinux, Gentoo, Mandrake, PLD, the various BSD flavors, etc. etc., etc. all have feature sets and development models that are in some ways different and for some uses superior to RedHat. Don't worry about that possibility. Worry about Novell wasting marketplace time with an old closed standard, such as happened with Netware, and bleeding off "anti-Microsoft" energies and "don't single source stuff" energies from the purely open source world.
And don't forget handling an alternative user mailbox directory, the "~/mail" setting necessary to make IMAP play nice with pine run locally on the IMAP server.
The installation CD's for various distributions and the gentoo CD's make excellent starting points for CD distribution firewalls, system recovery tools after someone has hand-edited /etc/passwd and accidentally corrupted the "root" entry, scrubbing Windows and other machines before they leave the building, and probing new hardware configurations with a known kernel before you try to actually install the darned OS.
*Good* perl is your friend. Bad perl is an abomination of S7t7n, written by n00bs to task those who actually have learned to check error results and learned that recursion is not your friend, documentation is for when you are actually writing the code, and one letter variable names are for consultants who want to guarantee a return call to fix what doesn't work anymore and can't be read by anyone else.
Twin infants are interesting in development. They are usually much less tiring than one would expect, because they play with and entertain and comfort each other, which is why their parents don't put them in a blender after a month or two.
And some infants take a lot more support than others: I've met some beautiful meatloafs you couldn't disturb from their naps with a two-by-four, and other delightful infants of pure evil who'd wake up shrieking from Brownian motion bouncing air molecules off their faces, preferably just when you finally got your own eyes closed.
Ahh, yes, you are proof of the dregs of the American school system at work. Don't learn your own language: don't bother to proofread, clearly your self-esteem has been developed by school to the point where such tawdry factors are unnecessary in the glare of the brilliance of your critical observations of *someone else's* writing.
No wonder your job has been outsourced: at least the overseas helpdesks bothered to learn the language ('Ð('re writing and speaking in.
Don't believe that source code theft is a small problem. As others have described here, some folks think it's OK to keep personal copies of everything they ever worked on, so they can use chunks of it later on, and never actually bother to notify their new employers that they do so.
This is why I vastly prefer to write my code under GPL, and grab new tools that are clearly open source: it's available for other people, and it's available for *me* to work with later, so I don't have to just throw away months of my work when I encounter a similar problem in a new place.
Hmm. Thank you for the expanded search terms, they lead to enlightening reading. The articles and analyses I was reading made reference to PRISM as the porting of VMS, not the underlying hardware. You've pointed me to interesting stuff. I will plead unclear source information, in that the web references I found without the MICA search term are far less clear and the former DEC employees I know never made that distinction clear. I shall chastise them and myself over beer the next time we go out, and thank you again for the pointers.
That is a fair point. But note that they didn't actually break the compatibility, or not very successfully: they simply got the startup tools to print lots of warnings if it detected the os of anything other than *their* version of MS-DOS. I do a lot of work in both the command line level and the GUI levels of a lot of different OS's, and have watched the development of GUI environments for a lot of them. I can accept that Win3.11 added a lot onto DOS, and that Win9x is a mature version of Win3.11, but don't see why you see Win9x as fundamentally distinct from the DOS underpinnings. It's like saying that X windows is the OS on a UNIX machine: most of the kernel limitations and the hardware handling is still there, even if you've added new layers of complexity for video and mouse handling.
Ahh. I see where I might be confusing. I did not mean to intimate that Mr. Cutler was told, by Microsoft, "bring the source code from the locked cabinat". Like the concerns about the person from Altavista whose behavior started this article, and in Mr. Cutler's case confirmed by the guts of Windows NT itself compared to the guts of VMS and by the DEC lawsuits of the time, I claim that Mr. Cutler stole plenty of trade secrets and code from DEC.
Whether he did so under orders from Microsoft before he left DEC is, frankly, irrelevant. I don't have the intimate knowledge of Mr. Cutler's life to hazard a good guess. But it's relevant to Microsoft's continuing behavior of theft. They don't *have* to give orders to steal trade secrets or orders from employee's old companies: it's profitable and effective to allow their new employees to do it themselves to save time on their new work assignments and never censure or punish them for it. Microsoft development teams get funding and resources based, not on cleanness or proper implementation or stability or security of code: they get approval from their management on the basis of sale-able features added. This makes code theft even tougher to detect.
The money made by capitalizing on such theft to add value to your well-funded monopoly and compete against the original developers is easily turned to legal fees to protect against any potential lawsuits. Fighting Microsoft in court tends to bankrupt companies. I'll leave the extensive analyses of the FUD and delay tactics of Microsoft's legal teams to other discussions. But it's clear that whether or not it is ever absolutely stated, they have little problem with such theft as a corporate policy.