You don't understand correctly, I'd suggest you read the RFCs regarding SMTP.
When an SMTP session is started, two pieces of data MUST be sent before the message. Those fields amount to "from" and "to" fields and are sent sequentially by "MAIL FROM:" and "RCPT TO:" fields in that order. The "from" portion may be forged, but the "to" field must be correct as it is the address that the server delivers the message to or uses for further forwarding/processing. If the server does not recognize the to field, it will usually return a simple error (550) and may the session at that point. Also, if the server does not like the "from" field (for any reason you can program for), an error can be returned and the session ended.
Again, this is all before the body of the message is sent with the "DATA" command, thus saving potentially megabytes of data transfer. This does note require the "return" address to be correct, as this is happening at the time of delivery and the servers are talking directly about the message.
The body of a message may (but is not required to) contain other headers such as subject, to, from, received, date, content-type, message-id etc, but these fields in the data area have nothing to do with delivery as far as the receiving server is concerned.
Now.. it's possible to configure a server to operate differently, accepting all mail blindly, buffering the messages, then later figuring out where they should go.
My personal server takes the "MAIL FROM:" data and parses it, checking that the remote domain exists and there is an SMTP server that accepts mail for that domain. If any of those checks fail, I return a "not available" error (421) and close the connection.
Isn't this similar to that failed mission (the one with the english/metric issue or something like that) where two probes were to crash in to the planet, then drill down some distance to take samples?
It's also true that a significant portion of the wealthiest people in the country did not graduate from a university. A good idea and determination will win over pure smarts any day. If you're less intelligent you can easily hire smart people to run the business. If you're not creative you can't easily hire people to give you ideas to start a company with. The wealthiest people in the U.S. are those who own(ed) their own business. You don't get filthy rich punching a time clock and collecting a paycheck from your employer every other week.
Not really. If you listen to these calls frequently you'll hear that duplicate questions are common. Sometimes a person comes on late, they are talking with someone else, or they don't actually listen to the call until they hear their name called.
Re:eeerh... i hate to say this
on
X43-A on to Mach 10
·
· Score: 4, Informative
I went and did some research to post the actual ground speed in miles per hour of the ship traveling at mach 10 at 95,000 feet and I learned an interesting thing which astonished me.
Actually, until you get very high in the atmosphere the speed of sound stays relatively constant compared to the speed of sound at sea level. Pressure and density decrease, but so does temperature.
You can plug in some number in a calculator at http://www.grc.nasa.gov/WWW/K-12/airplane/soun d.ht ml
The actual ground speed number (assuming no head/tail wind) of travelling at mach 10 at 95,000 feet is 6,777MPH or 1.887 miles per second.
Up until now I, perhaps like most, though that since pressure decreases exponentially with altitude, that the speed of sound must also decrease at some constant, or at least predictable, rate with altitude. This was a real eye opener for me.
No, I certainly don't, unless what I hear is in a federally regulated quarterly conference call to talk about the earnings report and the near-term future of the company.
If Apple executives were to lie or materially misrepresent the facts during this call they could be held responsible in a court.
*sigh* You apparently haven't listened to the call, yet you think you know better what the tone of the answer is.
Listen to the call, that question was asked directly at least twice from two different analysts, on top of being addresses outright by Apple at the start of the call.
"Steve" did not utter these answers, and "Steve" was not on the call. I'm not saying he wasn't involved in predetermining the answers, but the answers are not his.
I'd also say the quote "The processor is the most critical factor" is deliberately ambiguous. It could mean "There aren't enough of them", it could mean "They run too hot".
That's a stretch at best, especially given the forthright answers to the situation by Apple so far.
When asked specifically if cooling was the issue holding up the iMac they said "no" in long winded way.
No.. supply issues are the problem. This was clearly asked and answered in the call.
Question from Steve Malinivich: "To continue on the PPC issue, there's been some suggestion on the web that you have a heating issue with iMac as well, are you saying that's not at all the problem and that its purely the availability of microprocessors?"
Answer: "Steve: The processor is the most critical factor."
They don't say that heat is not an issue at all, but they clearly state that processor supply is, as you say, at the heart. Once can easily see that heating, while perhaps a concern, is not what's causing the delay.
Yes. the entire recycling drive is based on lies. The first lie was that we were running out of landfill space. That, as it turn out when you look at the numbers, it patently false. The people who wrote the initial report even admit they made up the numbers.
A for the whole "dangerous stuff in the landfill" argument: any landfill built must comply with EPA regulations. That means they must be lined and monitored to not allow any leakage of water in to the underlying ground.
There is almost no reason used to support recycling that holds up to scientific or economic scrutiny.
While it is indeed true that there is a lot of money to be made in the recycling business, most all of that money to be made is in charging consumers to recycle instead of tossing things in the landfill.
With the exception of aluminum, most recycling programs would loose money if not for the fees charged to end users.
Projects of that size usually don't rely on promiseware by third parties, they look at what is available now and plan on using that or they rely on closely held partners to deliver on the timeline. We've already seen Longhorn's ship date slip several times, then we were told that significant portions would be removed to meet the last promise. How can you possibly make a 4-6 plan when MS's ship dates and promised functionality are a highly fluid target?
No... anyone working on a large Windows based project should be planning on using XP, and whatever add-ons they need to get or write to accomplish their task.
As far as Apple (or any company) removing functionality or breaking an API at a later date after the project has gone live: so what. If you've taken 4 years to implement a system, you're not going to be changing anything about the system until absolutely necessary. In a system that takes 4 years to design, build and test, even the most minor of changes will be analyzied, simulated, then run on a testbed for months before being taken live. There are systems out there that are running on Windows NT 4 SP1 because later service packs and OS updates break the system and it's not worth the time to change the system when everything is working fine as-is.
This is the case with the phones up to about 6 months ago. I've written them (Nextel) several times asking for firmware upgrades that allow "moods" or "situations" via menu selection. Each group setting would contain volumes for ringer, mail, alerts, direct-connect, etc. You'd set these presets up through the web site for older phones, or via a Java app on the newer phones.
You'd have "night time", "office", "meeting", etc. At night for example, all noises/alerts would be off except messages from a particular email address or with a certain title. "meeting" might have most alerts set to vibrate except for text messaging.
The newer models like the i7xx have these presets in the software and I'm seriously considering getting one of these phones. My main holdback at the moment is that I REALLY like having the full display visible all the time on my i1000+. On the newer phones one line, at most, is visible with the flip phone closed. And yes, I want the flip phone, I dislike the flat phones... I want the mic in front of my mouth, not by my cheek.
Well, the other thing I did was call the ethics complaint toll free number listed in their "terms of service". This number is for complaints about violations of the TOS. Nextel's TOS prohibit using their services to send UCA (unsolicited commercial advertisements) to or from their phones. In this case the web site or their email gateway were being used for that purpose and they (Nextel) refused to enforce their TOS. I've also sent a note to the FCC regarding the issue in hopes that they will require mobile carriers to implement mechanisms that allow paying customers to learn the origin of and control the acceptance of these unwanted UCAs.
The only two ways for a web site to limit anonymous message sending are:
1. By IP address 2. By cookie
The first is not feasible as a single IP may be shared by literally thousands of computers through a proxy or NAT device. You can't penalize the third or fourth person for trying to send me a message just because several others have already sent me messages. The second doesn't work since a script or even a browser can accept a cookie then discard it for the next go-around. I've written these scripts to auto-vote in web polls that use cookies in an attempt to limit me to one vote per poll per day. Good bye cookie, good bye limit.
Logging in to a web site to send a message defeats the purpose of instant messaging.
As in my case (any anyone with a Nextel phone and SMS) anyone can send an SMTP email to my telephone number @messaging.nextel.com and the contents of the email will be sent to my phone (within certain limits).
Yup... you look at the stamp they embossed with and their name and ID number. You then call or write to the city/county/state that provided the NP's seal and ask if that I.D. number and name match with what they have on file and the commission is current.
Of course, this assumes you know you can trust the person on the other end of your communication to no be the person claiming to be the notary, or to be in conspiracy with the claimed notary, or that the notary's seal hasn't been forged.
In the end there is no way to absolutely "prove" the identity of a person. People can lie, records can be altered/forged, officials can be bought. It all comes down to a percentage/degree of certainty and trust.
Driver's license, passport, etc. only prove who the person claimed to be when they presented themselves to receive those documents, not who they actually are.
But what does that really accomplish? It just gives the hackers more accounts to probe around and guess passwords for. When I log in to a machine I need to be root 98% of the time. Remembering two secure/random passwords is a hassle. I have a hard enough time adapting when I change the one password.
BTW: when I say "root" I don't use that as the username at all, it's been changed to something else. Yes that's a bit of a hassle, but it works. Pneumonic username and random password = a tough remote hack.
There are two ways to accomplish this, which ones work depend upon your Nextel services:
1. send an email to "phone number@messaging,nextel.com" 2. write a short script that interfaces directly with the Nextel web site and send the messages through the "send a message" page(s).
The interesting part comes when you have "two way text messaging" and can reply to a message with pre-determined replies sent along with the message. You can have your system send you a message with several options, in my case:
nodename: detected root login originating from IP address: xxx.xxx.xxx.xxx 1. Ignore 2. Authorize node 3. disconnect node 4. disconnect / ban node
I then choose a reply and send it back to the node from which it came. Via some scripting that watched incoming emails the node then takes the appropriate action. The "ignore" option is there because if the node does not receive a reply within 5 minutes, it sends the message again.
First the confusion: The article was written in November of 2003, 9 months ago. SMS has been available for at least 8 years (perhaps not under that name) so why does the article talk about "early adopters"?
Second, the shocked part:
I recently started receiving SMS spam on my Nextel phone. I've has SMS and standard email on the phone for at least 5 years and just recently started receiving junk messages on it. At least once a day I'd get some garbled text telling me to call some number in Seattle, WA to purchase a college degree. The thing that shocked me was that Nextel does not indicate the source of the message on the phone that received it, You just get the text and the date/time stamp it was received. I called customer service and technical support, both informed me that Nextel there is no way to track the source of such a message (this is blatantly false, they just don't bother to track it), and that there was no way to block such messages by sender. If I didn't want the messages I'd just have to turn off the service all together. That simply isn't an option as SMS is one of the ways I monitor my systems; ie: all root logins from anyplace other than approved machines get sent to my phone; important client messages get through on SMS when I have my ringer off at night, etc. In the end all they did was refund my monthly messaging fee.
I finally gave up, called the number that was listed in the messages and threatened criminal and/or civil action if I received any more messages on my cell phone from them.
I haven't received any more junk in the week since that call. In the end I guess I'm out the nickel it cost to call long distance for a minute.
I just can't understand how a company can charge you for incoming messages when they have no way for you to filter them or even know the source of the message. How could they not see anonymous on-way communication as a potential (likely) source of abuse?
SMS is frequently free to send. All the SMS services I've seen have a web interface at the carrier's web site. Anyone cans send a message through these web interfaces for free. It's a LOT easier for a spammer to figure out SMS addresses (almost always the phone number) than email addresses. A simple random number generator and a a script can send potentially thousands of messages a minute
there are no external firewire drives. There are (to my knowledge) no Firewire drives at all. People take standard ATA/IDE drives and use an ATA/Firewire bridge to connect them up externally and bypass the extremely limited cable length of ATA.
Slashdot Mirror
You don't understand correctly, I'd suggest you read the RFCs regarding SMTP.
When an SMTP session is started, two pieces of data MUST be sent before the message. Those fields amount to "from" and "to" fields and are sent sequentially by "MAIL FROM:" and "RCPT TO:" fields in that order. The "from" portion may be forged, but the "to" field must be correct as it is the address that the server delivers the message to or uses for further forwarding/processing. If the server does not recognize the to field, it will usually return a simple error (550) and may the session at that point. Also, if the server does not like the "from" field (for any reason you can program for), an error can be returned and the session ended.
Again, this is all before the body of the message is sent with the "DATA" command, thus saving potentially megabytes of data transfer. This does note require the "return" address to be correct, as this is happening at the time of delivery and the servers are talking directly about the message.
The body of a message may (but is not required to) contain other headers such as subject, to, from, received, date, content-type, message-id etc, but these fields in the data area have nothing to do with delivery as far as the receiving server is concerned.
Now.. it's possible to configure a server to operate differently, accepting all mail blindly, buffering the messages, then later figuring out where they should go.
My personal server takes the "MAIL FROM:" data and parses it, checking that the remote domain exists and there is an SMTP server that accepts mail for that domain. If any of those checks fail, I return a "not available" error (421) and close the connection.
But without a catch-all address the sender gets an error message before the message is even sent, thi saving bandwidth for other uses.
To accept ALL email, then figure out if it's real or not seems like a tremendous waste of time to me.
Isn't this similar to that failed mission (the one with the english/metric issue or something like that) where two probes were to crash in to the planet, then drill down some distance to take samples?
It's also true that a significant portion of the wealthiest people in the country did not graduate from a university.
A good idea and determination will win over pure smarts any day. If you're less intelligent you can easily hire smart people to run the business. If you're not creative you can't easily hire people to give you ideas to start a company with.
The wealthiest people in the U.S. are those who own(ed) their own business. You don't get filthy rich punching a time clock and collecting a paycheck from your employer every other week.
What competition?
Where are these hordes of all-in-one, elegantly styled, decked out wintel systems that the iMac competes with?
Not really. If you listen to these calls frequently you'll hear that duplicate questions are common. Sometimes a person comes on late, they are talking with someone else, or they don't actually listen to the call until they hear their name called.
I went and did some research to post the actual ground speed in miles per hour of the ship traveling at mach 10 at 95,000 feet and I learned an interesting thing which astonished me.
n d.ht ml
Actually, until you get very high in the atmosphere the speed of sound stays relatively constant compared to the speed of sound at sea level. Pressure and density decrease, but so does temperature.
You can plug in some number in a calculator at
http://www.grc.nasa.gov/WWW/K-12/airplane/sou
The actual ground speed number (assuming no head/tail wind) of travelling at mach 10 at 95,000 feet is 6,777MPH or 1.887 miles per second.
Up until now I, perhaps like most, though that since pressure decreases exponentially with altitude, that the speed of sound must also decrease at some constant, or at least predictable, rate with altitude. This was a real eye opener for me.
No, I certainly don't, unless what I hear is in a federally regulated quarterly conference call to talk about the earnings report and the near-term future of the company.
If Apple executives were to lie or materially misrepresent the facts during this call they could be held responsible in a court.
*sigh* You apparently haven't listened to the call, yet you think you know better what the tone of the answer is.
Listen to the call, that question was asked directly at least twice from two different analysts, on top of being addresses outright by Apple at the start of the call.
"Steve" did not utter these answers, and "Steve" was not on the call. I'm not saying he wasn't involved in predetermining the answers, but the answers are not his.
I'd also say the quote "The processor is the most critical factor" is deliberately ambiguous. It could mean "There aren't enough of them", it could mean "They run too hot".
That's a stretch at best, especially given the forthright answers to the situation by Apple so far.
When asked specifically if cooling was the issue holding up the iMac they said "no" in long winded way.
No.. supply issues are the problem. This was clearly asked and answered in the call.
Question from Steve Malinivich: "To continue on the PPC issue, there's been some suggestion on the web that you have a heating issue with iMac as well, are you saying that's not at all the problem and that its purely the availability of microprocessors?"
Answer: "Steve: The processor is the most critical factor."
They don't say that heat is not an issue at all, but they clearly state that processor supply is, as you say, at the heart. Once can easily see that heating, while perhaps a concern, is not what's causing the delay.
Is that a complaint about recycling in general?
Yes. the entire recycling drive is based on lies. The first lie was that we were running out of landfill space. That, as it turn out when you look at the numbers, it patently false. The people who wrote the initial report even admit they made up the numbers.
A for the whole "dangerous stuff in the landfill" argument: any landfill built must comply with EPA regulations. That means they must be lined and monitored to not allow any leakage of water in to the underlying ground.
There is almost no reason used to support recycling that holds up to scientific or economic scrutiny.
While it is indeed true that there is a lot of money to be made in the recycling business, most all of that money to be made is in charging consumers to recycle instead of tossing things in the landfill.
With the exception of aluminum, most recycling programs would loose money if not for the fees charged to end users.
Huh?
What will this "strong authentication" authenticate against?
You don't seem to be making much sense to me.
By like 96.5%.
less than 300 million out of over 6.4 billion.
Projects of that size usually don't rely on promiseware by third parties, they look at what is available now and plan on using that or they rely on closely held partners to deliver on the timeline.
We've already seen Longhorn's ship date slip several times, then we were told that significant portions would be removed to meet the last promise. How can you possibly make a 4-6 plan when MS's ship dates and promised functionality are a highly fluid target?
No... anyone working on a large Windows based project should be planning on using XP, and whatever add-ons they need to get or write to accomplish their task.
As far as Apple (or any company) removing functionality or breaking an API at a later date after the project has gone live: so what. If you've taken 4 years to implement a system, you're not going to be changing anything about the system until absolutely necessary. In a system that takes 4 years to design, build and test, even the most minor of changes will be analyzied, simulated, then run on a testbed for months before being taken live. There are systems out there that are running on Windows NT 4 SP1 because later service packs and OS updates break the system and it's not worth the time to change the system when everything is working fine as-is.
This is the case with the phones up to about 6 months ago. I've written them (Nextel) several times asking for firmware upgrades that allow "moods" or "situations" via menu selection. Each group setting would contain volumes for ringer, mail, alerts, direct-connect, etc. You'd set these presets up through the web site for older phones, or via a Java app on the newer phones.
You'd have "night time", "office", "meeting", etc.
At night for example, all noises/alerts would be off except messages from a particular email address or with a certain title. "meeting" might have most alerts set to vibrate except for text messaging.
The newer models like the i7xx have these presets in the software and I'm seriously considering getting one of these phones. My main holdback at the moment is that I REALLY like having the full display visible all the time on my i1000+. On the newer phones one line, at most, is visible with the flip phone closed. And yes, I want the flip phone, I dislike the flat phones... I want the mic in front of my mouth, not by my cheek.
Well, the other thing I did was call the ethics complaint toll free number listed in their "terms of service". This number is for complaints about violations of the TOS.
Nextel's TOS prohibit using their services to send UCA (unsolicited commercial advertisements) to or from their phones. In this case the web site or their email gateway were being used for that purpose and they (Nextel) refused to enforce their TOS.
I've also sent a note to the FCC regarding the issue in hopes that they will require mobile carriers to implement mechanisms that allow paying customers to learn the origin of and control the acceptance of these unwanted UCAs.
That is patently absurd.
The only two ways for a web site to limit anonymous message sending are:
1. By IP address
2. By cookie
The first is not feasible as a single IP may be shared by literally thousands of computers through a proxy or NAT device. You can't penalize the third or fourth person for trying to send me a message just because several others have already sent me messages.
The second doesn't work since a script or even a browser can accept a cookie then discard it for the next go-around. I've written these scripts to auto-vote in web polls that use cookies in an attempt to limit me to one vote per poll per day. Good bye cookie, good bye limit.
Logging in to a web site to send a message defeats the purpose of instant messaging.
As in my case (any anyone with a Nextel phone and SMS) anyone can send an SMTP email to my telephone number @messaging.nextel.com and the contents of the email will be sent to my phone (within certain limits).
Yup... you look at the stamp they embossed with and their name and ID number. You then call or write to the city/county/state that provided the NP's seal and ask if that I.D. number and name match with what they have on file and the commission is current.
Of course, this assumes you know you can trust the person on the other end of your communication to no be the person claiming to be the notary, or to be in conspiracy with the claimed notary, or that the notary's seal hasn't been forged.
In the end there is no way to absolutely "prove" the identity of a person. People can lie, records can be altered/forged, officials can be bought. It all comes down to a percentage/degree of certainty and trust.
Driver's license, passport, etc. only prove who the person claimed to be when they presented themselves to receive those documents, not who they actually are.
But what does that really accomplish? It just gives the hackers more accounts to probe around and guess passwords for. When I log in to a machine I need to be root 98% of the time. Remembering two secure/random passwords is a hassle. I have a hard enough time adapting when I change the one password.
BTW: when I say "root" I don't use that as the username at all, it's been changed to something else. Yes that's a bit of a hassle, but it works. Pneumonic username and random password = a tough remote hack.
There are two ways to accomplish this, which ones work depend upon your Nextel services:
1. send an email to "phone number@messaging,nextel.com"
2. write a short script that interfaces directly with the Nextel web site and send the messages through the "send a message" page(s).
The interesting part comes when you have "two way text messaging" and can reply to a message with pre-determined replies sent along with the message.
You can have your system send you a message with several options, in my case:
nodename: detected root login originating from IP address: xxx.xxx.xxx.xxx
1. Ignore
2. Authorize node
3. disconnect node
4. disconnect / ban node
I then choose a reply and send it back to the node from which it came. Via some scripting that watched incoming emails the node then takes the appropriate action. The "ignore" option is there because if the node does not receive a reply within 5 minutes, it sends the message again.
You can also do this with power/UPS alerts
First the confusion: The article was written in November of 2003, 9 months ago. SMS has been available for at least 8 years (perhaps not under that name) so why does the article talk about "early adopters"?
Second, the shocked part:
I recently started receiving SMS spam on my Nextel phone. I've has SMS and standard email on the phone for at least 5 years and just recently started receiving junk messages on it. At least once a day I'd get some garbled text telling me to call some number in Seattle, WA to purchase a college degree.
The thing that shocked me was that Nextel does not indicate the source of the message on the phone that received it, You just get the text and the date/time stamp it was received.
I called customer service and technical support, both informed me that Nextel there is no way to track the source of such a message (this is blatantly false, they just don't bother to track it), and that there was no way to block such messages by sender. If I didn't want the messages I'd just have to turn off the service all together.
That simply isn't an option as SMS is one of the ways I monitor my systems; ie: all root logins from anyplace other than approved machines get sent to my phone; important client messages get through on SMS when I have my ringer off at night, etc.
In the end all they did was refund my monthly messaging fee.
I finally gave up, called the number that was listed in the messages and threatened criminal and/or civil action if I received any more messages on my cell phone from them.
I haven't received any more junk in the week since that call. In the end I guess I'm out the nickel it cost to call long distance for a minute.
I just can't understand how a company can charge you for incoming messages when they have no way for you to filter them or even know the source of the message. How could they not see anonymous on-way communication as a potential (likely) source of abuse?
SMS is frequently free to send. All the SMS services I've seen have a web interface at the carrier's web site. Anyone cans send a message through these web interfaces for free.
It's a LOT easier for a spammer to figure out SMS addresses (almost always the phone number) than email addresses. A simple random number generator and a a script can send potentially thousands of messages a minute
there are no external firewire drives. There are (to my knowledge) no Firewire drives at all.
People take standard ATA/IDE drives and use an ATA/Firewire bridge to connect them up externally and bypass the extremely limited cable length of ATA.