🚀 go-pugleaf

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     <david@ms.uky.edu>
<---- or:                {rutgers,uunet,cbosgd}!ukma!david, david@UKMA.BITNET
<---- "The market doesn't drop hundreds of points on a normal day..." --
<---- 		Fidelity Investments Corporation