🚀 go-pugleaf

In article <1990Dec31.013538.9473@Think.COM> barmar@think.com (Barry Margolin) writes:
>In article <1990Dec31.004055.10335@cbnewsk.att.com> hansen@pegasus.att.com (Tony L. Hansen) writes:
>>System V release 4 mail is completely content transparent. As long as the
>>transport media is capable of handling the mail, SVr4 mail will be able to
>>get it to you unchanged.

>What does it do when sending textual mail to a system that doesn't use
>ASCII encoding, e.g. an IBM mainframe, or to a system with a different
>newline convention (e.g. CRLF rather than LF)?  SMTP places restrictions on
>the characters that may appear in a message to support automated
>translation during the transfer process.

But the automated translation can currently only work with text while
many mailers are now capable of attaching arbitrary binary data to
messages.  Depending on the type of the content, a different transformation
(or none) may be desired.  Assuming that the non-textual portions are
encapsulated with "Content-Type:" and "Content-Length:" headers, it
would be easy for the transport to determine what, if any, transformation
to use.  In addition, an optional "Encoding-Method:" header can allow
temporary transformations to meet the character set requirements of the
transports.  If the sending program had a way to determine the capabilities
of the recipient, encoding could be done on-the-fly, using uuencode or
atob, and thus only done where necessary (but I don't know of anyone
actually doing this yet...).

These issues are going to have to be addressed for messages originating
on X.400 systems anyway, so why not try to do it efficiently by adding
the equivalent functionality to SMTP/uucp mailers?

Les Mikesell
  les@chinet.chi.il.us