Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!ukma!david From: david@ms.uky.edu (David Herron -- Resident E-mail Hack) Newsgroups: comp.mail.misc Subject: Re: Survey on damage by mailers. Message-ID: <7754@g.ms.uky.edu> Date: Sun, 22-Nov-87 23:52:05 EST Article-I.D.: g.7754 Posted: Sun Nov 22 23:52:05 1987 Date-Received: Wed, 25-Nov-87 06:34:42 EST References: <408@minya.UUCP> Reply-To: david@ms.uky.edu (David Herron -- Resident E-mail Hack) Organization: U of Kentucky, Mathematical Sciences Lines: 78 In article <408@minya.UUCP> jc@minya.UUCP (John Chambers) writes: >Hello. I'm interested in characterizing the sorts of damage that the >existing electronic mail systems can do to mail as they move it about. > > 1. Any occurrence of the string "\nFrom " has '>' inserted before > the 'F'. Actually, the "From " line at the beginning of the file is a misfeature (in this day and age ... when they came up with mail back then they weren't connected to the arpanet, rfc822 hadn't been written, and all sorts of fun things). > 2. If the string "\n.\n" occurs, the tail end of the file (starting > at the '.') is discarded. geeee ... >In addition, I know of mailers that do the following: > > 3. High-order bits are turned off (or set to parity). > 4. Null bytes are dropped. eh? both of those things aren't part of normal ascii text. Why would you expect a system which is designed for passing normal ascii text to do something reasonable with strange things. If you wanna do something like this then uuencode the file before mailing it. > 5. If a backspace occurs, it and the preceding character are deleted. > 6. ASCII tabs are expanded to some number of spaces. Weeeell... my comment above sort-of counts here. Also, different operating systems treat tabs in different ways. There is one OS around which sets tab stops at 10 columns rather than 8. Also, for some reason tabs MUST be expanded with mail (I dunno why ... it simply must). I have a vague memory that the system in question is Multics, but may be mistaken. 7. Prepending "host!" to the From: lines of mail passing through the site and going out through UUCP. This is a problem because it creates unreplyable mail. For instance, we are on the mtxinu-users@emory.edu mailing list. Before we joined the Internet we were getting our mail from the list via uucp. The mail would arrive here with headers like: From: emory!someone@utah.edu And the From: should have just been "someone@utah.edu". Depending on how we interpret the address, it will behave differently. I suppose that the people at emory wanted us to interpret ! first. However we're running MMDF and it's fairly tightly conformant to RFC-822. It'll interpret the @ first. So the message trundles off to utah.edu who is told to deliver the mail to emory!someone, which is almost certainly not right because it'll cause the mail to be delivered to Georgia! Note that I'm only mentioning the problem at emory because it was the first one which came to mind. Many sites have this problem ... It's a severe problem which should be fixed. 8. Truncation of long lines. For instance, mail on BITNET is 80 column PUNCH files sent to people's virtual reader. 9. Silent discarding (or any other sort of discarding) of mail which is "too long". SendMail has a limit (configurable) of message size ... it's usually set to something like 100K. BUT the mail system on the main instructional system here has a limit of 200 lines. (!) Further, it drops the message silently if it's too long. One of the common things to do here is print files at cluster sites by mailing them from a unix machine to "printer-name@ukpr.bitnet". It works and happens to be fairly fast ... however, if someone isn't careful the file could be too long and you'd never know it. -- <---- David Herron -- Resident E-Mail Hack <---- or: {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET <---- "The market doesn't drop hundreds of points on a normal day..." -- <---- Fidelity Investments Corporation