Henning Kiel wrote:
| On Tue, 16 Jan 2001, Phil Taylor wrote:
| > John Chambers wrote:
| > >Ain't email wonderful?
| > Yeah. It's too late to add an official end-of-tune marker now, but a
| > blank line followed by a full stop (period to you) should sort it without
| > causing problems elsewhere.
True, but this can itself cause problems. A line consisting
of just a period is used by SMTP (Internet) mail as an
end-of-message. The protocol has a foolproof way of dealing
with this, of course, but we have had a rush of companies
recently who can't be bothered to implement the protocol
correctly. [Insert gratuitous Microsoft/Apple/AOL bash
here.] There have been sporadic reports of files truncated
at single-period lines. Yes, they're bugs. Knowing that
doesn't help get the mail through.
| Talking about weird mail servers:
| Some mail server change a line beginning with "from" to ">from".
This is another version of the same class of bug. The
earliest unix mailers used a line starting with "From " as
a message separator. So they needed a way to pass such
lines within the text, and they chose to insert the '>' on
the sending end, and strip it out at the receiving end. But
we now have lots of email software that fails to undo this
insertion, with the results that you see.
Lots of people have since realized that these message
separator schemes were mistakes, and totally unnecessary.
It's a lot more practical and efficient to handle each
message as a separate file, and then you don't need such
separators. But as usual, we are forever stuck with
re-implementations of the original mistake, often with the
explanation that "Unix does it that way". This is nonsense,
of course; Unix doesn't care about or constrain an
application's file formats. But again, knowing that doesn't
fix someone else's buggy software.
The problems caused by ABC's tune terminator is yet another
example of the same mistake. It seems innocent at first,
but examples like Frank's difficulty getting his tune
across without a weird "coda" at the end shows why it was a
mistake. We've wasted far more time dealing with such
problems than would have ever been used to implement an
explicit end-of-tune token. Of course, the simplest scheme
would be to say "end of file is end of tune", and use the
concept of a directory to join lists of tunes. But this is
clearly not acceptable to a lot of people, so we have all
the usual problems of dealing with a single file that
contains a set of what are logically separate files.
Schemes for doing this correctly are known, and in fact
ABC's scheme would work fine, if we didn't have email
software around shooting it down.
| Let's see if it happens again:
| This is
| from my point of view.
It got here just fine. Here are two more test lines that
might get this message truncated, followed by another line
of text:
>From trillian.mit.edu!jc
.
If you didn't get this line, let me know. ;-)
--
voluntocracy n
1. governance by those who do the work.
2. the volunteers who do the work.
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
