Are the interwebz to blame for typos?
August 11, 2004 7:30 AM Subscribe
Can the Internet introduce typos into a text-only email? >>
I sent a plain text email (not HTML) to a list of a few thousand of my company's clients/prospects. One of them sent back a copy of the message he received, and of about 500 words, there were six or seven that were typos -- either randomly repeated characters (eexpect) or in one case, a word with a space inserted into the middle of it. The original email contained none of these errors.
These seem to me like errors that might be introduced by a slow connection with many dropped packets, and I'm thinking maybe the user got the message on a wireless device that could be to blame...anyone ever seen this or have any thoughts?
I will check my own wireless device's version of this message, but in the meantime, thought I'd check in here.
I sent a plain text email (not HTML) to a list of a few thousand of my company's clients/prospects. One of them sent back a copy of the message he received, and of about 500 words, there were six or seven that were typos -- either randomly repeated characters (eexpect) or in one case, a word with a space inserted into the middle of it. The original email contained none of these errors.
These seem to me like errors that might be introduced by a slow connection with many dropped packets, and I'm thinking maybe the user got the message on a wireless device that could be to blame...anyone ever seen this or have any thoughts?
I will check my own wireless device's version of this message, but in the meantime, thought I'd check in here.
it's unlikely that there's an error from noise in transmission, because they're supposed to be guaranteed protocols. much more likely is that there's some stupid filter replacing "bad" words with "clean" equivalents, or a bug in someone's code (probably in the email handling - an error in the network stack is much less likely because it would seriously screw up their network if it was as unreleiable as this).
or what the guy above said, really (plus a possible content filter)
posted by andrew cooke at 8:05 AM on August 11, 2004
or what the guy above said, really (plus a possible content filter)
posted by andrew cooke at 8:05 AM on August 11, 2004
Lots of mail transports tinker with headers and such, but the message body is considered a bit more sacred.
Minor quibble: except for "From" at the beginning of a line, which is changed to ">From" so it doesn't look like an envelope header and break the standard mbox format.
Other than that, yeah, what mragreeable said.
posted by nicwolff at 8:30 AM on August 11, 2004
Minor quibble: except for "From" at the beginning of a line, which is changed to ">From" so it doesn't look like an envelope header and break the standard mbox format.
Other than that, yeah, what mragreeable said.
posted by nicwolff at 8:30 AM on August 11, 2004
I've received replies to emails that, when quoting my original message, changed apostrophes into commas, so I wouldn't be surprised that other things get changed too.
I noticed it happens to emails sent to people on AOL.
posted by jazon at 8:32 AM on August 11, 2004
I noticed it happens to emails sent to people on AOL.
posted by jazon at 8:32 AM on August 11, 2004
I've received replies to emails that, when quoting my original message, changed apostrophes into commas, so I wouldn't be surprised that other things get changed too.
This is possibly because you used curly apostrophes in the original message. A character set mismatch can change these into characters that look like commas but actually are not. The actual body of the e-mail has not been changed, only the way that the text is displayed.
posted by kindall at 8:42 AM on August 11, 2004
This is possibly because you used curly apostrophes in the original message. A character set mismatch can change these into characters that look like commas but actually are not. The actual body of the e-mail has not been changed, only the way that the text is displayed.
posted by kindall at 8:42 AM on August 11, 2004
Check your list serving software. I know that here our list server software doesn't filter out words but it will silently route messages with certain words to the bit bucket.
For instance, if an email contains the word cancel it gets tossed out with no response to the original sender. This is loads of fun when you're designing a set of circuits that lets you transmit information across a single wire from both ends simultaneously. Part of the design is a canceller and it cancels the local signal from the local port. I ended up getting yelled at for not sending progress reports because they were all canned!
So I'd check if for instance rather than tossing messages it translates cancel to can-cel and such.
posted by substrate at 8:51 AM on August 11, 2004
For instance, if an email contains the word cancel it gets tossed out with no response to the original sender. This is loads of fun when you're designing a set of circuits that lets you transmit information across a single wire from both ends simultaneously. Part of the design is a canceller and it cancels the local signal from the local port. I ended up getting yelled at for not sending progress reports because they were all canned!
So I'd check if for instance rather than tossing messages it translates cancel to can-cel and such.
posted by substrate at 8:51 AM on August 11, 2004
except for "From" at the beginning of a line
i hate that! is it exim that does it? is there any other solution (i use maildir, so i don't need it, yet it appears even in messages i send to myself)?
posted by andrew cooke at 9:13 AM on August 11, 2004
i hate that! is it exim that does it? is there any other solution (i use maildir, so i don't need it, yet it appears even in messages i send to myself)?
posted by andrew cooke at 9:13 AM on August 11, 2004
I see this happen when I copy-n-paste stuff from a Word document where someone has edited the original, but someone else has not tracked the changes and accepted them. So while I see the pretty text, the edits are still floating around and when I paste the stuff into a text field the unaccepted changes are still there.
Just a thought.
posted by terrapin at 11:26 AM on August 11, 2004
Just a thought.
posted by terrapin at 11:26 AM on August 11, 2004
This sounds just like a problem I've seen with HTML and Netscape. One of the marketing people where I work would always call me with these typos -- repeated characters and extra spaces -- that would only show up on her screen. Simply refreshing the page would cause the typos to disappear -- so it was definitely on the client side. Eventually, I narrowed the source of the error down to her using Netscape 4.
Maybe these people are using Netscape Composer (or whatever their wonky e-mail client was called), or it might be an antiquated AOL client that uses Netscape's text rendering engine.
posted by eatitlive at 11:29 AM on August 11, 2004
Maybe these people are using Netscape Composer (or whatever their wonky e-mail client was called), or it might be an antiquated AOL client that uses Netscape's text rendering engine.
posted by eatitlive at 11:29 AM on August 11, 2004
i hate that! is it exim that does it? is there any other solution
All non-broken mail delivery agents do it - it's part of the BSD mbox file format "standard", which isn't defined anywhere but is canonical nonetheless. There is another solution - a "Content-Length" header - but if jwz doesn't like it that's bad enough for me.
Technically, it only has to be done when finally delivering to an mbox-formatted mailbox file, but it should generally be done as early as possible in the mail-sending process, so that if something cryptographically signs or analyzes the message body along the way it doesn't get changed after that.
Then, you might ask, why not have the mail-reading software turn ">From" back to "From"? Because there's no robust way to tell if it was intentional - better to mangle mail once than twice.
posted by nicwolff at 4:49 PM on August 11, 2004
All non-broken mail delivery agents do it - it's part of the BSD mbox file format "standard", which isn't defined anywhere but is canonical nonetheless. There is another solution - a "Content-Length" header - but if jwz doesn't like it that's bad enough for me.
Technically, it only has to be done when finally delivering to an mbox-formatted mailbox file, but it should generally be done as early as possible in the mail-sending process, so that if something cryptographically signs or analyzes the message body along the way it doesn't get changed after that.
Then, you might ask, why not have the mail-reading software turn ">From" back to "From"? Because there's no robust way to tell if it was intentional - better to mangle mail once than twice.
posted by nicwolff at 4:49 PM on August 11, 2004
luriete: you should contact your server admin. That should never happen on a modern system. Is it possible you are using ascii mode (the default for some older clients) to transfer files with multibyte or otherwise complex characters? This can probably cause some distortions (though at any point in the file). FTP is TCP based so the protocol has built in error correction, and what you send, the server should receive.
Bitnet is a different story, as it probably didn't have the kind of error correction that TCP has.
posted by advil at 11:57 PM on August 11, 2004
Bitnet is a different story, as it probably didn't have the kind of error correction that TCP has.
posted by advil at 11:57 PM on August 11, 2004
This thread is closed to new comments.
But, that said, it's actually pretty unlikely that an email travelling over any modern internet mail-delivery protocol would arrive with its body corrupted. Lots of mail transports tinker with headers and such, but the message body is considered a bit more sacred.
Error-detection is built into TCP/IP at the protocol level, so, according to spec, it would be impossible for a user-mode app to ever see a corrupt packet. I've never seen a corrupt email on a wireless device, and if I did, I'd expect to see corrupt web pages and images just as frequently.
It seems a bit more likely that a user or his email client did something odd in the process of replying. Or your software did something screwy right before it send the message. To put it another way, a bad TCP/IP stack or mail relay would be a fairly big deal, since those tend to be extensively tested and widely deployed. A bug in a user's mail agent would be, well, mundane.
Have no other people replied to the letter? Are you friends with any recipients where it wouldn't be awkward to ask them to forward it back to you to see if they also received it that way?
posted by mragreeable at 8:01 AM on August 11, 2004