How do you figure you can convert fossil fuel into methanol, or ANY other alchohol for that matter? Methanol is wood-alchohol.
Methanol is simply methane with an oxygen atom wedged in between one of the hydrogens and the carbon. Alcohols are hydrocarbons where you have an OH group joined to a carbon. For industrial scale chemistry scaling up a "lab" can be easier than using micro organisms.
With all that good information, I was surprised you didn't mention antifreeze. Years ago, antifreeze was made with ethanol. Farmers put antifreeze in their tractor tires to help keep them from having to refill the tires every time the weather changes.
There is also another alcohol used in anti-freeze. This is ethelene glycol or ethan-1-2-ol, considerably more toxic than either ethano or methanol.
but it seems to me that the most exciting aspect of this emerging technology is the fact that it is green! plugging into an existing electrical outlet may seem convenient and clean but how much carbon dioxide was pumped into the atmosphere to produce those watts?
What actually matters is how much of the carbon dioxide is from "fossil carbon". Burning wood is more "green" than burning coal. Also you can probably make methanol from crude oil, which isn't very green at all.
Perhaps you're thinking of the ban on cell phones? That has nothing to do with safety. A cell uses up bandwidth on every node that's in line-of-site. So someone in the air strains the system more than someone on the ground. If passengers were allowed to use their phones, local systems would get saturated every time a plane flies over them.
Unless you install a cell in the aircraft... Which is probably less kit than "Sky phones", since you don't need to provide handsets and credit card readers.
I don't think that adding X-headers to a message can really be called "forging" -- an MUA has every right in the world to put X-headers into messages it sends.
If an MUA is going to act on X-headers it had better be circumspect about doing so. Especially if it didn't put them in the message and dosn't have any idea who did...
Outcrap^H^H^H^Hlook tries to decode a message as an uuencoded attachment as soon as a message body line starts with "begin ". Feel free to think of the ramifications of that. (And yes, that's not "Header". That's "body", i.e. text supposed to be read by the recipient.)
It also tries to interpret various headers as metadata related to the message. This might make sense if the only emails it did this to were ones already in its message store, it might even make sense if it only did this with messages it can verify came from within an intranet. But doing this with random emails from the Internet is utterly stupid. Let alone that this appears to involve another Windows "feature" which has zero utility for many users in the first place.
If you can get your high horse to slow down long enough to step off it for a minute or two, you could install any of a zillion open source tools to modify your headers as messages pass in/out of your network, solving the problem and allowing you to use any MUA you please.
Which, if people want to use an MUA which uses X- headers for metadata they probably should have been using in the first place. Unless the MUA is written with an algorithm with says "if that email has just arrived from the Internet, then ignore the metadata."
The thing is, Moffit writes headers that abuse those headers -- and the X-* headers in question are only used by Outlook & Outlook Express (stuff like X-Message-Flag: Comment).
Except that he isn't "abusing" them. It's actually the MUA which is being daft in attempting to interpret arbitary data. Whilst there may be some sense in an MUA interpreting X- headers on mail it has previously processed (or obtained from a trusted source) doing this with random stuff from the Internet is just plain daft. Even if there is a useful case for using these type of headers as metadata on an intranet you should at minimum strip them from incomming Internet mail (and probably outgoing too.) This appears to be just another example of Microsoft software where a "feature" which most people don't even need is included (and enabled) by default and where this same "feature" involves treating unverified data from an unknown source as meaningful. The only unusual bit is that this one dosn't compromise the security of the machine in question. This isn't a "bug" it's poor design.
I'm sorry, but that's just stupid. If you have something that really needs to be a webpage (which I highly doubt) then you can send a webpage as an attachment, and explain why you are sending that in the email body.
Or even put the webpage on a webserver and send an email with the URL in angle brackets.
I would like to see a limited subset of HTML used for e-mail.
What makes more sense is to have a markup standard which can be easily understood by people. But which can also be interpreted by software. HTML with all its angle brackets is not easy for humans to follow. What's needed is a simple and lightweight type of markup. Like the one used for well over a decade for usenet postings...
But HTML doesn't add much overhead - a few dozen characters of headers and trailers, plus however much decorative formatting you want to add.
If you were writing hand crafted HTML that might be the case. But mechanically generated HTML, whatever kind of program is generating it is very often full of redundant tags. Because the algorithms used are often very simplistic and no attempt is made to optimise the output. Either for size or to a state of being easy for a human to understand it directly. IMHO it makes more sense to have human readable markup and allow for the possibility of a machine interpreting it than to have machine readable markup which a human has little chance of easily understanding.
1) It adds little or no value. Okay, so you feel that you can format the mail more readably using HTML. I find that I can make mails perfectly readable without it, so for me, it adds no value.
It's quite possible for someone to use HTML to make an email less readable than it would otherwise be. Espcially since machine generated HTML is often very hard for someone to follow. Let's say someone has their email sent to a standard mobile phone as SMS. If it's plain text they can easily read it, if it is stuffed full of redundant HTML tags then it is going to be very hard to read.
After all, there are a lot of websites out there that only work with IE/Windows. If someone think they can afford to ditch all windows users, feel free to do so...
Wonder how many of these are like the Dutch train website. Someone who knows what they are doing can fix them to work with any browser within a short time. Of course the fixed used here is probably illegal in places such as the USA.
Outlook is merely a tool, and it has many freely available alternatives, any of which can read messages containing lines that begin with the word 'begin'.
Then we have managers who have lost sight of the fact that it is just a tool. Instead seek creative ways to justify using Microsoft stuff for reasons which sound more like fashion statements than objectivly sound justifications.
That's what multipart/alternative is for -- read the spec. RFC 2046. You can write your email in Word, Illustrator, PDF or even TeX if you like, provided that your mail editor supports multipart/alternative correctly. It's polite to provide multiple representations -- eg. plain text, HTML, and El Weirdo File Format in the same message -- for downlevel clients.
There is nothing to ensure that the different versions actually are the same message though. You could quite easily have a text email with some HTML intended to work as malware...
Two copies of the message, one in plain text and the other with markup makes perfect sense to me -- because, frankly, color and formatting can help a LOT when it comes to getting your point across. Heck, even the original VT52 terminal creators recognized this -- no color, but the ability to do certain kinds of markup (underline, bold, inverse).
In which case it would make more sense to have a system of markup which is human readable. Then if the software supports displaying the message differently it can do that. If it dosn't then someone reading the message can see that there is some kind of markup of the text. Maybe even something like *bold* _underline_ #italic#, etc.
Don't you see the problem? Look at all the overhead that's tacked on because some marketing bozo wants his email to look 'pretty'.
Whilst adding nothing to the content.
Sending two copies of the same message, one in plain text and the other with tons of markup seems a bit ridiculous to me.
Anyone can read the text anyway, so why not just send that. The quoted-printable ie also redundant too. Remember also that if someone wanted to be nasty they could use this technique to send 2 (possibly more) completly different messages in the same email.
Maybe there should be a required netiquette section for any class on how to use a computer.
Especially covering how to reply to emails and follow up usenet posts. SOmething many OE users appear to have big trouble with.
Those users expect me to be able to read their Word format files without complaint. (Like I am going to pay almost $400 for a word processor for 1-2 documents a week.)
Though the free tools for looking at these might show you some interesting "extras" the senders didn't think they were sending...
They expect that I read their html formatted mail with bizzare IE-only extensions.
What proportion of the time do these fancy formats actually add anything to the content of the email. Even when they do are they the best way to do this?
My method of dealing with people who send Word documents is to return the favor by sending them Star Office format. It is amazing how much they complain about it. They expect me to install a very expensive package, but are totally unwilling to install something that costs them next to nothing. ($50 if they buy the boxed version.)
This sums it up very well Microsoft (and their supporters) expect everyone to do what they want. You can't negotiate with them, because they won't offer any "concessions" in return for any you make.
Outlook has it's own crappy database format. It puts all of your mail into one huge binary file. As per the usual M$ deception it displays a tree of that file's contents in a way that makes you think you have put them into directories and have a well ordered mail system.
Why do application writers go to all this trouble to make a psudo filesystem? When the operating system already provides one.
Mozilla developers recieve a bug report about a page not rendering correctly. They say "We followed the standards, get the page to change". Then the Page maintainer says, "It works in everything else, why should I change it?"
The problem is that in this situation it's not unknown for the page maintainer to actually mean "it works with the one browser I use". Because they don't have the first clue about how to test it with various browsers, let alone against the standards...
Which will probably end up mangled in the same way that dash,dash,space gets mangled by OE. Most likely most things which cause OE trouble cannot (easily) be generated using OE.
Anyway, the time will come when I'm the one to post results. I'll use Gnumeric, I think. I have been toying with the idea of actually posting a Gnumeric XML file to the list
Be sure to remember to ensure that the name ends in.XLS
Slashdot Mirror
IMO, they forfeited their rights the moment the lied to the United States of America (ie: To the judges face).
Yet in this case it's the judge who was criticiseed for saying "these arn't nice people".
But everyone is innocent until proven guilty, aren't they?
Unless they are pawns to distract attention away from utter failure of government to do its job.
How do you figure you can convert fossil fuel into methanol, or ANY other alchohol for that matter? Methanol is wood-alchohol.
Methanol is simply methane with an oxygen atom wedged in between one of the hydrogens and the carbon. Alcohols are hydrocarbons where you have an OH group joined to a carbon.
For industrial scale chemistry scaling up a "lab" can be easier than using micro organisms.
With all that good information, I was surprised you didn't mention antifreeze. Years ago, antifreeze was made with ethanol. Farmers put antifreeze in their tractor tires to help keep them from having to refill the tires every time the weather changes.
There is also another alcohol used in anti-freeze. This is ethelene glycol or ethan-1-2-ol, considerably more toxic than either ethano or methanol.
but it seems to me that the most exciting aspect of this emerging technology is the fact that it is green! plugging into an existing electrical outlet may seem convenient and clean but how much carbon dioxide was pumped into the atmosphere to produce those watts?
What actually matters is how much of the carbon dioxide is from "fossil carbon". Burning wood is more "green" than burning coal. Also you can probably make methanol from crude oil, which isn't very green at all.
Perhaps you're thinking of the ban on cell phones? That has nothing to do with safety. A cell uses up bandwidth on every node that's in line-of-site. So someone in the air strains the system more than someone on the ground. If passengers were allowed to use their phones, local systems would get saturated every time a plane flies over them.
Unless you install a cell in the aircraft... Which is probably less kit than "Sky phones", since you don't need to provide handsets and credit card readers.
Ah, but Weird Al can't release the parodies without permission from the song's owner.
IIRC he could but dosn't. Also heard that he seeks permission from the writer and/or signer even if they are not the current copyright holder.
I don't think that adding X-headers to a message can really be called "forging" -- an MUA has every right in the world to put X-headers into messages it sends.
If an MUA is going to act on X-headers it had better be circumspect about doing so. Especially if it didn't put them in the message and dosn't have any idea who did...
Outcrap^H^H^H^Hlook tries to decode a message as an uuencoded attachment as soon as a message body line starts with "begin ". Feel free to think of the ramifications of that. (And yes, that's not "Header". That's "body", i.e. text supposed to be read by the recipient.)
It also tries to interpret various headers as metadata related to the message. This might make sense if the only emails it did this to were ones already in its message store, it might even make sense if it only did this with messages it can verify came from within an intranet. But doing this with random emails from the Internet is utterly stupid. Let alone that this appears to involve another Windows "feature" which has zero utility for many users in the first place.
If you can get your high horse to slow down long enough to step off it for a minute or two, you could install any of a zillion open source tools to modify your headers as messages pass in/out of your network, solving the problem and allowing you to use any MUA you please.
Which, if people want to use an MUA which uses X- headers for metadata they probably should have been using in the first place. Unless the MUA is written with an algorithm with says "if that email has just arrived from the Internet, then ignore the metadata."
The thing is, Moffit writes headers that abuse those headers -- and the X-* headers in question are only used by Outlook & Outlook Express (stuff like X-Message-Flag: Comment).
Except that he isn't "abusing" them. It's actually the MUA which is being daft in attempting to interpret arbitary data. Whilst there may be some sense in an MUA interpreting X- headers on mail it has previously processed (or obtained from a trusted source) doing this with random stuff from the Internet is just plain daft.
Even if there is a useful case for using these type of headers as metadata on an intranet you should at minimum strip them from incomming Internet mail (and probably outgoing too.)
This appears to be just another example of Microsoft software where a "feature" which most people don't even need is included (and enabled) by default and where this same "feature" involves treating unverified data from an unknown source as meaningful. The only unusual bit is that this one dosn't compromise the security of the machine in question.
This isn't a "bug" it's poor design.
I'm sorry, but that's just stupid. If you have something that really needs to be a webpage (which I highly doubt) then you can send a webpage as an attachment, and explain why you are sending that in the email body.
Or even put the webpage on a webserver and send an email with the URL in angle brackets.
I would like to see a limited subset of HTML used for e-mail.
What makes more sense is to have a markup standard which can be easily understood by people. But which can also be interpreted by software. HTML with all its angle brackets is not easy for humans to follow. What's needed is a simple and lightweight type of markup. Like the one used for well over a decade for usenet postings...
But HTML doesn't add much overhead - a few dozen characters of headers and trailers, plus however much decorative formatting you want to add.
If you were writing hand crafted HTML that might be the case. But mechanically generated HTML, whatever kind of program is generating it is very often full of redundant tags. Because the algorithms used are often very simplistic and no attempt is made to optimise the output. Either for size or to a state of being easy for a human to understand it directly.
IMHO it makes more sense to have human readable markup and allow for the possibility of a machine interpreting it than to have machine readable markup which a human has little chance of easily understanding.
1) It adds little or no value. Okay, so you feel that you can format the mail more readably using HTML. I find that I can make mails perfectly readable without it, so for me, it adds no value.
It's quite possible for someone to use HTML to make an email less readable than it would otherwise be. Espcially since machine generated HTML is often very hard for someone to follow. Let's say someone has their email sent to a standard mobile phone as SMS. If it's plain text they can easily read it, if it is stuffed full of redundant HTML tags then it is going to be very hard to read.
After all, there are a lot of websites out there that only work with IE/Windows. If someone think they can afford to ditch all windows users, feel free to do so...
Wonder how many of these are like the Dutch train website. Someone who knows what they are doing can fix them to work with any browser within a short time.
Of course the fixed used here is probably illegal in places such as the USA.
Outlook is merely a tool, and it has many freely available alternatives, any of which can read messages containing lines that begin with the word 'begin'.
Then we have managers who have lost sight of the fact that it is just a tool. Instead seek creative ways to justify using Microsoft stuff for reasons which sound more like fashion statements than objectivly sound justifications.
That's what multipart/alternative is for -- read the spec. RFC 2046. You can write your email in Word, Illustrator, PDF or even TeX if you like, provided that your mail editor supports multipart/alternative correctly. It's polite to provide multiple representations -- eg. plain text, HTML, and El Weirdo File Format in the same message -- for downlevel clients.
There is nothing to ensure that the different versions actually are the same message though. You could quite easily have a text email with some HTML intended to work as malware...
Two copies of the message, one in plain text and the other with markup makes perfect sense to me -- because, frankly, color and formatting can help a LOT when it comes to getting your point across.
Heck, even the original VT52 terminal creators recognized this -- no color, but the ability to do certain kinds of markup (underline, bold, inverse).
In which case it would make more sense to have a system of markup which is human readable. Then if the software supports displaying the message differently it can do that. If it dosn't then someone reading the message can see that there is some kind of markup of the text. Maybe even something like *bold* _underline_ #italic#, etc.
Don't you see the problem? Look at all the overhead that's tacked on because some marketing bozo wants his email to look 'pretty'.
Whilst adding nothing to the content.
Sending two copies of the same message, one in plain text and the other with tons of markup seems a bit ridiculous to me.
Anyone can read the text anyway, so why not just send that. The quoted-printable ie also redundant too. Remember also that if someone wanted to be nasty they could use this technique to send 2 (possibly more) completly different messages in the same email.
Maybe there should be a required netiquette section for any class on how to use a computer.
Especially covering how to reply to emails and follow up usenet posts. SOmething many OE users appear to have big trouble with.
Those users expect me to be able to read their Word format files without complaint. (Like I am going to pay almost $400 for a word processor for 1-2 documents a week.)
Though the free tools for looking at these might show you some interesting "extras" the senders didn't think they were sending...
They expect that I read their html formatted mail with bizzare IE-only extensions.
What proportion of the time do these fancy formats actually add anything to the content of the email. Even when they do are they the best way to do this?
My method of dealing with people who send Word documents is to return the favor by sending them Star Office format. It is amazing how much they complain about it. They expect me to install a very expensive package, but are totally unwilling to install something that costs them next to nothing. ($50 if they buy the boxed version.)
This sums it up very well Microsoft (and their supporters) expect everyone to do what they want. You can't negotiate with them, because they won't offer any "concessions" in return for any you make.
Outlook has it's own crappy database format. It puts all of your mail into one huge binary file. As per the usual M$ deception it displays a tree of that file's contents in a way that makes you think you have put them into directories and have a well ordered mail system.
Why do application writers go to all this trouble to make a psudo filesystem? When the operating system already provides one.
Mozilla developers recieve a bug report about a page not rendering correctly. They say "We followed the standards, get the page to change". Then the Page maintainer says, "It works in everything else, why should I change it?"
The problem is that in this situation it's not unknown for the page maintainer to actually mean "it works with the one browser I use". Because they don't have the first clue about how to test it with various browsers, let alone against the standards...
Actually, multipart/alternative was meant to facilitate exactly the latter.
Except there is nothing to ensure that the alternatives are even the same message.
It should be begin with two spaces after it.
Which will probably end up mangled in the same way that dash,dash,space gets mangled by OE. Most likely most things which cause OE trouble cannot (easily) be generated using OE.
Anyway, the time will come when I'm the one to post results. I'll use Gnumeric, I think. I have been toying with the idea of actually posting a Gnumeric XML file to the list
.XLS
Be sure to remember to ensure that the name ends in